> > >>> i2c should really be initialised before framebuffer devices because
quoted text
> > >>> framebuffer devices tend to want to read DDC from monitors, which is
> > >>> basically a I2C EEPROM in the monitor.
> 
> This is already the case. i2c-core is initialized with
> subsys_initcall(), so it's available to all drivers initialized with
> module_init().

That's only one of many examples.  The more general reason to
want to change the position of I2C so it's early in the link
order (like many other "system" busses) is to ensure that I2C
drivers can rely on that initialization no matter where they
are in *link order* ... it's not just an init sequence issue.


quoted text
> > >>> ... but there's probably some reason why it's done the way it is today,
> > >>> and changing it could well cause stuff to break.
> > >>>       
> > >> We have made i2c the first driver subsystem to come up in our 2.6.20
> > >> kernel since we use i2c io expanders for power domain control. All we
> > >> did was change drivers/Makefile so that obj-$(CONFIG_I2C) += i2c/ is at
> > >> the very top of the file. We didn't have any problems with doing this.
> > >> YMMV of course.
> 
> Why don't you simply initialize the drivers in question with
> subsys_initcall()? That's what i2c-pnx, i2c-omap, i2c-davinci and
> tps65010 are doing at the moment.

If they happen to sit outside the I2C tree and *before* it in
link order, things will misbehave.

Agreed init sequencing declarations should Do The Right Thing.
But those declarations are of two types:  *_initcall() stuff,
and link order.  We've seen cases where the initcalls alone are
insufficient.

quoted text
> >  
> > +obj-y				+= i2c/
> >  obj-$(CONFIG_HAVE_GPIO_LIB)	+= gpio/
> 
> Some i2c bus drivers bit-bang GPIO pins...
> 
> >  obj-$(CONFIG_PCI)		+= pci/
> 
> ... and many are PCI devices, so will this work OK?

The gpiochip_add() function needed a bit of care to ensure that
platforms can use GPIOs well before tasking and IRQs work, and
thus before any initcalls run.  So that's not a problem.

Re PCI ... someone could investigate.


For the record, the OMAP tree puts I2C in the link order
later than this.  It wasn't moved earlier mostly out of
paranoia like yours.  (See below.  I'm not sure why "cbus"
is listed twice, or what OMAP boards have similar issues
with serio ...)

- Dave

# we also need input/serio early so serio bus is initialized by the time
# serial drivers start registering their serio ports
obj-$(CONFIG_SERIO)             += input/serio/
obj-y                           += serial/
obj-$(CONFIG_PARPORT)           += parport/
obj-y                           += base/ block/ misc/ mfd/ net/ media/ cbus/
obj-y                           += i2c/
obj-y                           += cbus/
obj-$(CONFIG_ARCH_OMAP)         += dsp/dspgateway/
obj-$(CONFIG_NUBUS)             += nubus/
obj-$(CONFIG_ATM)               += atm/
obj-y                           += macintosh/
obj-$(CONFIG_IDE)               += ide/
obj-$(CONFIG_SCSI)              += scsi/
obj-$(CONFIG_ATA)               += ata/
obj-$(CONFIG_FUSION)            += message/
 
--
unsubscribe notice
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/