Re: Darwin, G5 and TimeBase sync
Re: Darwin, G5 and TimeBase sync
- Subject: Re: Darwin, G5 and TimeBase sync
- From: Benjamin Herrenschmidt <email@hidden>
- Date: Tue, 09 Nov 2004 18:44:46 +1100
> On my side, I've tried implementing the timebase synchronisation
> in linux, on a CY28508 based machine (older dual 2Ghz), and it doesn't
> seem to work. From what I see, register 1 of the chip seem to contain
> 0xff, and the write of 0xf3 to it (clearing 0x0c) doesn't seem to have
> any effect... though If I turn the I2C interface from combined mode to
> stdsub mode for the write (the read stays in combined mode of course),
> then I get a lockup, which could mean some clock went off ...
Ok, I can confirm now that I have a working implementation in Linux on
both Pulsar and Cypress chip, I _think_ (again, I didn't have a chance
to actually test with the actual Darwin code, but I think the problem
is indeed there) you have a bug. Here is my a resume of my analysis:
NOTE: This may have gone unnoticed due to the rather slow timebase
(33Mhz) used, the flags + wait loops using for handshacking the 2 CPUs
while passing the timebase around may end up beeing "good enough" to
give a good synchronisation without the HW freeze actually working.
- If the code in Darwin actually froze the timebase as it's supposed
to, I suspect it would cause a lockup as soon as the i2c command
stopping the TB clock reaches the clock chip. The i2c driver does
IODelay() which uses the timebase.
- From my experiments, the reason it doesn't work is that the combined
mode used for reading from the i2c chip isn't suitable for writing to
it. In that case, an stdsub write should be used, that is the write of
the register address (| 0x80) and the actual data byte write should only
be separated by an ACK, not by a new start + address cycle. I found that
from the CY28510 datasheet which sounds similar to the 28508 used by
Apple. Experiment (reading back the register and testing if the TB is
actually frozen) confirms this. The Pulsar seem to behave the same way.
- Finally, a note about the IODelay in the I2C driver... I wonder if
this delay is actually necessary at all. I've never had it in the Linux
driver for the keywest/uni-n i2c cell without noticeable problem, and
the OF forth driver doesn't have any delay neither. Switching
explicitely to combined when reading and stdsub when writing in
MacRISC4CPU.cpp would then work with just the removal of that delay. Of
course, there may be a reason I don't know to have this delay here but
if that is the case, then your whole scheme cannot work, unless that
IODelay is replaced by some other implementation, for example using the
Keylargo timer.
Hope this is useful,
Regards,
Ben.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden