cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
241 Views
Registered: ‎02-25-2020

ZynqMP QSPI pinctrl

Jump to solution

Hi all,

I'm working on a custom ZynqMP/ZU2CG design with a QSPI flash device connected to MIO[0..5].

The upper QSPI interface pins on MIO[7..12] + FB_CLK (MIO6) are not used for QSPI communication.

Instead we are trying to use MIO[6..8] for general I/O, but I'm unsure how to configure the Linux pinctrl driver to use only MIO[0..5] for QSPI, and not claim the remaining pins for QSPI.

I'm familiar with the Xilinx pinctrl driver, and have successfully configured other interfaces including I2C, Ethernet and SD/MMC.

Looking at /sys/kernel/debug/pinctrl/firmware:zynqmp-firmware:pinctrl-zynqmp_pinctrl/pingroups I only see a single qspi group - 'qspi0_0_grp' - which includes MIO[0..4] and MIO[8..12] (SS and FB_CLK are in separate groups).

The problem is that, as expected, enabling the qspi0_0_grp group fails if the GPIO driver has already claimed MIO[6..8]:

[ 34.319141] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: pin MIO8 already requested by ff0a0000.gpio; cannot claim for ff0f0000.spi
[ 34.331336] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: pin-8 (ff0f0000.spi) status -22
[ 34.339776] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: could not request pin 8 (MIO8) from group qspi0_0_grp on device zynqmp_pinctrl
[ 34.352449] zynqmp-qspi ff0f0000.spi: Error applying setting, reverse things back
[ 34.359940] zynqmp-qspi: probe of ff0f0000.spi failed with error -22

Obviously what we need is to configure only MIO[0..5] for use with QSPI, but how do we go about that?

Is this a flaw in the pinctrl/firmware driver that it is not possible to specify only the pin group corresponding to the lower QSPI interface?

Or does the SoC not support using the remaining MIO lines for other purposes? Is it simply a hardware limitation?

Assuming it's not an SoC limitation an option for us might be to fall back on the pinctrl configuration performed in the FSBL, but it seems like this should be possible to do through the Linux pinctrl driver as well.

Thanks,
Carsten

0 Kudos
Reply
1 Solution

Accepted Solutions
161 Views
Registered: ‎02-25-2020

For anyone else running into this issue, it turns out that the SoC is perfectly capable of allocating just the lower MIO range for the QSPI interface, and leaving the remaining pins for general I/O.

We ended up patching the ARM Trusted Firmware program to support two new pin groups (QSPI + SS) for the lower QSPI interface. The source file of interest is https://github.com/Xilinx/arm-trusted-firmware/blob/master/plat/xilinx/zynqmp/pm_service/pm_api_pinctrl.c - see also https://github.com/Xilinx/arm-trusted-firmware/pull/3.

This enables us to specify our custom pin groups for QSPI in the device tree, along with GPIO groups for MIO[7..12] without generating any conflicts.

View solution in original post

1 Reply
162 Views
Registered: ‎02-25-2020

For anyone else running into this issue, it turns out that the SoC is perfectly capable of allocating just the lower MIO range for the QSPI interface, and leaving the remaining pins for general I/O.

We ended up patching the ARM Trusted Firmware program to support two new pin groups (QSPI + SS) for the lower QSPI interface. The source file of interest is https://github.com/Xilinx/arm-trusted-firmware/blob/master/plat/xilinx/zynqmp/pm_service/pm_api_pinctrl.c - see also https://github.com/Xilinx/arm-trusted-firmware/pull/3.

This enables us to specify our custom pin groups for QSPI in the device tree, along with GPIO groups for MIO[7..12] without generating any conflicts.

View solution in original post