Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)
To:     Mogens Jensen <mogens-jensen@protonmail.com>
Cc:     Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
        Dean Wallace <duffydack73@gmail.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Michael Turquette <mturquette@baylibre.com>,
        linux-clk <linux-clk@vger.kernel.org>,
        Stable <stable@vger.kernel.org>,
        Johannes Stezenbach <js@sig21.net>,
        Carlo Caione <carlo@endlessm.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20181025232517.ywnw54qibemosjws@picard>
 <20181030143836.feo7zcxiestylxoo@picard>
 <2d429c87-24c5-4075-683e-b0d12c3eb1c2@linux.intel.com>
 <d00df762-e4fc-06c5-701e-d5100bfd0e35@redhat.com>
 <e48696f0-aa3e-e20e-d038-9d8dda9cbfce@redhat.com>
 <BaxBOBmUCld7THAnRIDXUpKq8uQ2oJ49EaNlq0mZ11gFjA5JjhbfhVouLZGc1q74PrQC6uGfddKklIP059D_DtQwBqK-sn9rd4xEPhW9E6s=@protonmail.com>
 <d53738e1-4ba5-640e-7ef7-1705ab205061@redhat.com>
 <kAuINEBUUnlS5_uJafGtvryMEJVkDO4pb_yLfClwMcTS1h3sB1gYPcXBvg9X3RINfp5Uch7kLXuhTRX_JtouTYxoS6xNr77_b46e-mugl3k=@protonmail.com>
 <b8849ae1-5a38-e7a1-da14-dc7f9d164825@redhat.com>
 <3iO9ehQbZm_haTV0IuZ0qhsVHR0QLUbTgRJT8ZenGuRsnz2_uBvO93f0bHVYnsApibUT16JsJ0dgphLhUBd-u0t-lDBNsbvvlKWTgq8XOlw=@protonmail.com>
From:   Hans de Goede <hdegoede@redhat.com>
Message-ID: <3e12e051-b874-187d-d4f5-e146f59c659b@redhat.com>
Date:   Sun, 2 Dec 2018 13:25:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <3iO9ehQbZm_haTV0IuZ0qhsVHR0QLUbTgRJT8ZenGuRsnz2_uBvO93f0bHVYnsApibUT16JsJ0dgphLhUBd-u0t-lDBNsbvvlKWTgq8XOlw=@protonmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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