kernel 2.6.15: cpm_uart driver broken?

[Vitaly Bordug]

On Tue, 18 Apr 2006 16:05:40 +0200
David Jander <david.jander at protonic.nl> wrote:

> On Tuesday 18 April 2006 15:22, Vitaly Bordug wrote:
> >[..]
> > Well, existing code works just fine on 885ads and 866ads, that use SMC1 and
> > SMC2 as UARTs.
> 
> Interesting.
> 

And for PQ2 I can add 8260 , PQ2fads and 8272ads that had no issues with current driver
> > > I'm pretty sure the following is wrong, but I can't seem to fix it
> > > either. This seems to apply for both PQ and PQ2 type uarts:
> > > from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
> >
> > That's wrong - cpm_uart_cpm1.c applies to PQ only...
> 
> I know. cpm_uart_cpm2.c contains the same code, so it should be as broken as 
> the cpm_uart_cpm1.c.
pq2 are cache-coherent, so there are no such troubles in there. And allocation routine is different of course.
> 
> >[...]
> > Well, since it works on other boards, and kmalloc stuff seems to sorta work
> > as well, then I guess reason is screwed DMA thing for your board.
> > Check/alter CONFIG_CONSISTENT_* things and see if it will help.
> 
> I did not touch de defaults. What are the rules to change them? What do I have 
> to look out for?
> CONFIG_CONSISTENT_START = 0xff100000 and I suspect a problem here if I was 
> using MTD (currently disabled) since flash is at physical adress 
> 0xfe000000-0xffffffff on my board. Isn't MTD going to io_remap that area to 
> that same virtual adress? How's that supposed to work then?
> I changed CONFIG_CONSISTENT_START to 0xfd100000 and now the system freezes 
> when I write to the serial port :-(
> 

Unfortunately, I know nothing where the correct thing should be pulled from...
But the problem lies in dma stuff from what I can say.

> > And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf
> > etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are
> > never used actually in the code, hereby there is no difference what values
> > they contain...
> 
> Argh. Code looks obviously broken, but since it isn't used, it just works. 
> That is not good! We should fix that either way then.

The overhaul is on the way, I'll put the cleanup of the unused stuff together with other changes.

-- 
Sincerely, 
Vitaly