Hi Peter,

On 28.07.2016 13:48, Peter Ujfalusi wrote:

Please do CC the maintainers when sending patches.

Sorry, suppresscc=all ate my cc-cmd. Are we good now for further discussion?

On 07/26/16 15:05, Stefan Müller-Klieser wrote:

...

The AHCLKX clock output of the McASP can be used as audio MCLK, even if the McASP runs in slave mode. Add a DT binding to make this option available in a simple-card setup.

In other words: McASP is clock master, but we want to have the HCLK to be coming from internal AUXCLK and not from the AHCLKX pin, right?

I have my difficulties seeing it that way. I totally understand that from a driver/system perspective. But HCLK is not part of the I2S specification. So from the perspective of the audio interface, I think of the HCLK as a separate entity. To be on the same page, I should explain my use case. I want to add audio support for an am335x with a tlv320, no quartz is mounted for the codecs MCLK and we have an am335x M_OSC of 25 MHz. So to get precise audio sample rates, I want to provide HCLK to the codecs MCLK and use the codecs pll to act as the I2S master. So in my partial understanding of the McASP, it would run in sync with the clock provided by the codecs pll.

There might be also cases when McASP is slave _and_ we want to configure the HCLK from the AHCLKX ping. Adding new flag for this is not a good idea IMHO.

I expected more use cases to appear. This one I don't understand, though. If the McASP is slave, why would I want to sync to HCLK and not to CLK?

This is simply a workaround for the current simple card and might break if something is changing in there..

Thats true for all simple-cards using McASP right now, or?

I'm aware that this is a problematic issue. We can not have clock id support in the simple-card and I don't think it is a good idea to hack around this in the McASP driver. I don't see any other way right now then moving the McASP driver to CCF, or at first probably add CCF support to configure the clock routes while still keeping the ASoC way of configuring the clocks.

Ok. I tried first to implement CCF. I just was too afraid of breaking a lot of stuff. If you think thats the way to go, me too, I would prefer not putting more work in the old stuff. Then we come back to my issue with the I2S interface vs HCLK handling. Is HCLK the clock of the device or is it part of the audio interface (I2S "alike" streams)? I guess thats where the modeling difficulties are. Maybe its not either/or but we need both, because it can function as both?

...

Signed-off-by: Stefan Müller-Klieser s.mueller-klieser@phytec.de

Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt | 4 ++++ include/linux/platform_data/davinci_asp.h | 5 +++++ sound/soc/davinci/davinci-mcasp.c | 8 ++++++++ 3 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt index 46bc982..96d6244 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt @@ -39,6 +39,10 @@ Optional properties: please refer to pinctrl-bindings.txt

• fck_parent : Should contain a valid clock name which will be used as parent for the McASP fck

+- ahclkx-en: In case the MCASP runs in slave mode, e.g. i2s SCK and WS slave,

•         we can still provide the MCLK to a codec PLL using the AHCLKX
  

•         transmit clock output. This setup can be activated by using this
  

•         property. Clock master mode remains unaffected.
  

_if_ we hack this around in the driver I would rather have something like: hclk-source: Source of HCLK internal clock when McASP is clock master. With a new DT binding header file with defines:

Thats not enough for my use case as the McASP is audio interface slave. With my use case explanation, it maybe does make more sense now?

/* Source of High-frequency transmit/receive clock */ #define MCASP_CLK_HCLK_AHCLK 0 /* AHCLKX/R */ #define MCASP_CLK_HCLK_AUXCLK 1 /* Internal functional clock */

Basically my old patches for McASP clock selection but w/o the improving the simple card. The only change would be that we ignore the set_sysclk's clk_id parameter and use the private clk_id we got via DT when the dir is SND_SOC_CLOCK_IN. Oh, and set the PDIR also when AUXCLK is selected for HCLK. In the DT you would have for your setup:

hclk-source = MCASP_CLK_HCLK_AUXCLK;

Or something like that.

But I think in this way we can work around the simple-card posed limitation a bit better, but it is still a questionable workaround.

I have attached my local patches for reference.

So, with these patches, I would still need to toggle PDIR of AHCLKX in the case SND_SOC_CLOCK_IN + MCASP_CLK_HCLK_AUXCLK.

...

Example:

diff --git a/include/linux/platform_data/davinci_asp.h b/include/linux/platform_data/davinci_asp.h index 85ad68f..c878836 100644 --- a/include/linux/platform_data/davinci_asp.h +++ b/include/linux/platform_data/davinci_asp.h @@ -44,6 +44,11 @@ struct davinci_mcasp_pdata { int clk_input_pin;

/*

• * Activate AHCLKX clock output in slave mode.
  

• */
  

• bool ahclkx_en;
• /*
  • This flag works when both clock and FS are outputs for the cpu
  • and makes clock more accurate (FS is not symmetrical and the
  • clock is very fast.

diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 237dc67..aba888e 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -94,6 +94,7 @@ struct davinci_mcasp {

int sysclk_freq; bool bclk_master;

• bool ahclkx_en;

  /* McASP FIFO related */ u8 txnumevt;

@@ -605,6 +606,10 @@ static int davinci_mcasp_set_sysclk(struct snd_soc_dai *dai, int clk_id, mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE); mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKRCTL_REG, AHCLKRE); mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, AHCLKX);

• } else if (mcasp->ahclkx_en) {

• mcasp_clr_bits(mcasp, DAVINCI_MCASP_AHCLKRCTL_REG, AHCLKRE);
  

It is safe to set this bit as well.

Thanks, wouldn't want to assume that. That would make the patch even smaller. But I totally understand the case for CCF. What would be your starting point for the transition? Do you already have some patches?

Regards, Stefan

...

• mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE);
  

• mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, AHCLKX);
  

  } else { mcasp_clr_bits(mcasp, DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE); mcasp_clr_bits(mcasp, DAVINCI_MCASP_AHCLKRCTL_REG, AHCLKRE);

@@ -1610,6 +1615,8 @@ static struct davinci_mcasp_pdata *davinci_mcasp_set_pdata_from_of( if (ret >= 0) pdata->op_mode = val;

• pdata->ahclkx_en = of_property_read_bool(np, "ahclkx-en");
• ret = of_property_read_u32(np, "tdm-slots", &val); if (ret >= 0) { if (val < 2 || val > 32) {

@@ -1851,6 +1858,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) mcasp->version = pdata->version; mcasp->txnumevt = pdata->txnumevt; mcasp->rxnumevt = pdata->rxnumevt;

• mcasp->ahclkx_en = pdata->ahclkx_en;

  mcasp->dev = &pdev->dev;