On 03/19/2015 04:34 PM, Greg Knight wrote:
SO is it so that the codec's MCLK is coming from McASP AHCLKX (or R) and this clock need to be present all the time? W/o the MCLK the registers are not accessible?
Correct, the SGTL5000's I2C registers are not accessible without MCLK.
Yeah, according to the datasheet, it needs MCLK in order to communicate with it.
From my testing, the clock need only be present when the audio chip is in use. When not in use, the chip appears perfectly happy to not be clocked.
If you change audio controls while you don't have audio activity, you will still need to have the MCLK running.
Is there a better place to pull a ~12MHz clock signal for use as a master clock from an AM335X?
For a codec such as the SGTL5000 I would connect a clock, which is running all the time. If you take a look at the driver, it enables the clock at probe and leaves it running as long as the driver is loaded.
But AM335x has CLKOUT1,2 outputs as well. They are not high quality clocks, but can be enabled/disabled.
This will not work in mainline kernel. The McASP is turned off when it is not in use (no audio activity) so the AHCLKX/R is not going to be there on the ball output.
The clock-to-talk hack in the patch enables the AHCLKX line during codec initialization. From my testing, we don't seem to spend much time communicating with the device when we're not using it. Disabling the clock when it's not used should not be a problem.
As I said, this is not going to work in upstream kernel. The McASP is not even powered up during probe time anymore. It is only powered up when it is needed, this means that you will not have clocks for the codec coming from McASP pin. The driver is not designed to support such a use case, when you use one of it's clock as a master clock for external chip. In other words the McASP driver is not a clock driver. It might be possible to create a clock driver on top of the McASP driver as child, but it is really something which should not be supported.
How do you configure the frequency of the AHCLKX/R, this hack only enables it, so you are going to have _some_ clock going out.
The frequency is the 12 MHz (I think) I get out from AHCLKX without any further configuration; I have not investigated changing that frequency as it suited my needs. But I can look into doing set_clkdiv/set_sysclk during the clock-to-talk enable if that's more appropriate?
You should be using set_clkdiv and set_sysclk calls from the machine driver to configure the AHCLKX (we do not have AHCLKR supported in the driver ATM).
So, ehm, the SGTL5000 component logic (is this the machine driver?) should adjust the McASP's clocks? Am I misunderstanding? Would this not impact binding the SGTL5000 to devices that are *not* McASPs/break abstraction?
TBH I'm not clear on how the SGTL5000 bindings to other hardware work.
It works in other HW because the designers connected the SGTL5000's MCLK to a clock source which can be controlled or it is running all the time. In your case the designers chosen a clock line, which is not working as 'normal' clock.
Is it safe to assume set_sysclk is always going to adjust the I2S MCLK speed? Please pardon my crude questions, I'm not deeply familiar with the structure of ALSA.
With the setclkdiv/sysclk you can configure the AHCLKX direction and configure the divider to be used to generate the clock which goes out, or to divide down the clock which is coming in.
Another issue this hack has is: what happens if for some reason the SGTL5000 driver loads first? McASP will not enable the AHCLKX so the codec driver will fail reading the CHIP_ID and fails to load. You need to provide a dummy clock node to the codec, so that will not fail, but you will not have the MCLK.
I'll reformat the patches and try from a mainline kernel when I get some spare time.
I'm not sure if this can be accepted, sorry. It is really a hack and there are too many corner cases where the system can fail.