LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Light Hsieh (謝明燈)" <Light.Hsieh@mediatek.com>
To: "Chen-Yu Tsai" <wenst@chromium.org>,
	"Zhiyong Tao (陶志勇)" <Zhiyong.Tao@mediatek.com>
Cc: "Rob Herring" <robh+dt@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Sean Wang" <sean.wang@kernel.org>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	"Hui Liu (刘辉)" <Hui.Liu@mediatek.com>,
	"Eddie Huang (黃智傑)" <eddie.huang@mediatek.com>,
	"Biao Huang (黄彪)" <Biao.Huang@mediatek.com>,
	"Hongzhou Yang" <hongzhou.yang@mediatek.com>,
	"Sean Wang" <Sean.Wang@mediatek.com>,
	"Seiya Wang (王迺君)" <seiya.wang@mediatek.com>,
	"Devicetree List" <devicetree@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: RE: [PATCH v11 1/4] dt-bindings: pinctrl: mt8195: add rsel define
Date: Wed, 15 Sep 2021 05:01:34 +0000	[thread overview]
Message-ID: <SI2PR03MB5260191DA69F435F8539A11C84DB9@SI2PR03MB5260.apcprd03.prod.outlook.com> (raw)
In-Reply-To: <CAGXv+5FF25a=28YNmVx_FNJ1o+OrR_LWkd1VPe6ejoxX9-bkaA@mail.gmail.com>

For backward compatible to previous usage and many customers of mediatek, MTK would not change previous usage of bias-pull-up and bias-pull-down setting usage.

The si unit usage will only apply to rsel only.

Please sto  give comments on changing mediatek's previous usage.

Light

-----Original Message-----
From: Chen-Yu Tsai [mailto:wenst@chromium.org] 
Sent: Wednesday, September 15, 2021 11:25 AM
To: Zhiyong Tao (陶志勇)
Cc: Rob Herring; Linus Walleij; Mark Rutland; Matthias Brugger; Sean Wang; srv_heupstream; Hui Liu (刘辉); 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
Subject: Re: [PATCH v11 1/4] dt-bindings: pinctrl: mt8195: add rsel define

On Tue, Sep 14, 2021 at 8:27 PM zhiyong.tao <zhiyong.tao@mediatek.com> wrote:
>
> On Mon, 2021-09-06 at 16:20 +0800, Chen-Yu Tsai wrote:
> > On Sat, Sep 4, 2021 at 4:40 PM zhiyong.tao 
> > <zhiyong.tao@mediatek.com>
> > wrote:
> > >
> > > On Thu, 2021-09-02 at 11:35 +0800, Chen-Yu Tsai wrote:
> > > > On Thu, Sep 2, 2021 at 10:54 AM zhiyong.tao < 
> > > > zhiyong.tao@mediatek.com
> > > > > wrote:
> > > > >
> > > > > On Wed, 2021-09-01 at 12:35 +0800, Chen-Yu Tsai wrote:
> > > > > > On Mon, Aug 30, 2021 at 8:36 AM Zhiyong Tao < 
> > > > > > zhiyong.tao@mediatek.com> wrote:
> > > > > > >
> > > > > > > This patch adds rsel define for mt8195.
> > > > > > >
> > > > > > > Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com>
> > > > > > > ---
> > > > > > >  include/dt-bindings/pinctrl/mt65xx.h | 9 +++++++++
> > > > > > >  1 file changed, 9 insertions(+)
> > > > > > >
> > > > > > > diff --git a/include/dt-bindings/pinctrl/mt65xx.h
> > > > > > > b/include/dt-
> > > > > > > bindings/pinctrl/mt65xx.h
> > > > > > > index 7e16e58fe1f7..f5934abcd1bd 100644
> > > > > > > --- a/include/dt-bindings/pinctrl/mt65xx.h
> > > > > > > +++ b/include/dt-bindings/pinctrl/mt65xx.h
> > > > > > > @@ -16,6 +16,15 @@
> > > > > > >  #define MTK_PUPD_SET_R1R0_10 102  #define 
> > > > > > > MTK_PUPD_SET_R1R0_11 103
> > > > > > >
> > > > > > > +#define MTK_PULL_SET_RSEL_000  200 #define 
> > > > > > > +MTK_PULL_SET_RSEL_001  201 #define MTK_PULL_SET_RSEL_010  
> > > > > > > +202 #define MTK_PULL_SET_RSEL_011  203 #define 
> > > > > > > +MTK_PULL_SET_RSEL_100  204 #define MTK_PULL_SET_RSEL_101  
> > > > > > > +205 #define MTK_PULL_SET_RSEL_110  206 #define 
> > > > > > > +MTK_PULL_SET_RSEL_111  207
> > > > > >
> > > > > > Could you keep the spacing between constants tighter, or 
> > > > > > have no spacing at all? Like having MTK_PULL_SET_RSEL_000 
> > > > > > defined as 104 and so on. This would reduce the chance of 
> > > > > > new macro values colliding with actual resistor values set 
> > > > > > in the datasheets, plus a contiguous space would be easy to 
> > > > > > rule as macros.
> > > > > >
> > > > > > ChenYu
> > > > >
> > > > > Hi chenyu,
> > > > > By the current solution, it won't be mixed used by 
> > > > > MTK_PULL_SET_RSEL_XXX and real  resistor value.
> > > > > If user use MTK_PULL_SET_RSEL_XXX, They don't care the define 
> > > > > which means how much resistor value.
> > > >
> > > > What I meant was that by keeping the value space tight, we avoid 
> > > > the situation where in some new chip, one of the RSEL resistors 
> > > > happens to be 200 or 300 ohms. 100 is already taken, so there's 
> > > > nothing we can do if new designs actually do have 100 ohm 
> > > > settings.
> > > >
> > > > > We think that we don't contiguous macro space for different 
> > > > > register.
> > > > > It may increase code complexity to make having
> > > > > MTK_PULL_SET_RSEL_000
> > > > > defined as 104.
> > > >
> > > > Can you elaborate? It is a simple range check and offset 
> > > > handling.
> > > > Are
> > > > you concerned that a new design would have R2R1R0 and you would 
> > > > like the macros to be contiguous?
> > > >
> > > > BTW I don't quite get why decimal base values (100, 200, etc.) 
> > > > were chosen. One would think that binary bases are easier to 
> > > > handle in code.
> > > >
> > > >
> > > > ChenYu
> > > >
> > >
> > > Yes,we concerned that a new design would have R2R1R0 and we would 
> > > like the macros to be contiguous in the feature. we reserve it.
> >
> > I see. That makes sense. Do you expect to see R3 or even R4 in the 
> > future?
> > Or put another way, do you expect to see resistor values of 150 or
> > 200
> > supported?
> >
> > Maybe we could reserve 200 and start from 201 for the RSEL macros?
> >
> > Some planning needs to be done here to avoid value clashes.
> >
> > > We think that decimal and binary base values are the same for the 
> > > feature.
> >
> > With decimal numbers you end up wasting a bit more space, since the 
> > hardware is always using binary values. I just found it odd, that's 
> > all.
> >
> > ChenYu
> >
> > > > > Thanks.
>
> Hi ChenYu,
>
> In the next version, we provide a solution which we discussed internal 
> to avoid value clashes.
>
> The solution:
> 1. We will keep the define "MTK_PULL_SET_RSEL_000 200". It won't 
> change.
>
> 2. We will add a property in pio dtsi node, for example, the property 
> name is "rsel_resistance_in_si_unit".
> We will add a flag "rsel_si_unit" in pinctrl device.
> in probe function, we will identify the property name 
> "rsel_resistance_in_si_unit" to set the flag "rsel_si_unit" value.
> So it can void value clashes.

I suppose a "mediatek," prefix should be added. And to future proof things this should probably apply to all bias-up/down values, so "mediatek,bias-resistance-in-si-units"?

And the description should include something like that:

  Past usage of bias-up/down values included magic numbers to specify
  different hardware configurations based on register values. This
  property specifies that all values used for bias-up/down for this
  controller shall be in SI units.

And this proposal is still subject to maintainer (not me) review.


> 3.We will provide the define "MTK_PULL_SET_RSEL_000 200" and si unit 
> two solution. users can support which solution by add property 
> "rsel_resistance_in_si_unit" in dts node or not.

Thanks. I think this solution does provide a clear separation of the two value spaces.

ChenYu

> > > > >
> > > > > >
> > > > > > >  #define MTK_DRIVE_2mA  2
> > > > > > >  #define MTK_DRIVE_4mA  4
> > > > > > >  #define MTK_DRIVE_6mA  6
> > > > > > > --
> > > > > > > 2.18.0
> > > > > > > _______________________________________________
> > > > > > > Linux-mediatek mailing list 
> > > > > > > Linux-mediatek@lists.infradead.org
> > > > > > > https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-mediatek__;!!CTRNKA9wMg0ARbw!zfqxZT9WYP_G3T1jav-FwDuN6JMr70ldR-lKVmyhZjYDkIBoyCz1FKT-RGI7cVhOQn4$ 

  reply	other threads:[~2021-09-15  5:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30  0:35 [PATCH v11 0/4] Mediatek pinctrl patch on mt8195 Zhiyong Tao
2021-08-30  0:36 ` [PATCH v11 1/4] dt-bindings: pinctrl: mt8195: add rsel define Zhiyong Tao
2021-08-31 22:09   ` Rob Herring
2021-09-01  4:35   ` Chen-Yu Tsai
     [not found]     ` <1630551265.2247.11.camel@mhfsdcap03>
2021-09-02  3:35       ` Chen-Yu Tsai
     [not found]         ` <4787120f25e76ed3727e10011522fc075da52e32.camel@mediatek.com>
2021-09-06  8:20           ` Chen-Yu Tsai
     [not found]             ` <05f453a466995a6c272d585f18e81c5fcb837a0b.camel@mediatek.com>
2021-09-15  3:25               ` Chen-Yu Tsai
2021-09-15  5:01                 ` Light Hsieh (謝明燈) [this message]
2021-08-30  0:36 ` [PATCH v11 2/4] dt-bindings: pinctrl: mt8195: change pull up/down description Zhiyong Tao
2021-08-31 22:13   ` Rob Herring
     [not found]     ` <1630461636.21764.1.camel@mhfsdcap03>
2021-09-01 10:21       ` Chen-Yu Tsai
2021-08-30  0:36 ` [PATCH v11 3/4] pinctrl: mediatek: mt8195: Add pm_ops Zhiyong Tao
2021-08-31  7:53   ` Chen-Yu Tsai
2021-08-30  0:36 ` [PATCH v11 4/4] pinctrl: mediatek: add rsel setting on MT8195 Zhiyong Tao
2021-09-01 10:10   ` Chen-Yu Tsai
     [not found]     ` <b82ae857d8a3acf117721bb83d4dbbc44f612565.camel@mediatek.com>
2021-09-06 10:09       ` Chen-Yu Tsai
     [not found]         ` <74a3a96745e93c5a2392b8a39822c872fd468466.camel@mediatek.com>
2021-09-16  9:40           ` Chen-Yu Tsai
2021-09-19 19:33           ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SI2PR03MB5260191DA69F435F8539A11C84DB9@SI2PR03MB5260.apcprd03.prod.outlook.com \
    --to=light.hsieh@mediatek.com \
    --cc=Biao.Huang@mediatek.com \
    --cc=Hui.Liu@mediatek.com \
    --cc=Sean.Wang@mediatek.com \
    --cc=Zhiyong.Tao@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eddie.huang@mediatek.com \
    --cc=hongzhou.yang@mediatek.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sean.wang@kernel.org \
    --cc=seiya.wang@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=wenst@chromium.org \
    --subject='RE: [PATCH v11 1/4] dt-bindings: pinctrl: mt8195: add rsel define' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).