-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Oct 20, 2007, at 07:37, Marco Trillo wrote:

> On 10/20/07, Jachym Holecek <freza@netbsd.org> wrote:
>> # Jason Thorpe 2007-10-20:
>>> 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 could be implemented by providing an autoconf(9) API to register
>> new cfdata entries before device discovery is started. If the arch  
>> knows
>> the list of devices and their addresses, it would simply convert  
>> firmware
>> device table into cfdata dictionaries and indirect-search iic(4)  
>> would
>> then use it transparently.
>
> But this functionality is more controller-specific than
> architecture-specific. In the macppc example, the OpenFirmware nodes
> are ki2c(4) specific (and are in fact child nodes of the ki2c firmware
> nodes) and should not affect for example cuda(4) or pmu(4) -- and it
> should be possible to have all of these I2C controllers enabled
> without conflicts.

At least the stuff hooked up to cuda's i2c bus is highly model  
specific and usually doesn't have an OF node. Take the beige G3 as an  
example - only one i2c address can be found via OF ( sgsmix ) and  
that's nowhere near cuda's node. The other devices on this bus -  
pretty much all the video IO stuff - ha no OF nodes anywhere. Then,  
some Apple onboard graphics chips are controlled via i2c. With ki2c  
usually there are OF nodes but not always - by Gigabit G4 for  
instance has none while my iBook G4 does. Newer firmware tends to  
have more information about i2c devices.
So, we can build a table of config hints before autoconf runs, part  
from data found in the OF tree, part from 'just knowing' what kind of  
hw certain models come with.
Some devices have model ID registers and can be probed for, although  
sgsmix isn't one of them. Mixer chips in newer models may or may not  
have ID registers - TAS300x does, DACA does not etc. What I'm getting  
at is - drivers for chips with ID registers should use them ( yeah,  
mine usually don't but that's trivial to change ) so we only need to  
compile data for chips that can't be reliably probed for.

> Using the callback approach, the ki2c(4) device discover method would
> look at the child nodes of its OpenFirmware node and call a callback
> function of iic(4) to configure them. cuda(4) or pmu(4) would use a
> different implementation of the discover method.

Hmm, actually we can do both - not sure if it's worth the trouble  
though. If for instance ki2c would automatically compile config data  
for its childs when possible that's less work for the before autoconf  
data gatherer which would only have to deal with devices that can't  
be found that way.

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

iQEVAwUBRxoX5MpnzkX8Yg2nAQKeNwf/T818khvVktKtj/CyjlIC8SQIwworMGx1
yGkVIUjRZ+CB4E0AOjmGKFJrYSjoUpCjyaEhuZB/9ctMUoJF04BvHHbhgi6u21jT
3ihHLaXZKoacaoxYwoDyHcelNuKji7Wi8aBG/I3P1DlBIGRG0AhY18k4+ueo5hAD
UfIYTQiGygn9umSrUV1/fffgD1RI+iAxRLgHtdnF1t1hdwVZAC+WBvJv7TFgboI8
7QChZJ8LqLiMvl3z6xhOvqiCuifq0iGFXu4EPx1DYscNwF17dPjZ1jJFmxEAF10s
s9Sv9HCeOMhb01W76eu/ZN0nV4Kw0wFRBgD/NAsCn1j2OlrxYw3Q8A==
=E5yq
-----END PGP SIGNATURE-----