Burst I/O on PPC440GP
I am trying to perform I/O with a device attached to the external peripheral bus on a PPC440GP embedded processor. I am able to address the device and read and write to it, but I am only able to do non-burst I/O. Do I need to do something special to enable burst transactions? I've programmed the EBC0_B5CR and EBC0_B5AP device control registers appropriately to enable burst mode, but the transactions are still single I/O.
I've been testing this by using the u-boot mw.l command. Do I need to use PPC-specific instructions to perform burst I/O, or should an ordinary programmed I/O (using 32-bit write operations) be automatically queued up and converted to burst transactions?
The TLB I've added for the I/O region has the caching inhibit (I) and guarded
(G) bits set. Does caching or speculative access need to be enabled to allow bursting? Even if I added a TLB entry, it wouldn't do me any good in Linux, since it manages TLBs itself. So how would I do this from a Linux kernel driver?
Thanks.
Gregg
Hi Gregg,
Quoted 8 lines · Gregg Nemas
I am trying to perform I/O with a device attached to the external peripheral bus on a PPC440GP embedded processor. I am able to address the device and read and write to it, but I am only able to do non-burst I/O. Do I need to do something special to enable burst transactions? I've programmed the
EBC0_B5CRandEBC0_B5APdevice control registers appropriately to enable burst mode, but the transactions are still single I/O.
Quoted 4 lines
I've been testing this by using the u-boot mw.l command. Do I need to use PPC-specific instructions to perform burst I/O, or should an ordinary programmed I/O (using 32-bit write operations) be automatically queued up and converted to burst transactions?
Do you want to transfer bigger chunks of data? If yes, you may want to take a look at the dma controller of the 440gp. It definately is able to generate burst transactions and probably the ideal solution for your needs.
Another way to get burst transactions, is of course to use the cache, but I don't think that this is what you are looking for.
Best regards,
Stefan
Quoted 8 lines · Stefan Roese <sr <at> denx.de> writes:
Quoted 4 lines
I've been testing this by using the u-boot mw.l command. Do I need to use PPC-specific instructions to perform burst I/O, or should an ordinary programmed I/O (using 32-bit write operations) be automatically queued up and converted to burst transactions?
Do you want to transfer bigger chunks of data? If yes, you may want to take a look at the dma controller of the 440gp. It definately is able to generate burst transactions and probably the ideal solution for your needs.
No, actually it will be relatively small transfers (16-128 bytes). I considered using the DMA controller, but thought I would start out simple.
Quoted 2 lines
Another way to get burst transactions, is of course to use the cache, but I don't think that this is what you are looking for.
You say "of course", but it really isn't at all clear to me how this works. Why does enabling the cache allow burst operations? You are right that it is not what I would normally want to do for device I/O memory.
Thanks for your help.
Gregg
Quoted 28 lines · Gregg Nemas
Quoted 8 lines · Stefan Roese <sr <at> denx.de> writes:
Quoted 4 lines
I've been testing this by using the u-boot mw.l command. Do I need to use PPC-specific instructions to perform burst I/O, or should an ordinary programmed I/O (using 32-bit write operations) be automatically queued up and converted to burst transactions?
Do you want to transfer bigger chunks of data? If yes, you may want to take a look at the dma controller of the 440gp. It definately is able to generate burst transactions and probably the ideal solution for your needs.
No, actually it will be relatively small transfers (16-128 bytes). I considered using the DMA controller, but thought I would start out simple.
Quoted 2 lines
Another way to get burst transactions, is of course to use the cache, but I don't think that this is what you are looking for.
You say "of course", but it really isn't at all clear to me how this works. Why does enabling the cache allow burst operations? You are right that it is not what I would normally want to do for device I/O memory.
Thanks for your help.
Gregg
Quoted 9 lines
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Gregg,
With caching disabled, the CPU considers that your external device
needs to be updated with every memory write, since other devices may also access the memory and need to have the correct data. With caching enabled, the CPU will store your writes internally until the memory cache is flushed, which forces the writes to the external device. When flushing the cache (which is usually a relatively large amount of data, the cache will use burst transactions to write the data. However, with caching enabled, there is the possibility that the data in the external device is not in sync with what the CPU thinks is there, so if other devices access the external device, they will get the incorrect data.
Chuck