On Wed, 1 Jan 2014, One Thousand Gnomes wrote:
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.
any high speed signalling would probably also need the kernel interface.
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.
fair enough, would it make sense to redirect the discussion to focus on what a
good interface would be for the cases where there is special hardware
assistance? Then the discussion of if the same interface could/should be used to
emulate harsdware when it isn't there can be a seprate discussion.
And while this use case the original developer had in mind was the 'I've lost my
mind' notification to a human, I think it makes sense to consider other uses for
repeating pattern toggling of GPIO ports.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
