Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

[Darren Vincent Hart <darren@dvhart.com>]

On Sun, 2014-05-04 at 23:58 +0200, Rafael J. Wysocki wrote:
> > Same for pin control, where we have frameworks in the kernel on ARM,
> but
> > x86/ACPI tends to let firmware handle it all...
> 
> I would say if pin control information is made available to us by the
> firmware,
> we can use it.  If it is not, we need to live without it.

This is particularly a problem for designs intended to enable innovation
and spawn derivative products, like the MinnowBoard-Max. While we can
(and do) allow the end-user to toggle between native and GPIO modes for
functional blocks of pins, that's still more limiting than I (speaking
personally here) think it should be.

It made some sense to bury this in firmware when the board was static
and the product had no significant use case where these might need to
change.

On embedded boards though, Pinctrl (or the pins/buses it typically
controls rather) is on par with PCI and USB in terms of how the platform
is expanded to create the product. In my opinion, we will need greater
control at the OS level.

What does that mean for this discussion? The point of the ACPI spec
change is to allow for describing things not currently in the
specification without having to add that specific device type to the
spec. This can apply to pinctrl too, and we can update the
pinctrl-baytrail.c driver (for example) to make use of this new data (or
to use the default behavior if it is absent).

In order to make use of these properties, the driver would of course
need the ability to make such changes in kernel space, and it's a short
step from there to making that available more generally.

This is something I've only recently starting discussing with people.

Perhaps this is too specific an example and Olof had something more
general purpose in mind? 
 
-- 
Darren Hart
Intel Open Source Technology Center