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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 75DBDC2D0B1 for ; Thu, 6 Feb 2020 12:36:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4C217214AF for ; Thu, 6 Feb 2020 12:36:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728060AbgBFMgB (ORCPT ); Thu, 6 Feb 2020 07:36:01 -0500 Received: from foss.arm.com ([217.140.110.172]:57882 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726687AbgBFMgB (ORCPT ); Thu, 6 Feb 2020 07:36:01 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2A7B630E; Thu, 6 Feb 2020 04:36:01 -0800 (PST) Received: from [192.168.1.123] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 03BE73F68E; Thu, 6 Feb 2020 04:35:59 -0800 (PST) Subject: Re: [PATCH 2/3] ASoC: rockchip: Make RK3328 GPIO_MUTE control explicit To: Mark Brown Cc: lgirdwood@gmail.com, heiko@sntech.de, alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org, pgwipeout@gmail.com References: <29a846da33c02df64eca62b5fa0f3884652f788f.1580950046.git.robin.murphy@arm.com> <20200206114606.GM3897@sirena.org.uk> From: Robin Murphy Message-ID: Date: Thu, 6 Feb 2020 12:36:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200206114606.GM3897@sirena.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 2020-02-06 11:46 am, Mark Brown wrote: > On Thu, Feb 06, 2020 at 01:07:12AM +0000, Robin Murphy wrote: >> The RK3328 reference design uses an external line driver IC as a buffer >> on the analog codec output, enabled by the GPIO_MUTE pin, and such a >> configuration is currently assumed in the codec driver's direct poking >> of GRF_SOC_CON10 to control the GPIO_MUTE output value. However, some > > This makes sense but it is an ABI break so is going to need > quirking for existing boards that unfortunately rely on the > existing behaviour. Yeah, that's where it gets tricky - there doesn't seem to be a nice way to differentiate between "no GPIO because old DT" and "no GPIO because the enable is hard-wired/irrelevant and GPIO_MUTE doesn't do what you think it does", and it seems really improper to introduce a DT property for the sole purpose of telling a Linux driver not to assume something it shouldn't really have in the first place. My opinion fell on the side of a minor ABI break being the lesser of two evils, given that the worst case once people start enabling this codec on Renegade/ROC-CC boards (which I was only anticipating, but have just discovered is happening already[1]) results in unexpectedly stuffing 3.3V into the SD card and SoC I/O domain while both are in 1.8V mode, and that the change would only really affect one other current board (Rock64), where most mainline users are likely to be upgrading their DTB in lock-step with the kernel anyway. I guess the existing (mis)behaviour could be predicated on an of_machine_is_compatible() check for Rock64 boards - it's ugly, but should do the job if you feel it's more important to be 100% strict about not regressing supported systems for any possible kernel/DTB combination. Thanks, Robin. [1] https://github.com/armbian/build/commit/18b24717be9639b65b86db3dbcf2b42fe73ca12c 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=-7.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 38C84C2D0B1 for ; Thu, 6 Feb 2020 12:37:01 +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 B6A9B20661 for ; Thu, 6 Feb 2020 12:37:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="o9prtRQ8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6A9B20661 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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 F2F411685; Thu, 6 Feb 2020 13:36:08 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz F2F411685 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1580992619; bh=AvxCFg6wrMOSLPvSEGRenEwb6WRGod2EJ2Psov+MtFI=; h=To:References:From:Date:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=o9prtRQ8VjE+s/jHDuX4sbnXB7+3SByUMce4WA1I0t51Mbs+Gaj+hx9knjPg4Ecgx S1tl6BOc7krylibgJrANq6L0B3GDF74/UCDIBlynIM6LQHgt1zxr3TQfrHWTrVrawi Ljkx9KOfTSihfgGiFgCrPhvbnp8GVFGngtacC7T0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 5D46CF80059; Thu, 6 Feb 2020 13:36:08 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 42017F80162; Thu, 6 Feb 2020 13:36:07 +0100 (CET) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by alsa1.perex.cz (Postfix) with ESMTP id 9EAC4F800AB for ; Thu, 6 Feb 2020 13:36:02 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 9EAC4F800AB Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2A7B630E; Thu, 6 Feb 2020 04:36:01 -0800 (PST) Received: from [192.168.1.123] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 03BE73F68E; Thu, 6 Feb 2020 04:35:59 -0800 (PST) To: Mark Brown References: <29a846da33c02df64eca62b5fa0f3884652f788f.1580950046.git.robin.murphy@arm.com> <20200206114606.GM3897@sirena.org.uk> From: Robin Murphy Message-ID: Date: Thu, 6 Feb 2020 12:36:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200206114606.GM3897@sirena.org.uk> Content-Language: en-GB Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, heiko@sntech.de, lgirdwood@gmail.com, linux-rockchip@lists.infradead.org, pgwipeout@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: rockchip: Make RK3328 GPIO_MUTE control explicit 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On 2020-02-06 11:46 am, Mark Brown wrote: > On Thu, Feb 06, 2020 at 01:07:12AM +0000, Robin Murphy wrote: >> The RK3328 reference design uses an external line driver IC as a buffer >> on the analog codec output, enabled by the GPIO_MUTE pin, and such a >> configuration is currently assumed in the codec driver's direct poking >> of GRF_SOC_CON10 to control the GPIO_MUTE output value. However, some > > This makes sense but it is an ABI break so is going to need > quirking for existing boards that unfortunately rely on the > existing behaviour. Yeah, that's where it gets tricky - there doesn't seem to be a nice way to differentiate between "no GPIO because old DT" and "no GPIO because the enable is hard-wired/irrelevant and GPIO_MUTE doesn't do what you think it does", and it seems really improper to introduce a DT property for the sole purpose of telling a Linux driver not to assume something it shouldn't really have in the first place. My opinion fell on the side of a minor ABI break being the lesser of two evils, given that the worst case once people start enabling this codec on Renegade/ROC-CC boards (which I was only anticipating, but have just discovered is happening already[1]) results in unexpectedly stuffing 3.3V into the SD card and SoC I/O domain while both are in 1.8V mode, and that the change would only really affect one other current board (Rock64), where most mainline users are likely to be upgrading their DTB in lock-step with the kernel anyway. I guess the existing (mis)behaviour could be predicated on an of_machine_is_compatible() check for Rock64 boards - it's ugly, but should do the job if you feel it's more important to be 100% strict about not regressing supported systems for any possible kernel/DTB combination. Thanks, Robin. [1] https://github.com/armbian/build/commit/18b24717be9639b65b86db3dbcf2b42fe73ca12c _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH 2/3] ASoC: rockchip: Make RK3328 GPIO_MUTE control explicit Date: Thu, 6 Feb 2020 12:36:04 +0000 Message-ID: References: <29a846da33c02df64eca62b5fa0f3884652f788f.1580950046.git.robin.murphy@arm.com> <20200206114606.GM3897@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200206114606.GM3897-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> Content-Language: en-GB Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mark Brown Cc: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org List-Id: linux-rockchip.vger.kernel.org On 2020-02-06 11:46 am, Mark Brown wrote: > On Thu, Feb 06, 2020 at 01:07:12AM +0000, Robin Murphy wrote: >> The RK3328 reference design uses an external line driver IC as a buffer >> on the analog codec output, enabled by the GPIO_MUTE pin, and such a >> configuration is currently assumed in the codec driver's direct poking >> of GRF_SOC_CON10 to control the GPIO_MUTE output value. However, some > > This makes sense but it is an ABI break so is going to need > quirking for existing boards that unfortunately rely on the > existing behaviour. Yeah, that's where it gets tricky - there doesn't seem to be a nice way to differentiate between "no GPIO because old DT" and "no GPIO because the enable is hard-wired/irrelevant and GPIO_MUTE doesn't do what you think it does", and it seems really improper to introduce a DT property for the sole purpose of telling a Linux driver not to assume something it shouldn't really have in the first place. My opinion fell on the side of a minor ABI break being the lesser of two evils, given that the worst case once people start enabling this codec on Renegade/ROC-CC boards (which I was only anticipating, but have just discovered is happening already[1]) results in unexpectedly stuffing 3.3V into the SD card and SoC I/O domain while both are in 1.8V mode, and that the change would only really affect one other current board (Rock64), where most mainline users are likely to be upgrading their DTB in lock-step with the kernel anyway. I guess the existing (mis)behaviour could be predicated on an of_machine_is_compatible() check for Rock64 boards - it's ugly, but should do the job if you feel it's more important to be 100% strict about not regressing supported systems for any possible kernel/DTB combination. Thanks, Robin. [1] https://github.com/armbian/build/commit/18b24717be9639b65b86db3dbcf2b42fe73ca12c 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=-7.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 488A3C2D0B1 for ; Thu, 6 Feb 2020 12:36:12 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 1A2C2214AF for ; Thu, 6 Feb 2020 12:36:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CwuplZwE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A2C2214AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5QE/c94NvSWdBLcdtqWaJuXMTE67pvn2bPQWKfRCmbk=; b=CwuplZwEOF+RuXLnHurBDdm0s GU17OolnC79RxtXac+QaaIf2A+ocqBhqig/pbGga4T303NmpeW4lbb4hQxmmNQWL7wBK8OCpbEHT0 +vQFaFwvR/L+++RyVeCeivr5qNhFUamT2W6W9ZcMsjHoonIC0YOhKHSP3almQZZcxal3/bGwYFS6+ tEiFKPMis+jTVtJwC5Acvduf9jNaJ2bt1MlFFop8FQEn5yQLT1MfU+q4JOdn00gMn55x3vY0d1j6t FHTMkpsGrgpY1SXOYcuY8XqbvDICaXcEuID2z6pxf5uKisviNuLJmKM627s8iJ0YnCAoBav50/slo tgL5q2+oA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1izgO7-0000Ju-3U; Thu, 06 Feb 2020 12:36:07 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1izgO3-0000JJ-RH; Thu, 06 Feb 2020 12:36:05 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2A7B630E; Thu, 6 Feb 2020 04:36:01 -0800 (PST) Received: from [192.168.1.123] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 03BE73F68E; Thu, 6 Feb 2020 04:35:59 -0800 (PST) Subject: Re: [PATCH 2/3] ASoC: rockchip: Make RK3328 GPIO_MUTE control explicit To: Mark Brown References: <29a846da33c02df64eca62b5fa0f3884652f788f.1580950046.git.robin.murphy@arm.com> <20200206114606.GM3897@sirena.org.uk> From: Robin Murphy Message-ID: Date: Thu, 6 Feb 2020 12:36:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200206114606.GM3897@sirena.org.uk> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200206_043603_930955_A32F8FF4 X-CRM114-Status: GOOD ( 16.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, heiko@sntech.de, lgirdwood@gmail.com, linux-rockchip@lists.infradead.org, pgwipeout@gmail.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-02-06 11:46 am, Mark Brown wrote: > On Thu, Feb 06, 2020 at 01:07:12AM +0000, Robin Murphy wrote: >> The RK3328 reference design uses an external line driver IC as a buffer >> on the analog codec output, enabled by the GPIO_MUTE pin, and such a >> configuration is currently assumed in the codec driver's direct poking >> of GRF_SOC_CON10 to control the GPIO_MUTE output value. However, some > > This makes sense but it is an ABI break so is going to need > quirking for existing boards that unfortunately rely on the > existing behaviour. Yeah, that's where it gets tricky - there doesn't seem to be a nice way to differentiate between "no GPIO because old DT" and "no GPIO because the enable is hard-wired/irrelevant and GPIO_MUTE doesn't do what you think it does", and it seems really improper to introduce a DT property for the sole purpose of telling a Linux driver not to assume something it shouldn't really have in the first place. My opinion fell on the side of a minor ABI break being the lesser of two evils, given that the worst case once people start enabling this codec on Renegade/ROC-CC boards (which I was only anticipating, but have just discovered is happening already[1]) results in unexpectedly stuffing 3.3V into the SD card and SoC I/O domain while both are in 1.8V mode, and that the change would only really affect one other current board (Rock64), where most mainline users are likely to be upgrading their DTB in lock-step with the kernel anyway. I guess the existing (mis)behaviour could be predicated on an of_machine_is_compatible() check for Rock64 boards - it's ugly, but should do the job if you feel it's more important to be 100% strict about not regressing supported systems for any possible kernel/DTB combination. Thanks, Robin. [1] https://github.com/armbian/build/commit/18b24717be9639b65b86db3dbcf2b42fe73ca12c _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel