[alsa-devel] Patches to bind the SGTL5000 chip to AM33XX McASP

[Peter Ujfalusi]

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.

-- 
Péter