Booting Imac G5

[J. Mayer]

On Mon, 2004-11-22 at 08:42, Benjamin Herrenschmidt wrote:
> > OK, my mistake...
> > I forgot one point: I was using 2.6.10-rc2 while my previous tests were
> > with 2.6.10-rc1.
> > So it seems the bug was corrected between those two pre-release. Great !
> > 
> > For your information, here are some registers dumps:
> > PVR: 003c0300 MSR: 9000000000009032 PIR: 00000000
> > HID0: 0051108100000000 HID1: fd3c200000000000
> > HID4: 0000001000000000 HID5: 0000000000000000
> > 
> > For the SMU driver I need a function that uses dcbf, because we send a
> > buffer address to the SMU and the chip may modify this buffer. So I now
> > added another helper, like flush_dcache_phys_range but using dcbf
> > instead of dcbst.
> 
> Why ? dcbst should work as well... I use flush_dcache_phys_range() for
> the IOMMU without problem so far...

I need to invalidate the L1 cache because I need the memory to be read
again after the SMU updated the buffer. If I don't, I will read back my
request instead of the SMU answer.
This because the caches don't know that another chip will update this
memory area.
In fact, I spent quite a long time before I understood why I didn't get
valid SMU messages back....

> > > In addition, the L1 D cache of the 970 is write-through, so it should
> > > never contain dirty data anyway... so neither dcbf nor dcbst is strictly
> > > necessary, provided we have a sync before the icbi afaik ...
> > 
> > Well, don't we still need dcbst to flush the L2 cache ?
> 
> Not for flush_icache_dcache (that is I/D cache coherency) since only the
> L1 cache is split.

Well, OK, I was still thinking about flush_dcache_range &
flush_dcache_phys_range....

> > Furthermore, in flush_dcache_range & flush_dcache_phys_range, I can see
> > no icbi and I don't see why we should have one, as the thing is to flush
> > data cache, not icache.
> 
> They are mean't for a different purpose, which is to sync with
> non-coherent DMA devices, like the IOMMU (I'm not sure you actually need
> something like that for the SPU, normally, the northbridge should take
> care of coherency ...)

As the SMU is a separate chip, I'm not so surprised that the northbridge
does not know that it may "corrupt" some memory. The SMU may act as a
fake CPU while doing this if it was located on the processor bus.

If I understand things well, the CPU acts as an IIC slave for the SPU
(which seems to be a part of the SMU) then can receive commands from
this unit. But it seems that the CPU cannot talk directly to the SPU.

I implemented SMU communication the same way Apple does in the OF
driver: we talk through a doorbell buffer and a GPIO all located in the
MacIO space. The doorbell buffer only contains the physical address of
the buffer used to exchange data with the SMU.

-- 
J. Mayer <l_indien at magic.fr>
Never organized