Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752101AbaAEWXw (ORCPT ); Sun, 5 Jan 2014 17:23:52 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:33401 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751935AbaAEWXs (ORCPT ); Sun, 5 Jan 2014 17:23:48 -0500 Date: Sun, 5 Jan 2014 23:23:46 +0100 From: Pavel Machek To: One Thousand Gnomes , pali.rohar@gmail.com, sre@ring0.de, milo.kim@ti.com, linus.walleij@linaro.org Cc: Bryan Wu , David Lang , Joe Xue , "rpurdie@rpsys.net" , "rob@landley.net" , "milo.kim@ti.com" , "linux-leds@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: n900 led compiler (was Re: [PATCH] Add LED pattern trigger) Message-ID: <20140105222346.GA25152@amd.pavel.ucw.cz> 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> <20140103152313.4fd5c48f@alan.etchedpixels.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140103152313.4fd5c48f@alan.etchedpixels.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 to deal with resource > management for those devices if necessary (eg if they can only manage one > led of a set at a time). Hardware can do quite a lot: http://wiki.maemo.org/LED_patterns#Lysti_Format_Engine_Patterns_and_Commands (and more). I implemented compiler for it (should we put it into tools/ somewhere?) https://gitorious.org/tui/tui/source/5b3f5cacf8e208d3ea50d6066e549940d85e55be:maemo/notcc.py It can do quite a lot, including prime number computation. This uses 33% of program memory and only one of three execution units; but it does not work, maybe I made mistake somewhere or maybe our kernel can't take program this long. It only has 3 writable variables, which is quite limiting. start() a = 1 next_number: a += 1 b = 1 next_divisor: b += 1 br = b if (b==a) goto is_prime c = 0 c = c+b test_prime: if (c==a) goto not_prime if (a So the starting point has to be the hardware accelerated devices, whether > you then support software emulation in kernel or user space is a follow > on discussion. What the kernel/user API is also has to be a follow on Well... this one is turing complete, and I have a compiler, but I don't think it is good interface, either for library or kernel. I believe series of RGB values might be good interface, maybe with additional "want interpolation between these". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/