Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?

On Thu, Feb 02, 2006 at 09:45:04AM -0800, Eugene Surovegin wrote:

On Thu, Feb 02, 2006 at 07:37:01AM -0700, Matt Porter wrote:

quoted

I mentioned the BE iomap variants that are being used on some non-pci
parisc devices already. I'll give a partial example of something that
is non-pci yet "arch-independent".

Take a non-pci EHCI core (yes, I know it's little endian by definition
but suspend reality for a second).  You can create an arch-independent
EHCI driver that uses the platform bus by using the iomap accessors.
Since these cores are licensed every day by XYZ startups for their
latest "gee-whiz" SoC, it reasons that you'll see the same core on
multiple licensable SoC architectures. I've seen one such thing
on MIPS.

We also know that major semiconductor companies do the same thing
for their peripherals in some cases. They're just as willing to
buy somebody else's USB core, for example.  So, having a BE
non-pci device cross platform isn't a stretch.

Take a look at drivers/scsi/53c700.{c,h}. That generic driver
is why BE iomap accessors were added. It's in the process of
being shared between parisc and m68k.

Matt, my problem with this approach is that it repeats the same 
old mistakes but in "BE-mode", e.g. _assuming_ some access mode and 
hard-coding it into the driver. I fail to see how assuming big-endian 
is any better than assuming little-endian in this case. And this is 
not _portable_ in my book, no matter what some people want me to 
believe.

This fails miserably when for example you have a bus which does byte 
swaps in every half-word. And yes, I have such device on my table and 
I have to port PCMCIA/PCI drivers to this SoC :).

Yuck. But a good example that there are always ill-behaved exceptions.

Here is how inb looks like:

static inline u8 fpi_inb(unsigned long port)
{
    port ^= 1;
    return inb(port);
}

IMO, truly portable and driver independent I/O accessors should be 
implemented as a function pointers on per-bus (at least) basis which 
can be overridden by arch or board code. In this case we can get rid 
of "ugly" ifdefs in driver code :).

There are a ton of reasons for this too, but there's been resistance
in the past to anything adding an additional dereference to the ia32
case.  I think there's been some proposals to get around this and
maybe even some small level of acceptance. However, since the server
folks don't need it, it's slow going to get such a major change pushed
through.

FWIW, some Xscale IXPs could use the per-bus pointer accessors to
manage the some floating I/O windows more cleanly as well. RapidIO
has some use for it too. It's not just byte swapping at least.

You could drive this change, you know. :)

-Matt

Hi all,

I've been testing the PLB4 and PLB3 DMA controllers
for memory-to-memory transfers between the Yosemite
board SDRAM and a PCI board.

The PCI board contains a PLX PCI-9054 PCI controller
(PCI-to-local bus bridge), and the board contains
SDRAM at the addresses I was testing DMA.

So, the test is basically:

Yosemite SDRAM <-> 440EP bridge <-> PLX-9054 bridge <-> SDRAM

Here's the problem/issue:

PLB4 burst DMA reads are performed as blocks of 32-bytes
(8 transfers of 4-bytes), with the PCI command code
toggling between memory-read-multiple (MRM) and
then memory-read-line (MRL). The change in PCI command
code causes the PLX-9054 controller to consider each
32-byte burst to be a new transaction, and hence
it flushes its internal read FIFO and disconnects from
the local bus for each burst.

The PLB3 DMA controller does not do this, it always
bursts using a memory-read-line (MRL) PCI command code.
Hence the PLX-9054 can determine that the next 32-byte
burst follows on from the previous, and it can deliver
data from its internal FIFOs.

The performance results for transfers between the
Yosemite SDRAM and a device on the 33MHz/32-bit PCI bus were;

   DMA controller    Read          Write
   --------------    ----          -----

      PLB4           19.9MB/s     46.5MB/s

      PLB3           46.0MB/s     46.7MB/s

For the curious, here is the section from my test doc
containing logic analyzer traces;

http://www.ovro.caltech.edu/~dwh/yosemite_440ep_dma.pdf

The performance is below that of the maximum 132MB/s
achievable on the PCI bus. But since the DMA controllers
on the 440EP have to first read and then write,
I don't expect the DMA to do much better than 60MB/s.
So, the ~50MB/s I observed for the majority of tests
seems pretty reasonable.

I haven't had a chance to look at the 440EP PCI bridge
configuration registers that might lead to the use of the
MRM/MRL commands. I'll do that next. I just figured I'd
post these results now, so that others reading this
list might comment (Stefan from Denx comes to mind :))

Cheers
Dave