From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: "Bollinger, Seth" <Seth.Bollinger@digi.com>, Pavel Machek <pavel@ucw.cz>
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: Wed, 21 Oct 2020 22:23:53 +0200 [thread overview]
Message-ID: <1a86fe05-d8a3-b4b9-4065-b31abce287e2@gmail.com> (raw)
In-Reply-To: <78785807-3DB7-4A70-B135-2B20A260EA57@digi.com>
Hi Seth,
On 10/20/20 8:35 PM, Bollinger, Seth wrote:
>
>>>
>>> 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?
>
> In this case we’re using the api to turn the LED on and off, without blinking (in this case only).
>
>>
>>>> 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...?
>
> Ok, I’ll take a look. Thanks!
You might want to check also ledtrig-pattern and paragraph 2.
of its documentation [0].
[0] Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2020-10-21 20:24 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
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 [this message]
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=1a86fe05-d8a3-b4b9-4065-b31abce287e2@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=Seth.Bollinger@digi.com \
--cc=dmurphy@ti.com \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--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).