diff mbox series

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

Message ID 20210710081722.1828-2-zhiyong.tao@mediatek.com
State Superseded
Headers show
Series Mediatek pinctrl patch on mt8195 | expand

Commit Message

Zhiyong Tao July 10, 2021, 8:17 a.m. UTC
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(+)

Comments

Chen-Yu Tsai July 13, 2021, 7:17 a.m. UTC | #1
Hi,

On Sat, Jul 10, 2021 at 4:17 PM 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
> +

Instead of all the obscure macros and the new custom "rsel" property,
which BTW is not in the bindings, can't we just list the actual bias
resistance of each setting? We could also migrate away from R1R0.

Then we can specify the setting with the standard bias-pull-up/down
properties [1].

Also, please ask internally if Mediatek could relicense all the header
files that Mediatek has contributed under include/dt-bindings/pinctrl/ [2]
to GPL-2.0 and BSD dual license. These files are part of the DT bindings
and we really want them to be dual licensed as well, and not just the
YAML files.


Regards
ChenYu


[1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml#L37
[2] Note that a few files were contributed by other people

>  #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
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Zhiyong Tao July 22, 2021, 7:54 a.m. UTC | #2
On Tue, 2021-07-13 at 15:17 +0800, Chen-Yu Tsai wrote:
> Hi,

> 

> On Sat, Jul 10, 2021 at 4:17 PM 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

> > +

> 

> Instead of all the obscure macros and the new custom "rsel" property,

> which BTW is not in the bindings, can't we just list the actual bias

> resistance of each setting? We could also migrate away from R1R0.

> 

==>Hi Chenyu,
The rsel actual bias resistance of each setting:

MTK_PULL_SET_RSEL_000:75K in PU, 75k in PD;
MTK_PULL_SET_RSEL_001:10k in PU, 5k in PD;
MTK_PULL_SET_RSEL_010:5k in PU, 75k in PD;
MTK_PULL_SET_RSEL_011:4k in PU, 5K in PD;
MTK_PULL_SET_RSEL_100:3k in PU, 75k in PD;
MTK_PULL_SET_RSEL_101:2k in PU, 5K in PD;
MTK_PULL_SET_RSEL_110:1.5k in PU, 75k in PD;
MTK_PULL_SET_RSEL_111:1k in PU, 5k in PD.

The rsel actual bias resistance is different between PU and PD.

> Then we can specify the setting with the standard bias-pull-up/down

> properties [1].

> 

> Also, please ask internally if Mediatek could relicense all the header

> files that Mediatek has contributed under include/dt-bindings/pinctrl/ [2]

> to GPL-2.0 and BSD dual license. These files are part of the DT bindings

> and we really want them to be dual licensed as well, and not just the

> YAML files.

> 


==> We will confirm it internally and reply it later.

Thanks.
> 

> Regards

> ChenYu

> 

> 

> [1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml#L37

> [2] Note that a few files were contributed by other people

> 

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

> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Chen-Yu Tsai July 26, 2021, 8:02 a.m. UTC | #3
On Thu, Jul 22, 2021 at 3:54 PM zhiyong tao <zhiyong.tao@mediatek.com> wrote:
>

> On Tue, 2021-07-13 at 15:17 +0800, Chen-Yu Tsai wrote:

> > Hi,

> >

> > On Sat, Jul 10, 2021 at 4:17 PM 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

> > > +

> >

> > Instead of all the obscure macros and the new custom "rsel" property,

> > which BTW is not in the bindings, can't we just list the actual bias

> > resistance of each setting? We could also migrate away from R1R0.

> >

> ==>Hi Chenyu,

> The rsel actual bias resistance of each setting:

>

> MTK_PULL_SET_RSEL_000:75K in PU, 75k in PD;

> MTK_PULL_SET_RSEL_001:10k in PU, 5k in PD;

> MTK_PULL_SET_RSEL_010:5k in PU, 75k in PD;

> MTK_PULL_SET_RSEL_011:4k in PU, 5K in PD;

> MTK_PULL_SET_RSEL_100:3k in PU, 75k in PD;

> MTK_PULL_SET_RSEL_101:2k in PU, 5K in PD;

> MTK_PULL_SET_RSEL_110:1.5k in PU, 75k in PD;

> MTK_PULL_SET_RSEL_111:1k in PU, 5k in PD.

>

> The rsel actual bias resistance is different between PU and PD.


Thanks. Somehow I missed this when looking through the datasheet. This
encoding is interesting. Since it doesn't make sense to have both
pull-up and pull-down, even though the hardware seems capable of doing
so, I suppose the intent is to support 75k or 5k for pull-down, and
(75k, 10k, 5k, 4k, 3k, 2k, 1.5k, 1k) for pull-up?

We could add these values to the binding so we could check for misuse.

The range of values seems to also cover those supported by the
alternative R0/R1 settings. The values for kprow[01] and kpcol[01]
seem to be different though.

We should get rid of the MTK_PUPD_SET_R1R0_* macros at the same time.
They seem to be some magic values used with bias-pull-*, which is not
how the properties should be used. At the same time, they overlap with
mediatek,pull-* properties.

It would be great if we could standardize on the generic pinconf
properties, and also use real values that fit the requirements of the
properties, i.e. using real resistance values. I'm not sure if it
would make sense to enumerate which pins support which configurations
though.


Thanks
ChenYu


> > Then we can specify the setting with the standard bias-pull-up/down

> > properties [1].

> >

> > Also, please ask internally if Mediatek could relicense all the header

> > files that Mediatek has contributed under include/dt-bindings/pinctrl/ [2]

> > to GPL-2.0 and BSD dual license. These files are part of the DT bindings

> > and we really want them to be dual licensed as well, and not just the

> > YAML files.

> >

>

> ==> We will confirm it internally and reply it later.

>

> Thanks.

> >

> > Regards

> > ChenYu

> >

> >

> > [1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml#L37

> > [2] Note that a few files were contributed by other people

> >

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

> > > http://lists.infradead.org/mailman/listinfo/linux-mediatek

>
Chen-Yu Tsai July 29, 2021, 9:43 a.m. UTC | #4
On Thu, Jul 29, 2021 at 4:23 PM zhiyong.tao <zhiyong.tao@mediatek.com> wrote:
>

> On Mon, 2021-07-26 at 16:02 +0800, Chen-Yu Tsai wrote:

> > On Thu, Jul 22, 2021 at 3:54 PM zhiyong tao <zhiyong.tao@mediatek.com

> > > wrote:

> > >

> > > On Tue, 2021-07-13 at 15:17 +0800, Chen-Yu Tsai wrote:

> > > > Hi,

> > > >

> > > > On Sat, Jul 10, 2021 at 4:17 PM 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

> > > > > +

> > > >

> > > > Instead of all the obscure macros and the new custom "rsel"

> > > > property,

> > > > which BTW is not in the bindings, can't we just list the actual

> > > > bias

> > > > resistance of each setting? We could also migrate away from R1R0.

> > > >

> > >

> > > ==>Hi Chenyu,

> > > The rsel actual bias resistance of each setting:

> > >

> > > MTK_PULL_SET_RSEL_000:75K in PU, 75k in PD;

> > > MTK_PULL_SET_RSEL_001:10k in PU, 5k in PD;

> > > MTK_PULL_SET_RSEL_010:5k in PU, 75k in PD;

> > > MTK_PULL_SET_RSEL_011:4k in PU, 5K in PD;

> > > MTK_PULL_SET_RSEL_100:3k in PU, 75k in PD;

> > > MTK_PULL_SET_RSEL_101:2k in PU, 5K in PD;

> > > MTK_PULL_SET_RSEL_110:1.5k in PU, 75k in PD;

> > > MTK_PULL_SET_RSEL_111:1k in PU, 5k in PD.

> > >

> > > The rsel actual bias resistance is different between PU and PD.

> >

> > Thanks. Somehow I missed this when looking through the datasheet.

> > This

> > encoding is interesting. Since it doesn't make sense to have both

> > pull-up and pull-down, even though the hardware seems capable of

> > doing

> > so, I suppose the intent is to support 75k or 5k for pull-down, and

> > (75k, 10k, 5k, 4k, 3k, 2k, 1.5k, 1k) for pull-up?

> >

> > We could add these values to the binding so we could check for

> > misuse.

> >

> > The range of values seems to also cover those supported by the

> > alternative R0/R1 settings. The values for kprow[01] and kpcol[01]

> > seem to be different though.

> >

> > We should get rid of the MTK_PUPD_SET_R1R0_* macros at the same time.

> > They seem to be some magic values used with bias-pull-*, which is not

> > how the properties should be used. At the same time, they overlap

> > with

> > mediatek,pull-* properties.

> >

> > It would be great if we could standardize on the generic pinconf

> > properties, and also use real values that fit the requirements of the

> > properties, i.e. using real resistance values. I'm not sure if it

> > would make sense to enumerate which pins support which configurations

> > though.

> >

> >

> > Thanks

> > ChenYu

> >

> >

> The rsel actual bias resistance of each setting is different in

> different IC. we think that the define "MTK_PULL_SET_RSEL_000" is more

> common for all different IC.


I see. I personally prefer having things clearly described. I can
understand this might be an extra burden to support different chips
with different parameters, though this should be fairly straightforward
with lookup tables tied to the compatible strings.

Let's see if Rob and Linus have anything to add.


ChenYu


> Thanks.

>

> > > > Then we can specify the setting with the standard bias-pull-

> > > > up/down

> > > > properties [1].

> > > >

> > > > Also, please ask internally if Mediatek could relicense all the

> > > > header

> > > > files that Mediatek has contributed under include/dt-

> > > > bindings/pinctrl/ [2]

> > > > to GPL-2.0 and BSD dual license. These files are part of the DT

> > > > bindings

> > > > and we really want them to be dual licensed as well, and not just

> > > > the

> > > > YAML files.

> > > >

> > >

> > > ==> We will confirm it internally and reply it later.

> > >

> > > Thanks.

> > > >

> > > > Regards

> > > > ChenYu

> > > >

> > > >

> > > > [1]

> > > > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml#L37

> > > > [2] Note that a few files were contributed by other people

> > > >

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

> > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Chen-Yu Tsai Aug. 16, 2021, 6:10 a.m. UTC | #5
On Thu, Aug 5, 2021 at 7:02 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Jul 29, 2021 at 11:43 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> > On Thu, Jul 29, 2021 at 4:23 PM zhiyong.tao <zhiyong.tao@mediatek.com> wrote:
>
> > > The rsel actual bias resistance of each setting is different in
> > > different IC. we think that the define "MTK_PULL_SET_RSEL_000" is more
> > > common for all different IC.
> >
> > I see. I personally prefer having things clearly described. I can
> > understand this might be an extra burden to support different chips
> > with different parameters, though this should be fairly straightforward
> > with lookup tables tied to the compatible strings.
> >
> > Let's see if Rob and Linus have anything to add.
>
> Not much. We have "soft pushed" for this to be described as generic
> as possible, using SI units (ohms). But we also allow vendor-specific
> numbers in this attribute. Especially when reverse engineering SoCs
> that the contributor don't really have specs on (example M1 Mac).
>
> The intent with the SI units is especially for people like you folks working
> with Chromium to be able to use different SoCs and not feel lost
> to a forest of different ways of doing things and associated
> mistakes because vendors have hopelessly idiomatic pin configs.

I'll take that as "use SI units whenever possible and reasonable".

Thanks.

ChenYu
Linus Walleij Aug. 16, 2021, 11 p.m. UTC | #6
On Mon, Aug 16, 2021 at 5:38 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
> On Mon, Aug 16, 2021 at 6:48 PM zhiyong.tao <zhiyong.tao@mediatek.com> wrote:


> > > I'll take that as "use SI units whenever possible and reasonable".

> >

> > ==> so It doesn't need to change the define, is it right?

> > we will keep the common define.

>

> Actually I think it would be possible and reasonable to use SI units

> in this case, since you are the vendor and have the resistor values

> to implement the support. Having different sets of values for different

> chips is nothing out of the ordinary. We already have to account for

> different number of pins and different pin functions. That is what

> compatible strings are for.


I fully agree with Chen-Yu's analysis here.

Zhiyong can you make an attempt to use SI units (Ohms) and see
what it will look like? I think it will look better for users and it will
be less risk to make mistakes.

Yours,
Linus Walleij
Linus Walleij Aug. 17, 2021, 8:09 p.m. UTC | #7
On Tue, Aug 17, 2021 at 9:51 AM zhiyong.tao <zhiyong.tao@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     Max
>  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.

Yours,
Linus Walleij
Chen-Yu Tsai Aug. 18, 2021, 6:25 a.m. UTC | #8
On Wed, Aug 18, 2021 at 4:09 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Aug 17, 2021 at 9:51 AM zhiyong.tao <zhiyong.tao@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     Max
> >  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
diff mbox series

Patch

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
+
 #define MTK_DRIVE_2mA  2
 #define MTK_DRIVE_4mA  4
 #define MTK_DRIVE_6mA  6