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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
