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

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Wed, Nov 02, 2005 at 11:44:53AM -0800, Andy Isaacson wrote:
> On Sat, Oct 29, 2005 at 09:08:19PM +0200, Pavel Machek wrote:
> > > I2C drivers appear relatively late in the boot procedure and changing
> > > that isn't practical. I therefore ended up writing akita-ioexp which
> > 
> > It seems that making i2c init early is only sane choice. I realize PC people
> > will hate it... 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 (arch/mips/sibyte/{sb1250,bcm1480}/setup.c).  
> For the time being in the linux-mips tree we simply have two drivers
> talking to the I2C interface - sibyte/swarm/rtc_* and i2c-sibyte.c,
> and they are currently lacking even any trivial locking.  We haven't
> seen any problems yet but that's due to limited exercise - the default
> config doesn't hook up any drivers for the other chips on I2C.
> 
> How do other arches that have I2C RTCs deal with this problem?  Or is
> there something wrong with how arch/mips/kernel/time.c:time_init deals
> with the rtc?

On ARM, where we have I2C RTCs, I tend to leave xtime well alone in
time_init and just setup the timer.  When i2c is initialised, and
the bus and RTC have been detected, I set the time from them at
that point.

I haven't seen any problems with this approach.  In fact, I'd
rather time_init() just setup the timer, and we set the time of
day later during the kernels initialisation.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core