On Mon, Jul 18, 2022 at 4:27 PM AngeloGioacchino Del Regno
[off-list ref] wrote:

<snip>

quoted

quoted

Hello ChiaEn,

I propose to move this one to drivers/leds (or drivers/pwm) and, instead of
registering a backlight device, register a PWM device.

This way you will be able to reuse the generic backlight-pwm driver, as you'd
be feeding the PWM device exposed by this driver to the generic one: this will
most importantly make it easy to chain it with MTK_DISP_PWM (mtk-pwm-disp)
with a devicetree that looks like...

Out of interest, does MT6370 have the same structure for backlights as the prior
systems using mtk-pwm-disp or was mtk-pwm-disp simply a normal(-ish) PWM
that relied on something on the board for all the constant current
driver hardware?

As per my understanding, mtk-pwm-disp is chained to other multimedia features of
the display block of MediaTek SoCs, such as the AAL (adaptive ambient light),
CABC (content adaptive backlight control) etc, other than being a normal(ish)
PWM... that's the reason of my request.

Moreover, in the end, this PMIC's backlight controller is just a "fancy" PWM
controller, with OCP/OVP.

quoted

quoted

     pwmleds-disp {
             compatible = "pwm-leds";

             disp_led: disp-pwm {
                     label = "backlight-pwm";
                     pwms = <&pwm0 0 500000>;
                     max-brightness = <1024>;
             };
     };

     backlight_lcd0: backlight {
             compatible = "led-backlight";
             leds = <&disp_led>, <&pmic_bl_led>;
             default-brightness-level = <300>;
     };

I think this proposal has to start with the devicetree bindings rather
than the driver. Instead I think the question is: does this proposal
result in DT bindings that better describe the underlying hardware?

 From how I understand it - yes: we have a fancy PWM (&pwm0) that we use
to control display backlight (backlight-pwm)...

Obviously, here we're not talking about OLEDs, but LCDs, where the backlight
is made of multiple strings of WhiteLED (effectively, a "pwm-leds" controlled
"led-backlight").

Using PWM will also allow for a little more fine-grained board specific
configuration, as I think that this PMIC (and/or variants of it) will be
used in completely different form factors: I think that's going to be both
smartphones and tablets/laptops... and I want to avoid vendor properties
to configure the PWM part in a somehow different way.

quoted

This device has lots of backlight centric features (OCP, OVP, single
control with multiple outputs, exponential curves, etc) and its not
clear where they would fit into the "PWM" bindings.

For OCP and OVP, the only bindings that fit would be regulators, but that's
not a regulator... and that's about it - I don't really have arguments for
that.

What I really want to see here is usage of "generic" drivers like led_bl
and/or pwm_bl as to get some "standardization" around with all the benefits
that this carries.

quoted

Come to think of it I'm also a little worried also about the whole linear
versus exponential curve thing since I thought LED drivers were required
to use exponential curves.

That probably depends on how the controller interprets the data, I guess,
but I agree with you on this thought.

Hi Angelo,

MT6370 is just a SubPMIC, not an SoC, and is applied in cellular
telephones, tablet PCs, and portable instruments.
And the PWM mode of the MT6370 backlight driver is optional, and not
must be enabled.
From our perspective, this MT6370 backlight driver is not the same as
mtk-pwm-disp related driver.
Thanks!

Regards,
Angelo

-- 
Best Regards,
ChiaEn Wu