Walnut 405GP and SBLive sound card

Walnut 405GP and SBLive sound card

[Ira Weiny]

I am at the end of my rope...

What I know is:
I have a Walnut 405GP rev D board and a Creative SBLive sound card.
I have this card running on a G3 powermac. (endian fix)
And the card does get recognized and will start/top playing a continuous
tone at the correct times on the Walnut board.
There is a cache conherentcy issue on the 405GP when doing DMA.
Basically there is a hardware bug which does not flush the cache on
writes.  (I can't find the documentation from IBM which sort of hints at
this.)
I am _very_ confused by the virt_to_bus, virt_to_phys, ioremap,
memremap, and just about every other memory related functions I walk
through.  (and I can't seem to find PPC specific explanations for these
functions)
The driver calls the pci_(alloc/free)_consistent functions for the DMA
transfer buffers.

What I think:
I need to call dma_cache_wback_inv (with the correct address and size;
at the correct time)

What I am assuming:
The kernel I have (mvista 2001-04-12) works with a Promise IDE controler
so the PCI bridge must be setup and working ok.

My questions:
1) Where can I find PPC centric information on the kernel internals.
(Not just for this problem but as a general reference.)
I have purchased books which focus on the intel arch and have been to
many web sites which explain "UNIX internals" theory quite well.  But I
know theory...
2) Is dma_cache_wback_inv the correct way to do this?  If not, what is?

Thanks in advance,
Ira Weiny
iweiny@acm.org

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Walnut 405GP and SBLive sound card

[Dan Malek]

Ira Weiny wrote:

> There is a cache conherentcy issue on the 405GP when doing DMA.
> Basically there is a hardware bug which does not flush the cache on
> writes.

I'm not sure it's a bug, it's the way the part is designed.  It does
not have a hardware coherent cache, you have to manage it in
software.

> I am _very_ confused by the virt_to_bus, virt_to_phys, ioremap,
> memremap, and just about every other memory related functions I walk
> through.

Me, too.  So, I rewrote them :-).  Actually, I made some minor changes
for the 4xx and 8xx processors so the functions actually look up
real page table entries every time, instead of just assuming they
can perform some simple address arithmetic.  This was necessary for
the 4xx and 8xx, because of the mapping of internal devices, and doesn't
hurt on other processors.  These functions will also work correctly
with dynamically allocated kernel memory, although they aren't expected
to do so (but, I don't know why).

> The driver calls the pci_(alloc/free)_consistent functions for the DMA
> transfer buffers.

I'm currently fixing these functions to "do the right thing" on the
PowerPCs that are not cache coherent (4xx and 8xx).  There are still
lots of PCI drivers that don't call these functions and assume a
hardware cache coherent system, so those will need to be modified if
you choose to use one.

> I need to call dma_cache_wback_inv (with the correct address and size;
> at the correct time)

Since this is a PCI device, you should probably can the PCI
version of these operations, such as pci_dma_sync_single() or
pci_dma_sync_sg(), for example.

> The kernel I have (mvista 2001-04-12) works with a Promise IDE controler
> so the PCI bridge must be setup and working ok.

Not a good assumption (because I have recently broken it :-).  Several
people have contributed to a proper PCI enumeration function for PowerPC,
and that will soon find its way into this port.  Many of the PCI
features or controllers that appear to work on the 4xx and 8xx are
unique hacks for that purpose and don't imply anything else is going
to work.  Many people are working as quickly as we can to bring the
4xx up to the same functional level as other PowerPCs, and PCI is
receiving the most attention right now.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/