All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Baolin Wang <baolin.wang@linaro.org>,
	rteysseyre@gmail.com, bjorn.andersson@linaro.org,
	broonie@kernel.org, linux-leds@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger
Date: Fri, 24 Aug 2018 22:12:27 +0200	[thread overview]
Message-ID: <20180824201227.GB17146@amd> (raw)
In-Reply-To: <9bb7ac19-36a6-d11a-6d46-fc65c2026201@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

On Fri 2018-08-24 21:49:50, Jacek Anaszewski wrote:
> Hi Pavel,
> 
> On 08/24/2018 12:11 PM, Pavel Machek wrote:
> > Hi!
> > 
> >> I think that it would be more flexible if software pattern fallback
> >> was applied in case of pattern_set failure. Otherwise, it would
> >> lead to the situation where LED class devices that support hardware
> >> blinking couldn't be applied the same set of patterns as LED class
> >> devices that don't implement pattern_set. The latter will always have to
> >> resort to using software pattern engine which will accept far greater
> >> amount of pattern combinations.
> >>
> >> In this case we need to discuss on what basis the decision will be
> >> made on whether hardware or software engine will be used.
> >>
> >> Possible options coming to mind:
> >> - an interface will be provided to determine max difference between
> >>   the settings supported by the hardware and the settings requested by
> >>   the user, that will result in aligning user's setting to the hardware
> >>   capabilities
> >> - the above alignment rate will be predefined instead
> >> - hardware engine will be used only if user requests supported settings
> >>   on the whole span of the requested pattern
> >> - in each of the above cases it would be worth to think of the
> >>   interface to show the scope of the settings supported by hardware
> > 
> > I'd recommend keeping it simple. We use hardware engine if driver
> > author thinks pattern is "close enough".
> 
> The thing is that in the ledtrig-pattern v5 implementation there
> is no option of using software fallback if pattern_set op
> is initialized:
> 
> +	if (led_cdev->pattern_set) {
> +		return led_cdev->pattern_set(led_cdev, data->patterns,
> +					     data->npatterns, data->repeat);
> +	}

Yeah, that sounds wrong. (Sorry I did not pay enough attention).

It pattern_set() returns special error code, it should just continue
and use software pattern fallback.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2018-08-24 20:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06 12:05 [PATCH v5 1/2] leds: core: Introduce LED pattern trigger Baolin Wang
2018-08-06 12:06 ` [PATCH v5 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller Baolin Wang
2018-08-07 21:54 ` [PATCH v5 1/2] leds: core: Introduce LED pattern trigger Jacek Anaszewski
2018-08-07 21:54   ` Jacek Anaszewski
2018-08-08  6:01   ` Baolin Wang
2018-08-08 21:28     ` Jacek Anaszewski
2018-08-09  5:48       ` Baolin Wang
2018-08-09  5:48         ` Baolin Wang
2018-08-09 13:21         ` Jacek Anaszewski
2018-08-10 15:26           ` Baolin Wang
2018-08-10 18:10             ` Jacek Anaszewski
2018-08-11  2:17               ` Baolin Wang
2018-08-24 10:11   ` Pavel Machek
2018-08-24 19:49     ` Jacek Anaszewski
2018-08-24 20:12       ` Pavel Machek [this message]
2018-08-24 20:44         ` Jacek Anaszewski
2018-08-25  7:51           ` Baolin Wang
2018-08-28 20:25             ` Jacek Anaszewski
2018-08-28 21:13               ` Bjorn Andersson
2018-08-29 18:55                 ` Jacek Anaszewski
2018-08-29  9:48               ` Baolin Wang
2018-08-29 19:15                 ` Jacek Anaszewski
2018-08-30  3:26                   ` Baolin Wang
2018-08-30  7:39                     ` Baolin Wang
2018-08-28 20:47             ` Bjorn Andersson

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=20180824201227.GB17146@amd \
    --to=pavel@ucw.cz \
    --cc=baolin.wang@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=rteysseyre@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.