On Thu, 2007-08-23 at 18:15 -0500, Olof Johansson wrote: > On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote: > > On Wed, 22 Aug 2007, Olof Johansson wrote: > > > > > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init() > > > initcall is now called before I/O space is setup, but it's dependent on > > > it being available. > > > > > > Since there's no way to make dependencies between initcalls, we'll just > > > have to move it to device_initcall(). Yes, it's suboptimal but I'm not > > > aware of any better solution at this time. > > > > Do I understand it right, that with this change all UARTs, controlled by > > legacy_serial will be initialized later, and that for example console > > output will be first possible later? > > Yes, unfortunately. Unless they've got a udbg driver, since that > would give console output during early boot anyway (even without using > EARLY_DEBUG).
Legacy ports should get udbg first. > > Maybe, if there is really no other > > possibility for I/O space devices, we could have both calls > > > > arch_initcall(serial_mem_dev_init); > > device_initcall(serial_io_dev_init); > > > > so, that at least MEMIO based UARTs could still initialize as before? > > That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion > on how to get the IO setup earlier instead. IO space allocation now relies on get_vm_area() which can't be done too early (not in setup_arch) which is why I allocate all PCI IO space at PHB scanning time, which is a subsys initcall. An option would be to do it from some other init call, but that's a bit ugly. That means PCI would be split into setup_arch() setting up PHBs, that initcall allocating the IO spaces, and later, the actual scan. It would be tricky though as my current interface relies on pci_bus structures. So you would also need to re-split that into a low-level that works on the PHB and a high level version that works on the bus. Is this really necessary ? Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
