[PATCH v11 1/4] dt-bindings: pinctrl: mt8195: add rsel define
Chen-Yu Tsai
wenst at chromium.org
Mon Sep 6 01:20:45 PDT 2021
On Sat, Sep 4, 2021 at 4:40 PM zhiyong.tao <zhiyong.tao at 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 at 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 at mediatek.com> wrote:
> > > > >
> > > > > This patch adds rsel define for mt8195.
> > > > >
> > > > > Signed-off-by: Zhiyong Tao <zhiyong.tao at 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.
> > >
> > > >
> > > > > #define MTK_DRIVE_2mA 2
> > > > > #define MTK_DRIVE_4mA 4
> > > > > #define MTK_DRIVE_6mA 6
> > > > > --
> > > > > 2.18.0
> > > > > _______________________________________________
> > > > > Linux-mediatek mailing list
> > > > > Linux-mediatek at lists.infradead.org
> > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
More information about the linux-arm-kernel
mailing list