Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1371119 > unrolled thread

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration Mark Brown <broonie@kernel.org> - 2016-04-05 04:30 +0200
    Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration Linus Walleij <linus.walleij@linaro.org> - 2016-04-05 11:10 +0200
      Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration Mark Brown <broonie@kernel.org> - 2016-04-05 18:20 +0200
    Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration Octavian Purdila <octavian.purdila@intel.com> - 2016-04-05 15:00 +0200
      Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration Mark Brown <broonie@kernel.org> - 2016-04-05 19:40 +0200

#1371119 — Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

[Multipart message — attachments visible in raw view] — view raw

On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:

> This is a proposal for adding ACPI support for pin controller
> configuration.

> It has been developed to enable the MinnowBoard and IoT community
> by providing an easy way to specify pin multiplexing and
> pin configuration.

So this is mainly targeted at modules being added to base boards?
Without getting into the binding at all here it seems like this is not
solving the problem at the right abstraction level.  It's exposing the
pins on the SoC directly without any tie in with the functionality that
goes over those pins.  This means that any binding of a board to an ACPI
using system that just uses this is going to be entirely specific to the
particular combination of base and expansion board even if the
electrical connections are standard.

This is something that people are currently looking at for DT, there the
discussion has been about defining the connectors as entities and hiding
the details of the muxing on the SoC behind that along with higher level
concepts like instantiation of buses like I2C and SPI.  It seems like if
we do want to try to share between DT and ACPI we should be doing it at
that level rather than dealing with pinmuxing at the extremely low level
that pinctrl does.

Obviously for the more general ACPI use case the idiomatic way of
handling this is that the OS should never see anything about the
pin muxing.  With DT we need to really know what's going on with the
pinbox because the model is that even for things built into a single
board the OS is responsible for managing the pins but that's really not
how ACPI is expected to work.

[toc] | [next] | [standalone]

#1371334

On Mon, Apr 4, 2016 at 11:40 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>
>> This is a proposal for adding ACPI support for pin controller
>> configuration.
>
>> It has been developed to enable the MinnowBoard and IoT community
>> by providing an easy way to specify pin multiplexing and
>> pin configuration.
>
> So this is mainly targeted at modules being added to base boards?
> Without getting into the binding at all here it seems like this is not
> solving the problem at the right abstraction level.  It's exposing the
> pins on the SoC directly without any tie in with the functionality that
> goes over those pins.  This means that any binding of a board to an ACPI
> using system that just uses this is going to be entirely specific to the
> particular combination of base and expansion board even if the
> electrical connections are standard.

I have seen the same need beyond strictly embedded (MinnowBoard)
from the Intel camp.

These chips with funny Atom-specific codenames (baytrail, cherryview,
broxton, sunrisepoint etc) are not just used for these IoT use cases
but also for e.g. laptops of the ChromeBook form factor, and the same
pin control needs arise there, just at a different cadence related to
product cycle.

I bet they also have funny product-specific kernel trees :(

> This is something that people are currently looking at for DT, there the
> discussion has been about defining the connectors as entities and hiding
> the details of the muxing on the SoC behind that along with higher level
> concepts like instantiation of buses like I2C and SPI.  It seems like if
> we do want to try to share between DT and ACPI we should be doing it at
> that level rather than dealing with pinmuxing at the extremely low level
> that pinctrl does.

Agree: work is needed here. It is a big confusion, the whole model is
based around the configuration being pretty static as I recently
realized when just wanting to add a runtime-detected LCD panel
to a certain driver. No runtime patching of the DT or overlays or any
of the sort deliver what is really needed.

The only thing I heard which was actually doing something sensible
was when Matthew Garret once told that apple mice provide a
device tree fragment to the OS on how to handle it during bus
discovery.

I think that for random complex hotpluggable devices like what
greybus is trying to achieve this is needed too, despite the standard
USB-like device classes in all their glory.

> Obviously for the more general ACPI use case the idiomatic way of
> handling this is that the OS should never see anything about the
> pin muxing.  With DT we need to really know what's going on with the
> pinbox because the model is that even for things built into a single
> board the OS is responsible for managing the pins but that's really not
> how ACPI is expected to work.

See my previous mail for some kind of answer to this.

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1371762

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 05, 2016 at 11:00:50AM +0200, Linus Walleij wrote:
> On Mon, Apr 4, 2016 at 11:40 PM, Mark Brown <broonie@kernel.org> wrote:

> > So this is mainly targeted at modules being added to base boards?
> > Without getting into the binding at all here it seems like this is not
> > solving the problem at the right abstraction level.  It's exposing the

> I have seen the same need beyond strictly embedded (MinnowBoard)
> from the Intel camp.

> These chips with funny Atom-specific codenames (baytrail, cherryview,
> broxton, sunrisepoint etc) are not just used for these IoT use cases
> but also for e.g. laptops of the ChromeBook form factor, and the same
> pin control needs arise there, just at a different cadence related to
> product cycle.

Right, the chips are used in a broader space but in cases where they're
being used in fixed systems where we don't have to deal with repaceable
modules then the idiomatic thing for ACPI is to hide all the pinmuxing
from the operating system.

> I bet they also have funny product-specific kernel trees :(

Yup, they do.

> Agree: work is needed here. It is a big confusion, the whole model is
> based around the configuration being pretty static as I recently
> realized when just wanting to add a runtime-detected LCD panel
> to a certain driver. No runtime patching of the DT or overlays or any
> of the sort deliver what is really needed.

Yes, funnily enough the CHIP people were just talking about that
specific case at ELC yesterday (they patched u-boot to parse overlays
so the kernel never sees the hotplug).

> The only thing I heard which was actually doing something sensible
> was when Matthew Garret once told that apple mice provide a
> device tree fragment to the OS on how to handle it during bus
> discovery.

That's what people are doing with the BeagleBone/RPi/CHIP/96boards case
- it's one of the primary usecases for DT overlays but currently
everyone's final integration layer is out of tree.

> > Obviously for the more general ACPI use case the idiomatic way of
> > handling this is that the OS should never see anything about the
> > pin muxing.  With DT we need to really know what's going on with the
> > pinbox because the model is that even for things built into a single
> > board the OS is responsible for managing the pins but that's really not
> > how ACPI is expected to work.

> See my previous mail for some kind of answer to this.

Yup, will reply there.

[toc] | [prev] | [next] | [standalone]

#1371546

On Tue, Apr 5, 2016 at 12:40 AM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>
>> This is a proposal for adding ACPI support for pin controller
>> configuration.
>
>> It has been developed to enable the MinnowBoard and IoT community
>> by providing an easy way to specify pin multiplexing and
>> pin configuration.
>
> So this is mainly targeted at modules being added to base boards?

That is the main use case, yes. Velocity of platform
debugging/enabling is another one.

> Without getting into the binding at all here it seems like this is not
> solving the problem at the right abstraction level.  It's exposing the
> pins on the SoC directly without any tie in with the functionality that
> goes over those pins.

This is not completely true. The pinctrl drivers are exposing
functionality in terms of function groups (e.g., i2c1_grp, spi1_grp,
pwm1_grp, etc.) It is not enough, but it is a step in the right
direction for standard bindings and for tools that can build on top of
this.

>  This means that any binding of a board to an ACPI
> using system that just uses this is going to be entirely specific to the
> particular combination of base and expansion board even if the
> electrical connections are standard.
>

This can be solved by tools that work with high level abstractions and
generate this specific information.

> This is something that people are currently looking at for DT, there the
> discussion has been about defining the connectors as entities and hiding
> the details of the muxing on the SoC behind that along with higher level
> concepts like instantiation of buses like I2C and SPI.  It seems like if
> we do want to try to share between DT and ACPI we should be doing it at
> that level rather than dealing with pinmuxing at the extremely low level
> that pinctrl does.
>

At some point we still need to poke registers. We already have a
drivers that do this (pinctrl) and a standard configuration interface
(the pinctrl device tree bindings). It seems natural to build on top
of this for those higher level concepts / tools.

> Obviously for the more general ACPI use case the idiomatic way of
> handling this is that the OS should never see anything about the
> pin muxing. With DT we need to really know what's going on with the
> pinbox because the model is that even for things built into a single
> board the OS is responsible for managing the pins but that's really not
> how ACPI is expected to work.

Maybe. But we already expose pin control / muxing in
drivers/pinctrl/intel, yes, read-only at this point. Very useful for
debugging. Having write access would make debugging even more useful,
not to mention fast prototyping.

[toc] | [prev] | [next] | [standalone]

#1371824

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 05, 2016 at 03:51:18PM +0300, Octavian Purdila wrote:
> On Tue, Apr 5, 2016 at 12:40 AM, Mark Brown <broonie@kernel.org> wrote:

> > So this is mainly targeted at modules being added to base boards?

> That is the main use case, yes. Velocity of platform
> debugging/enabling is another one.

The speed thing sounds like someone needs to work on the tooling for
working on firmware TBH.

> >  This means that any binding of a board to an ACPI
> > using system that just uses this is going to be entirely specific to the
> > particular combination of base and expansion board even if the
> > electrical connections are standard.

> This can be solved by tools that work with high level abstractions and
> generate this specific information.

Simply stating that there are in future going to be some higher level
things which make use of this firmware interface isn't altogether
reassuring when we're still in the process of solving the issues for the
DT version of this...

> > This is something that people are currently looking at for DT, there the
> > discussion has been about defining the connectors as entities and hiding
> > the details of the muxing on the SoC behind that along with higher level
> > concepts like instantiation of buses like I2C and SPI.  It seems like if
> > we do want to try to share between DT and ACPI we should be doing it at
> > that level rather than dealing with pinmuxing at the extremely low level
> > that pinctrl does.

> At some point we still need to poke registers. We already have a
> drivers that do this (pinctrl) and a standard configuration interface
> (the pinctrl device tree bindings). It seems natural to build on top
> of this for those higher level concepts / tools.

Both DT and ACPI have a system model behind them and they're not the
stame system model.  Importing one into the other directly without
carefully thinking through how they play nicely with each other seems
likely to lead to problems further down the line, you might know exactly
how you intend this to work but how do we make sure that a firmware
author in some system integrator knows about this and is able to safely
write firmware in a few years?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web