Re: [RFC] The driver model, I2C and gpio provision on Sharp SL-C1000 (Akita)

[David Brownell <david-b@pacbell.net>]

> > It seems that making i2c init early is only sane choice. I realize PC people
> > will hate it...

What do you mean by "early"?  Other than maybe linking it earlier
in the drivers/Makefile, and probably running some arch-specific i2c
controller (and certain i2c chip) drivers at subsys_initcall rather
than at device_initcall ... does the 2.6.14 kernel need changes?


> > but apart from that, why is it impractical? 
> 
> FWIW, I have also run into this "I need I2C early in boot, but it's not
> inited until late" on SiByte ...

Likewise on many OMAP boards, which tend to have the power management
and other essential features on I2C.

Some board-specific init code ends up needing to run after the probe()
logic of the tps6501x driver ... like for example, using a GPIO (!)
there to power up the Ethernet controller which may be needed for the
root filesystem.  (At least on many development systems!)

You can see where that leads:  we patched the i2c subsystem so that
it runs at subsys_initcall ... and also the omap_i2c driver, and
the tps65010 driver.  No other drivers need to be changed, just the
ones involved in that board's power management.


Richard:

> I had to turn akita-ioexp into a platform device to get the suspend
> signal which is used to flush the workqueue. With a platform device
> available at machine init time, I can insert it as a parent of the corgi
> device chain which means its one of the last devices to be suspended.

By doing all that stuff as "subsys_initcall", the relevant I2C gpio
hardware will be also be suspended "late" ... without such a fake
platform device.  Unless you're doing selective suspend, details of
the device tree matter less than the order used to create devices.

- Dave