mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: David Lang <david@lang.hm>
Cc: Joe Xue <lgxue@hotmail.com>,
	"cooloney@gmail.com" <cooloney@gmail.com>,
	"rpurdie@rpsys.net" <rpurdie@rpsys.net>,
	"rob@landley.net" <rob@landley.net>,
	"milo.kim@ti.com" <milo.kim@ti.com>,
	"pavel@ucw.cz" <pavel@ucw.cz>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH] Add LED pattern trigger
Date: Wed, 1 Jan 2014 23:01:35 +0000	[thread overview]
Message-ID: <20140101230135.48f6f781@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <alpine.DEB.2.02.1401011423180.27645@nftneq.ynat.uz>

> whatever mechanism is created for toggling LEDs should be able to toggle 
> arbitrary GPIO pins, and there is a problem with the speed of the standard 
> access mechanisms in /sysfs. see this post on hackaday for an example
> 
> http://hackaday.com/2013/12/07/speeding-up-beaglebone-black-gpio-a-thousand-times/

The usage described is short human speed flashing patterns for things like
"my brain fell out" from devices, not trying to do 1KHz PWM dimming.
Dimming might actually be one case you want the kernel interface,
although it'll kill your power management.

> Also, since there are a number of cases where this is hardware accelerated, it 
> seems like there should be an abstration that userspace can use that doesn't 
> care if or how it's accelerated, setup the output and tell the system to do it 
> without worrying about the specific hardware details. Isn't that a large part of 
> what the kernel is supposed to be doing?

Not usually. The kernel is supposed to be providing a consistent interface
to hardware, not emulating bits you don't have. Now and then it does (Eg
FPU emulation) but in general the job it does is "make all the network
cards look the same" not "make pretend network cards out of string and
cups". It's not a hard and fast rule in either direction. There are cases
the kernel doesn't try and create a common interface for the hardware
because the abstraction that can be done at kernel level would be
nonsensical.

A library also allows a higher level of abstraction and better security,
and it allows consistency a kernel interface cannot provide as well as
not pinning down memory which at least in embedded space is valuable (and
may become more so in the 'internet of things' world of lower and lower
power and cheaper and cheaper widgets)

At best a kernel interface would mean people writing "post 3.15 do this,
pre 3.15 do the other". A library interface avoids that as it will work
with old kernels too, and can be taught to interface with acceleration
features, or even with other device types. A kernel interface cannot
drive X.10 for example, drive a remote bluetooth display, beep the code or
flash the LED patterns as an overlay on a monitor. Nor can it do things
like automatically routing the alert based upon stuff like "is the
display on", "is the management interface up" etc.

The library interface can also be made to do sensible things in virtual
environments, on other operating systems and so forth.

Alan

  reply	other threads:[~2014-01-01 23:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-30  0:11 Joe Xue
2013-12-30 16:21 ` One Thousand Gnomes
2013-12-30 23:24   ` Joe Xue
2013-12-31  0:18     ` One Thousand Gnomes
2013-12-31 18:48   ` Joe Xue
2014-01-01 20:10     ` One Thousand Gnomes
2014-01-01 22:44       ` David Lang
2014-01-01 23:01         ` One Thousand Gnomes [this message]
2014-01-01 23:51           ` David Lang
2014-01-03  0:14             ` Bryan Wu
2014-01-03  9:33               ` Richard Weinberger
2014-01-03 15:23               ` One Thousand Gnomes
2014-01-05 22:23                 ` n900 led compiler (was Re: [PATCH] Add LED pattern trigger) Pavel Machek
2014-01-07 15:40                   ` Linus Walleij
2013-12-30 18:33 ` [PATCH] Add LED pattern trigger Pavel Machek
2013-12-31  5:00   ` Joe Xue
2013-12-31 11:33     ` Pavel Machek
2013-12-31 12:29       ` Richard Weinberger
2013-12-31 19:03         ` Pavel Machek
2014-01-01 20:11           ` One Thousand Gnomes
2014-01-01  2:57 ` [PATCH v2 1/1] leds: " Joe Xue
2014-01-01  3:03 ` [PATCH v2 1/1] " Joe Xue
2014-01-06 21:47 ` [PATCH v3 1/1] leds: " lgxue
2014-01-06 22:10   ` Joe Xue

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=20140101230135.48f6f781@alan.etchedpixels.co.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=cooloney@gmail.com \
    --cc=david@lang.hm \
    --cc=lgxue@hotmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=milo.kim@ti.com \
    --cc=pavel@ucw.cz \
    --cc=rob@landley.net \
    --cc=rpurdie@rpsys.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

all inboxes | Powered by JetHome®