login
Header Space

 
 

Re: iic(4) device discovery

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Jachym Holecek <freza@...>
Cc: Marco Trillo <marcotrillo@...>, <tech-kern@...>
Date: Saturday, October 20, 2007 - 10:09 am

On Sat, Oct 20, 2007 at 03:30:07PM +0200, Jachym Holecek wrote:
ows
ware

No, this is not what a cfdata_t represents.  It's a potential instance
of a driver, not a device.  In order to create a cfdata_t, you need the
name of a driver.


Except the parent bus can't know about drivers able to claim a device
before it has called their match functions, and for that it needs a set
of cfdata_t.

Think of competing drivers for a device that identifies the same way to
the parent bus.

The issue at stake here is how to mix direct and indirect configurations
for a given bus.  It's possible under the current autoconf(9) framework
(albeit somewhat hackish).

The controler that attaches an iic instance has to pass a table of some
sort to the iic driver;  in the current autoconf(9) framework it would
unfortunately have to be through a pointer in the attach args (unless
you somehow delay attachment of children to give a chance to the parent
to set a property, but that's equally ugly).

Then the iic driver attaches its children in two distinct phases:
first, the direct configuration, enumerating the passed table.  The
trick here (again, in the current autoconf(9) framework) is to let
drivers know it's a direct configuration attempt.  That's a field to
add to the iic_attach_args structure as the id given by the controler.

If said id is "set" (e.g., it's a string and it's not NUL[L?]), a
driver's match function knows it's a direct config attempt and will use
said id to match.  If it isn't set, then it's an indirect config
attempt, and the driver will probe the usual way.

It gets ugly here because what we really want to avoid, whether the bus
be isa or icc, is a driver poking to some random address when not asked
to.  Which means that under the method given here, all drivers have to
be modified, most of them not to do anything but return 0 when a direct
config is attempted.

(Therefore, with a more refined autoconf(9), a driver would have a
match function for direct configuration, and a different one for
indirect configuration, more correctly called "probe function".)

In any case, cfdata_t are basically lines in the config files or its
equivalent for a LKM, but nothing more.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
iic(4) device discovery, Marco Trillo, (Fri Oct 19, 6:43 pm)
Re: iic(4) device discovery, Martin Husemann, (Fri Oct 19, 7:53 pm)
Re: iic(4) device discovery, Jason Thorpe, (Fri Oct 19, 7:56 pm)
Re: iic(4) device discovery, Marco Trillo, (Sat Oct 20, 4:42 am)
Re: iic(4) device discovery, Michael Lorenz, (Sat Oct 20, 11:07 am)
Re: iic(4) device discovery, Jachym Holecek, (Sat Oct 20, 5:12 am)
Re: iic(4) device discovery, Marco Trillo, (Sat Oct 20, 7:37 am)
Re: iic(4) device discovery, Michael Lorenz, (Sat Oct 20, 10:59 am)
Re: iic(4) device discovery, Jachym Holecek, (Sat Oct 20, 9:30 am)
Re: iic(4) device discovery, Quentin Garnier, (Sat Oct 20, 10:09 am)
Re: iic(4) device discovery, Martin Husemann, (Fri Oct 19, 8:04 pm)
speck-geostationary