Hi,

On 01-11-18 07:55, Mogens Jensen wrote:

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, October 31, 2018 9:29 AM, Hans de Goede hdegoede@redhat.com wrote:

...

Hi,

On 31-10-18 07:02, Mogens Jensen wrote:

...

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, October 30, 2018 7:10 PM, Hans de Goede hdegoede@redhat.com wrote:

...

Hi, On 30-10-18 19:56, Mogens Jensen wrote:

...

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, October 30, 2018 4:04 PM, Hans de Goede hdegoede@redhat.com wrote:

...

Hi, On 30-10-18 16:46, Hans de Goede wrote:

> Hi, > On 30-10-18 16:04, Pierre-Louis Bossart wrote: > >> In addition I am not aware of any baytrail device using plt_clk_0, so moving a common machine driver such a cht_bsw_max98090_ti to use plt_clk0 only would break other devices (e.g. Rambi/Orco). Asking for both clocks to be on might work though, > > Ok, so we need to have a DMI based quirk for the Swanky and maybe also > the clapper to use plt_clk_0 there. Asking for 2 clks if we only need > one does not seem like a good plan.

Dean, Mogens, To write a proper patch for this I'm going to need DMI strings from your devices. Can you please run (as normal user): grep . /sys/class/dmi/id/* 2> /dev/null And reply with the output of this command? I have attached the output from a coreboot seabios based clapper.

Thank you.

...

Should I still test 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and asoundrc from Dean? There seems to have been some development in the case since that request was made.

Yes please test that, I expect that to also fix things for the Clapper, but I need to have that confirmed before submitting a patch upstream adding a quirk for the Clapper to use pmc_plt_clk_0 instead of pmc_plt_clk_3. Regards, Hans

Unfortunately I only have access to longterm kernel 4.14 for building/running on this system, and 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch does not patch against 4.14.78. Can a test patch for 4.14 be created?

Can you run (as root):

for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat $i/clk_flags; echo; done

When running a kernel with working audio?

Then I can confirm that the Clapper is also using pmc_plt_clk_0, so that I can fix this for the clapper for 4.18+

I've just checked the 4.14 sources and in 4.14 the SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver does not support mclk control yet, so for the 4.14 kernel the only way to fix this is to revert the 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") commit.

Regards,

Hans

Here is the output from the Clapper with 4.14.78 and working sound:

/sys/kernel/debug/clk/pmc_plt_clk_0: 0x00000800 /sys/kernel/debug/clk/pmc_plt_clk_1: 0x00000000 /sys/kernel/debug/clk/pmc_plt_clk_2: 0x00000000 /sys/kernel/debug/clk/pmc_plt_clk_3: 0x00000000 /sys/kernel/debug/clk/pmc_plt_clk_4: 0x00000000 /sys/kernel/debug/clk/pmc_plt_clk_5: 0x00000000

Ok, so your Clapper model indeed is also using clk 0 and not clk 3 as expected. I've just submitted a patch upstream adding a quirk for this.

As for what the plan is with 4.14, I don't know. I believe that reverting the commit causing the issue there is fine.

Regards,

Hans