[Top] [All Lists]

readb() and writeb() timings

Subject: readb() and writeb() timings
From: Freddy Spierenburg <>
Date: Tue, 26 Sep 2006 17:35:37 +0200
Original-recipient: rfc822;
User-agent: Mutt/1.5.13 (2006-08-11)

And then it's time to play with my external UART again, which I
try to connect to the AMD Alchemy AU1100 processor. The UART
is connected by means of chip-select two and tree of the static
bus controller.

Of course it still doesn't work, but in playing with it I am
dazed and confused about some strange timings I do not
understand. Hopefully somebody over here is willing and able to
explain things a little bit to me.

I have written a small kernel module that will load and tries to
communicate with the UART. I see chip-select, read-enable,
write-enable and the likes toggle, so I'm really talking to the
UART. But in talking to it I do not understand some things
regarding readb() and writeb().

I do two readb()'s after each other like below:

        #define LSR 0x14
        void __iomem *p;

The readb()'s translate to the MIPS assembly below:

        lbu     $2,20($16)
        lbu     $2,20($16)

If I than use an oscilloscope to measure the time between the
assertion of the chip-select's I get approx. 250ns. So whatever I
try, I will not get two consecutive readb()'s faster than 250ns
after each other. No worries yet, since my friendly UART does not
want things to happen more fast than it can handle.

Next I do two writeb()'s after each other like below:

        /* I have skipped the ioremap() etc... for brevity. */

The writeb()'s translate to the MIPS assembly below:

        li      $3,165                  # 0xa5
        sb      $3,28($16)
        li      $3,90                   # 0x5a
        sb      $3,28($16)

Now the time between the assertion of the chip-select's is
approx. 175ns. Still no worries and I can again be happy with the

But here comes the great evil (tm). Now I do a readb() right
after a writeb():


And this translates like expected to:

        li      $3,90                   # 0x5a
        sb      $3,28($16)
        lbu     $3,20($16)

But now suddenly the CPU really cranks up it's engine and is able
to assert the chip-select again within approx. 4ns. And now I'm
in big trouble, since my friendly UART can't cope in this fast
paced world.

I'm also in big trouble, since I do not understand how this is
possible. How can it be that two consecutive readb()'s or
writeb()'s are at least 175ns apart from each other and a readb()
after a writeb() happens fast like hell? Can anybody explain this
to me?

Might be nice to add that a writeb() after a readb() takes again
a long time; approx. 700ns.

Also I have played a lot with the values in the mem_sttime
register and the long delay's in between do not stem from those
values. For some reason it just takes at least 250ns between two
consecutive readb()'s and 175ns between two writeb()'s. Anybody
got a hint why? And then especially why it does not take that
long between a writeb() and a readb()?

$ cat ~/.signature
Freddy Spierenburg <>
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1  E588 6F17 FD5D 7941 D1E1
$ # Please read before complain!

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>
  • readb() and writeb() timings, Freddy Spierenburg <=