From: Pavel Machek <pavel@ucw.cz>
To: Dan Murphy <dmurphy@ti.com>
Cc: jacek.anaszewski@gmail.com, robh@kernel.org, marek.behun@nic.cz,
devicetree@vger.kernel.org, linux-leds@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Date: Tue, 11 Aug 2020 12:29:53 +0200 [thread overview]
Message-ID: <20200811102953.nio3rslben3oymxb@duo.ucw.cz> (raw)
In-Reply-To: <20200722153146.8767-3-dmurphy@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4801 bytes --]
Hi!
> Introduce the LP5036/30/24/18/12/9 RGB LED driver.
> The difference in these parts are the number of
> LED outputs where the:
>
> LP5036 can control 36 LEDs
> LP5030 can control 30 LEDs
> LP5024 can control 24 LEDs
> LP5018 can control 18 LEDs
> LP5012 can control 12 LEDs
> LP5009 can control 9 LEDs
>
> The device has the ability to group LED outputs into control banks
> so that multiple LED banks can be controlled with the same mixing and
> brightness. Or the LED outputs can also be controlled independently.
>
> diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> new file mode 100644
> index 000000000000..f4ef9b7f21b2
> --- /dev/null
> +++ b/drivers/leds/leds-lp50xx.c
> @@ -0,0 +1,791 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// TI LP50XX LED chip family driver
> +// Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/
I assume 2018-2020
> +#define LP5012_OUT0_CLR 0x0b
> +#define LP5012_OUT1_CLR 0x0c
> +#define LP5012_OUT2_CLR 0x0d
> +#define LP5012_OUT3_CLR 0x0e
> +#define LP5012_OUT4_CLR 0x0f
> +#define LP5012_OUT5_CLR 0x10
> +#define LP5012_OUT6_CLR 0x11
> +#define LP5012_OUT7_CLR 0x12
> +#define LP5012_OUT8_CLR 0x13
> +#define LP5012_OUT9_CLR 0x14
> +#define LP5012_OUT10_CLR 0x15
> +#define LP5012_OUT11_CLR 0x16
> +
> +#define LP5024_OUT0_CLR 0x0f
> +#define LP5024_OUT1_CLR 0x10
> +#define LP5024_OUT2_CLR 0x11
> +#define LP5024_OUT3_CLR 0x12
> +#define LP5024_OUT4_CLR 0x13
> +#define LP5024_OUT5_CLR 0x14
> +#define LP5024_OUT6_CLR 0x15
> +#define LP5024_OUT7_CLR 0x16
> +#define LP5024_OUT8_CLR 0x17
> +#define LP5024_OUT9_CLR 0x18
> +#define LP5024_OUT10_CLR 0x19
> +#define LP5024_OUT11_CLR 0x1a
> +#define LP5024_OUT12_CLR 0x1b
> +#define LP5024_OUT13_CLR 0x1c
> +#define LP5024_OUT14_CLR 0x1d
> +#define LP5024_OUT15_CLR 0x1e
> +#define LP5024_OUT16_CLR 0x1f
> +#define LP5024_OUT17_CLR 0x20
> +#define LP5024_OUT18_CLR 0x21
> +#define LP5024_OUT19_CLR 0x22
> +#define LP5024_OUT20_CLR 0x23
> +#define LP5024_OUT21_CLR 0x24
> +#define LP5024_OUT22_CLR 0x25
> +#define LP5024_OUT23_CLR 0x26
> +#define LP5036_OUT0_CLR 0x14
> +#define LP5036_OUT1_CLR 0x15
> +#define LP5036_OUT2_CLR 0x16
> +#define LP5036_OUT3_CLR 0x17
> +#define LP5036_OUT4_CLR 0x18
> +#define LP5036_OUT5_CLR 0x19
> +#define LP5036_OUT6_CLR 0x1a
> +#define LP5036_OUT7_CLR 0x1b
> +#define LP5036_OUT8_CLR 0x1c
> +#define LP5036_OUT9_CLR 0x1d
> +#define LP5036_OUT10_CLR 0x1e
> +#define LP5036_OUT11_CLR 0x1f
> +#define LP5036_OUT12_CLR 0x20
> +#define LP5036_OUT13_CLR 0x21
> +#define LP5036_OUT14_CLR 0x22
> +#define LP5036_OUT15_CLR 0x23
> +#define LP5036_OUT16_CLR 0x24
> +#define LP5036_OUT17_CLR 0x25
> +#define LP5036_OUT18_CLR 0x26
> +#define LP5036_OUT19_CLR 0x27
> +#define LP5036_OUT20_CLR 0x28
> +#define LP5036_OUT21_CLR 0x29
> +#define LP5036_OUT22_CLR 0x2a
> +#define LP5036_OUT23_CLR 0x2b
> +#define LP5036_OUT24_CLR 0x2c
> +#define LP5036_OUT25_CLR 0x2d
> +#define LP5036_OUT26_CLR 0x2e
> +#define LP5036_OUT27_CLR 0x2f
> +#define LP5036_OUT28_CLR 0x30
> +#define LP5036_OUT29_CLR 0x31
> +#define LP5036_OUT30_CLR 0x32
> +#define LP5036_OUT31_CLR 0x33
> +#define LP5036_OUT32_CLR 0x34
> +#define LP5036_OUT33_CLR 0x35
> +#define LP5036_OUT34_CLR 0x36
> +#define LP5036_OUT35_CLR 0x37
These are really useless. Please get rid of them.
> +#define LP5009_MAX_LED_MODULES 2
> +#define LP5012_MAX_LED_MODULES 4
> +#define LP5018_MAX_LED_MODULES 6
> +#define LP5024_MAX_LED_MODULES 8
> +#define LP5030_MAX_LED_MODULES 10
> +#define LP5036_MAX_LED_MODULES 12
> +
> +#define LP5009_MAX_LEDS (LP5009_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
> +#define LP5012_MAX_LEDS (LP5012_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
> +#define LP5018_MAX_LEDS (LP5018_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
> +#define LP5024_MAX_LEDS (LP5024_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
> +#define LP5030_MAX_LEDS (LP5030_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
> +#define LP5036_MAX_LEDS (LP5036_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
As are these. In general, when define is used just once, please think
if we really need it.
> +static int lp50xx_probe_dt(struct lp50xx *priv)
> +{
> + struct fwnode_handle *child = NULL;
> + struct fwnode_handle *led_node = NULL;
> + struct led_init_data init_data = {};
> + struct led_classdev *led_cdev;
> + struct mc_subled *mc_led_info;
> + struct lp50xx_led *led;
> + int num_colors;
> + u32 color_id;
> + size_t i = 0;
No reason this has to be size_t. Int?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2020-08-11 10:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy
2020-07-22 15:31 ` [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2020-07-28 13:39 ` Dan Murphy
2020-08-04 19:55 ` Dan Murphy
2020-08-07 13:42 ` Dan Murphy
2020-08-11 10:32 ` Pavel Machek
2020-08-11 10:20 ` Pavel Machek
2020-08-11 17:07 ` Dan Murphy
2020-07-22 15:31 ` [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2020-08-11 10:29 ` Pavel Machek [this message]
2020-08-11 10:31 ` Pavel Machek
2020-08-11 10:54 ` Pavel Machek
2020-08-11 17:27 ` Dan Murphy
2020-08-11 22:01 ` Pavel Machek
2020-08-11 22:16 ` Dan Murphy
2020-08-11 22:26 ` Pavel Machek
2020-08-12 16:00 ` Dan Murphy
2020-07-22 15:31 ` [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag Dan Murphy
2020-07-28 13:38 ` Dan Murphy
2020-08-03 23:14 ` Linus Walleij
2020-07-22 15:31 ` [PATCH v32 4/6] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy
2020-07-22 15:31 ` [PATCH v32 5/6] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy
2020-07-22 15:31 ` [PATCH v32 6/6] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
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=20200811102953.nio3rslben3oymxb@duo.ucw.cz \
--to=pavel@ucw.cz \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=marek.behun@nic.cz \
--cc=robh@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).