On Thu, 2005-07-14 at 14:46 +0100, Russell King wrote:
> Then we try to register the console, which may result in this UART
> becoming a console. So now we have a console which is in low power
> mode. Bad bad bad. No cookie for the serial layer today.
I don't know if this is a possible
On Thu, 2005-07-14 at 14:46 +0100, Russell King wrote:
Then we try to register the console, which may result in this UART
becoming a console. So now we have a console which is in low power
mode. Bad bad bad. No cookie for the serial layer today.
I don't know if this is a possible short
Alex Williamson wrote:
>
> David, would you mind
> trying this on the XR16L255x part? (ie. don't use console=ttyS, use
> console=uart,...) Thanks,
I wasn't even aware you could do this...
These are the serial ports I have:
ttyS0 at MMIO 0xc800 (irq = 15) is a XScale IXP425 internal
On Wed, Jul 13, 2005 at 11:04:56AM -0600, Alex Williamson wrote:
> On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote:
> >No, I think this is a problem with the broken A2 UARTs getting
> > confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP
> > or UART_CAP_EFR from the
On Wed, Jul 13, 2005 at 11:04:56AM -0600, Alex Williamson wrote:
On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote:
No, I think this is a problem with the broken A2 UARTs getting
confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP
or UART_CAP_EFR from the
Alex Williamson wrote:
David, would you mind
trying this on the XR16L255x part? (ie. don't use console=ttyS, use
console=uart,...) Thanks,
I wasn't even aware you could do this...
These are the serial ports I have:
ttyS0 at MMIO 0xc800 (irq = 15) is a XScale IXP425 internal
ttyS1 at
On Wed, 2005-07-13 at 11:04 -0600, Alex Williamson wrote:
> Just trying to make sure that there's not a latent bug that we enable
> a bad sleep mode when the UART is being used for the console.
Yes, this is the problem. When a UART is specified as the console
using "console=uart,...", the
On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote:
>No, I think this is a problem with the broken A2 UARTs getting
> confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP
> or UART_CAP_EFR from the capabilities list for this UART, it behaves
> normally. Also, just
On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote:
No, I think this is a problem with the broken A2 UARTs getting
confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP
or UART_CAP_EFR from the capabilities list for this UART, it behaves
normally. Also, just
On Wed, 2005-07-13 at 11:04 -0600, Alex Williamson wrote:
Just trying to make sure that there's not a latent bug that we enable
a bad sleep mode when the UART is being used for the console.
Yes, this is the problem. When a UART is specified as the console
using console=uart,..., the console
On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote:
> On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
> > There was a bug in this area - does it happen with latest and greatest
> > kernels?
>
>Yes, I'm using a git pull from ~5hrs ago. How recent was the bug
> fix? It
On Mon, 2005-07-11 at 21:17 +0100, Russell King wrote:
> On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote:
> > On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
> > > There was a bug in this area - does it happen with latest and greatest
> > > kernels?
> >
> >Yes, I'm
On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
> On Mon, Jul 11, 2005 at 01:00:08PM -0600, Alex Williamson wrote:
> > On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote:
> >
> > > I've redid the patch and added a check for this. Alex, could you test
> > > this version, please.
> >
>
On Mon, Jul 11, 2005 at 01:00:08PM -0600, Alex Williamson wrote:
> On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote:
>
> > I've redid the patch and added a check for this. Alex, could you test
> > this version, please.
>
>This detects the A2 ST16C255x as an XR16550, so apparently the
On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote:
> I've redid the patch and added a check for this. Alex, could you test
> this version, please.
This detects the A2 ST16C255x as an XR16550, so apparently the sleep
check doesn't work. I contacted Exar about these two seemingly
On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote:
I've redid the patch and added a check for this. Alex, could you test
this version, please.
This detects the A2 ST16C255x as an XR16550, so apparently the sleep
check doesn't work. I contacted Exar about these two seemingly
identical
On Mon, Jul 11, 2005 at 01:00:08PM -0600, Alex Williamson wrote:
On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote:
I've redid the patch and added a check for this. Alex, could you test
this version, please.
This detects the A2 ST16C255x as an XR16550, so apparently the sleep
On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
On Mon, Jul 11, 2005 at 01:00:08PM -0600, Alex Williamson wrote:
On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote:
I've redid the patch and added a check for this. Alex, could you test
this version, please.
This
On Mon, 2005-07-11 at 21:17 +0100, Russell King wrote:
On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote:
On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
There was a bug in this area - does it happen with latest and greatest
kernels?
Yes, I'm using a git pull
On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote:
On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
There was a bug in this area - does it happen with latest and greatest
kernels?
Yes, I'm using a git pull from ~5hrs ago. How recent was the bug
fix? It worked fine
Russell King wrote:
> On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote:
>
>>The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
>>XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
>>UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's
Russell King wrote:
On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote:
The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a
buggy
On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote:
> The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
> XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
> UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a
> buggy Exar ST16C255x.
On Wed, 2005-07-06 at 19:57 +0100, Russell King wrote:
> On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote:
> > The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
> > XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
> > UART_CAP_EFR |
On Wed, 2005-07-06 at 19:57 +0100, Russell King wrote:
On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote:
The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
UART_CAP_EFR | UART_CAP_SLEEP).
On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote:
The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a
buggy Exar ST16C255x.
Hi,
The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a
buggy Exar ST16C255x.
Any suggestion on how to differentiate between the two parts?
Hi,
The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a
buggy Exar ST16C255x.
Any suggestion on how to differentiate between the two parts?
28 matches
Mail list logo
