pinctrl: zynq: configure SPI SSx pins separately

Since SCLK, MISO and MOSI are the only mandatory signals at Zynq's SPI
interfaces, SS0, SS1 and SS2 have to be configured separately as they may
be used as simple GPIO lines.

This, of course, has to be considered in the devicetree, so pin controller
configuration for e.g. an SPI0 using SS0 and SS1 only might look like the
following snippet (derived from the example of chapter "17.5.3
MIO/EMIO" Routing of Zynq-7000 TRM UG585). So MIO20 can now be used
as GPIO instead of being occupied by SPI0 SS2 function:

pinctrl_spi0_default: spi0-default {
	mux {
		function = "spi0";
		groups = "spi0_0_grp", "spi0_0_ss0_grp", "spi0_0_ss1_grp";
	};

	conf-output {
		pins = "MIO16", "MIO21";
		slew-rate = <0>;
		bias-disable;
		low-power-disable;
		io-standard = <1>;
	};

	conf-input {
		pins = "MIO17";
		slew-rate = <0>;
		bias-high-impedance;
		low-power-disable;
		io-standard = <1>;
	};

	conf-select {
		pins = "MIO18", "MIO19";
		slew-rate = <0>;
		bias-pull-up;
		low-power-disable;
		io-standard = <1>;
	};
};

pinctrl_gpio0_default {
	mux {
		function = "gpio0";
		groups = "gpio0_20_grp"
	};

	conf {
		pins = "MIO20";
		slew-rate = <0>;
		bias-pull-up;
		low-power-disable;
		io-standard = <1>;
	};
};

Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@gmail.com>
---
 .../bindings/pinctrl/xlnx,zynq-pinctrl.txt         |    5 +-
 drivers/pinctrl/pinctrl-zynq.c                     |   75 +++++++++++++++++---
 2 files changed, 67 insertions(+), 13 deletions(-)

Hi Helmut,

On Wed, 2015-04-22 at 11:14AM +0200, Helmut Buchsbaum wrote:
> Since SCLK, MISO and MOSI are the only mandatory signals at Zynq's SPI
> interfaces, SS0, SS1 and SS2 have to be configured separately as they may
> be used as simple GPIO lines.
> 
> This, of course, has to be considered in the devicetree, so pin controller
> configuration for e.g. an SPI0 using SS0 and SS1 only might look like the
> following snippet (derived from the example of chapter "17.5.3
> MIO/EMIO" Routing of Zynq-7000 TRM UG585). So MIO20 can now be used
> as GPIO instead of being occupied by SPI0 SS2 function:

I think this is very valid and correct. Thanks! One doubt I have though:
[...]
> @@ -548,10 +591,20 @@ static const char * const qspi0_groups[] = {"qspi0_0_grp"};
>  static const char * const qspi1_groups[] = {"qspi0_1_grp"};
>  static const char * const qspi_fbclk_groups[] = {"qspi_fbclk_grp"};
>  static const char * const qspi_cs1_groups[] = {"qspi_cs1_grp"};
> -static const char * const spi0_groups[] = {"spi0_0_grp", "spi0_1_grp",
> -					   "spi0_2_grp"};
> -static const char * const spi1_groups[] = {"spi1_0_grp", "spi1_1_grp",
> -					   "spi1_2_grp", "spi1_3_grp"};
> +static const char * const spi0_groups[] = {"spi0_0_grp", "spi0_0_ss0_grp",
> +					   "spi0_0_ss1_grp", "spi0_0_ss2_grp",
> +					   "spi0_1_grp", "spi0_1_ss0_grp",
> +					   "spi0_1_ss1_grp", "spi0_1_ss2_grp",
> +					   "spi0_2_grp", "spi0_2_ss0_grp",
> +					   "spi0_2_ss1_grp", "spi0_2_ss2_grp"};
> +static const char * const spi1_groups[] = {"spi1_0_grp", "spi1_0_ss0_grp",
> +					   "spi1_0_ss1_grp", "spi1_0_ss2_grp",
> +					   "spi1_1_grp", "spi1_1_ss0_grp",
> +					   "spi1_1_ss1_grp", "spi1_1_ss2_grp",
> +					   "spi1_2_grp", "spi1_2_ss0_grp",
> +					   "spi1_2_ss1_grp", "spi1_2_ss2_grp",
> +					   "spi1_3_grp", "spi1_3_ss0_grp",
> +					   "spi1_3_ss1_grp", "spi1_3_ss2_grp"};

Can we add this to the spiX groups or do we need individual
spix_ss_groups[] arrays? E.g. for the SD card detect signal and similar
we have individual groups arrays.

	Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 04/24/2015 08:21 PM, Sören Brinkmann wrote:
> Hi Helmut,
>
> On Wed, 2015-04-22 at 11:14AM +0200, Helmut Buchsbaum wrote:
>    
>> Since SCLK, MISO and MOSI are the only mandatory signals at Zynq's SPI
>> interfaces, SS0, SS1 and SS2 have to be configured separately as they may
>> be used as simple GPIO lines.
>>
>> This, of course, has to be considered in the devicetree, so pin controller
>> configuration for e.g. an SPI0 using SS0 and SS1 only might look like the
>> following snippet (derived from the example of chapter "17.5.3
>> MIO/EMIO" Routing of Zynq-7000 TRM UG585). So MIO20 can now be used
>> as GPIO instead of being occupied by SPI0 SS2 function:
>>      
> I think this is very valid and correct. Thanks! One doubt I have though:
> [...]
>    
>> @@ -548,10 +591,20 @@ static const char * const qspi0_groups[] = {"qspi0_0_grp"};
>>   static const char * const qspi1_groups[] = {"qspi0_1_grp"};
>>   static const char * const qspi_fbclk_groups[] = {"qspi_fbclk_grp"};
>>   static const char * const qspi_cs1_groups[] = {"qspi_cs1_grp"};
>> -static const char * const spi0_groups[] = {"spi0_0_grp", "spi0_1_grp",
>> -					   "spi0_2_grp"};
>> -static const char * const spi1_groups[] = {"spi1_0_grp", "spi1_1_grp",
>> -					   "spi1_2_grp", "spi1_3_grp"};
>> +static const char * const spi0_groups[] = {"spi0_0_grp", "spi0_0_ss0_grp",
>> +					   "spi0_0_ss1_grp", "spi0_0_ss2_grp",
>> +					   "spi0_1_grp", "spi0_1_ss0_grp",
>> +					   "spi0_1_ss1_grp", "spi0_1_ss2_grp",
>> +					   "spi0_2_grp", "spi0_2_ss0_grp",
>> +					   "spi0_2_ss1_grp", "spi0_2_ss2_grp"};
>> +static const char * const spi1_groups[] = {"spi1_0_grp", "spi1_0_ss0_grp",
>> +					   "spi1_0_ss1_grp", "spi1_0_ss2_grp",
>> +					   "spi1_1_grp", "spi1_1_ss0_grp",
>> +					   "spi1_1_ss1_grp", "spi1_1_ss2_grp",
>> +					   "spi1_2_grp", "spi1_2_ss0_grp",
>> +					   "spi1_2_ss1_grp", "spi1_2_ss2_grp",
>> +					   "spi1_3_grp", "spi1_3_ss0_grp",
>> +					   "spi1_3_ss1_grp", "spi1_3_ss2_grp"};
>>      
> Can we add this to the spiX groups or do we need individual
> spix_ss_groups[] arrays? E.g. for the SD card detect signal and similar
> we have individual groups arrays.
>
> 	Sören
>    

You're right. The cleaner solution is to keep the slave select groups in 
separate spix_ss_groups[] arrays. This also results in additional 
spix_ss pinmux functions. As a result this will be rather similar to the 
PC, WP and CD signals for SDIO. I'll change that and rework my patch.

Thanks,
Helmut

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html