Hi, > On Monday 06 June 2011, RafaÅ MiÅecki wrote: > > Greg, Arnd: could you take a look at this patch, please? > > > > With proposed patch we are going back to this ugly array and wrappers hacks. > > > > I was really happy with our final solution, but it seems it's not > > doable for embedded systems...? Is there something better we can do > > about this? > > > > 2011/6/6 Hauke Mehrtens <hauke@xxxxxxxxxx>: > > > When using bcma on a embedded device it is initialized very early at > > > boot. We have to do so as the cpu and interrupt management and all > > > other devices are attached to this bus and it has to be initialized so > > > early. In that stage we can not allocate memory or sleep, just use the > > > memory on the stack and in the text segment as the kernel is not > > > initialized far enough. This patch removed the kzallocs from the scan > > > code. Some earlier version of the bcma implementation and the normal > > > ssb implementation are doing it like this. > > > The __bcma_dev_wrapper struct is used as the container for the device > > > struct as bcma_device will be too big if it includes struct device. > > > > > > Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx> > > If you rely on device scan to find your CPUs and interrupt controllers, > you are screwed already, this won't work. > > In that case, it's better to have a few "early" drivers, as few as > possible, that don't go through the bus scan at all but have their > own ways of bootstrapping themselves. I don't know what you mean by > "CPU management", but I can only assume that it's not doing that much, > and you can just put the register values into the device tree. GPIOs, flash and UART could get initialized early without erom scanning as Chipcommon seems always to be the #0 core on the amba interconnect. > > For an interrupt controller, it should be ok to have it initialized > late, as long as it's only responsible for the devices on the same > bus and not for instance for IPI interrupts. Just make sure that you > do the bus scan and the initialization of the IRQ driver before you > initialize any drivers that rely in on the interrupts to be working. Without proper timer init (which requires both the chipcommon and mips cores knowledge) kernel will get hung somewhere inside calibrate_delay. It could get addressed if get bus scan called in arch_init_irq or plat_time_init - both are executed before calibrate_delay and with slab available. Have nice day, George
