Messages in this thread | | | Date | Mon, 29 Jul 2002 12:07:03 -0700 | From | Tom Rini <> | Subject | Re: Serial core problems on embedded PPC) |
| |
On Mon, Jul 29, 2002 at 08:13:52PM +0200, Benjamin Herrenschmidt wrote:
> >> a. architectures provide a sub-module to 8250.c which contains the > >> per-port details, rather than a table in serial.h. This would > >> ideally mean removing serial.h completely. The relevant object > >> would be linked into 8250.c when 8250.c is built as a module. > > > >I think this would work best. On PPC this would allow us to change the > >mess of include/asm-ppc/serial.h into a slightly cleaner Makefile > >(especially if we do the automagic <platforms/platform.h> or > ><asm/platform.h> bit that's been talked about in the past) magic and we > >could use that object file as well in the bootwrapper as well. > > Especially, please, let's avoid once for all statically defined table, > on PPC (specifically on pmac) the table is really dynamic, and > the "legacy ports" (if any) may not be ttyS0..1, but could well be > 2..3, or higher, all this having to be decided at runtime for both > built-in driver and modular (so eraly_serial_setup isn't good).
Well, on pmac yes. But for a good hunk of the rest of the PPC world the inital ports are static (and as long as new ports, ie pcmcia stuff, is handled sanely anyhow, I don't think this is an issue).
> I quite like the sub-module mecanism. I'd rather have it done the > opposite though. I don't care that much about sharing those files > with the bootloader, and i'd rather see the core serial code beeing > a submodule of the arch specific module.
Then how do you propose to keep the bootloader working and kill off the ugly ugly include/asm-ppc/serial.h ?
> Typically, that would give us: > > - 8250_legacy.c would load 8250 core, probe legacy ports and > instanciate them for typical x86 setup > - 8250_ppc.c would instanciate known ports on PReP or CHRP machines > and do nothing on pmac > - 8250_pci.c would be a pci_driver and instanciate ports for a given > PCI card > - 8250_cs.c would be a pcmcia driver and instanciate ports for a > given PCMCIA modem card > > etc... And of course, we can have an arbitrary set of the above loaded > instanciating ports are they are found.
I _think_ the 8250_cs.c case is seperate in this case. But most of what you describe would work fine in the arch-is-a-submodule case. What I was thinking of was some makefile bits to something like: # The true legacy ports, prep/chrp/others. With a _machine test or # something. serial-$(CONFIG_ALL_PPC) += legacy.o # K2 uses the legacy locations too serial-$(CONFIG_K2) += legacy.o # These boards make use of iomem_base/reg shift serial-$(CONFIG_A) += a_serial.o serial-$(CONFIG_B) += b_serial.o ...
obj-$(CONFIG_SERIAL_8250) += $(serial-y)
Or so. Maybe with a rule to turn $(serial-y) into arch_serial.o or something.
-- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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/
| |