public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>,
	urishk@yahoo.com, linux-media@vger.kernel.org
Subject: Re: Minimum kernel version supported by v4l-dvb
Date: Sat, 21 Feb 2009 15:26:28 +0100	[thread overview]
Message-ID: <20090221152628.196f5cb1@hyperion.delvare> (raw)
In-Reply-To: <200902211345.40411.hverkuil@xs4all.nl>

On Sat, 21 Feb 2009 13:45:40 +0100, Hans Verkuil wrote:
> On Saturday 21 February 2009 12:58:01 Mauro Carvalho Chehab wrote:
> > On Sat, 21 Feb 2009 08:28:50 +0100
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > OK, once more: there are two types of legacy code: one is that drivers
> > > have to be switched to use the new i2c API. That's what I've been
> > > working on all these months since Plumbers 2008. When all drivers that
> > > use i2c modules have been converted, then we can drop
> > > v4l2-i2c-drv-legacy.h and Jean can drop the autoprobing code in the i2c
> > > core.
> >
> > This will be great, provided that we can do the autoprobing for the audio
> > modules as required by a few drivers like bttv.
> 
> You cannot expect that a user can modprobe an i2c driver and it will 
> magically appear. That's going away. You can change the driver so that it 
> will load the module and let it probe for a series of i2c addresses. There 
> is also an option to let the i2c driver do additional checks (Jean knows 
> more about the details).

Actually with the new I2C binding model, you have quite a few options
depending of what you know and what you need.

* If you know that a given chip is at a given address, you call
  i2c_new_device() from the adapter driver's code.

* If you know a given chip is there but don't know the exact address,
  or if the chip may or may not be there, you call
  i2c_new_probed_device() from the adapter driver's code.

* If you know a given chip is there but don't know the address, or if
  the chip may or may not be there, and the device in question can be
  detected (ID registers you can read), you implement the detect()
  method in the I2C chip driver, which will test a number of addresses
  to find out if a supported chip is there or not. In the adapter driver,
  you define an I2C bus class (e.g. I2C_CLASS_TV_ANALOG) to allow the
  I2C chip driver to probe that specific bus.

* An alternative approach, if letting the I2C chip driver probe for the
  device is too dangerous, is to add custom detection code to the adapter
  driver. Imagine that different versions of the adapter have either
  I2C chip A or chip B at a given address, and the only way to
  differentiate is to write to a given register and read a value back
  from the chip. You can't do that on all I2C buses (writing to
  arbitrary registers is bad) but you can do it on your specific
  adapter. Depending on the result you then call i2c_new_device(A) or
  i2c_new_device(B).

The 3rd method is very similar to the legacy i2c binding model.

-- 
Jean Delvare

  parent reply	other threads:[~2009-02-21 14:26 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-18  8:55 Minimum kernel version supported by v4l-dvb Hans Verkuil
2009-02-18 10:10 ` Mauro Carvalho Chehab
2009-02-18 13:01   ` Jean Delvare
2009-02-20  3:57     ` hermann pitton
2009-02-20  6:53       ` Hans Verkuil
2009-02-20  9:49         ` Jean Delvare
2009-02-20 10:39           ` hermann pitton
2009-02-21  0:23     ` Mauro Carvalho Chehab
2009-02-21  1:12       ` Hans Verkuil
2009-02-21  2:13         ` Mauro Carvalho Chehab
2009-02-21  2:40           ` hermann pitton
2009-02-21  7:28           ` Hans Verkuil
2009-02-21 11:58             ` Mauro Carvalho Chehab
2009-02-21 12:45               ` Hans Verkuil
2009-02-21 12:56                 ` Mauro Carvalho Chehab
2009-02-21 16:20                   ` hermann pitton
2009-02-21 14:26                 ` Jean Delvare [this message]
2009-02-21 12:06           ` Trent Piepho
2009-02-21 13:01             ` Mauro Carvalho Chehab
2009-02-21 13:11             ` Jean Delvare
2009-02-21 13:28               ` Hans Verkuil
2009-02-21 13:56                 ` Jean Delvare
2009-02-21 13:58               ` Trent Piepho
2009-02-22 10:09                 ` Jean Delvare
2009-02-21  1:30       ` kilgota
2009-02-21  2:18         ` Mauro Carvalho Chehab
2009-02-21 16:42           ` kilgota
2009-02-21 20:04             ` Jean Delvare
2009-02-21  9:32       ` Jean Delvare
  -- strict thread matches above, loose matches on Subject: below --
2009-02-18 10:54 Hans Verkuil
2009-02-18 11:54 ` Mauro Carvalho Chehab
2009-02-17 13:23 Jean Delvare
2009-02-17 22:24 ` Laurent Pinchart
2009-02-17 23:06   ` Hans Verkuil
2009-02-21 11:50     ` Mauro Carvalho Chehab
2009-02-21 12:01       ` Hans Verkuil
2009-02-18  0:08 ` Mauro Carvalho Chehab
2009-02-18  0:18   ` Hans Verkuil
2009-02-18  2:08     ` Mauro Carvalho Chehab
2009-02-18  7:36       ` Hans Verkuil
2009-02-18  8:30         ` Uri Shkolnik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090221152628.196f5cb1@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=urishk@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox