Re: [PATCH 6/8] minnowboard-keys: Bind MinnowBoard buttons to arrowkeys

[Darren Hart]

On Wed, 2013-06-26 at 21:57 +0200, Linus Walleij wrote:
> On Wed, Jun 26, 2013 at 7:23 PM, Darren Hart <dvhart@xxxxxxxxxxxxxxx> wrote:
> > On Wed, 2013-06-26 at 10:16 -0700, Greg Kroah-Hartman wrote:
> >> On Wed, Jun 26, 2013 at 09:28:07AM -0700, Darren Hart wrote:
> 
> >> > The reason this is separate is that I
> >> > can easily see someone wanting to use these buttons in a different way
> >> > when integrating the MinnowBoard into some kind of product. The
> >> > minnowboard.c driver sets up the fixed functionality GPIO lines, such as
> >> > the LEDs (which can be easily reconfigured via triggers) while this
> >> > driver serves as an example of how the GPIO buttons could be used as
> >> > keys, but if included in the minnowboard driver, users couldn't get the
> >> > fixed functionality without also tying up these GPIO lines.
> >> >
> >> > I could remedy that with driver command-line options, but I know I've
> >> > heard Greg KH discourage their use in the past.
> >>
> >> Ick, yes, never do that type of thing as a command-line option, that's
> >> what device-tree is for :)
> >
> > I suppose when I convert to ACPI drivers I could merge them and have the
> > ACPI table include some data that enabled or disabled things like the
> > minnowboard-keys.... but that seems like more work for the user than it
> > should be to disable the example keys driver.
> 
> So now you make it sound that devicetree is somehow really superior
> to ACPI because it can actually be used to do some board-specific
> configs, and ACPI tables are too hard to use?
> 
> Device tree was what we came up with for ARM go get *away* from
> stashing custom config into the kernel, such as boardfiles and even
> more horrible things like a command-line switch for every key.
> 
> Is x86 now not really presenting anything better? I would have a second
> look at augmented ACPI tables, if that is what all of x86 is going to use.
> 
> FYI here is how I set up a heartbeat LED and some GPIO key in a
> device tree:
> 
>         /* The user LED on the board is set up to be used for heartbeat */
>         leds {
>                 compatible = "gpio-leds";
>                 user-led {
>                         label = "user_led";
>                         gpios = <&gpio0 2 0x1>;
>                         default-state = "off";
>                         linux,default-trigger = "heartbeat";
>                 };
>         };

This is something we should be able to do with ACPI 5 and SSDTs.

>         /* User key mapped in as "escape" */
>         gpio-keys {
>                 compatible = "gpio-keys";
>                 user-button {
>                         label = "user_button";
>                         gpios = <&gpio0 3 0x1>;
>                         linux,code = <1>; /* KEY_ESC */
>                         gpio-key,wakeup;
>                 };
>         };

And this too actually. I was thinking along the lines of the tables in
the firmware, but using SSDTs passed in (optionally) at boot, the user
can easily decide not to use the buttons with gpio-keys simply by not
passing in that SSDT. This had been the direction we were going with the
Lures (daughter cards), but we can also apply this to the board itself
as a way to provide a proper example of how to do this.

So the answer seems to be to put any fixed functionality into the board
firmware ACPI tables and leave the optional experimenter config to SSDTs
which the user can choose to use or not.

The rest of what minnowboard.c does (LVDS/GPIO setup) can (and should)
be done in the firmware directly, also eliminating the need for the 3/8
(sch_gpio_resume_set_enable()).

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/