Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754949AbaAAXwl (ORCPT ); Wed, 1 Jan 2014 18:52:41 -0500 Received: from mail.lang.hm ([64.81.33.126]:34111 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754766AbaAAXwj (ORCPT ); Wed, 1 Jan 2014 18:52:39 -0500 Date: Wed, 1 Jan 2014 15:51:32 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: One Thousand Gnomes cc: Joe Xue , "cooloney@gmail.com" , "rpurdie@rpsys.net" , "rob@landley.net" , "milo.kim@ti.com" , "pavel@ucw.cz" , "linux-leds@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: Re: [PATCH] Add LED pattern trigger In-Reply-To: <20140101230135.48f6f781@alan.etchedpixels.co.uk> Message-ID: References: <1388362275-1618-1-git-send-email-lgxue@hotmail.com> <20131230162158.7420e811@alan.etchedpixels.co.uk> <20140101201053.12be7d27@alan.etchedpixels.co.uk> <20140101230135.48f6f781@alan.etchedpixels.co.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2370 Lines: 45 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/