On Fri, Apr 28, 2017 at 3:39 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald > <rf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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. >> >> Note on the Kconfig options: >> The formula "default y if..." is used for PINCTRL_MADERA so that its >> select options will be processed, allowing us to group selects for >> pinctrl into the pinctrl Kconfig where they logically belong instead >> of accumulating under the parent MFD Kconfig. >> >> Signed-off-by: Richard Fitzgerald <rf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> >> --- >> Changes since V1: >> - dt binding moved to separate patch >> - moved all source into a subdirectory drivers/pinctrl/cirrus >> - split chip-specific tables into separate files >> - codec-specific build options are now selected from MFD >> - print useful information from madera_pin_dbg_show() >> - added gpio_set_direciton / gpio_request_enable / gpio_disable_free functions >> - added strict mode so GPIO and other functions are exclusive >> - replace #ifdefs with if (IS_ENABLED(...)) in probe >> - fixed bug reading registers in madera_pin_conf_get() > > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> If this hasn't been merged yet, can we get rid of all the MODULE / module references, since the Kconfigs are all bool type and hence we shouldn't need to use them. Alternatively we can do it in a follow-on patch if needed. Thanks, Paul. -- > > I guess you will apply this through MFD, so waiting for Lee to > pick it up. Alternatively I can apply it after the MFD core parts > are upstream. > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
