Re: [PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Rob Herring]

On Wed, Apr 05, 2017 at 11:07:57AM +0100, Richard Fitzgerald wrote:
> These codecs have a variable number of I/O lines each of which
> is individually selectable to a wide range of possible functions.
> 
> The functionality is slightly different from the traditional muxed
> GPIO since most of the functions can be mapped to any pin (and even
> the same function to multiple pins). Most pins have a dedicated
> "alternate" function that is only available on that pin. The
> alternate functions are usually a group of signals, though it is
> not always necessary to enable the full group, depending on the
> alternate function and how it is to be used. The mapping between
> alternate functions and GPIO pins varies between codecs depending
> on the number of alternate functions and available pins.
> 
> Signed-off-by: Richard Fitzgerald 
> ---
>  .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++

As Linus said, separate patch is preferred. But I don't have any other 
comments, so I'm not going to require it:

Acked-by: Rob Herring 

>  MAINTAINERS|2 +
>  drivers/pinctrl/Kconfig|   22 +
>  drivers/pinctrl/Makefile   |1 +
>  drivers/pinctrl/pinctrl-madera.c   | 1092 
> 
>  5 files changed, 1220 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
>  create mode 100644 drivers/pinctrl/pinctrl-madera.c

Re: [PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Rob Herring]

On Wed, Apr 05, 2017 at 11:07:57AM +0100, Richard Fitzgerald wrote:
> These codecs have a variable number of I/O lines each of which
> is individually selectable to a wide range of possible functions.
> 
> The functionality is slightly different from the traditional muxed
> GPIO since most of the functions can be mapped to any pin (and even
> the same function to multiple pins). Most pins have a dedicated
> "alternate" function that is only available on that pin. The
> alternate functions are usually a group of signals, though it is
> not always necessary to enable the full group, depending on the
> alternate function and how it is to be used. The mapping between
> alternate functions and GPIO pins varies between codecs depending
> on the number of alternate functions and available pins.
> 
> Signed-off-by: Richard Fitzgerald 
> ---
>  .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++

As Linus said, separate patch is preferred. But I don't have any other 
comments, so I'm not going to require it:

Acked-by: Rob Herring 

>  MAINTAINERS|2 +
>  drivers/pinctrl/Kconfig|   22 +
>  drivers/pinctrl/Makefile   |1 +
>  drivers/pinctrl/pinctrl-madera.c   | 1092 
> 
>  5 files changed, 1220 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
>  create mode 100644 drivers/pinctrl/pinctrl-madera.c

Re: [PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Richard Fitzgerald]

On Fri, 2017-04-07 at 10:54 +0200, Linus Walleij wrote:
> On Wed, Apr 5, 2017 at 12:07 PM, Richard Fitzgerald
>  wrote:
> 
> > These codecs have a variable number of I/O lines each of which
> > is individually selectable to a wide range of possible functions.
> >
> > The functionality is slightly different from the traditional muxed
> > GPIO since most of the functions can be mapped to any pin (and even
> > the same function to multiple pins). Most pins have a dedicated
> > "alternate" function that is only available on that pin. The
> > alternate functions are usually a group of signals, though it is
> > not always necessary to enable the full group, depending on the
> > alternate function and how it is to be used. The mapping between
> > alternate functions and GPIO pins varies between codecs depending
> > on the number of alternate functions and available pins.
> >
> > Signed-off-by: Richard Fitzgerald 
> 
> >  .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++
> 
> This should ideally be split into its own patch but I don't care
> much if the DT people are happy.
> 
> > +See also
> > +  the core bindings for the parent MFD driver:
> > +Documentation/devicetree/bindings/mfd/madera.txt
> > +
> > +  the generic pinmix bindings:
> > +Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> 
> Nice.
> 
> > +Required properties of parent mfd node:
> > +  - pinctrl-names : must be "defaults"
> 
> Do you mean "default"

Yes. I'll fix that.

> 
> Apart from this the bindings and example look very good to
> me, good job! I like it when people "just get it" with pin control
> and that is where we need to be with this subsystem.
> 
> > +config PINCTRL_MADERA
> > +   bool
> > +   default y if MFD_MADERA=y
> 

There was something special to do with the way dependencies are
processed, but I can't remember right now what that was. I'd have to
take another look at this to see if this "default y" pattern is still
necessary for this driver.

> Isn't it even proper for MFD_MADERA to explicitly
> select this driver. I see it hard how the chip would even
> work without this. (Maybe it already does select it but then
> default y is not necessary.)
> > +config PINCTRL_CS47L35
> > +   bool
> > +   default y if MFD_CS47L35=y
> 
> Similar comment for the subdrivers.
> 
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
> >  obj-$(CONFIG_PINCTRL_DA850_PUPD) += pinctrl-da850-pupd.o
> >  obj-$(CONFIG_PINCTRL_DIGICOLOR)+= pinctrl-digicolor.o
> >  obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
> > +obj-$(CONFIG_PINCTRL_MADERA)   += pinctrl-madera.o
> 
> Is it all in one file... despite all the Kconfig symbols... hm.
> I guess we can create drivers/pinctrl/cirrus the day we need more
> space.
> 

I have no objection to moving the source into pinctrl/cirrus

> > +/*
> > + * Pins are named after their GPIO number
> 
> So don't they have real names? Like the pin name on the underside of
> the chip? That is what this naming convention is actually for.
> 

Those are real names. Each pin is dual labelled with a "GPIOn" name and
also its alternate function (if it has one). The mapping of alternate
functions to GPIO pins isn't 1:1 across codecs. The GPIOn name is
consistent across codecs. If your pinctrl config is needing to refer to
the pin name, instead of the alternate function group, it can only be to
use it as a GPIO so the GPIO name is more relevant. This is what I was
trying to imply in my comment but using fewer words.

> > +/*
> > + * All single-pin functions can be mapped to any GPIO, however pinmux 
> > applies
> > + * functions to pin groups and only those groups declared as supporting 
> > that
> > + * function. To make this work we must put each pin in its own dummy group 
> > so
> > + * that the functions can be described as applying to all pins.
> > + * Since these do not correspond to anything in the actual hardware - they 
> > are
> > + * merely an adaptation to pinctrl's view of the world - we use the same 
> > name
> > + * as the pin to avoid confusion when comparing with datasheet instructions
> > + */
> > +static const char * const madera_pin_single_group_names[] = {
> > +   "gpio1",  "gpio2",  "gpio3",  "gpio4",  "gpio5",  "gpio6",  "gpio7",
> > +   "gpio8",  "gpio9",  "gpio10", "gpio11", "gpio12", "gpio13", 
> > "gpio14",
> > +   "gpio15", "gpio16", "gpio17", "gpio18", "gpio19", "gpio20", 
> > "gpio21",
> > +   "gpio22", "gpio23", "gpio24", "gpio25", "gpio26", "gpio27", 
> > "gpio28",
> > +   "gpio29", "gpio30", "gpio31", "gpio32", "gpio33", "gpio34", 
> > "gpio35",
> > +   "gpio36", "gpio37", "gpio38", "gpio39", "gpio40",
> > +};
> 
> If they are called "gpioN" in the datasheet I guess it is all right.
> That is how e.g. the Qualcomm driver is done.
> 
> > +#ifdef CONFIG_PINCTRL_CS47L85
> 
> So this makes me feel maybe we should create 

Re: [PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Richard Fitzgerald]

On Fri, 2017-04-07 at 10:54 +0200, Linus Walleij wrote:
> On Wed, Apr 5, 2017 at 12:07 PM, Richard Fitzgerald
>  wrote:
> 
> > These codecs have a variable number of I/O lines each of which
> > is individually selectable to a wide range of possible functions.
> >
> > The functionality is slightly different from the traditional muxed
> > GPIO since most of the functions can be mapped to any pin (and even
> > the same function to multiple pins). Most pins have a dedicated
> > "alternate" function that is only available on that pin. The
> > alternate functions are usually a group of signals, though it is
> > not always necessary to enable the full group, depending on the
> > alternate function and how it is to be used. The mapping between
> > alternate functions and GPIO pins varies between codecs depending
> > on the number of alternate functions and available pins.
> >
> > Signed-off-by: Richard Fitzgerald 
> 
> >  .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++
> 
> This should ideally be split into its own patch but I don't care
> much if the DT people are happy.
> 
> > +See also
> > +  the core bindings for the parent MFD driver:
> > +Documentation/devicetree/bindings/mfd/madera.txt
> > +
> > +  the generic pinmix bindings:
> > +Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> 
> Nice.
> 
> > +Required properties of parent mfd node:
> > +  - pinctrl-names : must be "defaults"
> 
> Do you mean "default"

Yes. I'll fix that.

> 
> Apart from this the bindings and example look very good to
> me, good job! I like it when people "just get it" with pin control
> and that is where we need to be with this subsystem.
> 
> > +config PINCTRL_MADERA
> > +   bool
> > +   default y if MFD_MADERA=y
> 

There was something special to do with the way dependencies are
processed, but I can't remember right now what that was. I'd have to
take another look at this to see if this "default y" pattern is still
necessary for this driver.

> Isn't it even proper for MFD_MADERA to explicitly
> select this driver. I see it hard how the chip would even
> work without this. (Maybe it already does select it but then
> default y is not necessary.)
> > +config PINCTRL_CS47L35
> > +   bool
> > +   default y if MFD_CS47L35=y
> 
> Similar comment for the subdrivers.
> 
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
> >  obj-$(CONFIG_PINCTRL_DA850_PUPD) += pinctrl-da850-pupd.o
> >  obj-$(CONFIG_PINCTRL_DIGICOLOR)+= pinctrl-digicolor.o
> >  obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
> > +obj-$(CONFIG_PINCTRL_MADERA)   += pinctrl-madera.o
> 
> Is it all in one file... despite all the Kconfig symbols... hm.
> I guess we can create drivers/pinctrl/cirrus the day we need more
> space.
> 

I have no objection to moving the source into pinctrl/cirrus

> > +/*
> > + * Pins are named after their GPIO number
> 
> So don't they have real names? Like the pin name on the underside of
> the chip? That is what this naming convention is actually for.
> 

Those are real names. Each pin is dual labelled with a "GPIOn" name and
also its alternate function (if it has one). The mapping of alternate
functions to GPIO pins isn't 1:1 across codecs. The GPIOn name is
consistent across codecs. If your pinctrl config is needing to refer to
the pin name, instead of the alternate function group, it can only be to
use it as a GPIO so the GPIO name is more relevant. This is what I was
trying to imply in my comment but using fewer words.

> > +/*
> > + * All single-pin functions can be mapped to any GPIO, however pinmux 
> > applies
> > + * functions to pin groups and only those groups declared as supporting 
> > that
> > + * function. To make this work we must put each pin in its own dummy group 
> > so
> > + * that the functions can be described as applying to all pins.
> > + * Since these do not correspond to anything in the actual hardware - they 
> > are
> > + * merely an adaptation to pinctrl's view of the world - we use the same 
> > name
> > + * as the pin to avoid confusion when comparing with datasheet instructions
> > + */
> > +static const char * const madera_pin_single_group_names[] = {
> > +   "gpio1",  "gpio2",  "gpio3",  "gpio4",  "gpio5",  "gpio6",  "gpio7",
> > +   "gpio8",  "gpio9",  "gpio10", "gpio11", "gpio12", "gpio13", 
> > "gpio14",
> > +   "gpio15", "gpio16", "gpio17", "gpio18", "gpio19", "gpio20", 
> > "gpio21",
> > +   "gpio22", "gpio23", "gpio24", "gpio25", "gpio26", "gpio27", 
> > "gpio28",
> > +   "gpio29", "gpio30", "gpio31", "gpio32", "gpio33", "gpio34", 
> > "gpio35",
> > +   "gpio36", "gpio37", "gpio38", "gpio39", "gpio40",
> > +};
> 
> If they are called "gpioN" in the datasheet I guess it is all right.
> That is how e.g. the Qualcomm driver is done.
> 
> > +#ifdef CONFIG_PINCTRL_CS47L85
> 
> So this makes me feel maybe we should create drivers/pinctrl/cirrus
> and split this driver into subdrivers per chip like others do.

Re: [PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Linus Walleij]

On Wed, Apr 5, 2017 at 12:07 PM, Richard Fitzgerald
 wrote:

> These codecs have a variable number of I/O lines each of which
> is individually selectable to a wide range of possible functions.
>
> The functionality is slightly different from the traditional muxed
> GPIO since most of the functions can be mapped to any pin (and even
> the same function to multiple pins). Most pins have a dedicated
> "alternate" function that is only available on that pin. The
> alternate functions are usually a group of signals, though it is
> not always necessary to enable the full group, depending on the
> alternate function and how it is to be used. The mapping between
> alternate functions and GPIO pins varies between codecs depending
> on the number of alternate functions and available pins.
>
> Signed-off-by: Richard Fitzgerald 

>  .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++

This should ideally be split into its own patch but I don't care
much if the DT people are happy.

> +See also
> +  the core bindings for the parent MFD driver:
> +Documentation/devicetree/bindings/mfd/madera.txt
> +
> +  the generic pinmix bindings:
> +Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

Nice.

> +Required properties of parent mfd node:
> +  - pinctrl-names : must be "defaults"

Do you mean "default"

Apart from this the bindings and example look very good to
me, good job! I like it when people "just get it" with pin control
and that is where we need to be with this subsystem.

> +config PINCTRL_MADERA
> +   bool
> +   default y if MFD_MADERA=y

Isn't it even proper for MFD_MADERA to explicitly
select this driver. I see it hard how the chip would even
work without this. (Maybe it already does select it but then
default y is not necessary.)

> +config PINCTRL_CS47L35
> +   bool
> +   default y if MFD_CS47L35=y

Similar comment for the subdrivers.

> @@ -17,6 +17,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
>  obj-$(CONFIG_PINCTRL_DA850_PUPD) += pinctrl-da850-pupd.o
>  obj-$(CONFIG_PINCTRL_DIGICOLOR)+= pinctrl-digicolor.o
>  obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
> +obj-$(CONFIG_PINCTRL_MADERA)   += pinctrl-madera.o

Is it all in one file... despite all the Kconfig symbols... hm.
I guess we can create drivers/pinctrl/cirrus the day we need more
space.

> +/*
> + * Pins are named after their GPIO number

So don't they have real names? Like the pin name on the underside of
the chip? That is what this naming convention is actually for.

> +/*
> + * All single-pin functions can be mapped to any GPIO, however pinmux applies
> + * functions to pin groups and only those groups declared as supporting that
> + * function. To make this work we must put each pin in its own dummy group so
> + * that the functions can be described as applying to all pins.
> + * Since these do not correspond to anything in the actual hardware - they 
> are
> + * merely an adaptation to pinctrl's view of the world - we use the same name
> + * as the pin to avoid confusion when comparing with datasheet instructions
> + */
> +static const char * const madera_pin_single_group_names[] = {
> +   "gpio1",  "gpio2",  "gpio3",  "gpio4",  "gpio5",  "gpio6",  "gpio7",
> +   "gpio8",  "gpio9",  "gpio10", "gpio11", "gpio12", "gpio13", "gpio14",
> +   "gpio15", "gpio16", "gpio17", "gpio18", "gpio19", "gpio20", "gpio21",
> +   "gpio22", "gpio23", "gpio24", "gpio25", "gpio26", "gpio27", "gpio28",
> +   "gpio29", "gpio30", "gpio31", "gpio32", "gpio33", "gpio34", "gpio35",
> +   "gpio36", "gpio37", "gpio38", "gpio39", "gpio40",
> +};

If they are called "gpioN" in the datasheet I guess it is all right.
That is how e.g. the Qualcomm driver is done.

> +#ifdef CONFIG_PINCTRL_CS47L85

So this makes me feel maybe we should create drivers/pinctrl/cirrus
and split this driver into subdrivers per chip like others do.

The coding style document does say that ifdefs are ugly.

Would you consider splitting it up?

> +static void madera_pin_dbg_show(struct pinctrl_dev *pctldev,
> +   struct seq_file *s,
> +   unsigned int offset)
> +{
> +   seq_puts(s, " madera-pinctrl");
> +}

I don't think the pinctrl debugfs callback is compulsory.
It would be nice if this added some actual useful information
about the pin.


> +   case PIN_CONFIG_DRIVE_OPEN_DRAIN:
> +   mask[0] |= MADERA_GP1_OP_CFG_MASK;
> +   conf[0] |= MADERA_GP1_OP_CFG;
> +   break;
> +   case PIN_CONFIG_DRIVE_PUSH_PULL:
> +   mask[0] |= MADERA_GP1_OP_CFG_MASK;
> +   conf[0] &= ~MADERA_GP1_OP_CFG;
> +   break;

This will be possible to reuse from a GPIO driver as back-end, nice!


> +   case PIN_CONFIG_INPUT_DEBOUNCE:
> +   

Re: [PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Linus Walleij]

On Wed, Apr 5, 2017 at 12:07 PM, Richard Fitzgerald
 wrote:

> These codecs have a variable number of I/O lines each of which
> is individually selectable to a wide range of possible functions.
>
> The functionality is slightly different from the traditional muxed
> GPIO since most of the functions can be mapped to any pin (and even
> the same function to multiple pins). Most pins have a dedicated
> "alternate" function that is only available on that pin. The
> alternate functions are usually a group of signals, though it is
> not always necessary to enable the full group, depending on the
> alternate function and how it is to be used. The mapping between
> alternate functions and GPIO pins varies between codecs depending
> on the number of alternate functions and available pins.
>
> Signed-off-by: Richard Fitzgerald 

>  .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++

This should ideally be split into its own patch but I don't care
much if the DT people are happy.

> +See also
> +  the core bindings for the parent MFD driver:
> +Documentation/devicetree/bindings/mfd/madera.txt
> +
> +  the generic pinmix bindings:
> +Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

Nice.

> +Required properties of parent mfd node:
> +  - pinctrl-names : must be "defaults"

Do you mean "default"

Apart from this the bindings and example look very good to
me, good job! I like it when people "just get it" with pin control
and that is where we need to be with this subsystem.

> +config PINCTRL_MADERA
> +   bool
> +   default y if MFD_MADERA=y

Isn't it even proper for MFD_MADERA to explicitly
select this driver. I see it hard how the chip would even
work without this. (Maybe it already does select it but then
default y is not necessary.)

> +config PINCTRL_CS47L35
> +   bool
> +   default y if MFD_CS47L35=y

Similar comment for the subdrivers.

> @@ -17,6 +17,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
>  obj-$(CONFIG_PINCTRL_DA850_PUPD) += pinctrl-da850-pupd.o
>  obj-$(CONFIG_PINCTRL_DIGICOLOR)+= pinctrl-digicolor.o
>  obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
> +obj-$(CONFIG_PINCTRL_MADERA)   += pinctrl-madera.o

Is it all in one file... despite all the Kconfig symbols... hm.
I guess we can create drivers/pinctrl/cirrus the day we need more
space.

> +/*
> + * Pins are named after their GPIO number

So don't they have real names? Like the pin name on the underside of
the chip? That is what this naming convention is actually for.

> +/*
> + * All single-pin functions can be mapped to any GPIO, however pinmux applies
> + * functions to pin groups and only those groups declared as supporting that
> + * function. To make this work we must put each pin in its own dummy group so
> + * that the functions can be described as applying to all pins.
> + * Since these do not correspond to anything in the actual hardware - they 
> are
> + * merely an adaptation to pinctrl's view of the world - we use the same name
> + * as the pin to avoid confusion when comparing with datasheet instructions
> + */
> +static const char * const madera_pin_single_group_names[] = {
> +   "gpio1",  "gpio2",  "gpio3",  "gpio4",  "gpio5",  "gpio6",  "gpio7",
> +   "gpio8",  "gpio9",  "gpio10", "gpio11", "gpio12", "gpio13", "gpio14",
> +   "gpio15", "gpio16", "gpio17", "gpio18", "gpio19", "gpio20", "gpio21",
> +   "gpio22", "gpio23", "gpio24", "gpio25", "gpio26", "gpio27", "gpio28",
> +   "gpio29", "gpio30", "gpio31", "gpio32", "gpio33", "gpio34", "gpio35",
> +   "gpio36", "gpio37", "gpio38", "gpio39", "gpio40",
> +};

If they are called "gpioN" in the datasheet I guess it is all right.
That is how e.g. the Qualcomm driver is done.

> +#ifdef CONFIG_PINCTRL_CS47L85

So this makes me feel maybe we should create drivers/pinctrl/cirrus
and split this driver into subdrivers per chip like others do.

The coding style document does say that ifdefs are ugly.

Would you consider splitting it up?

> +static void madera_pin_dbg_show(struct pinctrl_dev *pctldev,
> +   struct seq_file *s,
> +   unsigned int offset)
> +{
> +   seq_puts(s, " madera-pinctrl");
> +}

I don't think the pinctrl debugfs callback is compulsory.
It would be nice if this added some actual useful information
about the pin.


> +   case PIN_CONFIG_DRIVE_OPEN_DRAIN:
> +   mask[0] |= MADERA_GP1_OP_CFG_MASK;
> +   conf[0] |= MADERA_GP1_OP_CFG;
> +   break;
> +   case PIN_CONFIG_DRIVE_PUSH_PULL:
> +   mask[0] |= MADERA_GP1_OP_CFG_MASK;
> +   conf[0] &= ~MADERA_GP1_OP_CFG;
> +   break;

This will be possible to reuse from a GPIO driver as back-end, nice!


> +   case PIN_CONFIG_INPUT_DEBOUNCE:
> +   mask[0] |= MADERA_GP1_DB_MASK;
> +
> +   /*
> +

[PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Richard Fitzgerald]

These codecs have a variable number of I/O lines each of which
is individually selectable to a wide range of possible functions.

The functionality is slightly different from the traditional muxed
GPIO since most of the functions can be mapped to any pin (and even
the same function to multiple pins). Most pins have a dedicated
"alternate" function that is only available on that pin. The
alternate functions are usually a group of signals, though it is
not always necessary to enable the full group, depending on the
alternate function and how it is to be used. The mapping between
alternate functions and GPIO pins varies between codecs depending
on the number of alternate functions and available pins.

Signed-off-by: Richard Fitzgerald 
---
 .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++
 MAINTAINERS|2 +
 drivers/pinctrl/Kconfig|   22 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-madera.c   | 1092 
 5 files changed, 1220 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-madera.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
new file mode 100644
index 000..e9e20e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
@@ -0,0 +1,103 @@
+Cirrus Logic Madera class audio codecs pinctrl driver
+
+The Cirrus Logic Madera codecs provide a number of GPIO functions for
+interfacing to external hardware and to provide logic outputs to other devices.
+Certain groups of GPIO pins also have an alternate function, normally as an
+audio interface.
+
+The set of available GPIOs, functions and alternate function groups differs
+between codecs so refer to the datasheet for the codec for further information
+on what is supported on that device.
+
+The root node for this driver must be a subnode of the parent MFD driver node.
+It contains one subnode that is a container for an arbitrary number of subnodes
+to configure each pin or function group.
+
+See also
+  the core bindings for the parent MFD driver:
+Documentation/devicetree/bindings/mfd/madera.txt
+
+  the generic pinmix bindings:
+Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Required properties of parent mfd node:
+  - pinctrl-names : must be "defaults"
+  - pinctrl-0 : a phandle to the node containing the configuration subnodes
+
+Required properties of pinctrl subnode:
+  - compatible : must be "cirrus,madera-pinctrl"
+
+Required properties of configuration subnodes:
+  - groups : name of one pin group to configure. One of:
+   aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2,
+   dmic4, dmic5, dmic6,
+   gpio1, gpio2, ..., gpio40
+The gpioN groups select the single pin of this name for configuration
+
+Optional properties of configuration subnodes:
+  Any configuration option not explicitly listed in the dts will be left at
+  chip default setting.
+
+  - function : name of function to assign to this group. One of:
+   aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2,
+   dmic3, dmic4, dmic5, dmic6,
+   io, dsp-gpio, irq1, irq2,
+   fll1-clk, fll1-lock, fll2-clk, fll2-lock, fll3-clk, fll3-lock,
+   fllao-clk, fllao-lock,
+   opclk, opclk-async, pwm1, pwm2, spdif,
+   asrc1-in1-lock, asrc1-in2-lock, asrc2-in1-lock, asrc2-in2-lock,
+   spkl-short-circuit, spkr-short-circuit, spk-shutdown,
+   spk-overheat-shutdown, spk-overheat-warn,
+   timer1-sts, timer2-sts, timer3-sts, timer4-sts, timer5-sts, timer6-sts,
+   timer7-sts, timer8-sts,
+   log1-fifo-ne, log2-fifo-ne, log3-fifo-ne, log4-fifo-ne, log5-fifo-ne,
+   log6-fifo-ne, log7-fifo-ne, log8-fifo-ne,
+
+  - bias-disable : disable pull-up and pull-down
+  - bias-bus-hold : enable buskeeper
+  - bias-pull-up : output is pulled-up
+  - bias-pull-down : output is pulled-down
+  - drive-push-pull : CMOS output
+  - drive-open-drain : open-drain output
+  - drive-strength : drive strength in mA. Valid values are 4 or 8
+  - input-schmitt-enable : enable schmitt-trigger mode
+  - input-schmitt-disable : disable schmitt-trigger mode
+  - input-debounce : A value of 0 disables debounce, a value !=0 enables
+   debounce
+  - output-low : set the pin to output mode with low level
+  - output-high : set the pin to output mode with high level
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_defaults>;
+
+
+   pinctrl {
+   compatible = "cirrus,madera-pinctrl";
+
+   cs47l85_gpio_defaults: defaults {
+   aif1 {
+   

[PATCH 09/16] pinctrl: madera: Add driver for Cirrus Logic Madera codecs

[Richard Fitzgerald]

These codecs have a variable number of I/O lines each of which
is individually selectable to a wide range of possible functions.

The functionality is slightly different from the traditional muxed
GPIO since most of the functions can be mapped to any pin (and even
the same function to multiple pins). Most pins have a dedicated
"alternate" function that is only available on that pin. The
alternate functions are usually a group of signals, though it is
not always necessary to enable the full group, depending on the
alternate function and how it is to be used. The mapping between
alternate functions and GPIO pins varies between codecs depending
on the number of alternate functions and available pins.

Signed-off-by: Richard Fitzgerald 
---
 .../bindings/pinctrl/cirrus,madera-pinctrl.txt |  103 ++
 MAINTAINERS|2 +
 drivers/pinctrl/Kconfig|   22 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-madera.c   | 1092 
 5 files changed, 1220 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-madera.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
new file mode 100644
index 000..e9e20e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
@@ -0,0 +1,103 @@
+Cirrus Logic Madera class audio codecs pinctrl driver
+
+The Cirrus Logic Madera codecs provide a number of GPIO functions for
+interfacing to external hardware and to provide logic outputs to other devices.
+Certain groups of GPIO pins also have an alternate function, normally as an
+audio interface.
+
+The set of available GPIOs, functions and alternate function groups differs
+between codecs so refer to the datasheet for the codec for further information
+on what is supported on that device.
+
+The root node for this driver must be a subnode of the parent MFD driver node.
+It contains one subnode that is a container for an arbitrary number of subnodes
+to configure each pin or function group.
+
+See also
+  the core bindings for the parent MFD driver:
+Documentation/devicetree/bindings/mfd/madera.txt
+
+  the generic pinmix bindings:
+Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Required properties of parent mfd node:
+  - pinctrl-names : must be "defaults"
+  - pinctrl-0 : a phandle to the node containing the configuration subnodes
+
+Required properties of pinctrl subnode:
+  - compatible : must be "cirrus,madera-pinctrl"
+
+Required properties of configuration subnodes:
+  - groups : name of one pin group to configure. One of:
+   aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2,
+   dmic4, dmic5, dmic6,
+   gpio1, gpio2, ..., gpio40
+The gpioN groups select the single pin of this name for configuration
+
+Optional properties of configuration subnodes:
+  Any configuration option not explicitly listed in the dts will be left at
+  chip default setting.
+
+  - function : name of function to assign to this group. One of:
+   aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2,
+   dmic3, dmic4, dmic5, dmic6,
+   io, dsp-gpio, irq1, irq2,
+   fll1-clk, fll1-lock, fll2-clk, fll2-lock, fll3-clk, fll3-lock,
+   fllao-clk, fllao-lock,
+   opclk, opclk-async, pwm1, pwm2, spdif,
+   asrc1-in1-lock, asrc1-in2-lock, asrc2-in1-lock, asrc2-in2-lock,
+   spkl-short-circuit, spkr-short-circuit, spk-shutdown,
+   spk-overheat-shutdown, spk-overheat-warn,
+   timer1-sts, timer2-sts, timer3-sts, timer4-sts, timer5-sts, timer6-sts,
+   timer7-sts, timer8-sts,
+   log1-fifo-ne, log2-fifo-ne, log3-fifo-ne, log4-fifo-ne, log5-fifo-ne,
+   log6-fifo-ne, log7-fifo-ne, log8-fifo-ne,
+
+  - bias-disable : disable pull-up and pull-down
+  - bias-bus-hold : enable buskeeper
+  - bias-pull-up : output is pulled-up
+  - bias-pull-down : output is pulled-down
+  - drive-push-pull : CMOS output
+  - drive-open-drain : open-drain output
+  - drive-strength : drive strength in mA. Valid values are 4 or 8
+  - input-schmitt-enable : enable schmitt-trigger mode
+  - input-schmitt-disable : disable schmitt-trigger mode
+  - input-debounce : A value of 0 disables debounce, a value !=0 enables
+   debounce
+  - output-low : set the pin to output mode with low level
+  - output-high : set the pin to output mode with high level
+
+Example:
+
+codec: cs47l85@0 {
+   compatible = "cirrus,cs47l85";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_defaults>;
+
+
+   pinctrl {
+   compatible = "cirrus,madera-pinctrl";
+
+   cs47l85_gpio_defaults: defaults {
+   aif1 {
+   groups = "aif1";
+