From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 384A8C6786F for ; Tue, 30 Oct 2018 16:02:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0164E20664 for ; Tue, 30 Oct 2018 16:02:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0164E20664 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-clk-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727676AbeJaA4G (ORCPT ); Tue, 30 Oct 2018 20:56:06 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:36720 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727776AbeJaA4G (ORCPT ); Tue, 30 Oct 2018 20:56:06 -0400 Received: by mail-wm1-f66.google.com with SMTP id a8-v6so11832081wmf.1 for ; Tue, 30 Oct 2018 09:02:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eUUWXsHyPEdsJNyTQsdt8A4rZRWlaB55E03Ok6c9p0k=; b=QAYWTyoNfYiTLrKatTwPeGJIjEnUv9Z5qzPvfOWxYdXQzb5S4yd3alNtGe0JQvY/Uw q2WSBbEIvOsFko6iF8i1lXIxoqQkg9nP6xw+fxU0glf8Twd6FXiBL//6XsJkOgBzqB64 E2lmONFUR2bZgdhbIvCh+JaGx31Z0wJg/TSHeSQFkStxXTxviIN5uVF9VATwfR+q3033 nOvfLValLl1QIuT5bXOczSpOn38aghRV3zCCEW2Yy9wmwpay5zXUWkZhAidaE3DLzkW0 McBbAb3+xsZjBHxXSu93Yc8gnYUs3p5wUCSBXUMv6Qeu+g1rzd2bMIFpnUbLSE9asDgJ Gzlw== X-Gm-Message-State: AGRZ1gISHUS2HKrAWRkj+JsY9eq1JZcrN4Uenm38iCMD2S9tVlO9eie4 70IK6fTuOsG297H/9NwDHxSuOg== X-Google-Smtp-Source: AJdET5f/GfnSvgbcPS6Rh/HSmYulm7Z7NjHnQFIugDkx87fB+mCFMsfClMm5xvjWv5t7xEkf0JHvHQ== X-Received: by 2002:a1c:e456:: with SMTP id b83-v6mr2230726wmh.143.1540915321602; Tue, 30 Oct 2018 09:02:01 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id i7-v6sm27262444wmd.41.2018.10.30.09.02.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 09:02:00 -0700 (PDT) Subject: Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL) From: Hans de Goede To: Pierre-Louis Bossart , Dean Wallace Cc: Andy Shevchenko , Stephen Boyd , Michael Turquette , linux-clk , Stable , Johannes Stezenbach , Carlo Caione , Andy Shevchenko , Linux Kernel Mailing List , Mogens Jensen References: <20181025232517.ywnw54qibemosjws@picard> <154083512089.98144.9141070901932719147@swboyd.mtv.corp.google.com> <20181029190819.2ivlx73n6y6sx4vk@picard> <20181030143836.feo7zcxiestylxoo@picard> <2d429c87-24c5-4075-683e-b0d12c3eb1c2@linux.intel.com> Message-ID: <783f17c2-ecc6-00fc-5629-02319b965205@redhat.com> Date: Tue, 30 Oct 2018 17:02:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Hi, On 30-10-18 16:46, Hans de Goede wrote: > Hi, > > On 30-10-18 16:04, Pierre-Louis Bossart wrote: >> >> On 10/30/18 9:38 AM, Dean Wallace wrote: >>> On 30-10-18, Hans de Goede wrote: >>>> Hi Dean, >>>> >>>> Attached are 2 different attempts at fixing this. >>>> >>>> When trying these patches do not forget to remove the revert of the >>>> "Stop-marking-clocks-as-CLK_IS_CRITICAL" commit. >>>> >>>> Please first try the 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch >>>> patch I expect that one to do the trick indicating that the Swanky model >>>> uses a different pmc clk then which is normally used for the codec clock. >>>> >>>> If that patch does not fix things, please give the other patch a try. >> >> For Baytrail devices, the audio platform clocks are not managed by the firmware. They are for CHT-based devices - as can be seen by clock resources being described in the DSDT. We used to have a if(baytrail) in the code which was replaced by this CRITICAL label, but the point remains that there is a difference between the two SOC versions. > > As I mentioned before the CRITICAL flag was only added a year ago to workaround > an issue with on board ethernet needing plt_clk_4 on some laptops, this never > had anything to do with sound. Ah I see now that you later made some changes based on the patch to fix the ethernet: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=7735bce05a9c0bb0eb0f08c9002d65843a7c5798 Note though that that does not touch the machine driver which we are discussing now and the reporters machine is also BYT based. As explained below (in my original reply) I think it is fine to always manage the clk from within the kernel. But if you think this is a bad idea, we could re-introduce the is_valleyview() checks in machine drivers which are used on CHT devices. >> 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. > >> however you still have the problem of trying to manage from the kernel what the firmware already manages. > > The firmware only manages it when going to D3 state, with ASoC most of > the codecs gets turned off (and we no longer need the clock) but we do > not put the device in D3 / execute the _PS3 method. So from a pm pov > it is better if we manage the clk ourselves. > > Once we do actually put the device in D3 (on suspend) the kernel will have > already turned off the clk and the _OFF method of the CLK3 power resource > which directly pokes mmio, will just set the enable bit to 0 when it > already is 0, so no problem. Regards, Hans