linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-leds@vger.kernel.org, linux-gpio@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>
Subject: Re: [PATCH] leds: gpio: support multi-level brightness
Date: Tue, 8 Oct 2019 22:53:07 +0200	[thread overview]
Message-ID: <72129a38-d975-74d4-269d-6269556d7aae@gmail.com> (raw)
In-Reply-To: <CAC5umyiK8LBqQ1B1LPQgWXGCk_a+JyKgidrRZpPMDu+NZncDXw@mail.gmail.com>

On 10/6/19 4:11 PM, Akinobu Mita wrote:
> 2019年10月6日(日) 4:17 Jacek Anaszewski <jacek.anaszewski@gmail.com>:
>>
>> On 10/5/19 3:20 PM, Akinobu Mita wrote:
>>> 2019年10月5日(土) 6:17 Jacek Anaszewski <jacek.anaszewski@gmail.com>:
>>>>
>>>> Hi Akinobu,
>>>>
>>>> Why do you think this change is needed? Does it solve
>>>> some use case for you?
>>>
>>> It can be useful when using with an LED trigger that could set the
>>> brightness values other than LED_FULL or LED_OFF.
>>>
>>> The LED CPU trigger for all CPUs (not per CPU) sets the brightness value
>>> depending on the number of active CPUs.  We can define the multi brightness
>>> level gpio LED with fewer number of GPIO LEDs than the total number of
>>> CPUs, and the LEDs can be viewed as a level meter.
>>
>> Can't you achieve exactly the same effect by creating separate LED class
>> device for each GPIO LED and registering each of them for separate cpuN
>> trigger?
> 
> If there are GPIO LEDs as many as the total number of CPUs, we can.
> However, if there are only two GPIO LEDs and six CPUs, we can only know
> the CPU activity for two CPUs out of six CPUs with cpuN trigger.
> So it's different from using cpu (all) trigger with multi level (2-level)
> brightness GPIO LED.

OK, that's a reasonable argument. However, this is clearly
trigger-specific functionality and we should not delegate this
logic down to the driver.

What you propose should be a responsibility of a trigger that would
allow registering multiple LEDs for its disposal. This would have to
be different from existing LED Trigger mechanism, that blindly
applies trigger event to all LEDs that have registered for it.

Such a trigger would have to be a separate LED (pattern?) class device.
It would need to be told how many LEDs it is going to manage
and create files for filling the LED names. This design could be also
used for defining patterns spanning on multiple LEDs. Just a rough idea.
We can dwell on it if it catches.

-- 
Best regards,
Jacek Anaszewski



  reply	other threads:[~2019-10-08 20:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 15:34 [PATCH] leds: gpio: support multi-level brightness Akinobu Mita
2019-10-04 15:42 ` Dan Murphy
2019-10-05 13:13   ` Akinobu Mita
2019-11-04  9:09     ` Pavel Machek
2019-10-04 21:17 ` Jacek Anaszewski
2019-10-05 13:20   ` Akinobu Mita
2019-10-05 19:17     ` Jacek Anaszewski
2019-10-06 14:11       ` Akinobu Mita
2019-10-08 20:53         ` Jacek Anaszewski [this message]
2019-10-09 14:43           ` Akinobu Mita
2019-10-09 18:14             ` Jacek Anaszewski
2019-10-06  4:06 ` Bjorn Andersson
2019-10-06 14:13   ` Akinobu Mita

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=72129a38-d975-74d4-269d-6269556d7aae@gmail.com \
    --to=jacek.anaszewski@gmail.com \
    --cc=akinobu.mita@gmail.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=dmurphy@ti.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@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).