DCD interrupt for i.MX25 UART

DCD interrupt for i.MX25 UART

[Uwe Kleine-König]

Hello,

I have a problem with an UART on an i.MX25 based machine. I implemented
DCD (and other handshake lines) irq handling[1].

Now a user of this patch noticed that DCD handling (at least) is broken.
The problem is that the USR2_DCDDELT bit doesn't clear:

	root at hostname:~ memtool md 0x43f90080+0x34  
	43f90080: 00000000 00004021 0000078c 00004002                ....!@....... at ..
	43f90090: 00000b41 00002040 00005268 0000002b                A...@ ..hR..+...
	43f900a0: 00000000 000000bf 00002e62 00000008                ........b.......
	43f900b0: 0000251c                                           .%..

	root at hostname:~ memtool mw 0x43f90098 0x0x40

	root at hostname:~ memtool md 0x43f90080+0x34  
	43f90080: 00000000 00004021 0000078c 00004002                ....!@....... at ..
	43f90090: 00000b41 00002040 00005268 0000002b                A...@ ..hR..+...
	43f900a0: 00000000 000000bf 00002e62 00000008                ........b.......
	43f900b0: 0000251c                                           .%..

In fact even writing 0xffff doesn't change the register, where I would expect
that the DCDDELT bit (0x40) disappears. I'm sure there is nothing toggling this
line.

The net effect is that the irq blocks the machine until it is disabled with

	[   51.885987] irq 61: nobody cared (try booting with the "irqpoll" option)

.

This is on an i.MX25 and I checked the erratas also of the newer i.MX
cpus, but I didn't find anything.

Did I miss something? Is this a known bug? Do you have a recommendation
other than not to set UCR3_DCD? I cannot test the same problem for RI
because my hardware doesn't use it, but I wouldn't be surprised if that
had the same problem.

It would be great to get a statement from you on this topic.

Best regards
Uwe

[1] Message-Id: 1457605569-7828-3-git-send-email-u.kleine-koenig at pengutronix.de

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

DCD interrupt for i.MX25 UART

[Lothar Waßmann]

Hi,

On Wed, 23 Mar 2016 16:36:38 +0100 Uwe Kleine-K?nig wrote:
> Hello,
> 
> I have a problem with an UART on an i.MX25 based machine. I implemented
> DCD (and other handshake lines) irq handling[1].
> 
> Now a user of this patch noticed that DCD handling (at least) is broken.
> The problem is that the USR2_DCDDELT bit doesn't clear:
> 
> 	root at hostname:~ memtool md 0x43f90080+0x34  
> 	43f90080: 00000000 00004021 0000078c 00004002                ....!@....... at ..
> 	43f90090: 00000b41 00002040 00005268 0000002b                A...@ ..hR..+...
> 	43f900a0: 00000000 000000bf 00002e62 00000008                ........b.......
> 	43f900b0: 0000251c                                           .%..
> 
> 	root at hostname:~ memtool mw 0x43f90098 0x0x40
                                              ^^^^^^
This looks rather fishy.

> 	root at hostname:~ memtool md 0x43f90080+0x34  
> 	43f90080: 00000000 00004021 0000078c 00004002                ....!@....... at ..
> 	43f90090: 00000b41 00002040 00005268 0000002b                A...@ ..hR..+...
> 	43f900a0: 00000000 000000bf 00002e62 00000008                ........b.......
> 	43f900b0: 0000251c                                           .%..
> 
> In fact even writing 0xffff doesn't change the register, where I would expect
> that the DCDDELT bit (0x40) disappears. I'm sure there is nothing toggling this
> line.
> 
Are you sure the clock is enabled when doing your manual tests?


Lothar Wa?mann

DCD interrupt for i.MX25 UART

[Uwe Kleine-König]

Hallo Lothar,

On Tue, Mar 29, 2016 at 01:14:43PM +0200, Lothar Wa?mann wrote:
> On Wed, 23 Mar 2016 16:36:38 +0100 Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > I have a problem with an UART on an i.MX25 based machine. I implemented
> > DCD (and other handshake lines) irq handling[1].
> > 
> > Now a user of this patch noticed that DCD handling (at least) is broken.
> > The problem is that the USR2_DCDDELT bit doesn't clear:
> > 
> > 	root at hostname:~ memtool md 0x43f90080+0x34  
> > 	43f90080: 00000000 00004021 0000078c 00004002                ....!@....... at ..
> > 	43f90090: 00000b41 00002040 00005268 0000002b                A...@ ..hR..+...
> > 	43f900a0: 00000000 000000bf 00002e62 00000008                ........b.......
> > 	43f900b0: 0000251c                                           .%..
> > 
> > 	root at hostname:~ memtool mw 0x43f90098 0x0x40
>                                               ^^^^^^
> This looks rather fishy.

Probably a cut-and-paste problem. I tried this several times with
various values, the bit doesn't clear.

> > 	root at hostname:~ memtool md 0x43f90080+0x34  
> > 	43f90080: 00000000 00004021 0000078c 00004002                ....!@....... at ..
> > 	43f90090: 00000b41 00002040 00005268 0000002b                A...@ ..hR..+...
> > 	43f900a0: 00000000 000000bf 00002e62 00000008                ........b.......
> > 	43f900b0: 0000251c                                           .%..
> > 
> > In fact even writing 0xffff doesn't change the register, where I would expect
> > that the DCDDELT bit (0x40) disappears. I'm sure there is nothing toggling this
> > line.
> > 
> Are you sure the clock is enabled when doing your manual tests?

I guess they are. For sure the same thing happens with the driver active
and the device open. And the symptoms are the same: If the DCDDELTA irq
is enabled and active the machine is stuck until the irq upper layers
disable the respective irq.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |