On Sun, Jan 5, 2014 at 11:23 PM, Pavel Machek wrote:
> I implemented compiler for it (should we put it into tools/ somewhere?)
We have a precedent for putting firmware compilers into the kernel
tree:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/aic7xxx/aicasm
Hi!
> > IMHO, firstly we should take this trigger into kernel, most time it
> > works as a module. But we need to define a good interface between
> > kernel and user space.
>
> You need the interface defined first. To do that it needs to reflect the
> actual hardware accelerated devices, and also
> Also for user space application, I think we don't have any user space
> LED library, if I'm wrong please correct me. Why there is no such
> library, since we don't need it.
No - rght now it is a case of "we don't have a kernel driver because we
don't need one"
> IMHO, firstly we should take thi
On Fri, Jan 3, 2014 at 1:14 AM, Bryan Wu wrote:
> IMHO, firstly we should take this trigger into kernel, most time it
> works as a module. But we need to define a good interface between
> kernel and user space.
Put it in first place into the kernel such that it becomes ABI and
nobody is allowed
t
On Wed, Jan 1, 2014 at 3:51 PM, David Lang wrote:
> 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
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
> 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-t
On Wed, 1 Jan 2014, One Thousand Gnomes wrote:
On Tue, 31 Dec 2013 13:48:50 -0500
Joe Xue wrote:
+ * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
+ * ledtrig-heartbeat.c and Shuah Khan's ledtrig-transient.c
I stil think this belongs in user space except for platforms with
> > Why do we need this within the kernel?
> > Patterns can easily created using a simple user space program.
>
> Some machines (N900) can do blinking in hardware, and we want
> consistent kernel-user interface. See the mailing list.
We have things called "libraries", see the mailing list.
Alan
On Tue, 31 Dec 2013 13:48:50 -0500
Joe Xue wrote:
> >> + * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
> >> + * ledtrig-heartbeat.c and Shuah Khan's ledtrig-transient.c
> >
> > I stil think this belongs in user space except for platforms with hardware
> > acceleration for it.
>
On Tue 2013-12-31 13:29:21, Richard Weinberger wrote:
> On Tue, Dec 31, 2013 at 12:33 PM, Pavel Machek wrote:
> > On Tue 2013-12-31 00:00:39, Joe Xue wrote:
> >> > What about something like this?
> >> >
> >> > Not shcheduling timer when nothing changed should save a bit of
> >> > power/cpu...
> >
>> + * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
>> + * ledtrig-heartbeat.c and Shuah Khan's ledtrig-transient.c
>
> I stil think this belongs in user space except for platforms with hardware
> acceleration for it.
This can free the user space application from loop or thread.
On Tue, Dec 31, 2013 at 12:33 PM, Pavel Machek wrote:
> On Tue 2013-12-31 00:00:39, Joe Xue wrote:
>> > What about something like this?
>> >
>> > Not shcheduling timer when nothing changed should save a bit of
>> > power/cpu...
>> >
>> > if (pattern_data->pattern[pattern_data->count] == '/') {
>>
On Tue 2013-12-31 00:00:39, Joe Xue wrote:
> > What about something like this?
> >
> > Not shcheduling timer when nothing changed should save a bit of power/cpu...
> >
> > if (pattern_data->pattern[pattern_data->count] == '/') {
> > return;
> > }
> >
> > this = pattern_data->pattern[pattern_data->c
> What about something like this?
>
> Not shcheduling timer when nothing changed should save a bit of power/cpu...
>
> if (pattern_data->pattern[pattern_data->count] == '/') {
> return;
> }
>
> this = pattern_data->pattern[pattern_data->count]
> if (this == '#')
> new_brigtness = pattern_data->brig
On Mon, 30 Dec 2013 18:24:51 -0500
Joe Xue wrote:
> >> +#define MAX_PATTEN_LEN 255
> >
> > Arbitary limits that are not needed if it was in userspace, and not it
> > seems a sensible one - why not use 256 ?
>
> The maximum memory is 256, we keep one for '\0'
Why - you have pattern_len already ?
>> +#define MAX_PATTEN_LEN 255
>
> Arbitary limits that are not needed if it was in userspace, and not it
> seems a sensible one - why not use 256 ?
The maximum memory is 256, we keep one for '\0'
>> +static ssize_t pattern_delay_unit_store(struct device *dev,
>> + struct device_attribute *attr,
Hi!
> The LED pattern trigger allows LEDs blink in user defined pattern.
>
> new file: Documentation/leds/ledtrig-pattern.txt
> modified: drivers/leds/trigger/Kconfig
> modified: drivers/leds/trigger/Makefile
> new file: drivers/leds/trigger/ledtrig-pattern.c
>
>
> + * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
> + * ledtrig-heartbeat.c and Shuah Khan's ledtrig-transient.c
I stil think this belongs in user space except for platforms with hardware
acceleration for it.
> +#define MAX_PATTEN_LEN 255
Arbitary limits that are not nee
The LED pattern trigger allows LEDs blink in user defined pattern.
new file: Documentation/leds/ledtrig-pattern.txt
modified: drivers/leds/trigger/Kconfig
modified: drivers/leds/trigger/Makefile
new file: drivers/leds/trigger/ledtrig-pattern.c
Suggested-by:
20 matches
Mail list logo
