davinci-mcasp: extension to use AHCLKX pin as external clock source

davinci-mcasp: extension to use AHCLKX pin as external clock source

[Urs Fässler]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

The AHCLKX pin seems not to be supported as external source. The first
patch is a general fix to allow external clock. The second allows you to
select the AHCLKX pin as clock source.

Patch built against v3.19-rc7


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: davinci-mcasp: extension to use AHCLKX pin as external clock source

[Peter Ujfalusi]

On 02/06/2015 11:22 AM, Urs Fässler wrote:
> The AHCLKX pin seems not to be supported as external source. The first
> patch is a general fix to allow external clock. The second allows you to
> select the AHCLKX pin as clock source.
> 
> Patch built against v3.19-rc7
> 

I don't think this series is correct. You can just issue:
snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);

from the machine driver to select AHCLKX as input.

-- 
Péter

Re: davinci-mcasp: extension to use AHCLKX pin as external clock source

[Urs Fässler]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

On 06.02.2015 12:50, Peter Ujfalusi wrote:
> On 02/06/2015 11:22 AM, Urs Fässler wrote:
>> The AHCLKX pin seems not to be supported as external source. The first
>> patch is a general fix to allow external clock. The second allows you to
>> select the AHCLKX pin as clock source.
>>
>> Patch built against v3.19-rc7
>>
> 
> I don't think this series is correct. You can just issue:
> snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
> 
> from the machine driver to select AHCLKX as input.
> 
I checked everything and the source of the problem is, that on our
hardware the bit clock of the codec is connected to AHCLKX. According to
the datasheet, AHCLKX is for the master clock only. On the other hand,
it is possible to route a bitclock from AHCLKX to the subsystem (what I
did with my patches).

Now my question is, if it is even worth trying to bring such an option
for the driver (use AHCLKX as bit clock in) upstream?

Thanks
Urs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: davinci-mcasp: extension to use AHCLKX pin as external clock source

[Peter Ujfalusi]

On 02/10/2015 04:17 PM, Urs Fässler wrote:
> On 06.02.2015 12:50, Peter Ujfalusi wrote:
>> On 02/06/2015 11:22 AM, Urs Fässler wrote:
>>> The AHCLKX pin seems not to be supported as external source. The first
>>> patch is a general fix to allow external clock. The second allows you to
>>> select the AHCLKX pin as clock source.
>>>
>>> Patch built against v3.19-rc7
>>>
>>
>> I don't think this series is correct. You can just issue:
>> snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
>>
>> from the machine driver to select AHCLKX as input.
>>
> I checked everything and the source of the problem is, that on our
> hardware the bit clock of the codec is connected to AHCLKX.

Why would any HW designer do this???

Just to clarify this: the bitclock from codec is only connected to AHCLKX pin,
or is it also connected to the ACLKX pin?
The use of AHCLKX/R pin is _optional_ in McASP and it serves the purpose of
providing a way to have synchronized master clock for the codec and McASP.
ACLKX, AFSX and data pins are mandatory to be connected.

> According to the datasheet, AHCLKX is for the master clock only.

Yes, it is for the master clock to be used by both codec and McASP to avoid
clock drifting.

> On the other hand, it is possible to route a bitclock from AHCLKX to
 >the subsystem (what I did with my patches).

Yes, it is possible, when McASP is master it can use the signal on AHCLKX pin
to generate the BCLK/FS.

> Now my question is, if it is even worth trying to bring such an option
> for the driver (use AHCLKX as bit clock in) upstream?

I don't want HW designers to get ideas from code - but if they did what I
think they did with your HW they certainly not going to bother checking TRM or
code...

But I think you can still get the setup working, if it is really like this:

McASP
AHCLKX <-- bitclock <-- codec
ACLKX  (not connected while it should have been)
FSX    <-- framsync <-- codec

In this case you want to configure the codec to be CBM_CFM and McASP as
CBS_CFM (we don't have this supported in the driver, but not a big deal to add).

And you call:
snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
snd_soc_dai_set_clkdiv(cpu_dai, 1, 1);

You will have the codec providing the FS and driving the bitclock (connected
to wrong McASP pin). McASP will drive the bitclock using the AHCLKX as source
using divide by 1. McASP will not try to drive FS.

-- 
Péter

Re: davinci-mcasp: extension to use AHCLKX pin as external clock source

[Urs Fässler]

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

On 12.02.2015 09:09, Peter Ujfalusi wrote:
> On 02/10/2015 04:17 PM, Urs Fässler wrote:
>> On 06.02.2015 12:50, Peter Ujfalusi wrote:
>>> On 02/06/2015 11:22 AM, Urs Fässler wrote:
>>>> The AHCLKX pin seems not to be supported as external source. The first
>>>> patch is a general fix to allow external clock. The second allows you to
>>>> select the AHCLKX pin as clock source.
>>>>
>>>> Patch built against v3.19-rc7
>>>>
>>>
>>> I don't think this series is correct. You can just issue:
>>> snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
>>>
>>> from the machine driver to select AHCLKX as input.
>>>
>> I checked everything and the source of the problem is, that on our
>> hardware the bit clock of the codec is connected to AHCLKX.
> 
> Why would any HW designer do this???

It was not intended that way.

> Just to clarify this: the bitclock from codec is only connected to AHCLKX pin,
> or is it also connected to the ACLKX pin?
> The use of AHCLKX/R pin is _optional_ in McASP and it serves the purpose of
> providing a way to have synchronized master clock for the codec and McASP.
> ACLKX, AFSX and data pins are mandatory to be connected.
>
>> According to the datasheet, AHCLKX is for the master clock only.
> 
> Yes, it is for the master clock to be used by both codec and McASP to avoid
> clock drifting.
> 
>> On the other hand, it is possible to route a bitclock from AHCLKX to
>  >the subsystem (what I did with my patches).
> 
> Yes, it is possible, when McASP is master it can use the signal on AHCLKX pin
> to generate the BCLK/FS.
> 
>> Now my question is, if it is even worth trying to bring such an option
>> for the driver (use AHCLKX as bit clock in) upstream?
> 
> I don't want HW designers to get ideas from code - but if they did what I
> think they did with your HW they certainly not going to bother checking TRM or
> code...
> 
> But I think you can still get the setup working, if it is really like this:
> 
> McASP
> AHCLKX <-- bitclock <-- codec
> ACLKX  (not connected while it should have been)
> FSX    <-- framsync <-- codec
> 
> In this case you want to configure the codec to be CBM_CFM and McASP as
> CBS_CFM (we don't have this supported in the driver, but not a big deal to add).
> 
> And you call:
> snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
> snd_soc_dai_set_clkdiv(cpu_dai, 1, 1);
> 
> You will have the codec providing the FS and driving the bitclock (connected
> to wrong McASP pin). McASP will drive the bitclock using the AHCLKX as source
> using divide by 1. McASP will not try to drive FS.

Thanks, that looks better than my patches. We will fix the hardware and
use your solution for the already produced boards.

Urs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]