Subject: Re: iic(4) device discovery
To: Marco Trillo <marcotrillo@gmail.com>
From: Michael Lorenz <macallan@netbsd.org>
List: tech-kern
Date: 10/20/2007 11:07:23
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Oct 20, 2007, at 04:42, Marco Trillo wrote:

> On 10/20/07, Jason Thorpe <thorpej@shagadelic.org> wrote:
>>
>> On Oct 19, 2007, at 4:53 PM, Martin Husemann wrote:
>>
>>> IMHO (but it's late at night here, this is just a quick gut  
>>> feeling) a
>>> direct configured ofiic bus with tiny special attachments is the
>>> cleaner
>>> solution.
>>
>> I would much rather see a properties-based solution whereby a  
>> platform-
>> specific callback could provide an array of devices to be direct-
>> configured.
>
> This sounds fine too. Would this be a 'prop_array_t' object being
> added to the 'struct i2c_controller' or an array member being added to
> the device properties dictionary of iic(4)?
>
> I think the later will be problematic, because the device list is
> controller-specific more than platform-specific, so it should be
> created and passed directly by the I2C controller (ki2c or cuda in the
> above examples).

Just to make things worse - some PMUs also have i2c buses ( we don't  
support that right now but that may change any time ) and very few  
have nodes for individual i2c devices.
I think a hybrid approach would be best - pass config hints via  
proplib when attaching the i2cbus and let the i2c controller gather  
those data either via MD callback ( for i2c controllers that aren't  
100% macppc-specific, although neither cuda nor ki2c fall into this  
category ) or some other ways, like model specific tables, various OF  
nodes and so on.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBRxoZq8pnzkX8Yg2nAQLTNwf9FJlSglSbyorj3n/0eEP+jZsxqbJaN1Ho
QPMFlxqEoSLEfN1m/SvtoQVnx8Lel79mx1NQF147QSOsZbIcjAJA1TCS1i2RqtIq
y+tHAuxeJB7xpJdNMKX7eIMudNeT6uPJh98nLSoGLoe86nutyGYwgoZnd1CusMiF
r2FFkgL91+DtZ2BX5pNaCMqJJ7gmN2omlupxrOkAwx4Enl4nYNwG6rE6y6wWxhv2
XIDZnG8EgdbUJkwiveyWQIenwhl80QcKggiRCG1S1Jn4KJXWc03ZM47u3jYOOrbx
fD06gSOXOChWtJKcE9t2/KbdGMedouLw3wMizSXL/6VKPzHXbIdlgA==
=tIGk
-----END PGP SIGNATURE-----