linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>
Cc: <linux-leds@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH v17 00/17] Multi Color LED Framework
Date: Tue, 25 Feb 2020 16:44:37 -0600	[thread overview]
Message-ID: <e05580eb-670e-9e62-f3c4-84980e2193d2@ti.com> (raw)
In-Reply-To: <be76fdac-9d32-b9b2-c01d-3aa315b14463@gmail.com>

Hello

On 2/25/20 4:17 PM, Jacek Anaszewski wrote:
> On 2/25/20 11:19 AM, Pavel Machek wrote:
>> Hi!
>>
>>>>    leds: lp5521: Add multicolor framework multicolor brightness support
>>>>    leds: lp55xx: Fix checkpatch file permissions issues
>>>>    leds: lp5523: Fix checkpatch issues in the code
>>>>    dt: bindings: Update lp55xx binding to recommended LED naming
>>> I have no open comments on this patchset except for a DT change requested by
>>> Shawn Gao but this change should wait till after this patchset is merged.
>>>
>>> Is there something holding this up?
>> Yes... my time; sorry about that.
>>
>> The fact that it changes API makes it important to get it right, and
>> hard/impossible to fix it once it is merged... and I don't think this
>> is the right interface (sorry).
>>
>> In particular, I don't think having directory per channel is a good
>> idea. It makes atomic updates impossible (minor),
> It is possible via brightness file, although it will need first writing
> intensity files, which only will cache colors, and actual write to hw
> occurs on write to brightness file. This has been discussed dozen of
> times throughout last year, and you even proposed the formula for
> calculating per-color-subled brightness basing on global brightness and
> intensity set for each color.

I actually just got your reply Pavel.  Unfortunately I don't have the 
band width to spin any more major framework changes and as you know this 
has been discussed over and over and over again with multiple iterations 
and multiple designs.

I still don't agree with some nebulous unbound array being passed into 
the driver via sysfs. As we have discussed at length in the past this 
implementation is just as bad if not worse then what I am proposing. I 
also have provided that particular array implementation and it failed to 
get any ACKs as it violated sysfs rules and was wrought with corner 
cases and mismatches of color to intensity values.  And calling the 
sysfs node channel_intensity and channel_names is not correct this is a 
LP55xx naming convention and should not be applied.

But as Jacek indicated lets have the sysfs maintainer provide the 
consultation on the array implementation again.

And as I have stated above my time has run out on trying to get this 
framework completed so I will just re-write the lp50xx driver against 
the standard LED class implementation and abandon any hope of actually 
improving the LED subsystem for multi color ICs.  As I don't have 
another year or two to debate this interface again and try to implement 
the code just for it to get another NACK in the end and having to 
rewrite the framework again.

Dan



  reply	other threads:[~2020-02-25 22:49 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-27 15:00 [RESEND PATCH v17 00/17] Multi Color LED Framework Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 01/17] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 02/17] " Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 03/17] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 04/17] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 05/17] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 06/17] dt: bindings: lp55xx: Be consistent in the document with LED acronym Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 07/17] dt: bindings: lp55xx: Update binding for Multicolor Framework Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 08/17] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 09/17] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 10/17] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 11/17] leds: lp55xx: Convert LED class registration to devm_* Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 12/17] leds: lp55xx: Add multicolor framework support to lp55xx Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 13/17] leds: lp5523: Update the lp5523 code to add multicolor brightness function Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 14/17] leds: lp5521: Add multicolor framework multicolor brightness support Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 15/17] leds: lp55xx: Fix checkpatch file permissions issues Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 16/17] leds: lp5523: Fix checkpatch issues in the code Dan Murphy
2020-01-27 15:00 ` [RESEND PATCH v17 17/17] dt: bindings: Update lp55xx binding to recommended LED naming Dan Murphy
2020-02-12 13:09 ` [RESEND PATCH v17 00/17] Multi Color LED Framework Dan Murphy
2020-02-25 10:19   ` Pavel Machek
2020-02-25 22:17     ` Jacek Anaszewski
2020-02-25 22:44       ` Dan Murphy [this message]
2020-02-26 12:59       ` Pavel Machek
2020-02-26 20:45         ` Jacek Anaszewski
2020-02-26 22:10           ` Dan Murphy
2020-02-27 10:58           ` Pavel Machek
2020-02-27 12:43             ` Greg KH
2020-02-27 13:07               ` Dan Murphy
2020-02-27 13:29                 ` Dan Murphy
2020-02-27 21:22                 ` Jacek Anaszewski
2020-02-28  7:42                   ` Greg KH
2020-02-28  9:34                     ` Pavel Machek
2020-02-28 12:30                     ` Dan Murphy
2020-02-28  9:39                   ` Pavel Machek

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=e05580eb-670e-9e62-f3c4-84980e2193d2@ti.com \
    --to=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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).