Google
  Web www.spinics.net

[RFC | PATCH] move device-specific private data out of tuner struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 5/30/07, hermann pitton <hermann-pitton at arcor.de> wrote:
> Am Dienstag, den 29.05.2007, 22:19 -0400 schrieb Michael Krufky:
> > Markus Rechberger wrote:
> > > On 5/29/07, Mauro Carvalho Chehab <mchehab at infradead.org> wrote:
> > >> Em Ter, 2007-05-29 ?s 16:38 -0400, Michael Krufky escreveu:
> > >> > As it stands currently, all device-specific data for analog tuner
> > >> > drivers are stored in the main tuner struct.  This is a potential
> > >> waste
> > >> > of memory for tuner drivers that do not utilize all of these
> > >> structures.
> > >> >
> > >> > Up until now, as the needs of the drivers have changed, a developer
> > >> > would issue an RFC to explain what he needs to add to the tuner
> struct
> > >> > in order to handle the necessary change for the driver in question.
> > >> > With these private structures moved out of the main tuner struct,
> such
> > >> > changes in the future would only affect the specific tuner driver.
> > >> >
> > >> > I have written a driver for the Philips / NXP TDA18271 silicon tuner.
> > >> > This driver needs to maintain a snapshot of the register values in
> > >> > memory -- this would be a waste of space for the other tuner
> > >> drivers, as
> > >> > this space would only be needed for the tda18271.  Since this
> > >> memory is
> > >> > only needed for the TDA18271, it makes sense that it should be
> > >> stored in
> > >> > a private area specific to the TDA18271, only.
> > >> >
> > >> > The attached patch allocates these private structures on an as-needed
> > >> > basis, within the object code for that specific tuner, rather than
> > >> > globally inside the main tuner structure.  This change could also be
> > >> > considered as a cleanup / overhaul, which brings the tuner.ko module
> > >> > closer to an object-oriented design.
> > >> >
> > >> > Would anybody have any issues with this patch, if it were applied?
> > >>
> > >> The patch looks sane and it is really a good idea. Of course, it should
> > >> be tested on all touched tuners.
> > >>
> > >
> > > this is a good change yes.
> > >
> > > Markus
> > Mauro & Markus,
> >
> > Thanks for the feedback -- I've already tested this on the tda8290 +
> > 8275, and on a tin can tuner (LG-H064F) using a tda9887 ...  The only
> > tuner driver affected by this change that hasn't been tested yet is
> > mt20xx.  Does anybody have a card using mt20xx that can test this?
> >
> > It should be safe to push it into the master branch and -mm , to achieve
> > sufficient testing before the 2.6.23 merge window opens, which should be
> > months away.
> >
> > For now, I've pushed the changeset to this tree:
> >
> > http://linuxtv.org/hg/~mkrufky/tuner
> >
> > - tuner: Move device-specific private data out of tuner struct
> >
> >  drivers/media/video/mt20xx.c     |   33 +++++++++---
> >  drivers/media/video/tda8290.c    |  105
> > ++++++++++++++++++++++++---------------
> >  drivers/media/video/tda9887.c    |   37 ++++++++-----
> >  drivers/media/video/tuner-core.c |   10 +++
> >  include/media/tuner.h            |   13 ----
> >  5 files changed, 124 insertions(+), 74 deletions(-)
> >
> > Cheers,
> >
> > Mike
> >
>
> Michael,
>
> it seems there is a real problem and me doing only user level debug
> can't resolve it.
>
> Markus seems to think he can force his work over Mauro.
>

this is unrelated to his patches, and I do not want to force the work
over Mauro.
People have to get up their ass and realize what they're doing here by
holding down the whole development.
I know that my solution isn't optimal but it doesn't close down the
whole code, and a better solution would also require a much deeper
redesign of the v4l and dvb API, which is not going to happen during
the next few weeks/months for sure and these changes carry alot other
changes on the back at the moment, however it's explained in the other
mail you sent.
If people are really interested in all that they should learn from
what I did and try to make it better based on that code even if it
means that they have to get their hands on that code again.
And why learn? In private discussions with several developers they're
OK with such a change and would even go further with modifying the
structs but still base on the same core idea.

Markus



[Linux Media]     [Older V4L]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [SSH]     [Linux USB]

-->
Add to Google Powered by Linux

Google PageRank Checking tool