linux-kernel - Re: [linux-dvb] [PATCH] Userspace tuner

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <37219a840709141220p543b0da9x53f48eabc1cfe8c9@mail.gmail.com>
Date:	Fri, 14 Sep 2007 15:20:51 -0400
From:	"Michael Krufky" <mkrufky@...uxtv.org>
To:	"Mauro Carvalho Chehab" <mchehab@...radead.org>
Cc:	"Markus Rechberger" <mrechberger@...il.com>,
	"video4linux-list@...hat.com" <video4linux-list@...hat.com>,
	"Manu Abraham" <abraham.manu@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-dvb@...uxtv.org" <linux-dvb@...uxtv.org>
Subject: Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Mauro Carvalho Chehab <mchehab@...radead.org> wrote:
> > > - The hybrid tuner support, that where your requirement, when all those
> > > discussions started, were already added to the subsystem. So now, an
> > > hybrid tuner can be accessed by both DVB and V4L devices;
> > >
> >
> > It's far more complex as the thing which is implemented there.
> > The only thing that has been implemented is that one moduleformat
> > can be loaded by the v4l and by the dvb framework nothing else at the
> > moment. I told you at the kernel summit about that and I think you
> > knew about that before.
> >
> > Just to quote some text:
> > "Right now, a separate instance of the driver is used for analog /
> > digital tuning.  In order to use a single instance, we will have to
> > store a pointer to the dvb_frontend structure on the bridge level, but
> > there are various other prerequisites that must be dealt with before we
> > get to that point.
> >
> > We _will_ get there though, eventually."
>
> Maybe it is still not perfect. Feel free to improve it. Several people
> from the community, including me, already offered you help to add your
> driver, reworking on the 5% of the stuff that aren't compatible with the
> V4L/DVB core API design.

For clarification, Markus is quoting me, above.

The idea is to eventually store a pointer to the dvb_frontend
structure on the bridge level to be used as a single entry point
between the analog and digital subsystems.  However, we are not yet
ready for this, as the refactoring process has a lot more to be done
beforehand.

Phase 1 of the refactoring was to implement the core changes required
for a single module to be used by both v4l and dvb, and to convert the
existing tuner modules to the new internal API.

Phase 2, a work in progress, involves the removal of duplicated code.
For example, the current code in the master branch still has tda8275 /
tda8275a analog code inside of tda8290.c, where the digital tuning
code is in tda827x.c ...  This was resolved in this changeset:

Move all tda8275/8275a tuning code from tda8290 module into tda827x module
http://linuxtv.org/hg/~mkrufky/philipsNXP/rev/09c2e16a8cdd

This code is working fine, and I have it pushed to linuxtv.org for the
sake of testing.  I have not requested merge to master because I still
have some cleanups to do, and I do not want this to go to 2.6.24.

(side note: basic support for TDA8295 + TDA18271 has been added to my
philipsNXP tree, as well)

Tuner-simple and dvb-pll will have to undergo a similar treatment, and
it's not going to happen overnight.  But I *am* working on it.

I've outlined a basic roadmap to the refactoring plans in my original RFC:
http://linuxtv.org/pipermail/linux-dvb/2007-August/019950.html

What I didn't mention in that RFC, however, is the method in which I
plan to remove the multiple instantiations of the tuner code for a
single piece of hardware, by moving the dvb_frontend pointer to the
bridge level.  Since this change depends on the other refactoring to
be completed first, I found it unnecessary to explain this in detail
at this point.

When the time comes, a new RFC will be sent out to deal with that matter.

There is no reason why the Xceive driver cannot be merged into the
current development tree using the hybrid tuner framework as it stands
today.

Regards,

Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/