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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 EEC35C352BE for ; Tue, 14 Apr 2020 18:27:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D36D920575 for ; Tue, 14 Apr 2020 18:27:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586888858; bh=setRMLbaGbdY6PfeXmGfv+P7oCdBEUV8af+jR4fH8Oo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=J4OjPHeT5laK55iLYK3EILdG19E9AOATCXL1XMmTKKymx4uFWpohac2nUKOCo9OuP 2LX7psCZxh3Okehsvoy9LbKv9re1fAm/BTQ+19o7pu1sMjlxuvTwW8S/pbX6TtOuzA UkvwDHxvzI+4626OfHJ3tKoGtG7w1ruvczwW4Uqg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2503957AbgDNS1e (ORCPT ); Tue, 14 Apr 2020 14:27:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:39760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2503953AbgDNS1c (ORCPT ); Tue, 14 Apr 2020 14:27:32 -0400 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2070620774; Tue, 14 Apr 2020 18:27:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586888851; bh=setRMLbaGbdY6PfeXmGfv+P7oCdBEUV8af+jR4fH8Oo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mgUpmwnb5CDveFVgJHc4JDrOUzHq9FBD78BcxY4mQQouaDyuIGe1f1kFNblCrx3Ja nvkNxhJcNe9EQKPcCiE/1QcJc81oQZh4MeXoY97nuBMpATca9MxwKNv/YFNGy/LPEn eGjATpc0T7zOs8qPcKYUdihbl1y7nTWUKNhxcqK8= Date: Tue, 14 Apr 2020 19:27:28 +0100 From: Mark Brown To: Pierre-Louis Bossart Cc: alsa-devel@alsa-project.org, tiwai@suse.de, Andy Shevchenko , Daniel Matuschek , Matthias Reichl , Hui Wang , linux-gpio@vger.kernel.org, Linus Walleij , Bartosz Golaszewski , linux-clk@vger.kernel.org, Michael Turquette , Stephen Boyd , Rob Herring Subject: Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock Message-ID: <20200414182728.GM5412@sirena.org.uk> References: <20200409195841.18901-1-pierre-louis.bossart@linux.intel.com> <20200409195841.18901-3-pierre-louis.bossart@linux.intel.com> <20200414174530.GK5412@sirena.org.uk> <8ee01a4f-ceb2-d207-7cef-cf766fa670af@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2YJj5f1P6Th4nBRw" Content-Disposition: inline In-Reply-To: <8ee01a4f-ceb2-d207-7cef-cf766fa670af@linux.intel.com> X-Cookie: I've only got 12 cards. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org --2YJj5f1P6Th4nBRw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 14, 2020 at 01:14:41PM -0500, Pierre-Louis Bossart wrote: > On 4/14/20 12:45 PM, Mark Brown wrote: > > On Thu, Apr 09, 2020 at 02:58:27PM -0500, Pierre-Louis Bossart wrote: > > > Using devm_clk_get() with a NULL string fails on ACPI platforms, use > > > the "sclk" string as a fallback. > > Is this something that could be fixed at the ACPI level? > I guess to fix this we'd need some sort of ACPI-level connection or > description of the clock, and I've never seen such a description? Wait, so SCLK is in the *global* namespace and the provider has to register the same name? That doesn't sound clever. It might be better to have the board register the connection from the clock provider to the device rather than hard code global namespace strings like this, that sounds like a recipie for misery. It is really sad that nobody involved in producing these systems that don't work with the current limitations in ACPI has been able to make progress on improving ACPI so it can cope with modern hardware and we're having to deal with this stuff. > All the examples I've seen use an explicit 'mclk' string (that's e.g. what > we did for the PMC clocks for Baytrail/Cherrytrail machine drivers, we added > a lookup). Here I used 'sclk' since it's what TI refers to in their > documentation. They appear to call it SCK not SCLK. --2YJj5f1P6Th4nBRw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl6WAJAACgkQJNaLcl1U h9BADwf/fED5QJj8MeBLvtZRaTiqY4MJ/SKDCRbWQCSE1rKJquN+Q6S3Sw9LA6Pl +b6iqkWOyfvqyeHJTwR0cSNAgmaPHhbsmMKx6zX2+lyV0PO440CQ9B7EyK48Bp4F CX950pYjFVn0bmMKvwCE2zfogp2U7ZZky8NftSWGUkYb84/8sRyL3MTa52dR+SEW XI7I157Jehggi1pMsv5W11ikZnzGF3IwlIviWtq/3cM1Ji+4ZDiYCAni/zheOfFF w8OdUEoRqh8NIU2/apKSFLWAuyEubp7v2i784hEmjJrXgDQfs4P06rwb2Z0Og2MG 0xmKr5g0y2UpAqVwO5SPq+uriix5FA== =5dN/ -----END PGP SIGNATURE----- --2YJj5f1P6Th4nBRw-- 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.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, 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 26D30C2BA19 for ; Tue, 14 Apr 2020 18:28:32 +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 A7C0F20575 for ; Tue, 14 Apr 2020 18:28:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="kIQ7okof"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="mgUpmwnb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7C0F20575 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 0CC25168D; Tue, 14 Apr 2020 20:27:40 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 0CC25168D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1586888910; bh=setRMLbaGbdY6PfeXmGfv+P7oCdBEUV8af+jR4fH8Oo=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kIQ7okofV+pxitlXtL58LwvTTPHkI1kXo/JggI8h5eKTJtTkglFKakcvogCUtFBht whHy09yEMb7NpzzpWUFWVcgQucbJjOBE/GnyL4rVqKyYmBl3udooEn2TU9NNNlwfM4 yQq3DWbNYjiwT2oFMAwD3QH1pSV153gKOF9lG3KU= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 7CA63F800F5; Tue, 14 Apr 2020 20:27:39 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 1F85EF8013D; Tue, 14 Apr 2020 20:27:36 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id AA00CF80115 for ; Tue, 14 Apr 2020 20:27:33 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz AA00CF80115 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="mgUpmwnb" Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2070620774; Tue, 14 Apr 2020 18:27:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586888851; bh=setRMLbaGbdY6PfeXmGfv+P7oCdBEUV8af+jR4fH8Oo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mgUpmwnb5CDveFVgJHc4JDrOUzHq9FBD78BcxY4mQQouaDyuIGe1f1kFNblCrx3Ja nvkNxhJcNe9EQKPcCiE/1QcJc81oQZh4MeXoY97nuBMpATca9MxwKNv/YFNGy/LPEn eGjATpc0T7zOs8qPcKYUdihbl1y7nTWUKNhxcqK8= Date: Tue, 14 Apr 2020 19:27:28 +0100 From: Mark Brown To: Pierre-Louis Bossart Subject: Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock Message-ID: <20200414182728.GM5412@sirena.org.uk> References: <20200409195841.18901-1-pierre-louis.bossart@linux.intel.com> <20200409195841.18901-3-pierre-louis.bossart@linux.intel.com> <20200414174530.GK5412@sirena.org.uk> <8ee01a4f-ceb2-d207-7cef-cf766fa670af@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2YJj5f1P6Th4nBRw" Content-Disposition: inline In-Reply-To: <8ee01a4f-ceb2-d207-7cef-cf766fa670af@linux.intel.com> X-Cookie: I've only got 12 cards. User-Agent: Mutt/1.10.1 (2018-07-13) 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 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" --2YJj5f1P6Th4nBRw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 14, 2020 at 01:14:41PM -0500, Pierre-Louis Bossart wrote: > On 4/14/20 12:45 PM, Mark Brown wrote: > > On Thu, Apr 09, 2020 at 02:58:27PM -0500, Pierre-Louis Bossart wrote: > > > Using devm_clk_get() with a NULL string fails on ACPI platforms, use > > > the "sclk" string as a fallback. > > Is this something that could be fixed at the ACPI level? > I guess to fix this we'd need some sort of ACPI-level connection or > description of the clock, and I've never seen such a description? Wait, so SCLK is in the *global* namespace and the provider has to register the same name? That doesn't sound clever. It might be better to have the board register the connection from the clock provider to the device rather than hard code global namespace strings like this, that sounds like a recipie for misery. It is really sad that nobody involved in producing these systems that don't work with the current limitations in ACPI has been able to make progress on improving ACPI so it can cope with modern hardware and we're having to deal with this stuff. > All the examples I've seen use an explicit 'mclk' string (that's e.g. what > we did for the PMC clocks for Baytrail/Cherrytrail machine drivers, we added > a lookup). Here I used 'sclk' since it's what TI refers to in their > documentation. They appear to call it SCK not SCLK. --2YJj5f1P6Th4nBRw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl6WAJAACgkQJNaLcl1U h9BADwf/fED5QJj8MeBLvtZRaTiqY4MJ/SKDCRbWQCSE1rKJquN+Q6S3Sw9LA6Pl +b6iqkWOyfvqyeHJTwR0cSNAgmaPHhbsmMKx6zX2+lyV0PO440CQ9B7EyK48Bp4F CX950pYjFVn0bmMKvwCE2zfogp2U7ZZky8NftSWGUkYb84/8sRyL3MTa52dR+SEW XI7I157Jehggi1pMsv5W11ikZnzGF3IwlIviWtq/3cM1Ji+4ZDiYCAni/zheOfFF w8OdUEoRqh8NIU2/apKSFLWAuyEubp7v2i784hEmjJrXgDQfs4P06rwb2Z0Og2MG 0xmKr5g0y2UpAqVwO5SPq+uriix5FA== =5dN/ -----END PGP SIGNATURE----- --2YJj5f1P6Th4nBRw--