From: Stas Sergeev <stsp@list.ru>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-leds@vger.kernel.org,
Linux kernel <linux-kernel@vger.kernel.org>,
Stas Sergeev <stsp@users.sourceforge.net>
Subject: Re: [PATCH v2 0/3] leds: blink resolution improvements
Date: Thu, 30 Apr 2015 23:42:35 +0300 [thread overview]
Message-ID: <554293BB.6000709@list.ru> (raw)
In-Reply-To: <20150430173024.GB21211@amd>
30.04.2015 20:30, Pavel Machek пишет:
>> For the timer trigger I would pretty much like my approach to stay.
>> The reason is that the PWM I need to do, is not strictly a PWM -
>> it needs the ON period in range of tens or hundreds of milliseconds,
>> while the OFF period is in a couple of usecs (or vice-versa). No
> That is a PWM, right? I see why you'd want to have short "on", but I
> don't see why you'd want short "off"...
OK so you demand the full details... sigh. :)
Well the board I have, was created by some crazy people.
They wanted to add an external watchdog, and what they
did was to program one of the leds to "heartbeat" and wire
it to the external MCU that controls the power. So when it
heartbeats, watchdog will not re-power the board.
Now I want to use that led as a led, not as a watchdog.
For that I unfortunately need those "almost ON/almost OFF"
timings.
This board is all but linux-friendly. For example I have already
submitted the patches that allow mvneta MAC to work without
MDIO. And there is a lot of fun ahead in getting the rest to work.
> There's one thing you have to do: having two files, one specifiying
> units and second one specifying timeout is not going to work.
Oh but there is already 2: delay_on/delay_off.
> What about simply "echo 0.001 > delay_on"?
This is possible.
But please consider the following reservations:
- There is already 2 files, so you are not going to write settings
atomically anyway. When resolution changes, it might be better
to just reset to the sane defaults (not in my current patch).
- As was already discussed in the same thread, not all drivers
can support sub-ms delays. For these drivers such resolutions
should not be available. With separate file this is naturally
achieved: you either don't create it at all, or list only the possible
resolutions. With your approach you never know whether you
can write 0.0001 or not.
- You will set the delay in ms units. For example for 100us you'll
write 0.1. IMHO it is counter-intuitive: people will make a mistake
and try 0.0001 instead, wrongly assuming that this is in seconds.
And nanoseconds should then better be removed, as writing
nanosecond delay will just require too much zeros.
Now I am not saying I am against that approach.
More like I have already considered it and have not prioritized
it over the one with the new file. But feel free to convince me
that it is better and I'll implement it in the next update.
next prev parent reply other threads:[~2015-04-30 20:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 17:08 [PATCH v2 0/3] leds: blink resolution improvements Stas Sergeev
2015-04-27 17:09 ` [PATCH 1/3] leds: use hrtimer for blinking Stas Sergeev
2015-04-27 17:11 ` Stas Sergeev
2015-04-27 17:12 ` [PATCH 2/3] ledtrig-timer: add blink delay_unit control Stas Sergeev
2015-04-27 17:14 ` [PATCH 3/3] leds: update documentation about new delay units Stas Sergeev
2015-04-27 20:54 ` [PATCH v2 0/3] leds: blink resolution improvements Pavel Machek
2015-04-27 21:14 ` Stas Sergeev
2015-04-30 17:30 ` Pavel Machek
2015-04-30 20:42 ` Stas Sergeev [this message]
2015-05-03 10:34 ` Pavel Machek
2015-05-03 11:35 ` Stas Sergeev
2015-05-11 22:11 ` Pavel Machek
2015-04-27 22:23 ` Stas Sergeev
2015-04-28 8:57 ` Jacek Anaszewski
2015-04-28 10:12 ` Stas Sergeev
2015-04-28 12:58 ` Jacek Anaszewski
2015-04-28 13:26 ` Stas Sergeev
2015-04-29 15:06 ` Jacek Anaszewski
2015-04-29 11:26 ` Stas Sergeev
2015-04-29 15:14 ` Jacek Anaszewski
2015-04-30 17:11 ` Stas Sergeev
2015-05-04 7:55 ` Jacek Anaszewski
2015-05-04 12:12 ` Stas Sergeev
2015-05-04 15:22 ` Jacek Anaszewski
2015-05-04 17:20 ` Stas Sergeev
2015-05-05 8:22 ` Jacek Anaszewski
2015-05-05 13:02 ` Stas Sergeev
2015-05-06 7:20 ` Jacek Anaszewski
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=554293BB.6000709@list.ru \
--to=stsp@list.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=stsp@users.sourceforge.net \
/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).