Re: [PATCH v2 0/2] pinctrl: Intel Cherryview/Braswell support

[Grant Likely]

On Wed, Nov 5, 2014 at 10:15 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> On Wednesday, November 05, 2014 09:46:14 PM Grant Likely wrote:
>> On Tue, Nov 4, 2014 at 5:54 PM, Timur Tabi <timur@xxxxxxxxxxxxxx> wrote:
>> > On 11/04/2014 02:20 AM, Mika Westerberg wrote:
>> >>
>> >> There is nothing like that yet in ACPI world but with the ACPI _DSD
>> >> patches we are getting properties similar to DT which means that we can
>> >> provide pinctrl bindings from ACPI systems as well.
>> >
>> >
>> > Do you know if anyone has signed up to actually do the work of defining how
>> > pinctrl will look in ACPI?  I'm guessing the simplest approach would be to:
>>
>> Actually, for the most part we /don't/ want to try and put pinctrl
>> into an ACPI binding. The assumption is that on an ACPI platform it
>> would be the combination of ACPI and firmware responsible for the pin
>> mappings, not the operating system.
>>
>> Before even attempting to put pinctrl mappings into your driver, there
>> should instead be a conversation at the ACPI spec level about whether
>> or not it makes sense and what such a binding should look like.
>
> We may need to support pinctrl on ACPI platforms in the meantime, though,
> for reasons that Mika mentioned at one point (there are systems where the
> firmware mangles things etc., which quite frankly is to be expected).
>
> So while I'm all for discussing this in the ASWG, what's the interim approach
> we should be using, in your opinion?

Context would be useful at this point. I know (well, I /strongly/
suspect) that Timur is working on ARM server support, where as most of
the work you, Darren and Mika are doing is focused on getting into
embedded.

The reason I'm pushing for a pinctrl discussion at the ASWG level is
because it affects OS portability. The OS should not not be required
to have a driver for the pinctrl hardware in order to boot into a
usable state (at least far enough to obtain further drivers). The same
goes for clock controllers and power regulators. In x86 world this is
the default assumption, but in the ARM world it needs to be
re-enforced over and over to break out of the embedded mindset that a
lot of us have.

So, to answer your question, what's the interim approach? I think it
is two things:
1) The base assumption must be that firmware sets up the pinctrl
hardware into a usable state at boot and ACPI is used to adjust it as
part of the normal OSPM runtime PM operations on devices.

2) Where direct control over the pinctrl hardware is required by the
OS, build it into the GPIO driver functionality (which from what I
understand is exactly what Mika has done). If any data for the pinctrl
is required from ACPI, it can be driver specific data, but any attempt
to create a generic binding that the OS is expected to understand
should be avoided. This is so we don't end up with the OS needing to
understand more than is in the ACPI spec in order to boot.

For a more generic solution (building into OSPM the understanding of
pin groups and how to control them when power managing devices), there
needs to be work at the ASWG level to figure out what it is going to
look like.

g.

>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/