Switching OMAP HFCLK during runtime

Matt Weber said:

1) Source a good OMAP HFCLK 19.2mhz clock (CLOCK1)

2) boot linux

3) load a FPGA that will generate an additional 19.2Mhz HFCLK  (CLOCK2) from a higher resolution source

This much sounds ok...

Matt Weber said:

4) Switch to (CLOCK2) without doing anything on the omap to prepare for that switch or even compensate for it.....  This is assuming USB is up and functional and other peripheral interfaces. 

I think you already know the answer to this one!  You definitely can't just switch it over blindly.  One specific issue that comes to mind would be if the clocks are nearly 180 degrees out of phase that you would get a "blip" in the clock signal when making the switch, i.e. for one clock period you would see only a small fraction of a clock.

I do have an idea of how to get around it. You might need a small hardware change.  In particular I was trying to think of a way to use the sys_clkreq signal for this purpose.For starters make sure you've read Section 3.5.3.5.1 "Clock Request (sys_clkreq) Control" in the TRM. My idea, perhaps far fetched, would be to go into a low power mode such that sys_clkreq is de-asserted and the external 19.2 MHz clock turned off.  When you then come out of the low power state (e.g. by timer or external wake-up) the FPGA would "magically" become the new clock source when sys_clkreq was asserted.  That's where the hardware change comes in, i.e. I think you'd need an external mux to switch the input clock during the low power mode.

I think there's a lot of nitty gritty details to this approach. It's the only thing that seems remotely possible though.

(For future debugging of clock issues, after fixing the above issues....) Are there any OMAP VCO or TPS registers that would provide sticky status of PLL and DPLL unlocks or error conditions? 

I haven't found much so far that I can look at after seeing a failure that looks like it's clock related.

Matt Weber said:

Are there any OMAP VCO or TPS registers that would provide sticky status of PLL and DPLL unlocks or error conditions?

I don't know of anything. I generally use the Clock Tree Tool to inspect the various clock frequencies being generated and to make sure nothing is out of spec.