On Tue, Jan 27, 2015 at 9:09 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > On 01/27/2015 09:30 AM, Rob Herring wrote: >> On Tue, Jan 27, 2015 at 6:44 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: >>> Hi Rob, >>> >>> On 01/26/2015 11:50 PM, Rob Herring wrote: >>>> Add mrvl,pxa-uart and mrvl,mmp-uart compatible strings for the of_serial >>>> driver. These are 8250 variants which have a port type of PORT_XSCALE. >>>> >>>> There is also the serial driver pxa.c with these compatible strings >>>> already. However, it can be replaced with the common 8250 driver. It has >>>> some issues like it cannot coexist with the 8250 driver due to tty name >>>> collision. That also means adding these compatible strings here should >>>> not case a problem. >>> >>> So what determines which driver is controlling the port if both >>> drivers are built-in? >> >> If both are built-in, whoever registers ttyS ports first wins. This >> will be the 8250 driver due to link order. > > Ok, but then I think the commit log should reflect that this patch > effectively replaces pxa2xx-uart driver with the 8250 driver for PXA/MMP uarts > if both drivers are built-in or both drivers are modules. It doesn't always. It is only on DT enabled platforms. But I can be more explicit about that. There is another patch to remove the PXA driver entirely which I'm inquiring about why it was never merged [1]. This is why I went down the path of getting the 8250 driver to work rather than trying to fix the PXA driver. >> So I guess PXA systems have avoided this by never building in 8250 driver. > > Platform devices are initialized first, so before this patch the pxa2xx-uart > driver would have claimed the platform ports before the 8250 driver, if > both were built-in (or both modules). That's not exactly what I observed. The console is killed when the real driver initializes. I have no other debug output capability after that, so I'm not completely sure what was happening. Part of the problem is you need to move uart_register_driver to probe from the initcall as this is what other serial drivers sharing ttyS have done. Using 8250 earlycon with the PXA driver seems to cause problems, so I'd have to duplicate the earlycon support in the PXA driver. > Maybe Kconfig should warn if they're both built-in or both modules? Is there a way to do that? Rob [1] https://lkml.org/lkml/2015/1/19/471 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
