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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html