summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/xilinx
diff options
context:
space:
mode:
authorMarek Vasut <marex@denx.de>2022-12-15 16:20:23 +0100
committerMichal Simek <michal.simek@amd.com>2023-01-05 10:18:07 +0100
commita4b2e6063cfeaab1160501acfb27e8618a7c693f (patch)
treefa849d688d301834a7e2410b87efba1ef64b8ae9 /drivers/firmware/xilinx
parentfirmware: xilinx: Remove kernel-doc marking in the code (diff)
downloadlinux-a4b2e6063cfeaab1160501acfb27e8618a7c693f.tar.xz
linux-a4b2e6063cfeaab1160501acfb27e8618a7c693f.zip
firmware: xilinx: Clear IOCTL_SET_SD_TAPDELAY using PM_MMIO_WRITE
In case the tap delay required by Arasan SDHCI is set to 0, the current embeddedsw firmware unconditionally writes IOU_SLCR SD_ITAPDLY to 0x100 (SD0_ITAPDLYENA=1, SD0_ITAPDLYSEL=0). Previous behavior was to keep the IOU_SLCR SD_ITAPDLY set to 0x0. There is some sort of difference in the behavior between SD0_ITAPDLYENA=1/0 with the same SD0_ITAPDLYSEL=0, even though the behavior should be identical -- zero delay added to rxclk_in line. The former breaks HS200 training in low temperature conditions. Write IOU_SLCR SD_ITAPDLY register to 0 using PM_MMIO_WRITE which seem to allow unrestricted WRITE access (and PM_MMIO_READ which allows read access) to the entire address space. This way, it is possible to work around the defect in IOCTL_SET_SD_TAPDELAY design which does not permit clearing SDx_ITAPDLYENA bit. Note that the embeddedsw firmware does not permit clearing the SD_ITAPDLY SD0_ITAPDLYENA bit, this bit can only ever be set by the firmware and it is often impossible to update the possibly broken firmware. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20221215152023.8387-1-marex@denx.de Signed-off-by: Michal Simek <michal.simek@amd.com>
Diffstat (limited to 'drivers/firmware/xilinx')
-rw-r--r--drivers/firmware/xilinx/zynqmp.c27
1 files changed, 25 insertions, 2 deletions
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 129f68d7a6f5..acd83d29c866 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -738,8 +738,31 @@ EXPORT_SYMBOL_GPL(zynqmp_pm_get_pll_frac_data);
*/
int zynqmp_pm_set_sd_tapdelay(u32 node_id, u32 type, u32 value)
{
- return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, IOCTL_SET_SD_TAPDELAY,
- type, value, NULL);
+ u32 reg = (type == PM_TAPDELAY_INPUT) ? SD_ITAPDLY : SD_OTAPDLYSEL;
+ u32 mask = (node_id == NODE_SD_0) ? GENMASK(15, 0) : GENMASK(31, 16);
+
+ if (value) {
+ return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_SET_SD_TAPDELAY,
+ type, value, NULL);
+ }
+
+ /*
+ * Work around completely misdesigned firmware API on Xilinx ZynqMP.
+ * The IOCTL_SET_SD_TAPDELAY firmware call allows the caller to only
+ * ever set IOU_SLCR SD_ITAPDLY Register SD0_ITAPDLYENA/SD1_ITAPDLYENA
+ * bits, but there is no matching call to clear those bits. If those
+ * bits are not cleared, SDMMC tuning may fail.
+ *
+ * Luckily, there are PM_MMIO_READ/PM_MMIO_WRITE calls which seem to
+ * allow complete unrestricted access to all address space, including
+ * IOU_SLCR SD_ITAPDLY Register and all the other registers, access
+ * to which was supposed to be protected by the current firmware API.
+ *
+ * Use PM_MMIO_READ/PM_MMIO_WRITE to re-implement the missing counter
+ * part of IOCTL_SET_SD_TAPDELAY which clears SDx_ITAPDLYENA bits.
+ */
+ return zynqmp_pm_invoke_fn(PM_MMIO_WRITE, reg, mask, 0, 0, NULL);
}
EXPORT_SYMBOL_GPL(zynqmp_pm_set_sd_tapdelay);