All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: ChiYuan Huang <cy_huang@richtek.com>
Cc: ChiaEn Wu <chiaen_wu@richtek.com>,
	corbet@lwn.net, pavel@ucw.cz, matthias.bgg@gmail.com,
	andriy.shevchenko@linux.intel.com, jacek.anaszewski@gmail.com,
	angelogioacchino.delregno@collabora.com,
	linux-doc@vger.kernel.org, peterwu.pub@gmail.com,
	linux-leds@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	szunichen@gmail.com, Alice Chen <alice_chen@richtek.com>
Subject: Re: [PATCH v17 RESEND 1/3] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support
Date: Wed, 8 Mar 2023 14:02:52 +0000	[thread overview]
Message-ID: <20230308140252.GM9667@google.com> (raw)
In-Reply-To: <20230307022302.GA4930@linuxcarl2.richtek.com>

On Tue, 07 Mar 2023, ChiYuan Huang wrote:

> Hi, Lee:
>
> Thanks's for the reviewing.
> To prevent the misunderstanding, reply as below.
> No reply means will do.
>
> On Sun, Mar 05, 2023 at 08:55:33AM +0000, Lee Jones wrote:
> > On Thu, 23 Feb 2023, ChiaEn Wu wrote:
> >
> > > From: ChiYuan Huang <cy_huang@richtek.com>
> > >
> > > The MediaTek MT6370 is a highly-integrated smart power management IC,
> > > which includes a single cell Li-Ion/Li-Polymer switching battery
> > > charger, a USB Type-C & Power Delivery (PD) controller, dual
> > > Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> > > a display bias driver and a general LDO for portable devices.
> > >
> > > Add support for the MediaTek MT6370 Current Sink Type LED Indicator
> > > driver. It can control four channels current-sink RGB LEDs with 3 modes:
> > > constant current, PWM, and breath mode.
> > >
> > > Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> > > Co-developed-by: Alice Chen <alice_chen@richtek.com>
> > > Signed-off-by: Alice Chen <alice_chen@richtek.com>
> > > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com>
> > > ---
> > > v17
> > > - Update the year of Copyright from 2022 to 2023
> > >
> > > ---
> > >  drivers/leds/rgb/Kconfig           |   13 +
> > >  drivers/leds/rgb/Makefile          |    1 +
> > >  drivers/leds/rgb/leds-mt6370-rgb.c | 1009 ++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 1023 insertions(+)
> > >  create mode 100644 drivers/leds/rgb/leds-mt6370-rgb.c

[...]

> > > +static int mt6370_gen_breath_pattern(struct mt6370_priv *priv,
> > > +				     struct led_pattern *pattern, u32 len,
> > > +				     u8 *pattern_val, u32 val_len)
> > > +{
> > > +	enum mt6370_led_ranges sel_range;
> > > +	struct led_pattern *curr;
> > > +	unsigned int sel;
> > > +	u32 val = 0;
> > > +	int i;
> > > +
> > > +	if (len < P_MAX_PATTERNS && val_len < P_MAX_PATTERNS / 2)
> > > +		return -EINVAL;
> > > +
> > > +	/*
> > > +	 * Pattern list
> > > +	 * tr1:	 byte 0, b'[7: 4]
> >
> > Perhaps this is standard formatting and I'm just not aware of it, but
> > the space is throwing me and making me think twice.  Does this mean bits
> > 7 through 4, so b'11110000?
> >
> Yes. like as you said. Sorry for the redudant space make you confused.
> I'm not sure whether it's a standard formating or not.
> Sometimes, in datasheet, we'll use this format to represent the bitfield for functions.
> Your format is also good for it.
> And which one is preferable?

Since neither of us are sure, just take the space out for now please.

> > > +	 * tr2:	 byte 0, b'[3: 0]
> > > +	 * tf1:	 byte 1, b'[7: 4]
> > > +	 * tf2:	 byte 1, b'[3: 0]
> > > +	 * ton:	 byte 2, b'[7: 4]
> > > +	 * toff: byte 2, b'[3: 0]
> > > +	 */
> > > +	for (i = 0; i < P_MAX_PATTERNS; i++) {
> > > +		curr = pattern + i;
> > > +
> > > +		sel_range = i == P_LED_TOFF ? R_LED_TOFF : R_LED_TRFON;
> > > +
> > > +		linear_range_get_selector_within(priv->ranges + sel_range,
> > > +						 curr->delta_t, &sel);
> > > +
> > > +		if (i % 2) {
> > > +			val |= sel;
> > > +		} else {
> > > +			val <<= 8;
> > > +			val |= sel << 4;
> > > +		}
> > > +	}

[...]

> > > +static int mt6370_led_register(struct device *dev, struct mt6370_led *led,
> > > +			       struct led_init_data *init_data)
> > > +{
> > > +	struct mt6370_priv *priv = led->priv;
> > > +	int ret;
> > > +
> > > +	if (led->index == MT6370_VIRTUAL_MULTICOLOR) {
> >
> > This too could be split into separate functions to tidy things up a
> > little.
> >
> Like as below?
>
> if (led->index == MT6370_VIRTUAL_MULTICOLOR)
>    return mt6370_multicolor_led_register(....)
>
> if (led->index == MT6370_LED_ISNK4) {
>     .....
> }
>
> ret = mt6370_init_isnk_default_state(...)

Yes, that kind of thing.

> Since the multilor case directly return from the sub-function, else can be removed.

> > > +		ret = mt6370_mc_brightness_set(&led->mc.led_cdev, 0);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Couldn't set multicolor brightness\n");
> > > +
> > > +		ret = devm_led_classdev_multicolor_register_ext(dev, &led->mc,
> > > +								init_data);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Couldn't register multicolor\n");
> > > +	} else {
> > > +		if (led->index == MT6370_LED_ISNK4) {
> > > +			ret = regmap_field_write(priv->fields[F_CHGIND_EN], 1);
> > > +			if (ret)
> > > +				return dev_err_probe(dev, ret, "Failed to set CHRIND to SW\n");
> > > +		}
> > > +
> > > +		ret = mt6370_isnk_init_default_state(led);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Failed to init %d isnk state\n",
> > > +					     led->index);
> > > +
> > > +		ret = devm_led_classdev_register_ext(dev, &led->isink,
> > > +						     init_data);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Couldn't register isink %d\n", led->index);
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int mt6370_check_vendor_info(struct mt6370_priv *priv)
> > > +{
> > > +	unsigned int devinfo, vid;
> > > +	int ret;
> > > +
> > > +	ret = regmap_read(priv->regmap, MT6370_REG_DEV_INFO, &devinfo);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	vid = FIELD_GET(MT6370_VENID_MASK, devinfo);
> > > +	if (vid == 0x9 || vid == 0xb) {
> >
> > Are there nice human readable associates of these (vendor?) IDS?
> >
> For clearly understanding, I'll define these two as 'MT6372_VENDOR_ID' and 'MT6372C_VENDOR_ID'.

Much better, thank you.

--
Lee Jones [李琼斯]

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee@kernel.org>
To: ChiYuan Huang <cy_huang@richtek.com>
Cc: ChiaEn Wu <chiaen_wu@richtek.com>,
	corbet@lwn.net, pavel@ucw.cz, matthias.bgg@gmail.com,
	andriy.shevchenko@linux.intel.com, jacek.anaszewski@gmail.com,
	angelogioacchino.delregno@collabora.com,
	linux-doc@vger.kernel.org, peterwu.pub@gmail.com,
	linux-leds@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	szunichen@gmail.com, Alice Chen <alice_chen@richtek.com>
Subject: Re: [PATCH v17 RESEND 1/3] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support
Date: Wed, 8 Mar 2023 14:02:52 +0000	[thread overview]
Message-ID: <20230308140252.GM9667@google.com> (raw)
In-Reply-To: <20230307022302.GA4930@linuxcarl2.richtek.com>

On Tue, 07 Mar 2023, ChiYuan Huang wrote:

> Hi, Lee:
>
> Thanks's for the reviewing.
> To prevent the misunderstanding, reply as below.
> No reply means will do.
>
> On Sun, Mar 05, 2023 at 08:55:33AM +0000, Lee Jones wrote:
> > On Thu, 23 Feb 2023, ChiaEn Wu wrote:
> >
> > > From: ChiYuan Huang <cy_huang@richtek.com>
> > >
> > > The MediaTek MT6370 is a highly-integrated smart power management IC,
> > > which includes a single cell Li-Ion/Li-Polymer switching battery
> > > charger, a USB Type-C & Power Delivery (PD) controller, dual
> > > Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> > > a display bias driver and a general LDO for portable devices.
> > >
> > > Add support for the MediaTek MT6370 Current Sink Type LED Indicator
> > > driver. It can control four channels current-sink RGB LEDs with 3 modes:
> > > constant current, PWM, and breath mode.
> > >
> > > Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> > > Co-developed-by: Alice Chen <alice_chen@richtek.com>
> > > Signed-off-by: Alice Chen <alice_chen@richtek.com>
> > > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com>
> > > ---
> > > v17
> > > - Update the year of Copyright from 2022 to 2023
> > >
> > > ---
> > >  drivers/leds/rgb/Kconfig           |   13 +
> > >  drivers/leds/rgb/Makefile          |    1 +
> > >  drivers/leds/rgb/leds-mt6370-rgb.c | 1009 ++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 1023 insertions(+)
> > >  create mode 100644 drivers/leds/rgb/leds-mt6370-rgb.c

[...]

> > > +static int mt6370_gen_breath_pattern(struct mt6370_priv *priv,
> > > +				     struct led_pattern *pattern, u32 len,
> > > +				     u8 *pattern_val, u32 val_len)
> > > +{
> > > +	enum mt6370_led_ranges sel_range;
> > > +	struct led_pattern *curr;
> > > +	unsigned int sel;
> > > +	u32 val = 0;
> > > +	int i;
> > > +
> > > +	if (len < P_MAX_PATTERNS && val_len < P_MAX_PATTERNS / 2)
> > > +		return -EINVAL;
> > > +
> > > +	/*
> > > +	 * Pattern list
> > > +	 * tr1:	 byte 0, b'[7: 4]
> >
> > Perhaps this is standard formatting and I'm just not aware of it, but
> > the space is throwing me and making me think twice.  Does this mean bits
> > 7 through 4, so b'11110000?
> >
> Yes. like as you said. Sorry for the redudant space make you confused.
> I'm not sure whether it's a standard formating or not.
> Sometimes, in datasheet, we'll use this format to represent the bitfield for functions.
> Your format is also good for it.
> And which one is preferable?

Since neither of us are sure, just take the space out for now please.

> > > +	 * tr2:	 byte 0, b'[3: 0]
> > > +	 * tf1:	 byte 1, b'[7: 4]
> > > +	 * tf2:	 byte 1, b'[3: 0]
> > > +	 * ton:	 byte 2, b'[7: 4]
> > > +	 * toff: byte 2, b'[3: 0]
> > > +	 */
> > > +	for (i = 0; i < P_MAX_PATTERNS; i++) {
> > > +		curr = pattern + i;
> > > +
> > > +		sel_range = i == P_LED_TOFF ? R_LED_TOFF : R_LED_TRFON;
> > > +
> > > +		linear_range_get_selector_within(priv->ranges + sel_range,
> > > +						 curr->delta_t, &sel);
> > > +
> > > +		if (i % 2) {
> > > +			val |= sel;
> > > +		} else {
> > > +			val <<= 8;
> > > +			val |= sel << 4;
> > > +		}
> > > +	}

[...]

> > > +static int mt6370_led_register(struct device *dev, struct mt6370_led *led,
> > > +			       struct led_init_data *init_data)
> > > +{
> > > +	struct mt6370_priv *priv = led->priv;
> > > +	int ret;
> > > +
> > > +	if (led->index == MT6370_VIRTUAL_MULTICOLOR) {
> >
> > This too could be split into separate functions to tidy things up a
> > little.
> >
> Like as below?
>
> if (led->index == MT6370_VIRTUAL_MULTICOLOR)
>    return mt6370_multicolor_led_register(....)
>
> if (led->index == MT6370_LED_ISNK4) {
>     .....
> }
>
> ret = mt6370_init_isnk_default_state(...)

Yes, that kind of thing.

> Since the multilor case directly return from the sub-function, else can be removed.

> > > +		ret = mt6370_mc_brightness_set(&led->mc.led_cdev, 0);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Couldn't set multicolor brightness\n");
> > > +
> > > +		ret = devm_led_classdev_multicolor_register_ext(dev, &led->mc,
> > > +								init_data);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Couldn't register multicolor\n");
> > > +	} else {
> > > +		if (led->index == MT6370_LED_ISNK4) {
> > > +			ret = regmap_field_write(priv->fields[F_CHGIND_EN], 1);
> > > +			if (ret)
> > > +				return dev_err_probe(dev, ret, "Failed to set CHRIND to SW\n");
> > > +		}
> > > +
> > > +		ret = mt6370_isnk_init_default_state(led);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Failed to init %d isnk state\n",
> > > +					     led->index);
> > > +
> > > +		ret = devm_led_classdev_register_ext(dev, &led->isink,
> > > +						     init_data);
> > > +		if (ret)
> > > +			return dev_err_probe(dev, ret, "Couldn't register isink %d\n", led->index);
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int mt6370_check_vendor_info(struct mt6370_priv *priv)
> > > +{
> > > +	unsigned int devinfo, vid;
> > > +	int ret;
> > > +
> > > +	ret = regmap_read(priv->regmap, MT6370_REG_DEV_INFO, &devinfo);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	vid = FIELD_GET(MT6370_VENID_MASK, devinfo);
> > > +	if (vid == 0x9 || vid == 0xb) {
> >
> > Are there nice human readable associates of these (vendor?) IDS?
> >
> For clearly understanding, I'll define these two as 'MT6372_VENDOR_ID' and 'MT6372C_VENDOR_ID'.

Much better, thank you.

--
Lee Jones [李琼斯]

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

  reply	other threads:[~2023-03-08 14:06 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23 11:23 [PATCH v17 RESEND 0/3] Add MediaTek MT6370 PMIC support ChiaEn Wu
2023-02-23 11:23 ` ChiaEn Wu
2023-02-23 11:23 ` [PATCH v17 RESEND 1/3] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support ChiaEn Wu
2023-02-23 11:23   ` ChiaEn Wu
2023-02-23 13:14   ` AngeloGioacchino Del Regno
2023-02-23 13:14     ` AngeloGioacchino Del Regno
2023-03-05  8:55   ` Lee Jones
2023-03-05  8:55     ` Lee Jones
2023-03-07  2:23     ` ChiYuan Huang
2023-03-07  2:23       ` ChiYuan Huang
2023-03-08 14:02       ` Lee Jones [this message]
2023-03-08 14:02         ` Lee Jones
2023-02-23 11:23 ` [PATCH v17 RESEND 2/3] leds: flash: mt6370: Add MediaTek MT6370 flashlight support ChiaEn Wu
2023-02-23 11:23   ` ChiaEn Wu
2023-03-05 10:06   ` Lee Jones
2023-03-05 10:06     ` Lee Jones
2023-03-07  3:44     ` ChiYuan Huang
2023-03-07  3:44       ` ChiYuan Huang
2023-03-08 13:54       ` Lee Jones
2023-03-08 13:54         ` Lee Jones
2023-03-09  1:49         ` ChiYuan Huang
2023-03-09  1:49           ` ChiYuan Huang
2023-03-09 17:24           ` Lee Jones
2023-03-09 17:24             ` Lee Jones
2023-02-23 11:23 ` [PATCH v17 RESEND 3/3] docs: leds: Add MT6370 RGB LED pattern document ChiaEn Wu
2023-02-23 11:23   ` ChiaEn Wu
2023-03-05 10:18   ` Lee Jones
2023-03-05 10:18     ` Lee Jones
2023-03-07  4:08     ` ChiYuan Huang
2023-03-07  4:08       ` ChiYuan Huang
2023-03-08 13:42       ` Lee Jones
2023-03-08 13:42         ` Lee Jones

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=20230308140252.GM9667@google.com \
    --to=lee@kernel.org \
    --cc=alice_chen@richtek.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chiaen_wu@richtek.com \
    --cc=corbet@lwn.net \
    --cc=cy_huang@richtek.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=peterwu.pub@gmail.com \
    --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.