On Sat, 2010-04-10 at 20:31 -0500, Bill Gatliff wrote:
> Right now I'm thinking mostly about GPIO devices which need to register
> before things like gpio-leds can use them. Sometimes the GPIO expansion
> chip of interest is on i2c, other times it's spi, and still others it's
> a platform or USB device. Linking the gpio-led driver late helps that
> specific situation.
What it boils down to is that driver A depends on a service provided by
driver B. At some stage, your dependency -has- to be expressed. Either
using the device-tree, or by hard wiring a GPIO number, maybe by having
the platform code figure out the GPIO number and shoving it into a
platform_data structure, etc... but at -some- point, driver "A" needs
some kind of "identifier" to the service provided by driver "B". In our
case, let's say it's a GPIO number.
That's when you can start kicking in a simple mechanism for exporting
services. Let's say the GPIO layer does
register_service("gpio", gpio_service_query);
With something like
int gpio_service_query(const char *query_string);
Which can parse whatever arguments are passed after the service name and
return success or failure (or even return a struct device *, whatever,
this is just a rough sketch).
>From there, you can have for the drivers something like:
request_service(const char *name, struct device *myself);
Which takes a service name of the form "service:args", for example
"gpio:5" for GPIO #5.
That returns 0 if found, -EAGAIN if not found yet, -EINVAL if rejected
(the service "gpio" can decide that there cannot be a GPIO 5 on the
system, whatever) for example. In addition, it would attach "myself" (if
non-NULL) to an internal list so that later, it's probe() routine can be
called again.
We then add a way for probe() to return -EAGAIN to put the driver "on
hold" silently.
And finally, maybe a way for services to re-run their query (new GPIOs
were added for example) for all "pending" drivers.
I haven't looked at the flip side here which is service -removal- of
course. We may get away without dealing with it... tbd.
> But what about when I want to use a pin on a GPIO expansion device as
> the card-detect for an MMC slot? Or, as I've just recently noticed in
> one hardware platform I'm working on, using a pin on a SPI GPIO expander
> as a chip-select for another SPI device, but through gpiolib?
> Eventually, the dependencies don't become circular but changing the link
> order will break some and fix others. Ugh.
As I said above, at some stage, -somebody- can identify the dependency,
which ends up being translated into a GPIO number, an OF device path, or
something .... That should be enough for the above to be made to fit
no ?
> Definitely, a free-for-all isn't going to work. But I don't think that
> having every driver do its own kthread_run() is a solution, either.
> I'll keep tinkering. :)
I'd rather keep threads out of the picture for now. IE. Leave the
decision as to do threaded probing or not at a different level.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
