Message ID | 20191204101042.4275-6-cleger@kalray.eu |
---|---|
State | Changes Requested, archived |
Headers | show |
Series | Add pinctrl support for dwapb gpio driver | expand |
Context | Check | Description |
---|---|---|
robh/checkpatch | success |
On Wed, Dec 4, 2019 at 12:13 PM Clement Leger <cleger@kalray.eu> wrote: > > Since the driver has been moved to pinctrl and now supports it, move the > documentation into pinctrl folder. In the same time, add documentation > for pinctrl properties such has snps,has-pinctrl and description of pin > alternate functions. > +- snps,has-pinctrl : If present, register the pinctrl controller. I'm wondering why we can't always assume pin control? > -F: Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt > +F: Documentation/devicetree/bindings/pinctrl/snps-dwapb-gpio.txt I guess this should be a part of patch 2 when you move driver w/o changes to a new folder.
----- On 4 Dec, 2019, at 13:45, Andy Shevchenko andy.shevchenko@gmail.com wrote: > On Wed, Dec 4, 2019 at 12:13 PM Clement Leger <cleger@kalray.eu> wrote: >> >> Since the driver has been moved to pinctrl and now supports it, move the >> documentation into pinctrl folder. In the same time, add documentation >> for pinctrl properties such has snps,has-pinctrl and description of pin >> alternate functions. > >> +- snps,has-pinctrl : If present, register the pinctrl controller. > > I'm wondering why we can't always assume pin control? This hardware IP is configured when instantiated to include support for muxing. If configured without support, the registers will exists but won't configure anything. I guess that it's not really a problem but it will lead to unusable pin muxing. > >> -F: Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt >> +F: Documentation/devicetree/bindings/pinctrl/snps-dwapb-gpio.txt > > I guess this should be a part of patch 2 when you move driver w/o > changes to a new folder. Agreed. I will do that, Thanks > > -- > With Best Regards, > Andy Shevchenko
On Wed, Dec 04, 2019 at 02:52:59PM +0100, Clément Leger wrote: > > ----- On 4 Dec, 2019, at 13:45, Andy Shevchenko andy.shevchenko@gmail.com wrote: > > > On Wed, Dec 4, 2019 at 12:13 PM Clement Leger <cleger@kalray.eu> wrote: > >> > >> Since the driver has been moved to pinctrl and now supports it, move the > >> documentation into pinctrl folder. In the same time, add documentation > >> for pinctrl properties such has snps,has-pinctrl and description of pin > >> alternate functions. > > > >> +- snps,has-pinctrl : If present, register the pinctrl controller. > > > > I'm wondering why we can't always assume pin control? > > This hardware IP is configured when instantiated to include support for > muxing. If configured without support, the registers will exists but won't > configure anything. > I guess that it's not really a problem but it will lead to unusable > pin muxing. Can't you determine this by the presence of child nodes? Rob
Hi Rob, Indeed, I could do that if you think that's a better option. Andy however suggested to always register a pinctrl controller. Both options suits me. Let me know what option you want me to implement. Thanks, Clément ----- On 16 Dec, 2019, at 22:39, Rob Herring robh@kernel.org wrote: > On Wed, Dec 04, 2019 at 02:52:59PM +0100, Clément Leger wrote: >> >> ----- On 4 Dec, 2019, at 13:45, Andy Shevchenko andy.shevchenko@gmail.com wrote: >> >> > On Wed, Dec 4, 2019 at 12:13 PM Clement Leger <cleger@kalray.eu> wrote: >> >> >> >> Since the driver has been moved to pinctrl and now supports it, move the >> >> documentation into pinctrl folder. In the same time, add documentation >> >> for pinctrl properties such has snps,has-pinctrl and description of pin >> >> alternate functions. >> > >> >> +- snps,has-pinctrl : If present, register the pinctrl controller. >> > >> > I'm wondering why we can't always assume pin control? >> >> This hardware IP is configured when instantiated to include support for >> muxing. If configured without support, the registers will exists but won't >> configure anything. >> I guess that it's not really a problem but it will lead to unusable >> pin muxing. > > Can't you determine this by the presence of child nodes? > > Rob
diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/pinctrl/snps-dwapb-gpio.txt similarity index 76% rename from Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt rename to Documentation/devicetree/bindings/pinctrl/snps-dwapb-gpio.txt index 839dd32ffe11..4fb1b754a2bd 100644 --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/snps-dwapb-gpio.txt @@ -1,4 +1,4 @@ -* Synopsys DesignWare APB GPIO controller +* Synopsys DesignWare APB GPIO & pinmux controller Required properties: - compatible : Should contain "snps,dw-apb-gpio" @@ -33,8 +33,16 @@ controller. use the interrupts-extended property to specify the interrupts and set the interrupt controller handle for unused interrupts to 0. - snps,nr-gpios : The number of pins in the port, a single cell. +- snps,has-pinctrl : If present, register the pinctrl controller. - resets : Reset line for the controller. +Required properties for pin configuration node: +- function: string representing a function to mux for pins + dw apb controller only has two functions for each pins (sw and hw). When set + in software mode, the gpio controller controls the pin output. When + configured in hardware mode, an external peripheral controls the pin signal. +- pins: string array of pins to be muxed. + Example: gpio: gpio@20000 { @@ -60,6 +68,17 @@ gpio: gpio@20000 { gpio-controller; #gpio-cells = <2>; snps,nr-gpios = <8>; + snps,has-pinctrl; reg = <1>; + + uart0_pins: pinmux_uart0_pins { + function = "hw"; + pins = "pin0", "pin1"; + }; + + uart1_pins: pinmux_uart1_pins { + function = "hw"; + pins = "pin2", "pin3"; + }; }; }; diff --git a/MAINTAINERS b/MAINTAINERS index 35b90ad9f594..e8f9e827d687 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15873,7 +15873,7 @@ M: Hoan Tran <hoan@os.amperecomputing.com> L: linux-gpio@vger.kernel.org S: Maintained F: drivers/pinctrl/dw/pinctrl-dwapb.c -F: Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt +F: Documentation/devicetree/bindings/pinctrl/snps-dwapb-gpio.txt SYNOPSYS DESIGNWARE AXI DMAC DRIVER M: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Since the driver has been moved to pinctrl and now supports it, move the documentation into pinctrl folder. In the same time, add documentation for pinctrl properties such has snps,has-pinctrl and description of pin alternate functions. Signed-off-by: Clement Leger <cleger@kalray.eu> --- .../bindings/{gpio => pinctrl}/snps-dwapb-gpio.txt | 21 ++++++++++++++++++++- MAINTAINERS | 2 +- 2 files changed, 21 insertions(+), 2 deletions(-) rename Documentation/devicetree/bindings/{gpio => pinctrl}/snps-dwapb-gpio.txt (76%)