site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com
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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com