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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
