[U-Boot-Users] Burst I/O on PPC440GP

[U-Boot-Users] Burst I/O on PPC440GP

[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_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

[U-Boot-Users] Burst I/O on PPC440GP

[Stefan Roese]

Hi Gregg,

On Thursday 06 October 2005 19:37, Gregg Nemas wrote:
> 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?

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

[U-Boot-Users] Re: Burst I/O on PPC440GP

[Gregg Nemas]

Stefan Roese <sr <at> denx.de> writes:

> > 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.

> 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

[U-Boot-Users] Re: Burst I/O on PPC440GP

[Chuck Gales]

On 10/6/05, Gregg Nemas <gnemas@gmail.com> wrote:
> Stefan Roese <sr <at> denx.de> writes:
>
> > > 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.
>
> > 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
>
>
>
>
> -------------------------------------------------------
> 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