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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A639C54EAA for ; Mon, 30 Jan 2023 23:50:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230025AbjA3Xuq (ORCPT ); Mon, 30 Jan 2023 18:50:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229890AbjA3Xup (ORCPT ); Mon, 30 Jan 2023 18:50:45 -0500 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E5D52DE61 for ; Mon, 30 Jan 2023 15:50:40 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id hx15so17329277ejc.11 for ; Mon, 30 Jan 2023 15:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CdvsgrA7Oj6v+pII1HiNSeqEHAP6/ZI2lwGFyGvAsVo=; b=tVYM9mla89v6h9OfFJ28dH2M4ZDks3lAvzO9SVJu1Ka6s/vkom70IHE0p5q49UOCFF lcan7e2Gj5FSDUDe2P24iDG8tXKJK4xIldHuQXaBUZR8D8e2aSW9xfFPy/vRgfJ2Zbv5 WlmReiaewmzxqZg6myB8M6amgfobV8b09t2C7G/uZnKexMDy6fz8Jfcjmii33nUgzWA3 8hW9Ih1KamU9QEUl0rLPXbzqPG0fBg1FLI9Q2tfo3EsA0uK7jC+/VJi7tz9cLmVuH9/9 uryy7MUv/uPnQN1totDd2kaiTGpSyHKD9zDuFnqD99oJt7Y7yDnVN45hhWiX+M9IcEnD hobw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CdvsgrA7Oj6v+pII1HiNSeqEHAP6/ZI2lwGFyGvAsVo=; b=LuhHMbXk+thyXXYGdNX3N4H/sXExkpNS6Em1kx8gpUat4JKbNFVA5jQV/o2b2olsSF f9lAK4814hf3fw3aismYKNIC8eKZ1zjlMSWgQe2Qbagv4IWIrbpaZGLaA3Qu4Cwmv7ek Hrtiw9P5meMtKONFO+ZKfWGub12ZZlo92XISj/9fSw6Ezu4v4fNlGkXgKiDRrAIFKATU 77L4KjRwjRhBT0XIStWwGDJQea0gByDvgEG17qYyITEIpLS1hivz0NcgcUogkafQS10H tcJKxrlQeIkMlmgKeOVhX802Paw7hGj2zgS2OUIqJXvd8jpvLxkS5FySLreQUf4hwAhH 2bBQ== X-Gm-Message-State: AO0yUKUqPteKQwkW0A4hGGnnMOvdyQtfxHq/7LxToFCUBAiq1nSxoOQF PtGRnK53qiLIaetUHt2DuIgzyA== X-Google-Smtp-Source: AK7set/R03RcQsWZDYsuBbf4+cDKPgc0v65LKBW157TWbbBEU6KqM2q+lfaQITm6rV7drKYB4ApuwQ== X-Received: by 2002:a17:906:58d6:b0:878:5372:a34b with SMTP id e22-20020a17090658d600b008785372a34bmr25791758ejs.45.1675122639006; Mon, 30 Jan 2023 15:50:39 -0800 (PST) Received: from [192.168.1.101] (abyl20.neoplus.adsl.tpnet.pl. [83.9.31.20]) by smtp.gmail.com with ESMTPSA id w9-20020a170906184900b007c0f217aadbsm7421143eje.24.2023.01.30.15.50.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Jan 2023 15:50:38 -0800 (PST) Message-ID: Date: Tue, 31 Jan 2023 00:50:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 Subject: Re: [RFC PATCH 1/2] dt-bindings: pincfg-node: Introduce an overridable way to set bias on pins To: Linus Walleij Cc: linux-arm-msm@vger.kernel.org, andersson@kernel.org, agross@kernel.org, krzysztof.kozlowski@linaro.org, marijn.suijten@somainline.org, Rob Herring , Krzysztof Kozlowski , linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230130165435.2347569-1-konrad.dybcio@linaro.org> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 31.01.2023 00:10, Linus Walleij wrote: > On Mon, Jan 30, 2023 at 5:54 PM Konrad Dybcio wrote: > >> We came to a point where we sometimes we support a few dozen boards >> with a given SoC. Sometimes, we have to take into consideration >> configurations which deviate rather significatly from the reference >> or most common designs. In the context of pinctrl, this often comes >> down to wildly different pin configurations. While pins, function and >> drive-strength are easily overridable, the (mostly) boolean properties >> associated with setting bias, aren't. This wouldn't be much of a >> problem if they didn't differ between boards so often, preventing us >> from having a "nice" baseline setup without inevitably having to go >> with an ugly /delete-property/. > > I see what the problem is. > > Have you considered pulling out *all* the pin config for a certain > reference design into its own .dtsi file, simply? And then not include > that to the next product. > > This pattern is pretty common. It's *a* solution, but we already have some soc-pmics.dtsi-s which include PMICs and reference regulator-to-peripherals assignments. Adding another soc-reference-pins.dtsi would open the doors for other soc-abcxyz.dtsi-s which would in turn lead to exchanging the problem of redefining the same sets of properties 50 times to having to include 20 device trees for each and every device. Allow that and we basically have msm-3.10 except in torvalds/linux. Adding to that, some devices are 98% compliant with the reference designs, but randomly swap out one pin etc. > >> Introduce bias-type, a bias-type- >> specific property and clone the pinconf-generic type enum into >> dt-bindings to allow for setting the bias in an easily overridable >> manner such as: >> >> // SoC DT >> i2c0_pin: i2c0-pin-state { >> pins = "gpio10"; >> function = "gpio"; >> bias-type = ; >> }; >> >> // Deviant board DT >> &i2c0_pin { >> bias-type = ; >> }; >> >> Signed-off-by: Konrad Dybcio > > The idea is pretty straight-forward. > > But it applies to systems already using the bool flags. So what do > we do the day we manage to have: > > { > bias-type = ; > bias-pull-up; > }; > > As you see this makes it necessary to author some really nasty > YAML to make sure this cannot happen or everyone has to make > a runtime check for it. oneOf: - bias-type - enum: - bias-pull-down - bias-... Doesn't seem really nasty to me.. And a runtime check is basically in place, as I made sure the code in 2/2 prefers bias-type and falls back to the existing mechanism if it's not found. > > Another problem is that I was just discussing with Bjorn for some > specific i2c pull-up, was actually using the argument for > bias-pull-up with a parameter: > > bias-pull-up = <8000000>; // 8kOhm pull-up This is an easy fix. Count the elements and if there's more than one, pass the second one as a value. Both of these things already have common of_ functions made just for that. > > Not to mention that other platforms than qcom use this and > qcom use it for drive-strength I think? > > +#define DRIVE_STRENGTH 9 > +#define DRIVE_STRENGTH_UA 10 > > drive-strength = <8>; // 8mA drive strength > > bias-type = ; > > OK where do I put my 8 mA now? If you look at the 2/2 patch, this property only reads BIAS_ values, which can't coexist anyway. I copied the entire enum for completeness. But if we were to go with this approach, having one for (in|out)put-*, where only having one of them at a time makes sense could be beneficial too.. Konrad > > Yours, > Linus Walleij