Known issues with amba-pl010.c driver?

Known issues with amba-pl010.c driver?

[H Hartley Sweeten]

Hello all,

Are there any known issues with the amba-pl010.c driver?

I have an application running on an ep93xx based system that uses one
of the serial ports to communicate with another board.  I am seeing
pauses while sending data from the ep93xx to the other board.

I see a similar pause when using one of the other serial ports as a
console.  When doing something that spews a lot of data to the port
the delays are very noticeable.  For instance the command:

/ # du

Spews the correct output but there are a number of pauses.

Both ports are running at a baud rate of 57600 if that matters.

Is there any way to debug this?

Thanks,
Hartley

Known issues with amba-pl010.c driver?

[Russell King - ARM Linux]

On Tue, May 18, 2010 at 07:22:12PM -0500, H Hartley Sweeten wrote:
> Are there any known issues with the amba-pl010.c driver?

I'm not aware of any problems with it.  It was used on ARM's early
Integrator platforms, but not their later ones having been superseded
by the PL011 primecell.

> I see a similar pause when using one of the other serial ports as a
> console.  When doing something that spews a lot of data to the port
> the delays are very noticeable.  For instance the command:

How long are these delays?

Known issues with amba-pl010.c driver?

[H Hartley Sweeten]

On Friday, May 21, 2010 12:32 PM, Russell King wrote:
> On Tue, May 18, 2010 at 07:22:12PM -0500, H Hartley Sweeten wrote:
>> Are there any known issues with the amba-pl010.c driver?
>
> I'm not aware of any problems with it.  It was used on ARM's early
> Integrator platforms, but not their later ones having been superseded
> by the PL011 primecell.
>
>> I see a similar pause when using one of the other serial ports as a
>> console.  When doing something that spews a lot of data to the port
>> the delays are very noticeable.  For instance the command:
>
> How long are these delays?

Hard to tell, but it is very noticeable just doing something like 'dmesg'
on the console.

I first get some random number of characters, anywhere from none to something
less than a full line (80 characters).  Then there is a noticeable pause.  This
is followed by some random length block of data, another pause, then the
remainder of the output.

I'm not sure if it will help but the 'dmesg' output on my system is 7,472
bytes.

It might have nothing to do with the pl010 driver itself.  I just don't know
where to start digging in the driver stack to figure out where the pauses are
coming from.

Regards,
Hartley

Known issues with amba-pl010.c driver?

[Russell King - ARM Linux]

On Fri, May 21, 2010 at 04:17:28PM -0500, H Hartley Sweeten wrote:
> Hard to tell, but it is very noticeable just doing something like 'dmesg'
> on the console.
> 
> I first get some random number of characters, anywhere from none to something
> less than a full line (80 characters).  Then there is a noticeable pause.  This
> is followed by some random length block of data, another pause, then the
> remainder of the output.
> 
> I'm not sure if it will help but the 'dmesg' output on my system is 7,472
> bytes.
> 
> It might have nothing to do with the pl010 driver itself.  I just don't know
> where to start digging in the driver stack to figure out where the pauses are
> coming from.

I assume that this isn't a new problem, but something that's always
happened?

The function in pl010 which loads the characters into the TX fifo is
pl010_tx_chars().  Note that without XON/XOFF flow control,
uap->port.x_char will always be zero.

The loop which loads the FIFO is:

        count = uap->port.fifosize >> 1;
        do {
                writel(xmit->buf[xmit->tail], uap->port.membase + UART01x_DR);
                xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
                uap->port.icount.tx++;
                if (uart_circ_empty(xmit))
                        break;
        } while (--count > 0);

and the thinking here is that the hardware gives us an interrupt when the
FIFO drops below half-full, so we load the FIFO up with up to half the
maximum number of characters at each interrupt.

In the case of ARM's PL010, that's a 16 byte FIFO - but yours may be
a different depth.  If it's smaller, the driver needs to know that so
it doesn't overrun the FIFO.  I'd suggest ensuring that 'fifosize' is
correct for your implementation.

Known issues with amba-pl010.c driver?

[H Hartley Sweeten]

On Friday, May 21, 2010 2:35 PM, Russell King wrote:
> On Fri, May 21, 2010 at 04:17:28PM -0500, H Hartley Sweeten wrote:
>> Hard to tell, but it is very noticeable just doing something like 'dmesg'
>> on the console.
>> 
>> I first get some random number of characters, anywhere from none to something
>> less than a full line (80 characters).  Then there is a noticeable pause.  This
>> is followed by some random length block of data, another pause, then the
>> remainder of the output.
>> 
>> I'm not sure if it will help but the 'dmesg' output on my system is 7,472
>> bytes.
>> 
>> It might have nothing to do with the pl010 driver itself.  I just don't know
>> where to start digging in the driver stack to figure out where the pauses are
>> coming from.
>
> I assume that this isn't a new problem, but something that's always
> happened?

Not really sure.  I have always used the serial port as a console and never really
noticed the problem.  But, now that I'm trying to actually use one of the ports
in a user app to send data it's very apparent.  That's when I noticed it on the
console also.

> The function in pl010 which loads the characters into the TX fifo is
> pl010_tx_chars().  Note that without XON/XOFF flow control,
> uap->port.x_char will always be zero.
>
> The loop which loads the FIFO is:
>
>         count = uap->port.fifosize >> 1;
>         do {
>                 writel(xmit->buf[xmit->tail], uap->port.membase + UART01x_DR);
>                 xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
>                 uap->port.icount.tx++;
>                 if (uart_circ_empty(xmit))
>                         break;
>         } while (--count > 0);
> 
> and the thinking here is that the hardware gives us an interrupt when the
> FIFO drops below half-full, so we load the FIFO up with up to half the
> maximum number of characters at each interrupt.
> 
> In the case of ARM's PL010, that's a 16 byte FIFO - but yours may be
> a different depth.  If it's smaller, the driver needs to know that so
> it doesn't overrun the FIFO.  I'd suggest ensuring that 'fifosize' is
> correct for your implementation.

The ep93xx pl010 uarts have 16 byte transmit and receive FIFOs.  Also, the 
interrupt does occur when the transmit FIFO is at least half empty.  I also
verified that the FIFOs are enabled.

Regards,
Hartley