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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 094F4C3815B for ; Wed, 15 Apr 2020 20:23:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E580E20774 for ; Wed, 15 Apr 2020 20:23:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2441997AbgDOUX4 (ORCPT ); Wed, 15 Apr 2020 16:23:56 -0400 Received: from mga05.intel.com ([192.55.52.43]:41716 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2442001AbgDOUXC (ORCPT ); Wed, 15 Apr 2020 16:23:02 -0400 IronPort-SDR: Kph5SZPCExo7dhzKarMnx/3kezfyhYzJ+e0vw3dHNxTCewcoMRt1xvY+JNBFxpavWE8SzSY0ZV tAnPPX4xcxJA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2020 13:23:02 -0700 IronPort-SDR: 08Pg1nHfQyQeKArKnSkmpdMH/b4HOwFCML4/ru7SX9KLnJdr4lOWTww+DWNMC0geyIscbyA35T ROiYRywaa4Dw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,388,1580803200"; d="scan'208";a="332606832" Received: from jplam-mobl1.amr.corp.intel.com (HELO [10.209.82.197]) ([10.209.82.197]) by orsmga001.jf.intel.com with ESMTP; 15 Apr 2020 13:22:59 -0700 Subject: Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock To: Mark Brown Cc: alsa-devel@alsa-project.org, Rob Herring , linux-gpio@vger.kernel.org, tiwai@suse.de, Linus Walleij , Stephen Boyd , Daniel Matuschek , Hui Wang , Matthias Reichl , Michael Turquette , Bartosz Golaszewski , Andy Shevchenko , linux-clk@vger.kernel.org References: <20200414174530.GK5412@sirena.org.uk> <8ee01a4f-ceb2-d207-7cef-cf766fa670af@linux.intel.com> <20200414182728.GM5412@sirena.org.uk> <3017b762-7a0c-cee2-06dd-1e96f52eb849@linux.intel.com> <20200414195031.GP5412@sirena.org.uk> <0d2aed9b-5c79-9ed2-6ca1-67b2688e4c99@linux.intel.com> <20200415113630.GC5265@sirena.org.uk> <4635e57b-fccd-d8a9-fa99-8124debb3428@linux.intel.com> <20200415162247.GF5265@sirena.org.uk> <9a7fbbac-818a-01d0-7a32-8ae313f9ad50@linux.intel.com> <20200415195033.GL5265@sirena.org.uk> From: Pierre-Louis Bossart Message-ID: Date: Wed, 15 Apr 2020 15:22:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200415195033.GL5265@sirena.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org > In the case of this driver could you look at registering the link from > the device for the clocks? Have it say "I supply SCK on device X" as it > registers. That should be fairly straightforward I think, we do that > for one of the regulators. When you wrote 'in the case of this driver', were you referring to the clock provider, saying 'I support SCK on device i2c-104C5122:00' ? If you have a pointer on the regulator example, I'd appreciate it, I am really way beyond my comfort zone. > The main thing I want to avoid is having to have the CODEC drivers know > platform specific strings that they're supposed to look up, or general > approaches where that ends up being a thing that looks idiomatic. That > was something board files did for a while, it didn't work very well and > we did something better with clkdev instead. I'm a lot less worried > about this for cases where it's two devices that are part of the SoC > talking to each other, that's relatively well controled and doesn't > affect non-x86 platforms. When it starts touching the CODECs it's a lot > more worrying. I see the nuance, thanks for the clarification. Maybe an alternate suggestion if you want to avoid hard-coded strings in the kernel: what if we added optional properties for the clock lookup name in both the codec and clock driver, and set the name in a _DSD blob. That would move the platform-specific names to platform firmware, and avoid the links described above that are probably ACPI-only. In this case we can add whatever we want, the DSDT table contains absolutely nothing for audio so we can add things as needed, and in case another usage of this codec happens in a future device they'd have to define their own clock name and store it in platform firmware. > I think by now there's ample evidence that it's worth investing in > better firmware descriptions :( Indeed, and tools to check they are correct! Most of the stuff we defined for SoundWire ends-up wrong or undefined, still an uphill battle... 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=-2.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 B0BE1C2BA19 for ; Wed, 15 Apr 2020 20:24:12 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 32FA72076D for ; Wed, 15 Apr 2020 20:24:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="PQ/GGhx+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32FA72076D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 75490852; Wed, 15 Apr 2020 22:23:20 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 75490852 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1586982250; bh=Xm/800VbqWEfDTybnii7kgQcbbjpEapNNZpdU5w5cq8=; h=Subject:To:References:From:Date:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=PQ/GGhx+DOk3c1QFqo91I1j3rlnUpNUFYUadGgI6720nAKru5po3mBn1Nt0yFkrQ9 7yyHfcsEBXhZKEYy5nW/IjxCByTqmXTyCWhKzLyWnzFWokACUVcMPd13L8VK0/ahbr gWXBvKGW+nIt63yY7b2Rbr1l7KbDiyj89jv+GuHg= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id EAE22F80115; Wed, 15 Apr 2020 22:23:19 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 93597F80245; Wed, 15 Apr 2020 22:23:18 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id F31D5F80115 for ; Wed, 15 Apr 2020 22:23:14 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz F31D5F80115 IronPort-SDR: OkzE65VNRV/4kU5r9Z8vjnMHRctKsOfATSdUBK8rvvDfFlzD1b6EJCNbP3r1hOL9xvjg7A42fi 7Z9XjHnoqMTQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2020 13:23:02 -0700 IronPort-SDR: 08Pg1nHfQyQeKArKnSkmpdMH/b4HOwFCML4/ru7SX9KLnJdr4lOWTww+DWNMC0geyIscbyA35T ROiYRywaa4Dw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,388,1580803200"; d="scan'208";a="332606832" Received: from jplam-mobl1.amr.corp.intel.com (HELO [10.209.82.197]) ([10.209.82.197]) by orsmga001.jf.intel.com with ESMTP; 15 Apr 2020 13:22:59 -0700 Subject: Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock To: Mark Brown References: <20200414174530.GK5412@sirena.org.uk> <8ee01a4f-ceb2-d207-7cef-cf766fa670af@linux.intel.com> <20200414182728.GM5412@sirena.org.uk> <3017b762-7a0c-cee2-06dd-1e96f52eb849@linux.intel.com> <20200414195031.GP5412@sirena.org.uk> <0d2aed9b-5c79-9ed2-6ca1-67b2688e4c99@linux.intel.com> <20200415113630.GC5265@sirena.org.uk> <4635e57b-fccd-d8a9-fa99-8124debb3428@linux.intel.com> <20200415162247.GF5265@sirena.org.uk> <9a7fbbac-818a-01d0-7a32-8ae313f9ad50@linux.intel.com> <20200415195033.GL5265@sirena.org.uk> From: Pierre-Louis Bossart Message-ID: Date: Wed, 15 Apr 2020 15:22:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200415195033.GL5265@sirena.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: alsa-devel@alsa-project.org, Matthias Reichl , tiwai@suse.de, Linus Walleij , Stephen Boyd , Daniel Matuschek , linux-clk@vger.kernel.org, Hui Wang , linux-gpio@vger.kernel.org, Rob Herring , Bartosz Golaszewski , Andy Shevchenko , Michael Turquette X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" > In the case of this driver could you look at registering the link from > the device for the clocks? Have it say "I supply SCK on device X" as it > registers. That should be fairly straightforward I think, we do that > for one of the regulators. When you wrote 'in the case of this driver', were you referring to the clock provider, saying 'I support SCK on device i2c-104C5122:00' ? If you have a pointer on the regulator example, I'd appreciate it, I am really way beyond my comfort zone. > The main thing I want to avoid is having to have the CODEC drivers know > platform specific strings that they're supposed to look up, or general > approaches where that ends up being a thing that looks idiomatic. That > was something board files did for a while, it didn't work very well and > we did something better with clkdev instead. I'm a lot less worried > about this for cases where it's two devices that are part of the SoC > talking to each other, that's relatively well controled and doesn't > affect non-x86 platforms. When it starts touching the CODECs it's a lot > more worrying. I see the nuance, thanks for the clarification. Maybe an alternate suggestion if you want to avoid hard-coded strings in the kernel: what if we added optional properties for the clock lookup name in both the codec and clock driver, and set the name in a _DSD blob. That would move the platform-specific names to platform firmware, and avoid the links described above that are probably ACPI-only. In this case we can add whatever we want, the DSDT table contains absolutely nothing for audio so we can add things as needed, and in case another usage of this codec happens in a future device they'd have to define their own clock name and store it in platform firmware. > I think by now there's ample evidence that it's worth investing in > better firmware descriptions :( Indeed, and tools to check they are correct! Most of the stuff we defined for SoundWire ends-up wrong or undefined, still an uphill battle...