[PATCH v10 1/2] dt-bindings: pinctrl: mt8195: add rsel define

[zhiyong.tao]

On Wed, 2021-08-18 at 14:25 +0800, Chen-Yu Tsai wrote:
> On Wed, Aug 18, 2021 at 4:09 AM Linus Walleij <
> linus.walleij at linaro.org> wrote:
> > 
> > On Tue, Aug 17, 2021 at 9:51 AM zhiyong.tao <
> > zhiyong.tao at mediatek.com> wrote:
> > 
> > > In one chip, If GPIO is different, the MTXXXX_PULL_UP_RSEL_001
> > > may
> > > means different actual bias resistance setting.
> > > 
> > > For example,
> > > 
> > > KPROW IO
> > > Paramters       Descriptions                   Min      Typ     M
> > > ax
> > >  UNIT
> > > Rpd     Input pull-down
> > > resistance      40      75      190     Kohm
> > > Rpu     Input pull-up
> > > resistance        40      75      190     Kohm
> > > Rpd     Input pull-down
> > > resistance      0.8     1.6     2       Kohm
> > > Rpu     Input pull-up
> > > resistance        0.8     1.6     2       Kohm
> > 
> > This is exactly why we should try to use SI units in the device
> > tree.
> > I assume that the software can eventually configure which
> > resistance
> > it gets?
> > 
> > The electronics people will say make sure it is pulled down by
> > around
> > 80 kOhm, they can put that on the device tree and your code can
> > say, "hm 40 < 80 < 190 this is OK" and let the value pass.
> > 
> > We do not define these exact semantics, it is up to the driver code
> > to decide what to do with the Ohm value 80000 in this case, but
> > it makes perfect sent for me to let it pass and fail if someone
> > for example requests 20 kOhm, or at least print a helpful warning:
> > 
> > dev_warn(dev, "the requested resistance %d is out of range,
> > supported
> > range %d to %d kOhm\n",
> >                  val, low, high);
> > 
> > This is what makes the SI units really helpful for people writing
> > device
> > trees: solve real integration tasks and make it easy to do the
> > right thing.
> 
> I think this makes a lot of sense. The driver could select the
> closest
> setting. And from what Zhiyong mentioned offline, the resistor values
> aren't exact as specified in the datasheet. I suppose this is
> expected
> with any electronics. So the hardware integration will say to pull up
> or down by some value, and the driver will do its best to fulfill
> that
> request. That precludes DT schema checking for the values used, but I
> think that is a good compromise.
> 
> Zhiyong also mentioned that some of their downstream integrators
> might
> not be able to deal with actual values, and would prefer symbols tied
> to specific RSEL values. I think that would be doable together using
> some _magic_ values, but I would prefer not to if it were avoidable.
> 
> 
> Regards
> ChenYu

Hi chenyu & Linus,

Thanks for your suggestion.

we will try to update a new version to use SI units in the device tree
in the rsel feature patch.

Thanks