Messages in this thread | | | From | David Brownell <> | Subject | Re: [RFC] The driver model, I2C and gpio provision on Sharp SL-C1000 (Akita) | Date | Wed, 2 Nov 2005 23:06:48 -0800 |
| |
> > 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |