devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
	Lee Jones <lee.jones@linaro.org>, Luca Weiss <luca@z3ntu.xyz>,
	Doug Anderson <dianders@chromium.org>,
	Rob Herring <robh+dt@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-pwm@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v14 2/2] leds: Add driver for Qualcomm LPG
Date: Wed, 11 May 2022 09:17:25 -0700	[thread overview]
Message-ID: <YnvhleAI5RW0ZvkV@ripper> (raw)
In-Reply-To: <20220507063659.GA6968@amd>

On Fri 06 May 23:36 PDT 2022, Pavel Machek wrote:

> Hi!
> 
> > > > As such the pattern sequence provided to hw_pattern looks to be the
> > > > smae, but I don't see that it can be made compatible.
> > > > 
> > > > > Can I get either patch to disable pattern infrastructure for now or to
> > > > > get it compatible?
> > > > > 
> > > > 
> > > > I'd be happy to get this updated to your liking, but this was one of the
> > > > drivers we discussed when we introduced the pattern trigger and led to
> > > > the conclusion that we need the ability to do hw-specific patterns.
> > > > 
> > > > As such this document provides the hardware specific documentation, as
> > > > we describe under "hw_pattern" in
> > > > Documentation/ABI/testing/sysfs-class-led-trigger-pattern.
> > > > 
> > > > Please advice on what you would like me to do.
> > > 
> > > I'd like you to use same format leds-trigger-pattern describes.
> > > 
> > > If someone passes "255 500 0 500", that's requesting gradual transitions and
> > > your hw can not do that. You return -EINVAL.
> > > 
> > > If someone wants that kind of blinking, they need to pass "255 0 255 500 0 0 0 500".
> > > 
> > 
> > So the section under hw_pattern in sysfs-class-led-trigger-pattern that
> > says:
> > 
> > "Since different LED hardware can have different semantics of
> > hardware patterns, each driver is expected to provide its own
> > description for the hardware patterns in their documentation
> > file at Documentation/leds/."
> > 
> > That doesn't apply to this piece of hardware & driver?
> 
> It applies: since your hardware can not do arbitrary patterns, you
> need description of what kinds of patterns it can do.
> 
> But you should still use compatible format, so that pattern that is
> valid for hw_pattern file is valid for pattern file, too, and produces
> same result.
> 

Okay, I didn't understand that the hw_pattern needs to be a subset of
the pattern. I will prepare a patch to require the pattern to include
the zero-time entries as well.

> If you believe documentation implies something else, it may need to be
> clarified.
> 

I'll read it again and if needed I'll try to clarify the expectations.

Thanks,
Bjorn

  reply	other threads:[~2022-05-11 16:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03 21:42 [PATCH v14 1/2] dt-bindings: leds: Add Qualcomm Light Pulse Generator binding Bjorn Andersson
2022-03-03 21:43 ` [PATCH v14 2/2] leds: Add driver for Qualcomm LPG Bjorn Andersson
2022-03-03 22:10   ` Doug Anderson
2022-04-06 15:18     ` Doug Anderson
2022-04-28 16:42       ` Doug Anderson
2022-04-11 18:37   ` Bjorn Andersson
2022-04-28 17:23   ` Luca Weiss
2022-04-30  9:56   ` Marijn Suijten
2022-04-30 12:35   ` Marijn Suijten
2022-04-30 14:51     ` Marijn Suijten
2022-05-04  7:30   ` Pavel Machek
2022-05-04 14:51     ` Bjorn Andersson
2022-05-06 16:09       ` Pavel Machek
2022-05-06 16:27         ` Bjorn Andersson
2022-05-07  6:36           ` Pavel Machek
2022-05-11 16:17             ` Bjorn Andersson [this message]
2022-04-30 10:06 ` [PATCH v14 1/2] dt-bindings: leds: Add Qualcomm Light Pulse Generator binding Marijn Suijten
2022-04-30 12:13 ` Marijn Suijten
2022-05-04  7:24 ` Pavel Machek
2022-05-04 16:21   ` 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=YnvhleAI5RW0ZvkV@ripper \
    --to=bjorn.andersson@linaro.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=luca@z3ntu.xyz \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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).