Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly

[Jon Smirl <jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Sun, Jun 7, 2009 at 9:25 AM, Jon Smirl<jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Jun 7, 2009 at 2:35 AM, Hans Verkuil<hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> wrote:
>> On Sunday 07 June 2009 00:20:26 Jon Smirl wrote:
>>> On Sat, Jun 6, 2009 at 9:00 AM, Hans Verkuil<hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> wrote:
>>> > Hi all,
>>> >
>>> > For video4linux we sometimes need to probe for a single i2c address.
>>> > Normally you would do it like this:
>>>
>>> Why does video4linux need to probe to find i2c devices? Can't the
>>> address be determined by knowing the PCI ID of the board?
>>
>> There are two reasons we need to probe: it is either because when the board
>> was added no one bothered to record which chip was on what address (this
>> happened in particular with old drivers like bttv) or because there is
>> simply no other way to determine the presence or absence of an i2c device.
>
> Unrecorded boards could be handled by adding a printk at driver init
> time asking people to email you the needed information. Then remove
> the printks as soon as you get the answer.
>
>>
>> E.g. there are three versions of one card: without upd64083 (Y/C separation
>> device) and upd64031a (ghost reduction device), with only the upd64031a and
>> one with both. Since they all have the same PCI ID the only way to
>> determine the model is to probe.
>
> Did they happen to change the subsystem device_id? There are two pairs
> of PCI IDs on each card. Most of the time the subsystem vendor/device
> isn't set.

Example using lspci -vvv -nn

This is an Intel ICH8 but Dell as set in a subsystem id if 1028:01db
to indicate their custom use of the generic part.

00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus
Controller [8086:283e] (rev 02)
	Subsystem: Dell Device [1028:01db]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin C routed to IRQ 10
	Region 0: Memory at dffdab00 (32-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at ece0 [size=32]
	Kernel modules: i2c-i801




>
> Getting rid of the probes altogether is the most reliable solution.
> There is probably a way to identify these boards more specifically
> that you haven't discovered yet.  PCI subsystem device ID is worth
> checking.
>
>>
>> Regards,
>>
>>        Hans
>>
>>>
>>> > static const unsigned short addrs[] = {
>>> >        addr, I2C_CLIENT_END
>>> > };
>>> >
>>> > client = i2c_new_probed_device(adapter, &info, addrs);
>>> >
>>> > This is a bit awkward and I came up with this macro:
>>> >
>>> > #define V4L2_I2C_ADDRS(addr, addrs...) \
>>> >        ((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
>>> >
>>> > This can construct a list of one or more i2c addresses on the fly. But
>>> > this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
>>> >
>>> > With this macro we can just do:
>>> >
>>> > client = i2c_new_probed_device(adapter, &info, I2C_ADDRS(addr));
>>> >
>>> > Comments?
>>> >
>>> > Regards,
>>> >
>>> >        Hans
>>> >
>>> > --
>>> > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
>>> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>>
>
>
>
> --
> Jon Smirl
> jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>



-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org