Got some feedback today on the xc5000 tree I posted yesterday. It's been generally positive, although one user is reporting some suspicious behavior.
I also started debugging why the Pinnacle 800i stopped working with my tree. I bisected the patch series and determined that the problem was introduced in the patch that started doing power management by pulling the xc5000 reset pin low. I had assumed it was some problem with re-initializing the xc5000 after being brought out of reset, however that was not the issue. It turns up that the xc5000 reset callback is strobing the cx23883's MO_SRST_IO pin as opposed to a GPIO. As a result, both the xc5000 and the s5h1409 were being reset, and the s5h1409 was being left in an unknown state. As a quick hack to prove my theory, I added a call to s5h1409_init() to s5h1409_set_parameters() and I started to get lock again.
Here's the problem: I don't know whether MO_SRST_IO controls some power supply that feeds the two parts, or whether it *really* is tied to both the reset pin of the xc5000 and the s5h1409. If they are not independently addressable, then I don't know what I'm going to do (disable power management for that board perhaps?).
To make life more annoying, the xc5000 is under an RF shield, so I cannot just break out a meter and trace out the pin, unless I'm willing to get access to a hot air rework station so I can remove the shield. I might be able to iterate the GPIOs in software, but I'm nervous about driving one of the input pins, which could burn something out.
I sent some email to my engineering contact at Pinnacle, and if I'm lucky he can just look at the schematic and tell me how it's wired up. Otherwise I'm going to have to do it the hard way...
