[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8b4dbe10709141407p757d0909s5a4d49a7eb44d929@mail.gmail.com>
Date: Fri, 14 Sep 2007 22:07:36 +0100
From: "Aidan Thornton" <makosoft@...glemail.com>
To: "Michael Krufky" <mkrufky@...uxtv.org>
Cc: "Mauro Carvalho Chehab" <mchehab@...radead.org>,
"Manu Abraham" <abraham.manu@...il.com>,
"video4linux-list@...hat.com" <video4linux-list@...hat.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
Hi,
On 9/14/07, Michael Krufky <mkrufky@...uxtv.org> wrote:
> 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.
I think this will require a rethink of either how the em2880-dvb
driver works or how frontend drivers work. The current API expects
users to initialise their frontend and then bind a tuner to it.
em2880-dvb is a sort of subdriver that attaches to the main driver,
and doesn't have any control over when or how it initialises its
tuner, so it can't delay tuner initialisation until the frontend has
been initialised. (I don't think it's the only hybrid driver that
works this way either). Of course, I could be missing something.
> 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.
I'm not convinced this is entirely true. In order to avoid unnecessary
reinitialisation of the device, the driver needs to know whether the
device is in analog or digital mode, and I can't see a way of doing it
with the current API. (I think existing drivers, such as the xc2028
driver in one branch, use the older analog API and make the digital
driver a wrapper around it.) Again, I may be missing something.
Aidan
-
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/
Powered by blists - more mailing lists