Subject: Re: iic(4) device discovery
To: Marco Trillo <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 10/20/2007 10:59:48
-----BEGIN PGP SIGNED MESSAGE-----
On Oct 20, 2007, at 07:37, Marco Trillo wrote:
> On 10/20/07, Jachym Holecek <email@example.com> 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
>>> I would much rather see a properties-based solution whereby a
>>> specific callback could provide an array of devices to be direct-
>> This could be implemented by providing an autoconf(9) API to register
>> new cfdata entries before device discovery is started. If the arch
>> the list of devices and their addresses, it would simply convert
>> device table into cfdata dictionaries and indirect-search iic(4)
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----