Re: Representing Embedded Architectures at the Kernel Summit

[Grant Likely <grant.likely@secretlab.ca>]

On Tue, Jun 16, 2009 at 2:06 AM, Mike Frysinger<vapier.adi@gmail.com> wrote:
> On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
>> James Bottomley wrote:
>> Another issue that affects embedded architectures is drivers initialization
>> order. There are a lot of cases when you need the drivers to be initialized in
>> particular order, and current initcalls scheme does not allow fine grained
>> control for it.
>
> example: device configuration information stored in i2c eeprom (i.e.
> dimensions of attached framebuffer), but i2c is not available when
> framebuffer layer is setup.  framebuffer driver has to be built as a
> module and loaded by userspace, or i2c information is read by
> bootloader and passed down to the kernel.

I experimented a bit with having some infrastructure for waiting for
another device to get either registered as part of the phylib stuff I
was doing.  Here's the patchwork link to the discussion:

http://patchwork.ozlabs.org/patch/24152/

I never actually pushed through and finished it because it turned out
to be a non-issue for Ethernet devices in the end.  However, I can see
the value.  With this approach, a driver can use a
bus_register_notifier() variant without caring about the device
registration order, and the drivers notifier callback will get called
at the appropriate time.

In your example case I could see the framebuffer driver deferring the
final part of its initialization until the needed i2c device shows up.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.