On Tue, Jun 16, 2009 at 04:06:48AM -0400, Mike Frysinger wrote:

> On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
> > James Bottomley wrote:
> >> We've got to the point where there are simply too many embedded
> >> architectures to invite all the arch maintainers to the kernel summit.
> >> So, this year, we thought we'd do embedded via topic driven invitations
> >> instead.  So what we're looking for is a proposal to discuss the issues
> >> most affecting embedded architectures, or preview any features affecting
> >> the main kernel which embedded architectures might need ... or any other
> >> topics from embedded architectures which might need discussion or
> >> debate.
> >
> > Another issue that affects embedded architectures is drivers initialization
> > order. There are a lot of cases when you need the drivers to be initialized 
> > in
> > particular order, and current initcalls scheme does not allow fine grained
> > control for it.
> 
> example: device configuration information stored in i2c eeprom (i.e.
> dimensions of attached framebuffer), but i2c is not available when
> framebuffer layer is setup.  framebuffer driver has to be built as a
> module and loaded by userspace, or i2c information is read by
> bootloader and passed down to the kernel.

I2C or similar busses can be a particularly annoying if they contain
essential configuration information such as memory size which is needed
long before anything else.  So for far a common solution is that platforms
are carrying a private (aka redundant, ugly) early-i2c system that's just
about sufficient for this purpose.

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to