PXA/8250 UART Conflicts

PXA/8250 UART Conflicts

[Michael Cashwell]

Greetings,

I'm using a PXA270-based Gumstix and a provisional 2.6.33.2 kernel to explore supporting a dual 8250-like UART chip over i2c for one of our hardware guys. But enabling both the 8250 and pxa2xx-uart drivers conflicts at the ttySn level. Both seem to do the following:

serial_core: uart_register_driver() ->
tty_io:      tty_register_driver() ->
char_dev:    register_chrdev_region()

using the same starting minor number. Thus the first driver gets /dev/ttyS0 and up and the rest fail with -EBUSY.

Am I missing something? Are these drivers just incompatible and Kconfig shouldn't let me turn both on? (In fact, doing so kills the console if it's on an internal PXA uart because the 8250 driver loads first. That was "fun with JTAG".)

I'd like the tty layer to just assign the minor numbers in sequence, first come first served. But I don't see how to get that. Or is there some platform way to influence the tty range requested?

Any pearls of wisdom would be welcome.

-Mike

PXA/8250 UART Conflicts

[Russell King - ARM Linux]

On Tue, May 11, 2010 at 11:00:36AM -0400, Michael Cashwell wrote:
> I'd like the tty layer to just assign the minor numbers in sequence,
> first come first served. But I don't see how to get that. Or is there
> some platform way to influence the tty range requested?

It's just plain not supported.  You can't have two different tty drivers
using the same namespace and have it work.

Unfortunately, earlier on it was the opinion that "ttyS" means "serial
driver" and therefore "we shall use the ttyS namespace for our SoC
driver".  And this is the resulting mess that it causes.

There were insane patches around to hack all the serial drivers up to
be able to use the "ttyS" space, by making the 8250 driver "special".

The other solution, which projects which wanted PCMCIA serial-like
cards to work with PXA chips is to patch the PXA serial driver to use
a different major/minor/namespace - it reuses the SA1100 serial port
space since you'll never end up with both SA1100 and PXA together.

commit 2fdedac721107de791da77f6ed5600a092cd06b1
Author: Russell King <rmk@dyn-67.arm.linux.org.uk>
Date:   Sun Aug 24 23:12:59 2008 +0100

    [SERIAL] pxa: Allow alternate major/minor numbers for PXA serial
    
    LX needs to use both the PXA driver, and the 8250 driver for modems/
    GPRS and the like.  Allow the PXA serial driver to exist using the
    StrongARM major/minor number space.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index e522572..9187256 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -648,6 +648,15 @@ config SERIAL_PXA
 	  If you have a machine based on an Intel XScale PXA2xx CPU you
 	  can enable its onboard serial ports by enabling this option.
 
+config SERIAL_PXA_ALTMAJOR
+	bool "PXA serial port uses ttySA instead of ttyS"
+	depends on ARM && ARCH_PXA && SERIAL_PXA
+	help
+	  Moves the PXA serial ports to ttySA to allow the 8250 driver
+	  to register the serial ports it wants as ttySx. If you do not
+	  do this, then the serial_cs driver and others than rely on
+	  8250 support will not work.
+
 config SERIAL_PXA_CONSOLE
 	bool "Console on PXA serial port"
 	depends on SERIAL_PXA
diff --git a/drivers/serial/pxa.c b/drivers/serial/pxa.c
index b8629d7..6af59a0 100644
--- a/drivers/serial/pxa.c
+++ b/drivers/serial/pxa.c
@@ -682,7 +682,11 @@ serial_pxa_console_setup(struct console *co, char *options)
 }
 
 static struct console serial_pxa_console = {
+#ifdef CONFIG_SERIAL_PXA_ALTMAJOR
+	.name		= "ttySA",
+#else
 	.name		= "ttyS",
+#endif
 	.write		= serial_pxa_console_write,
 	.device		= uart_console_device,
 	.setup		= serial_pxa_console_setup,
@@ -719,9 +723,15 @@ struct uart_ops serial_pxa_pops = {
 static struct uart_driver serial_pxa_reg = {
 	.owner		= THIS_MODULE,
 	.driver_name	= "PXA serial",
+#ifdef CONFIG_SERIAL_PXA_ALTMAJOR
+	.dev_name	= "ttySA",
+	.major		= 204,
+	.minor		= 5,
+#else
 	.dev_name	= "ttyS",
 	.major		= TTY_MAJOR,
 	.minor		= 64,
+#endif
 	.nr		= 4,
 	.cons		= PXA_CONSOLE,
 };

PXA/8250 UART Conflicts

[Dmitry Artamonow]

On 17:12 Tue 11 May     , Russell King - ARM Linux wrote:
> On Tue, May 11, 2010 at 11:00:36AM -0400, Michael Cashwell wrote:
> > I'd like the tty layer to just assign the minor numbers in sequence,
> > first come first served. But I don't see how to get that. Or is there
> > some platform way to influence the tty range requested?
> 
> It's just plain not supported.  You can't have two different tty drivers
> using the same namespace and have it work.
> 
> Unfortunately, earlier on it was the opinion that "ttyS" means "serial
> driver" and therefore "we shall use the ttyS namespace for our SoC
> driver".  And this is the resulting mess that it causes.

Yup, that's a long standing bug (and still not fixed). I remember I first
happened to stumble upon it about three years ago and it's already been old
back then. In fact it's a general PITA on any PXA board with PCMCIA/CF
slot (handhelds, for example, but not only) when you trying to use some
serial PCMCIA peripherals (e.g. GPSes, wired and wireless modems,
RS232 converters, maybe even bluetooth dongles). With 8250 enabled as a module 
and PXA serial built-in it simply doesn't works.

Openembedded guys for ages have patched kernel with hacks like these to solve
this problem:
http://git.openembedded.org/cgit.cgi/openembedded/plain/recipes/linux/linux-rp-2.6.26/pxa-serial-hack.patch

Though, personally I'm preferring solution with moving PXA ports into
another namespace (be it ttySA, or ttyPXA, or whatever). So maybe it's
time to finally make a first step and apply something like Russell's patch now,
and then gradually deprecate usage of old ttyS namespace for PXA, or maybe
even left it as a non-default config option (so users who can't reconfigure
their userspace/bootloader can still use newer kernels with old behaviour).

I'd like to hear some comments on the subject from Eric (adding him to Cc:)

-- 
Best regards,
Dmitry "MAD" Artamonow

PXA/8250 UART Conflicts

[Eric Miao]

On Thu, May 13, 2010 at 11:40 PM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
> On 17:12 Tue 11 May ? ? , Russell King - ARM Linux wrote:
>> On Tue, May 11, 2010 at 11:00:36AM -0400, Michael Cashwell wrote:
>> > I'd like the tty layer to just assign the minor numbers in sequence,
>> > first come first served. But I don't see how to get that. Or is there
>> > some platform way to influence the tty range requested?
>>
>> It's just plain not supported. ?You can't have two different tty drivers
>> using the same namespace and have it work.
>>
>> Unfortunately, earlier on it was the opinion that "ttyS" means "serial
>> driver" and therefore "we shall use the ttyS namespace for our SoC
>> driver". ?And this is the resulting mess that it causes.
>
> Yup, that's a long standing bug (and still not fixed). I remember I first
> happened to stumble upon it about three years ago and it's already been old
> back then. In fact it's a general PITA on any PXA board with PCMCIA/CF
> slot (handhelds, for example, but not only) when you trying to use some
> serial PCMCIA peripherals (e.g. GPSes, wired and wireless modems,
> RS232 converters, maybe even bluetooth dongles). With 8250 enabled as a module
> and PXA serial built-in it simply doesn't works.
>
> Openembedded guys for ages have patched kernel with hacks like these to solve
> this problem:
> http://git.openembedded.org/cgit.cgi/openembedded/plain/recipes/linux/linux-rp-2.6.26/pxa-serial-hack.patch
>
> Though, personally I'm preferring solution with moving PXA ports into
> another namespace (be it ttySA, or ttyPXA, or whatever). So maybe it's
> time to finally make a first step and apply something like Russell's patch now,
> and then gradually deprecate usage of old ttyS namespace for PXA, or maybe
> even left it as a non-default config option (so users who can't reconfigure
> their userspace/bootloader can still use newer kernels with old behaviour).
>
> I'd like to hear some comments on the subject from Eric (adding him to Cc:)
>

No comment so far. Though I'm not sure if it might be time to bring pxa back
to 8250 :-)

PXA/8250 UART Conflicts

[Marc Zyngier]

On Tue, 11 May 2010 11:00:36 -0400, Michael Cashwell
<mboards@prograde.net>
wrote:
> Greetings,
> 
> I'm using a PXA270-based Gumstix and a provisional 2.6.33.2 kernel to
> explore supporting a dual 8250-like UART chip over i2c for one of our
> hardware guys. But enabling both the 8250 and pxa2xx-uart drivers
conflicts
> at the ttySn level. Both seem to do the following:
> 
> serial_core: uart_register_driver() ->
> tty_io:      tty_register_driver() ->
> char_dev:    register_chrdev_region()
> 
> using the same starting minor number. Thus the first driver gets
> /dev/ttyS0 and up and the rest fail with -EBUSY.
> 
> Am I missing something? Are these drivers just incompatible and Kconfig
> shouldn't let me turn both on? (In fact, doing so kills the console if
it's
> on an internal PXA uart because the 8250 driver loads first. That was
"fun
> with JTAG".)

Both Viper and Zeus platforms faced the exact same problem. On the Viper,
either we let the 8250 driver manage all the serial ports (including the
PXA ports), or we only have the 3 PXA UARTs. On the Zeus, the PXA driver is
simply out of the picture as the console lives on one of the 8250 UARTs.

> I'd like the tty layer to just assign the minor numbers in sequence,
first
> come first served. But I don't see how to get that. Or is there some
> platform way to influence the tty range requested?

I remember a SPARC hack in drivers/serial/8250.c (grep for CONFIG_SPARC)
for the exact same purpose. Not that I would recommend doing so for PXA or
any other platform...

        M.
-- 
Who you jivin' with that Cosmik Debris?

PXA/8250 UART Conflicts

[Michael Cashwell]

On May 11, 2010, at 12:29 PM, Marc Zyngier wrote:

> On Tue, 11 May 2010 11:00:36 -0400, Michael Cashwell wrote:
>> 
>> Am I missing something? Are these drivers just incompatible ... ?
> 
> Both Viper and Zeus platforms faced the exact same problem. On the Viper, either we let the 8250 driver manage all the serial ports (including the PXA ports) ...

Thanks to all who responded. For my UART eval I when with this approach.

Not to hijack my own thread, but I have the 8250 via i2c working in pio mode. (DMA mode calls a wait_ function and gave me a flood of "scheduling while atomic" BUGs.)

But alas, trying to do this via SPI is not working. It seems that even without DMA the SPI layer uses interrupts and a tasklet to keep the transfers going and the 8250 driver does most of its work at atomic time (either directly in the top-half or inside a spin_lock_irqsave).

Thus, the sync SPI calls hit the same "scheduling while atomic" problem as non-PIO i2c and the async calls (followed by a cpu_relax() waiting for my completion function to run) never complete. I've seen some messages about an SPI functions that would allow for scheduling but no clear resolution.

This has me wondering why the 8250 driver needs to globally disable interrupts so much. In fact, other than the special case where it shares IRQs with other drivers I don't see why it needs to globally stop interrupts at all. If it has sole possession of its IRQs it would seem to me that the top-half could just run the bottom half at task-time and have it service the hardware. If it did that calling into SPI would be OK.

I may just be confused at this point. I'm still pondering my (few apparent) options, but at least it works with i2c.

Thanks for the assistance.

-Mike