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 [off-list ref] wrote:

On Mon, 2021-09-06 at 16:20 +0800, Chen-Yu Tsai wrote:

quoted

On Sat, Sep 4, 2021 at 4:40 PM zhiyong.tao 
[off-list ref]
wrote:

quoted

On Thu, 2021-09-02 at 11:35 +0800, Chen-Yu Tsai wrote:

quoted

On Thu, Sep 2, 2021 at 10:54 AM zhiyong.tao < 
zhiyong.tao@mediatek.com

quoted

wrote:

On Wed, 2021-09-01 at 12:35 +0800, Chen-Yu Tsai wrote:

quoted

On Mon, Aug 30, 2021 at 8:36 AM Zhiyong Tao < 
zhiyong.tao@mediatek.com> wrote:

quoted

This patch adds rsel define for mt8195.

Signed-off-by: Zhiyong Tao <redacted>
---
 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.

quoted

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.

quoted

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

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

 #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$