Celebration in the streets (aka pinmux is merged)

Celebration in the streets (aka pinmux is merged)

[Joel Stanley]

Congratulations Andrew and everyone who has helped with design,
testing and review.

This is a major component of the Aspeed SoC support that is now
complete. It allows us to configure the pads (pins) of the SoC using
the device tree and/or from other drivers, instead of looking up
registers in the datasheet and sticking values all over the place.

The driver is in the subsystem tree and on it's way to appear in Linux 4.9.

Cheers,

Joel


---------- Forwarded message ----------
From: Linus Walleij <linus.walleij@linaro.org>
Date: Thu, Sep 8, 2016 at 12:20 AM
Subject: Re: [PATCH v3 5/8] pinctrl: Add core support for Aspeed SoCs
To: Andrew Jeffery <andrew@aj.id.au>
Cc: Joel Stanley <joel@jms.id.au>, Alexandre Courbot
<gnurou@gmail.com>, Mark Rutland <mark.rutland@arm.com>, Rob Herring
<robh+dt@kernel.org>, Benjamin Herrenschmidt
<benh@kernel.crashing.org>, Jeremy Kerr <jk@ozlabs.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>


On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery <andrew@aj.id.au> wrote:

> The Aspeed SoCs typically provide more than 200 pins for GPIO and other
> functions. The signal enabled on a pin is determined on a priority
> basis, where a given pin can provide a number of different signal types.
>
> In addition to the priority levels, the Aspeed pin controllers describe
> the signal active on a pin by compound logical expressions involving
> multiple operators, registers and bits. Some difficulty arises as a
> pin's function bit masks for each priority level are frequently not the
> same (i.e. we cannot just flip a bit to change from a high to low
> priority signal), or even in the same register(s). Some configuration
> bits affect multiple pins, while in other cases the signals for a bus
> must each be enabled individually.
>
> Together, these features give rise to some complexity in the
> implementation. A more complete description of the complexities is
> provided in the associated header file.
>
> The patch doesn't implement pinctrl/pinmux/pinconf for any particular
> Aspeed SoC, rather it adds the framework for defining pinmux
> configurations.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Reviewed-by: Joel Stanley <joel@jms.id.au>

Patch applied! It's not getting better than this through iteration, it is better
to get the system up and develop inside the mainline tree from now on.

Re: Celebration in the streets (aka pinmux is merged)

[Benjamin Herrenschmidt]

On Thu, 2016-09-08 at 14:54 +0930, Joel Stanley wrote:
> Congratulations Andrew and everyone who has helped with design,
> testing and review.
> 
> This is a major component of the Aspeed SoC support that is now
> complete. It allows us to configure the pads (pins) of the SoC using
> the device tree and/or from other drivers, instead of looking up
> registers in the datasheet and sticking values all over the place.
> 
> The driver is in the subsystem tree and on it's way to appear in
> Linux 4.9.

Congratulations guys ! This was probably the single most challenging
kernel component of the stack !

Beers on me next time you're in town :-)

Ben.

> Cheers,
> 
> Joel
> 
> 
> ---------- Forwarded message ----------
> From: Linus Walleij <linus.walleij@linaro.org>
> Date: Thu, Sep 8, 2016 at 12:20 AM
> Subject: Re: [PATCH v3 5/8] pinctrl: Add core support for Aspeed SoCs
> To: Andrew Jeffery <andrew@aj.id.au>
> Cc: Joel Stanley <joel@jms.id.au>, Alexandre Courbot
> <gnurou@gmail.com>, Mark Rutland <mark.rutland@arm.com>, Rob Herring
> <robh+dt@kernel.org>, Benjamin Herrenschmidt
> <benh@kernel.crashing.org>, Jeremy Kerr <jk@ozlabs.org>,
> "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
> "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
> "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
> 
> 
> On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery <andrew@aj.id.au>
> wrote:
> 
> > 
> > The Aspeed SoCs typically provide more than 200 pins for GPIO and
> > other
> > functions. The signal enabled on a pin is determined on a priority
> > basis, where a given pin can provide a number of different signal
> > types.
> > 
> > In addition to the priority levels, the Aspeed pin controllers
> > describe
> > the signal active on a pin by compound logical expressions
> > involving
> > multiple operators, registers and bits. Some difficulty arises as a
> > pin's function bit masks for each priority level are frequently not
> > the
> > same (i.e. we cannot just flip a bit to change from a high to low
> > priority signal), or even in the same register(s). Some
> > configuration
> > bits affect multiple pins, while in other cases the signals for a
> > bus
> > must each be enabled individually.
> > 
> > Together, these features give rise to some complexity in the
> > implementation. A more complete description of the complexities is
> > provided in the associated header file.
> > 
> > The patch doesn't implement pinctrl/pinmux/pinconf for any
> > particular
> > Aspeed SoC, rather it adds the framework for defining pinmux
> > configurations.
> > 
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > Reviewed-by: Joel Stanley <joel@jms.id.au>
> 
> Patch applied! It's not getting better than this through iteration,
> it is better
> to get the system up and develop inside the mainline tree from now
> on.

Re: Celebration in the streets (aka pinmux is merged)

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]

On Thu, 2016-09-08 at 16:11 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2016-09-08 at 14:54 +0930, Joel Stanley wrote:
> > 
> > Congratulations Andrew and everyone who has helped with design,
> > testing and review.
> > 
> > This is a major component of the Aspeed SoC support that is now
> > complete. It allows us to configure the pads (pins) of the SoC using
> > the device tree and/or from other drivers, instead of looking up
> > registers in the datasheet and sticking values all over the place.
> > 
> > The driver is in the subsystem tree and on it's way to appear in
> > Linux 4.9.
> Congratulations guys ! This was probably the single most challenging
> kernel component of the stack !

I think this taught me a valuable lesson about volunteering for random
work...

> 
> Beers on me next time you're in town :-)

I'll take you up on that! Does Canberra have enough beer? :D

Andrew

> 
> Ben.
> 
> > 
> > Cheers,
> > 
> > Joel
> > 
> > 
> > ---------- Forwarded message ----------
> > From: Linus Walleij <linus.walleij@linaro.org>
> > Date: Thu, Sep 8, 2016 at 12:20 AM
> > Subject: Re: [PATCH v3 5/8] pinctrl: Add core support for Aspeed SoCs
> > To: Andrew Jeffery <andrew@aj.id.au>
> > Cc: Joel Stanley <joel@jms.id.au>, Alexandre Courbot
> > <gnurou@gmail.com>, Mark Rutland <mark.rutland@arm.com>, Rob Herring
> > <robh+dt@kernel.org>, Benjamin Herrenschmidt
> > <benh@kernel.crashing.org>, Jeremy Kerr <jk@ozlabs.org>,
> > "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
> > "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
> > "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
> > 
> > 
> > On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery <andrew@aj.id.au>
> > wrote:
> > 
> > > 
> > > 
> > > The Aspeed SoCs typically provide more than 200 pins for GPIO and
> > > other
> > > functions. The signal enabled on a pin is determined on a priority
> > > basis, where a given pin can provide a number of different signal
> > > types.
> > > 
> > > In addition to the priority levels, the Aspeed pin controllers
> > > describe
> > > the signal active on a pin by compound logical expressions
> > > involving
> > > multiple operators, registers and bits. Some difficulty arises as a
> > > pin's function bit masks for each priority level are frequently not
> > > the
> > > same (i.e. we cannot just flip a bit to change from a high to low
> > > priority signal), or even in the same register(s). Some
> > > configuration
> > > bits affect multiple pins, while in other cases the signals for a
> > > bus
> > > must each be enabled individually.
> > > 
> > > Together, these features give rise to some complexity in the
> > > implementation. A more complete description of the complexities is
> > > provided in the associated header file.
> > > 
> > > The patch doesn't implement pinctrl/pinmux/pinconf for any
> > > particular
> > > Aspeed SoC, rather it adds the framework for defining pinmux
> > > configurations.
> > > 
> > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > > Reviewed-by: Joel Stanley <joel@jms.id.au>
> > Patch applied! It's not getting better than this through iteration,
> > it is better
> > to get the system up and develop inside the mainline tree from now
> > on.
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]