From: Daniel Thompson <daniel.thompson@linaro.org>
To: cy_huang <u0084500@gmail.com>
Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
lee.jones@linaro.org, jingoohan1@gmail.com, pavel@ucw.cz,
deller@gmx.de, cy_huang@richtek.com, lucas_tsai@richtek.com,
devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-leds@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] backlight: rt4831: Add the property parsing for ocp level selection
Date: Thu, 26 May 2022 11:05:10 +0100 [thread overview]
Message-ID: <20220526100510.3utwh5bov4ax2jmg@maple.lan> (raw)
In-Reply-To: <1653534995-30794-3-git-send-email-u0084500@gmail.com>
On Thu, May 26, 2022 at 11:16:35AM +0800, cy_huang wrote:
> From: ChiYuan Huang <cy_huang@richtek.com>
>
> Add the property parsing for ocp level selection.
Isn't this just restating the Subject: line?
It would be better to provide information useful to the reviewer here.
Something like:
"Currently this driver simply inherits whatever over-current protection
level is programmed into the hardware when it is handed over. Typically
this will be the reset value, <whatever>A, although the bootloader could
have established a different value.
Allow the correct OCP value to be provided by the DT."
BTW please don't uncritically copy the above into the patch header. It is
just made something up as an example and I did no fact checking...
>
> Reported-by: Lucas Tsai <lucas_tsai@richtek.com>
> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> ---
> drivers/video/backlight/rt4831-backlight.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/video/backlight/rt4831-backlight.c b/drivers/video/backlight/rt4831-backlight.c
> index 42155c7..c81f7d9 100644
> --- a/drivers/video/backlight/rt4831-backlight.c
> +++ b/drivers/video/backlight/rt4831-backlight.c
> @@ -12,6 +12,7 @@
> #define RT4831_REG_BLCFG 0x02
> #define RT4831_REG_BLDIML 0x04
> #define RT4831_REG_ENABLE 0x08
> +#define RT4831_REG_BLOPT2 0x11
>
> #define RT4831_BLMAX_BRIGHTNESS 2048
>
> @@ -23,6 +24,8 @@
> #define RT4831_BLDIML_MASK GENMASK(2, 0)
> #define RT4831_BLDIMH_MASK GENMASK(10, 3)
> #define RT4831_BLDIMH_SHIFT 3
> +#define RT4831_BLOCP_MASK GENMASK(1, 0)
> +#define RT4831_BLOCP_SHIFT 0
>
> struct rt4831_priv {
> struct device *dev;
> @@ -120,6 +123,16 @@ static int rt4831_parse_backlight_properties(struct rt4831_priv *priv,
> if (ret)
> return ret;
>
> + ret = device_property_read_u8(dev, "richtek,bled-ocp-sel", &propval);
> + if (ret)
> + propval = RT4831_BLOCPLVL_1P2A;
Is 1.2A the reset value for the register?
Additionally, it looks like adding a hard-coded default would cause
problems for existing platforms where the bootloader doesn't use
richtek,bled-ocp-sel and pre-configures a different value itself.
Would it be safer (in terms of working nicely with older bootloaders)
to only write to the RT4831_BLOCP_MASK if the new property is set?
Daniel.
> +
> + propval = min_t(u8, propval, RT4831_BLOCPLVL_1P8A);
> + ret = regmap_update_bits(priv->regmap, RT4831_REG_BLOPT2, RT4831_BLOCP_MASK,
> + propval << RT4831_BLOCP_SHIFT);
> + if (ret)
> + return ret;
> +
> ret = device_property_read_u8(dev, "richtek,channel-use", &propval);
> if (ret) {
> dev_err(dev, "richtek,channel-use DT property missing\n");
> --
> 2.7.4
>
next prev parent reply other threads:[~2022-05-26 10:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 3:16 [PATCH 0/2] Add the property to make ocp level selectable cy_huang
2022-05-26 3:16 ` [PATCH 1/2] dt-bindings: backlight: rt4831: Add the new property for ocp level selection cy_huang
2022-05-26 8:06 ` Krzysztof Kozlowski
2022-05-26 8:13 ` ChiYuan Huang
2022-05-26 10:32 ` Krzysztof Kozlowski
2022-06-02 13:56 ` Rob Herring
2022-06-02 13:58 ` Krzysztof Kozlowski
2022-06-02 15:31 ` ChiYuan Huang
2022-06-05 16:11 ` Krzysztof Kozlowski
2022-06-06 1:39 ` ChiYuan Huang
2022-06-06 6:20 ` Krzysztof Kozlowski
2022-05-26 3:16 ` [PATCH 2/2] backlight: rt4831: Add the property parsing " cy_huang
2022-05-26 10:05 ` Daniel Thompson [this message]
2022-05-27 2:24 ` ChiYuan Huang
2022-05-27 10:56 ` 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=20220526100510.3utwh5bov4ax2jmg@maple.lan \
--to=daniel.thompson@linaro.org \
--cc=cy_huang@richtek.com \
--cc=deller@gmx.de \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jingoohan1@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee.jones@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=lucas_tsai@richtek.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=u0084500@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®