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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 72ED2C4320A for ; Tue, 17 Aug 2021 05:44:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4AC1360F58 for ; Tue, 17 Aug 2021 05:44:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234261AbhHQFpA (ORCPT ); Tue, 17 Aug 2021 01:45:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234237AbhHQFo7 (ORCPT ); Tue, 17 Aug 2021 01:44:59 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB288C0613CF for ; Mon, 16 Aug 2021 22:44:26 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id x7so31050126ljn.10 for ; Mon, 16 Aug 2021 22:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YOKejl87y0ski0VdMRkyNRA2v7H+vqyupx7Esp13/wE=; b=a6IvKzyOyIQZqQYz+g/aLPoRbm5h20bCZsjIxf2QcwFz0VIyf7oEIDWaVkrgyH8dVy h4m6QRA7pfehKCUKoALq+XGDZt5U7OBbb0gKEDtP7fuIogf7goHUm/xLrW3OSFHRYE/2 l/S0skrt0NKW06MSkEcsSsY+vfCoBhM6F24NE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YOKejl87y0ski0VdMRkyNRA2v7H+vqyupx7Esp13/wE=; b=UCjzrenCMhfHmKobLozpvFDOu6gwWuxcBPqvOXJ3Ny/K0qWkatxbwSU3XnKTpuV/gm NgDOLH3jRgD8o3Ie5Y3+3XZH7dps9y2PW6oJ2db2jOBa6KGjMDez3Om7y1ocIGgNSwz2 o0rPPp7VrkXzAx7umCneWD8ocPTRdkFU2dxGpf51sLctdoEkHBeYq0dX/xAzMXVVEWdn CbyRi3qGwXlAnJvmS7naXBsqg18HPCVlh6O08FkeZIeJXz0er51CJtP1vaq7u0iz8KfP sLntxziwAVEjW2fU/hph1/T1y6c1mF3VbxF12NjAGLtGgAOn0C/Z6J/kaCb3Wo6HNjSl P3fA== X-Gm-Message-State: AOAM5302bwsQ/qcGuiA6aX7NLL7ToaMyVIwCh2NGXbI6WT8h65JkvPoZ n31AfHbIgNT0ltTeMod7LIUs5OYomYnmYqhwEoAgcw== X-Google-Smtp-Source: ABdhPJwDdjRJIqMRTx/tVA7vEY9ayN6r0dWnuWHx5K0aCWGb+5ATkAUHpOt5qq3zzCPruae3ZI8O0IO36YD+eRA8lIM= X-Received: by 2002:a05:651c:1785:: with SMTP id bn5mr1677465ljb.18.1629179065185; Mon, 16 Aug 2021 22:44:25 -0700 (PDT) MIME-Version: 1.0 References: <20210710081722.1828-1-zhiyong.tao@mediatek.com> <20210710081722.1828-2-zhiyong.tao@mediatek.com> <1626940470.29611.9.camel@mhfsdcap03> <07388dac4e25e0f260725e8f80ba099d5aa80949.camel@mediatek.com> <4fd12d5c53f6492e5fa3ba94a78b9a149f5b6ed9.camel@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Tue, 17 Aug 2021 13:44:13 +0800 Message-ID: Subject: Re: [PATCH v10 1/2] dt-bindings: pinctrl: mt8195: add rsel define To: "zhiyong.tao" Cc: Linus Walleij , Rob Herring , Mark Rutland , Matthias Brugger , Sean Wang , srv_heupstream , hui.liu@mediatek.com, Eddie Huang , Light Hsieh , Biao Huang , Hongzhou Yang , Sean Wang , Seiya Wang , Devicetree List , LKML , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "moderated list:ARM/Mediatek SoC support" , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Aug 17, 2021 at 10:21 AM zhiyong.tao wrote: > > On Tue, 2021-08-17 at 01:00 +0200, Linus Walleij wrote: > > On Mon, Aug 16, 2021 at 5:38 PM Chen-Yu Tsai > > wrote: > > > On Mon, Aug 16, 2021 at 6:48 PM zhiyong.tao < > > > zhiyong.tao@mediatek.com> wrote: > > > > > I'll take that as "use SI units whenever possible and > > > > > reasonable". > > > > > > > > ==> so It doesn't need to change the define, is it right? > > > > we will keep the common define. > > > > > > Actually I think it would be possible and reasonable to use SI > > > units > > > in this case, since you are the vendor and have the resistor values > > > to implement the support. Having different sets of values for > > > different > > > chips is nothing out of the ordinary. We already have to account > > > for > > > different number of pins and different pin functions. That is what > > > compatible strings are for. > > > > I fully agree with Chen-Yu's analysis here. > > > > Zhiyong can you make an attempt to use SI units (Ohms) and see > > what it will look like? I think it will look better for users and it > > will > > be less risk to make mistakes. > > > > Yours, > > Linus Walleij > > Hi Linus & chen-yu, > > The rsel actual bias resistance of each setting is different in > different IC. For example, in mt8195, the rsel actual bias resistance > setting like as: > MTK_PULL_SET_RSEL_000:75K in PU, 75k in PD; > MTK_PULL_SET > _RSEL_001:10k in PU, 5k in PD; > MTK_PULL_SET_RSEL_010:5k in PU, 75k in > PD; > MTK_PULL_SET_RSEL_011:4k in PU, 5K in PD; > MTK_PULL_SET_RSEL_100:3k in > PU, 75k in PD; > MTK_PULL_SET_RSEL_101:2k in PU, 5K in PD; > MTK_PULL_SET_RSE > L_110:1.5k in PU, 75k in PD; > MTK_PULL_SET_RSEL_111:1k in PU, 5k in PD. > > but in mt8192, the rsel actual bias resistance setting like as: > MTK_PULL_SET_RSEL_000:75K in PU, 75k in PD; > MTK_PULL_SET_RSEL_001:3k in PU, 5k in PD; > MTK_PULL_SET_RSEL_010:10k in PU, 75k in PD; > MTK_PULL_SET_RSEL_011:1k in PU, 5K in PD; > > Can you help me to provide a suggestion common define for the all > different IC? > It seems that we should add a new define, if we upstream a new IC > pinctrl driver in the future. I assume you mean the macros used in the device tree? The point of using SI units is to get rid of the macros. Instead of: bias-pull-up = ; and bias-pull-down = ; We want: bias-pull-up = <75000>; and bias-pull-down = <5000>; And the pinctrl driver then converts the real values in the device tree into register values using some lookup table. The DT schema could then enumerate all the valid resistor values, and get proper validity checking. Now if you really wanted to keep some symbols for mapping hardware register values to resistor values, you could have #define MT8192_PULL_UP_RSEL_001 75000 #define MT8192_PULL_DOWN_RSEL_001 5000 or have them all named MTK_PULL_{UP,DOWN}_RSEL_NNN, but split into different header files, one per SoC. Personally I think having the macros is a bad idea if proper values are available. It just adds another layer of indirection, and another area where errors can creep in. Regards ChenYu