Subject: Re: Strange transmit corruption in jsm driver on geode sc1200
	system
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <20060825203047.GH13641@csclub.uwaterloo.ca>
References: <20060825203047.GH13641@csclub.uwaterloo.ca>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 25 Aug 2006 22:20:17 +0100
Message-Id: <1156540817.3007.270.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1222
Lines: 30

Ar Gwe, 2006-08-25 am 16:30 -0400, ysgrifennodd Lennart Sorensen:
> The driver is doing memcpy_toio to tranfer data to the transmit FIFO
> (which is a 64byte memory mapped block of memory on the PCI bus as far
> as I can tell).  The data in the transmit queue is in the right order

That should be staying in order unless the device memory is mislabelled
and prefetchable etc.

> being passed to memcpy_toio, but somehow by the time it is in the uart
> and goes out the transmiter, every 4th byte is moved 3 bytes back.

What happens if you swap the memcpy_toio with while() writeb() ?

> I read something about the geodes doing memory write reordering, but
> that it is supposed to magically not screw up PCI writes.  I have no
> idea if it is or not though.

They do a lot of stuff but it should not affect the PCI side and I'd
expect it to do other things than byte lane re-ordering.

> Does anyone have any suggestions for something to try?

Is the buffer 32bit aligned ?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/