On 01/27/2015 11:44 AM, Rob Herring wrote: > 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. Ah. I had seen your inquiry but didn't grasp the significance. Greg acked that patch over 8 mos ago; it's still stuck somewhere? OTOH, I didn't realize that patch removed the PXA driver. That driver has errata workarounds which didn't get integrated into the 8250 core; it seems a shame to toss that away. [ Sidebar: I did a trial split of 8250_core into a separate 8250 base module and an 8250 universal driver. I keep having to rework the split but it's pretty close now; the 8250 base module might be just the thing for simplifying the pxa driver and getting console/earlycon/dma for free. Let me see what I can do about getting that done. ] >>> 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. Ah, yep. I missed that subtlety. > 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? I think so; conf warns if one setting overrides another, so I think there's probably a way to make that happen in the Kconfig. I'll mess with that later tonight or tomorrow, and get back to you. Regards, Peter Hurley -- 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
