From: Pavel Machek <pavel@ucw.cz>
To: "Bollinger, Seth" <Seth.Bollinger@digi.com>
Cc: "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
Dan Murphy <dmurphy@ti.com>, Seth Bollinger <seth.boll@gmail.com>
Subject: Re: Strange timer LED behavior
Date: Tue, 20 Oct 2020 20:33:00 +0200 [thread overview]
Message-ID: <20201020183300.GB25906@duo.ucw.cz> (raw)
In-Reply-To: <CF36FC5F-6FA9-4797-A6D6-6533D795DAD1@digi.com>
[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]
On Tue 2020-10-20 18:28:33, Bollinger, Seth wrote:
>
> >
> >> Is there a way to avoid this? Even if we write the on value twice,
> >> it will flash for 500ms at least once…
> >
> > There should be. Can you simply write new values to on and off,
> > without writing zeros there?
>
> In this case we’re switching from on:86400, off:0 -> on:0, off:86400. We write off first, then on using fwrite() to a file. From the trace, it looks like on is always stored first. So, the first store is on:0, off:0 for a brief period (enough to trigger the default), and then off is stored. We’re already trying to not have them not both be zero at the same time. I tried putting fflush() between them, but that didn’t help. I suppose we could try to sleep some period of time, but this seems bad as well. Maybe write and read to verify the value is correctly stored?
>
I don't understand. Why would you use blink with on:86400, off:0?
> > If there's no reasonable value to change the frequency, we'll need to
> > fix that.
>
> I think if we could control the delays with trigger set to none, then we could set the delays and enable the timer trigger for a no glitch operation. I suppose if there was a timer-off trigger, that would work as well, but seems kind of silly.
>
You may want to look at ledtrig-transient and ledtrig-oneshot...?
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2020-10-20 18:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 13:08 Strange timer LED behavior Bollinger, Seth
2020-10-19 14:06 ` Pavel Machek
2020-10-19 14:16 ` Bollinger, Seth
2020-10-20 12:04 ` Bollinger, Seth
2020-10-20 12:21 ` Pavel Machek
2020-10-20 12:31 ` Bollinger, Seth
2020-10-20 18:08 ` Pavel Machek
2020-10-20 18:28 ` Bollinger, Seth
2020-10-20 18:33 ` Pavel Machek [this message]
2020-10-20 18:35 ` Bollinger, Seth
2020-10-20 18:40 ` Pavel Machek
2020-10-20 18:51 ` Bollinger, Seth
2020-10-22 10:06 ` Pavel Machek
2020-10-22 11:34 ` Bollinger, Seth
2020-10-24 7:45 ` Pavel Machek
2020-10-21 20:23 ` Jacek Anaszewski
2020-10-22 11:35 ` Bollinger, Seth
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=20201020183300.GB25906@duo.ucw.cz \
--to=pavel@ucw.cz \
--cc=Seth.Bollinger@digi.com \
--cc=dmurphy@ti.com \
--cc=linux-leds@vger.kernel.org \
--cc=seth.boll@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 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).