All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: ChiaEn Wu <peterwu.pub@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	Jingoo Han <jingoohan1@gmail.com>, Pavel Machek <pavel@ucw.cz>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Sebastian Reichel <sre@kernel.org>,
	Chunfeng Yun <chunfeng.yun@mediatek.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	"Krogerus, Heikki" <heikki.krogerus@linux.intel.com>,
	Helge Deller <deller@gmx.de>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	ChiaEn Wu <chiaen_wu@richtek.com>,
	Alice Chen <alice_chen@richtek.com>,
	ChiYuan Huang <cy_huang@richtek.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	USB <linux-usb@vger.kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	"open list:FRAMEBUFFER LAYER" <linux-fbdev@vger.kernel.org>,
	szuni chen <szunichen@gmail.com>
Subject: Re: [PATCH v6 13/13] video: backlight: mt6370: Add MediaTek MT6370 support
Date: Tue, 26 Jul 2022 12:59:54 +0100	[thread overview]
Message-ID: <20220726115954.kpkmidrk3zo3dpbq@maple.lan> (raw)
In-Reply-To: <CABtFH5+in-+=6r3wOvQ8-78DT9CXaMursJukhx+kdwMvvP3djw@mail.gmail.com>

On Tue, Jul 26, 2022 at 07:28:48PM +0800, ChiaEn Wu wrote:
> On Tue, Jul 26, 2022 at 5:31 PM Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> ...
> > > > Does the MT6372 support more steps than this? In other words does it use
> > > > a fourteen bit scale or does it use an 11-bit scale at a different
> > > > register location?
> > >
> > > Hi Daniel,
> > >
> > > Thanks for your reply.
> > > Yes, MT6372 can support 16384 steps and uses a 14-bit scale register
> > > location. But the maximum current of each
> > > channel of MT6372 is the same as MT6370 and MT6371, both 30mA.
> > > The main reason why MT6372 is designed this way is that one of the
> > > customers asked for a more delicate
> > > adjustment of the backlight brightness. But other customers actually
> > > do not have such requirements.
> > > Therefore, we designed it this way for maximum compatibility in software.
>
> Sorry for I used of the wrong word, I mean is 'driver', not
> higher-level software
>
> >
> > I don't think that is an acceptable approach for the upstream kernel.
> >
> > To be "compatible" with (broken) software this driver ends up reducing
> > the capability of the upstream kernel to the point it becomes unable to
> > meet requirements for delicate adjustment (requirements that were
> > sufficiently important to change the hardware design so you could meet
> > them).
>
> Originally, we just wanted to use one version of the driver to cover
> all the SubPMIC of the 6370 series(6370~6372).
> And, the users who use this series SubPMIC can directly apply this
> driver to drive the backlight device without knowing the underlying
> hardware.
> To achieve this goal, we have designed it to look like this.

You don't need a second driver to support two different values for
max-brightness. The same driver can support both ranges with nothing but
a small tweak during the driver probe function.


> ...
> > > > > +
> > > > > +     if (brightness) {
> > > > > +             brightness_val[0] = (brightness - 1) & MT6370_BL_DIM2_MASK;
> > > > > +             brightness_val[1] = (brightness - 1) >> fls(MT6370_BL_DIM2_MASK);
> > > > > +
> > > > > +             /*
> > > > > +              * To make MT6372 using 14 bits to control the brightness
> > > > > +              * backward compatible with 11 bits brightness control
> > > > > +              * (like MT6370 and MT6371 do), we left shift the value
> > > > > +              * and pad with 1 to remaining bits. Hence, the MT6372's
> > > > > +              * backlight brightness will be almost the same as MT6370's
> > > > > +              * and MT6371's.
> > > > > +              */
> > > > > +             if (priv->vid_type == MT6370_VID_6372) {
> > > > > +                     brightness_val[0] <<= MT6370_BL_DIM2_6372_SHIFT;
> > > > > +                     brightness_val[0] |= MT6370_BL_DUMMY_6372_MASK;
> > > > > +             }
> > > >
> > > > This somewhat depends on the answer to the first question above, but
> > > > what is the point of this shifting? If the range is 14-bit then the
> > > > driver should set max_brightness to 16384 and present the full range of
> > > > the MT6372 to the user.
> > >
> > > So should we make all 16384 steps of MT6372 available to users?
> >
> > Yes.
> >
> >
> > > Does that mean the DTS needs to be modified as well?
> >
> > Yes... the property to set initial brightness needs a 14-bit range.
> >
> > It would also be a good idea to discuss with the DT maintainers whether
> > you should introduce a second compatible string (ending 6372) in order
> > to allow the DT validation checks to detect accidental use of MT6372
> > ranges on MT6370 hardware.
>
> hmmm... I have just thought about it,
> maybe I can just modify the maximum value of default-brightness and
> max-brightness in DT to 16384,
> modify the description and add some comments.

What for?

All the other backlight drivers (there are >130 of them) expose the hardware
range[1]. Most userspaces will already know how to handle that (by reading
the max_brightness and, if it is recent enough, also the scale
properties in sysfs).

I'm still don't understand why one should fix a bug in the userspace by
implementing a hack in the driver.


[1] Well almost. The PWM backlight driver does contain support for
    dead-spot avoidance and to allow the adoption of exponential scale.
    However this  purpose of these is based on how PWM backlights work



> And then on the driver side,
> we can use mt6370_check_vendor_info( ) to determine whether it is MT6372.
> If no, then in mt6370_bl_update_status(), first brightness_val / 8 and then set.
> In mt6370_bl_get_brightness(), first brightness_val * 8 and then return;
>
> If I do this change, does this meet your requirements?

Not really.

It's still misleading a sophisticated userspace, which may make bad
rounding decisions for backlight animation, in order to support a broken
one.


> > > Or, for the reasons, I have just explained (just one customer has this
> > > requirement), then we do not make any changes for compatibility
> > > reasons?
> >
> > I'd be curious what the compatiblity reasons are. In other words what
> > software breaks?
>
> The reason is as above. We just hope the users who use this series SubPMIC can
> directly apply this driver to drive the backlight device without
> knowing the underlying hardware.
> Not software breaks.

As above, ignoring the max_brightness property is a bug in the
userspace. I'm still unclear why sending faked ranges to userspace
it a better solution than fixing the userspace.


Daniel.

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: ChiaEn Wu <peterwu.pub@gmail.com>
Cc: "open list:FRAMEBUFFER LAYER" <linux-fbdev@vger.kernel.org>,
	"Krogerus, Heikki" <heikki.krogerus@linux.intel.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Alice Chen <alice_chen@richtek.com>,
	linux-iio <linux-iio@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	ChiYuan Huang <cy_huang@richtek.com>, Pavel Machek <pavel@ucw.cz>,
	Lee Jones <lee.jones@linaro.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	Helge Deller <deller@gmx.de>, Rob Herring <robh+dt@kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Chunfeng Yun <chunfeng.yun@mediatek.com>,
	Guenter Roeck <linux@roeck-us.net>,
	devicetree <devicetree@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	szuni chen <szunichen@gmail.com>, Mark Brown <broonie@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	USB <linux-usb@vger.kernel.org>,
	Sebastian Reichel <sre@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ChiaEn Wu <chiaen_wu@richtek.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH v6 13/13] video: backlight: mt6370: Add MediaTek MT6370 support
Date: Tue, 26 Jul 2022 12:59:54 +0100	[thread overview]
Message-ID: <20220726115954.kpkmidrk3zo3dpbq@maple.lan> (raw)
In-Reply-To: <CABtFH5+in-+=6r3wOvQ8-78DT9CXaMursJukhx+kdwMvvP3djw@mail.gmail.com>

On Tue, Jul 26, 2022 at 07:28:48PM +0800, ChiaEn Wu wrote:
> On Tue, Jul 26, 2022 at 5:31 PM Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> ...
> > > > Does the MT6372 support more steps than this? In other words does it use
> > > > a fourteen bit scale or does it use an 11-bit scale at a different
> > > > register location?
> > >
> > > Hi Daniel,
> > >
> > > Thanks for your reply.
> > > Yes, MT6372 can support 16384 steps and uses a 14-bit scale register
> > > location. But the maximum current of each
> > > channel of MT6372 is the same as MT6370 and MT6371, both 30mA.
> > > The main reason why MT6372 is designed this way is that one of the
> > > customers asked for a more delicate
> > > adjustment of the backlight brightness. But other customers actually
> > > do not have such requirements.
> > > Therefore, we designed it this way for maximum compatibility in software.
>
> Sorry for I used of the wrong word, I mean is 'driver', not
> higher-level software
>
> >
> > I don't think that is an acceptable approach for the upstream kernel.
> >
> > To be "compatible" with (broken) software this driver ends up reducing
> > the capability of the upstream kernel to the point it becomes unable to
> > meet requirements for delicate adjustment (requirements that were
> > sufficiently important to change the hardware design so you could meet
> > them).
>
> Originally, we just wanted to use one version of the driver to cover
> all the SubPMIC of the 6370 series(6370~6372).
> And, the users who use this series SubPMIC can directly apply this
> driver to drive the backlight device without knowing the underlying
> hardware.
> To achieve this goal, we have designed it to look like this.

You don't need a second driver to support two different values for
max-brightness. The same driver can support both ranges with nothing but
a small tweak during the driver probe function.


> ...
> > > > > +
> > > > > +     if (brightness) {
> > > > > +             brightness_val[0] = (brightness - 1) & MT6370_BL_DIM2_MASK;
> > > > > +             brightness_val[1] = (brightness - 1) >> fls(MT6370_BL_DIM2_MASK);
> > > > > +
> > > > > +             /*
> > > > > +              * To make MT6372 using 14 bits to control the brightness
> > > > > +              * backward compatible with 11 bits brightness control
> > > > > +              * (like MT6370 and MT6371 do), we left shift the value
> > > > > +              * and pad with 1 to remaining bits. Hence, the MT6372's
> > > > > +              * backlight brightness will be almost the same as MT6370's
> > > > > +              * and MT6371's.
> > > > > +              */
> > > > > +             if (priv->vid_type == MT6370_VID_6372) {
> > > > > +                     brightness_val[0] <<= MT6370_BL_DIM2_6372_SHIFT;
> > > > > +                     brightness_val[0] |= MT6370_BL_DUMMY_6372_MASK;
> > > > > +             }
> > > >
> > > > This somewhat depends on the answer to the first question above, but
> > > > what is the point of this shifting? If the range is 14-bit then the
> > > > driver should set max_brightness to 16384 and present the full range of
> > > > the MT6372 to the user.
> > >
> > > So should we make all 16384 steps of MT6372 available to users?
> >
> > Yes.
> >
> >
> > > Does that mean the DTS needs to be modified as well?
> >
> > Yes... the property to set initial brightness needs a 14-bit range.
> >
> > It would also be a good idea to discuss with the DT maintainers whether
> > you should introduce a second compatible string (ending 6372) in order
> > to allow the DT validation checks to detect accidental use of MT6372
> > ranges on MT6370 hardware.
>
> hmmm... I have just thought about it,
> maybe I can just modify the maximum value of default-brightness and
> max-brightness in DT to 16384,
> modify the description and add some comments.

What for?

All the other backlight drivers (there are >130 of them) expose the hardware
range[1]. Most userspaces will already know how to handle that (by reading
the max_brightness and, if it is recent enough, also the scale
properties in sysfs).

I'm still don't understand why one should fix a bug in the userspace by
implementing a hack in the driver.


[1] Well almost. The PWM backlight driver does contain support for
    dead-spot avoidance and to allow the adoption of exponential scale.
    However this  purpose of these is based on how PWM backlights work



> And then on the driver side,
> we can use mt6370_check_vendor_info( ) to determine whether it is MT6372.
> If no, then in mt6370_bl_update_status(), first brightness_val / 8 and then set.
> In mt6370_bl_get_brightness(), first brightness_val * 8 and then return;
>
> If I do this change, does this meet your requirements?

Not really.

It's still misleading a sophisticated userspace, which may make bad
rounding decisions for backlight animation, in order to support a broken
one.


> > > Or, for the reasons, I have just explained (just one customer has this
> > > requirement), then we do not make any changes for compatibility
> > > reasons?
> >
> > I'd be curious what the compatiblity reasons are. In other words what
> > software breaks?
>
> The reason is as above. We just hope the users who use this series SubPMIC can
> directly apply this driver to drive the backlight device without
> knowing the underlying hardware.
> Not software breaks.

As above, ignoring the max_brightness property is a bug in the
userspace. I'm still unclear why sending faked ranges to userspace
it a better solution than fixing the userspace.


Daniel.

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: ChiaEn Wu <peterwu.pub@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	Jingoo Han <jingoohan1@gmail.com>, Pavel Machek <pavel@ucw.cz>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Sebastian Reichel <sre@kernel.org>,
	Chunfeng Yun <chunfeng.yun@mediatek.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	"Krogerus, Heikki" <heikki.krogerus@linux.intel.com>,
	Helge Deller <deller@gmx.de>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	ChiaEn Wu <chiaen_wu@richtek.com>,
	Alice Chen <alice_chen@richtek.com>,
	ChiYuan Huang <cy_huang@richtek.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	USB <linux-usb@vger.kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	"open list:FRAMEBUFFER LAYER" <linux-fbdev@vger.kernel.org>,
	szuni chen <szunichen@gmail.com>
Subject: Re: [PATCH v6 13/13] video: backlight: mt6370: Add MediaTek MT6370 support
Date: Tue, 26 Jul 2022 12:59:54 +0100	[thread overview]
Message-ID: <20220726115954.kpkmidrk3zo3dpbq@maple.lan> (raw)
In-Reply-To: <CABtFH5+in-+=6r3wOvQ8-78DT9CXaMursJukhx+kdwMvvP3djw@mail.gmail.com>

On Tue, Jul 26, 2022 at 07:28:48PM +0800, ChiaEn Wu wrote:
> On Tue, Jul 26, 2022 at 5:31 PM Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> ...
> > > > Does the MT6372 support more steps than this? In other words does it use
> > > > a fourteen bit scale or does it use an 11-bit scale at a different
> > > > register location?
> > >
> > > Hi Daniel,
> > >
> > > Thanks for your reply.
> > > Yes, MT6372 can support 16384 steps and uses a 14-bit scale register
> > > location. But the maximum current of each
> > > channel of MT6372 is the same as MT6370 and MT6371, both 30mA.
> > > The main reason why MT6372 is designed this way is that one of the
> > > customers asked for a more delicate
> > > adjustment of the backlight brightness. But other customers actually
> > > do not have such requirements.
> > > Therefore, we designed it this way for maximum compatibility in software.
>
> Sorry for I used of the wrong word, I mean is 'driver', not
> higher-level software
>
> >
> > I don't think that is an acceptable approach for the upstream kernel.
> >
> > To be "compatible" with (broken) software this driver ends up reducing
> > the capability of the upstream kernel to the point it becomes unable to
> > meet requirements for delicate adjustment (requirements that were
> > sufficiently important to change the hardware design so you could meet
> > them).
>
> Originally, we just wanted to use one version of the driver to cover
> all the SubPMIC of the 6370 series(6370~6372).
> And, the users who use this series SubPMIC can directly apply this
> driver to drive the backlight device without knowing the underlying
> hardware.
> To achieve this goal, we have designed it to look like this.

You don't need a second driver to support two different values for
max-brightness. The same driver can support both ranges with nothing but
a small tweak during the driver probe function.


> ...
> > > > > +
> > > > > +     if (brightness) {
> > > > > +             brightness_val[0] = (brightness - 1) & MT6370_BL_DIM2_MASK;
> > > > > +             brightness_val[1] = (brightness - 1) >> fls(MT6370_BL_DIM2_MASK);
> > > > > +
> > > > > +             /*
> > > > > +              * To make MT6372 using 14 bits to control the brightness
> > > > > +              * backward compatible with 11 bits brightness control
> > > > > +              * (like MT6370 and MT6371 do), we left shift the value
> > > > > +              * and pad with 1 to remaining bits. Hence, the MT6372's
> > > > > +              * backlight brightness will be almost the same as MT6370's
> > > > > +              * and MT6371's.
> > > > > +              */
> > > > > +             if (priv->vid_type == MT6370_VID_6372) {
> > > > > +                     brightness_val[0] <<= MT6370_BL_DIM2_6372_SHIFT;
> > > > > +                     brightness_val[0] |= MT6370_BL_DUMMY_6372_MASK;
> > > > > +             }
> > > >
> > > > This somewhat depends on the answer to the first question above, but
> > > > what is the point of this shifting? If the range is 14-bit then the
> > > > driver should set max_brightness to 16384 and present the full range of
> > > > the MT6372 to the user.
> > >
> > > So should we make all 16384 steps of MT6372 available to users?
> >
> > Yes.
> >
> >
> > > Does that mean the DTS needs to be modified as well?
> >
> > Yes... the property to set initial brightness needs a 14-bit range.
> >
> > It would also be a good idea to discuss with the DT maintainers whether
> > you should introduce a second compatible string (ending 6372) in order
> > to allow the DT validation checks to detect accidental use of MT6372
> > ranges on MT6370 hardware.
>
> hmmm... I have just thought about it,
> maybe I can just modify the maximum value of default-brightness and
> max-brightness in DT to 16384,
> modify the description and add some comments.

What for?

All the other backlight drivers (there are >130 of them) expose the hardware
range[1]. Most userspaces will already know how to handle that (by reading
the max_brightness and, if it is recent enough, also the scale
properties in sysfs).

I'm still don't understand why one should fix a bug in the userspace by
implementing a hack in the driver.


[1] Well almost. The PWM backlight driver does contain support for
    dead-spot avoidance and to allow the adoption of exponential scale.
    However this  purpose of these is based on how PWM backlights work



> And then on the driver side,
> we can use mt6370_check_vendor_info( ) to determine whether it is MT6372.
> If no, then in mt6370_bl_update_status(), first brightness_val / 8 and then set.
> In mt6370_bl_get_brightness(), first brightness_val * 8 and then return;
>
> If I do this change, does this meet your requirements?

Not really.

It's still misleading a sophisticated userspace, which may make bad
rounding decisions for backlight animation, in order to support a broken
one.


> > > Or, for the reasons, I have just explained (just one customer has this
> > > requirement), then we do not make any changes for compatibility
> > > reasons?
> >
> > I'd be curious what the compatiblity reasons are. In other words what
> > software breaks?
>
> The reason is as above. We just hope the users who use this series SubPMIC can
> directly apply this driver to drive the backlight device without
> knowing the underlying hardware.
> Not software breaks.

As above, ignoring the max_brightness property is a bug in the
userspace. I'm still unclear why sending faked ranges to userspace
it a better solution than fixing the userspace.


Daniel.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-26 12:00 UTC|newest]

Thread overview: 154+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-22 10:23 [PATCH v6 00/13] Add MediaTek MT6370 PMIC support ChiaEn Wu
2022-07-22 10:23 ` ChiaEn Wu
2022-07-22 10:23 ` ChiaEn Wu
2022-07-22 10:23 ` [PATCH v6 01/13] dt-bindings: usb: Add MediaTek MT6370 TCPC ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23 ` [PATCH v6 02/13] dt-bindings: power: supply: Add MediaTek MT6370 Charger ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23 ` [PATCH v6 03/13] dt-bindings: leds: mt6370: Add MediaTek MT6370 current sink type LED indicator ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23 ` [PATCH v6 04/13] dt-bindings: leds: Add MediaTek MT6370 flashlight ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-30 21:30   ` Pavel Machek
2022-07-30 21:30     ` Pavel Machek
2022-07-30 21:30     ` Pavel Machek
2022-07-22 10:23 ` [PATCH v6 05/13] dt-bindings: backlight: Add MediaTek MT6370 backlight ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-07-22 10:23   ` ChiaEn Wu
2022-08-01  6:47   ` ChiaEn Wu
2022-08-01  6:47     ` ChiaEn Wu
2022-07-22 10:24 ` [PATCH v6 06/13] dt-bindings: mfd: Add MediaTek MT6370 ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24 ` [PATCH v6 07/13] mfd: mt6370: Add MediaTek MT6370 support ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-25  7:59   ` Andy Shevchenko
2022-07-25  7:59     ` Andy Shevchenko
2022-07-25  7:59     ` Andy Shevchenko
2022-07-25  8:29     ` ChiaEn Wu
2022-07-25  8:29       ` ChiaEn Wu
2022-07-25  8:29       ` ChiaEn Wu
2022-07-25  8:43       ` Andy Shevchenko
2022-07-25  8:43         ` Andy Shevchenko
2022-07-25  8:43         ` Andy Shevchenko
2022-07-25  9:06         ` ChiaEn Wu
2022-07-25  9:06           ` ChiaEn Wu
2022-07-25  9:06           ` ChiaEn Wu
2022-07-25  9:09           ` Andy Shevchenko
2022-07-25  9:09             ` Andy Shevchenko
2022-07-25  9:09             ` Andy Shevchenko
2022-07-22 10:24 ` [PATCH v6 08/13] usb: typec: tcpci_mt6370: Add MediaTek MT6370 tcpci driver ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 14:19   ` Guenter Roeck
2022-07-22 14:19     ` Guenter Roeck
2022-07-22 14:19     ` Guenter Roeck
2022-07-25  7:06   ` Chunfeng Yun
2022-07-25  7:06     ` Chunfeng Yun
2022-07-25  7:06     ` Chunfeng Yun
2022-07-25  7:17     ` ChiaEn Wu
2022-07-25  7:17       ` ChiaEn Wu
2022-07-25  7:17       ` ChiaEn Wu
2022-07-25  8:03   ` Andy Shevchenko
2022-07-25  8:03     ` Andy Shevchenko
2022-07-25  8:03     ` Andy Shevchenko
2022-07-22 10:24 ` [PATCH v6 09/13] iio: adc: mt6370: Add MediaTek MT6370 support ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-25  8:10   ` Andy Shevchenko
2022-07-25  8:10     ` Andy Shevchenko
2022-07-25  8:10     ` Andy Shevchenko
2022-07-22 10:24 ` [PATCH v6 10/13] power: supply: mt6370: Add MediaTek MT6370 charger driver ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-25  8:25   ` Andy Shevchenko
2022-07-25  8:25     ` Andy Shevchenko
2022-07-25  8:25     ` Andy Shevchenko
2022-07-22 10:24 ` [PATCH v6 11/13] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:52   ` AngeloGioacchino Del Regno
2022-07-22 10:52     ` AngeloGioacchino Del Regno
2022-07-22 10:52     ` AngeloGioacchino Del Regno
2022-07-25  8:40   ` Andy Shevchenko
2022-07-25  8:40     ` Andy Shevchenko
2022-07-25  8:40     ` Andy Shevchenko
2022-07-26 11:45     ` ChiaEn Wu
2022-07-26 11:45       ` ChiaEn Wu
2022-07-26 11:45       ` ChiaEn Wu
2022-07-26 12:17       ` Andy Shevchenko
2022-07-26 12:17         ` Andy Shevchenko
2022-07-26 12:17         ` Andy Shevchenko
2022-07-27  7:36         ` ChiaEn Wu
2022-07-27  7:36           ` ChiaEn Wu
2022-07-27  7:36           ` ChiaEn Wu
2022-07-27 10:03           ` Andy Shevchenko
2022-07-27 10:03             ` Andy Shevchenko
2022-07-27 10:03             ` Andy Shevchenko
2022-07-30 21:39   ` Pavel Machek
2022-07-30 21:39     ` Pavel Machek
2022-07-30 21:39     ` Pavel Machek
2022-08-01  7:55     ` szuni chen
2022-08-01  7:55       ` szuni chen
2022-07-22 10:24 ` [PATCH v6 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:48   ` AngeloGioacchino Del Regno
2022-07-22 10:48     ` AngeloGioacchino Del Regno
2022-07-22 10:48     ` AngeloGioacchino Del Regno
2022-07-25  8:51   ` Andy Shevchenko
2022-07-25  8:51     ` Andy Shevchenko
2022-07-25  8:51     ` Andy Shevchenko
2022-07-29  6:17     ` szuni chen
2022-07-29  6:17       ` szuni chen
2022-07-29  6:17       ` szuni chen
2022-07-29 10:34       ` Andy Shevchenko
2022-07-29 10:34         ` Andy Shevchenko
2022-07-29 10:34         ` Andy Shevchenko
2022-07-25  8:55   ` Andy Shevchenko
2022-07-25  8:55     ` Andy Shevchenko
2022-07-25  8:55     ` Andy Shevchenko
2022-07-26  4:15     ` szuni chen
2022-07-26  4:15       ` szuni chen
2022-07-26  4:15       ` szuni chen
2022-07-26  6:10       ` Andy Shevchenko
2022-07-26  6:10         ` Andy Shevchenko
2022-07-26  6:10         ` Andy Shevchenko
2022-07-30 21:42   ` Pavel Machek
2022-07-30 21:42     ` Pavel Machek
2022-07-30 21:42     ` Pavel Machek
2022-08-04  9:53     ` Alice Chen
2022-08-04  9:53       ` Alice Chen
2022-08-04  9:53       ` Alice Chen
2022-07-22 10:24 ` [PATCH v6 13/13] video: backlight: mt6370: Add MediaTek MT6370 support ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-22 10:24   ` ChiaEn Wu
2022-07-25  9:07   ` Andy Shevchenko
2022-07-25  9:07     ` Andy Shevchenko
2022-07-25  9:07     ` Andy Shevchenko
2022-07-25 10:31   ` Daniel Thompson
2022-07-25 10:31     ` Daniel Thompson
2022-07-25 10:31     ` Daniel Thompson
2022-07-26  2:20     ` ChiaEn Wu
2022-07-26  2:20       ` ChiaEn Wu
2022-07-26  2:20       ` ChiaEn Wu
2022-07-26  9:30       ` Daniel Thompson
2022-07-26  9:30         ` Daniel Thompson
2022-07-26  9:30         ` Daniel Thompson
2022-07-26 11:28         ` ChiaEn Wu
2022-07-26 11:28           ` ChiaEn Wu
2022-07-26 11:28           ` ChiaEn Wu
2022-07-26 11:59           ` Daniel Thompson [this message]
2022-07-26 11:59             ` Daniel Thompson
2022-07-26 11:59             ` Daniel Thompson
2022-07-27  6:24             ` ChiaEn Wu
2022-07-27  6:24               ` ChiaEn Wu
2022-07-27  6:24               ` ChiaEn Wu
2022-07-28 11:31               ` Daniel Thompson
2022-07-28 11:31                 ` Daniel Thompson
2022-07-28 11:31                 ` Daniel Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220726115954.kpkmidrk3zo3dpbq@maple.lan \
    --to=daniel.thompson@linaro.org \
    --cc=alice_chen@richtek.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=broonie@kernel.org \
    --cc=chiaen_wu@richtek.com \
    --cc=chunfeng.yun@mediatek.com \
    --cc=cy_huang@richtek.com \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=jic23@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lars@metafoo.de \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=matthias.bgg@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=peterwu.pub@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sre@kernel.org \
    --cc=szunichen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.