lkml.org 
[lkml]   [2005]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] The driver model, I2C and gpio provision on Sharp SL-C1000 (Akita)
Date
> > 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/

\
 
 \ /
  Last update: 2005-11-03 08:09    [W:0.076 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site