Date: Wed, 7 May 2014 10:46:31 -0400 From: Larry Baird <lab@gta.com> To: Ermal Lu??i <eri@freebsd.org> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org>, Jim Thompson <jim@netgate.com> Subject: Re: apu1c led driver Message-ID: <20140507144631.GA24565@gta.com> In-Reply-To: <CAPBZQG3v4WTxnuW8xMpRJyK0HD9GcZe0dw_xi61AXnC6PygFtg@mail.gmail.com> References: <20140422020109.GA57760@gta.com> <69BC3E8E-A5D1-4CAD-96A0-9139FFBD8AA3@netgate.com> <CAPBZQG3v4WTxnuW8xMpRJyK0HD9GcZe0dw_xi61AXnC6PygFtg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 07, 2014 at 10:19:39AM +0200, Ermal Lu??i wrote:
> Hello,
>
> find attached the driver as written today.
> It needs some reshaping to be integrate with led(4) and gpio(4).
>
> I will see to have the reshaping done and submit it for inclusion.
> The idea as it is today is that it expses an gpioapu device to which you
> can write a string with 3 digits "101" for each led.
> If you read from this device you just get the status of the switch on the
> APU.
I was about to submit a version of my own. Instead I will take some
code from my verison and add it to yours. I attached a modified version that
uses the led(4) framework to create:
/dev/led/led1, /dev/led/led2, and /dev/led/led3.
I am curious about the gpioapu_close() function. what is it attempting
to do? My first thought was it was tring to put the leds back to a know
state. But it is writing to the mode switch?
Larry
--
------------------------------------------------------------------------
Larry Baird
Global Technology Associates, Inc. 1992-2012 | http://www.gta.com
Celebrating Twenty Years of Software Innovation | Orlando, FL
Email: lab@gta.com | TEL 407-380-0220
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140507144631.GA24565>