On Tue, Sep 14, 2021 at 8:27 PM zhiyong.tao <zhiyong.tao@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > > 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@xxxxxxxxxxxx > > > > > 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@xxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > This patch adds rsel define for mt8195. > > > > > > > > > > > > > > Signed-off-by: Zhiyong Tao <zhiyong.tao@xxxxxxxxxxxx> > > > > > > > --- > > > > > > > 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@xxxxxxxxxxxxxxxxxxx > > > > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
