| Message ID | 20221215152023.8387-1-marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3] firmware: xilinx: Clear IOCTL_SET_SD_TAPDELAY using PM_MMIO_WRITE | expand |
On 12/15/22 16:20, Marek Vasut wrote: > 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> > --- > Cc: Abhyuday Godhasara <abhyuday.godhasara@xilinx.com> > Cc: Harsha <harsha.harsha@xilinx.com> > Cc: Michal Simek <michal.simek@amd.com> > Cc: Rajan Vaja <rajan.vaja@xilinx.com> > Cc: Ronak Jain <ronak.jain@xilinx.com> > Cc: Tanmay Shah <tanmay.shah@xilinx.com> > To: linux-arm-kernel@lists.infradead.org > --- > V2: - Use PM_MMIO_WRITE to clear SD_xTAPDLYx bitfields and work around > the IOCTL_SET_SD_TAPDELAY design defect. > - Update commit message accordingly. > V3: - Move SD_ITAPDLY, SD_OTAPDLYSEL to include/linux/firmware/xlnx-zynqmp.h > --- > drivers/firmware/xilinx/zynqmp.c | 27 +++++++++++++++++++++++++-- > include/linux/firmware/xlnx-zynqmp.h | 4 ++++ > 2 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c > index 129f68d7a6f53..acd83d29c8667 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); > > diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h > index b986e267d149b..eb88b4ba62f98 100644 > --- a/include/linux/firmware/xlnx-zynqmp.h > +++ b/include/linux/firmware/xlnx-zynqmp.h > @@ -79,6 +79,10 @@ > #define EVENT_ERROR_PSM_ERR1 (0x28108000U) > #define EVENT_ERROR_PSM_ERR2 (0x2810C000U) > > +/* ZynqMP SD tap delay tuning */ > +#define SD_ITAPDLY 0xFF180314 > +#define SD_OTAPDLYSEL 0xFF180318 > + > enum pm_api_cb_id { > PM_INIT_SUSPEND_CB = 30, > PM_ACKNOWLEDGE_CB = 31, Applied. M
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c index 129f68d7a6f53..acd83d29c8667 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); diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h index b986e267d149b..eb88b4ba62f98 100644 --- a/include/linux/firmware/xlnx-zynqmp.h +++ b/include/linux/firmware/xlnx-zynqmp.h @@ -79,6 +79,10 @@ #define EVENT_ERROR_PSM_ERR1 (0x28108000U) #define EVENT_ERROR_PSM_ERR2 (0x2810C000U) +/* ZynqMP SD tap delay tuning */ +#define SD_ITAPDLY 0xFF180314 +#define SD_OTAPDLYSEL 0xFF180318 + enum pm_api_cb_id { PM_INIT_SUSPEND_CB = 30, PM_ACKNOWLEDGE_CB = 31,
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> --- Cc: Abhyuday Godhasara <abhyuday.godhasara@xilinx.com> Cc: Harsha <harsha.harsha@xilinx.com> Cc: Michal Simek <michal.simek@amd.com> Cc: Rajan Vaja <rajan.vaja@xilinx.com> Cc: Ronak Jain <ronak.jain@xilinx.com> Cc: Tanmay Shah <tanmay.shah@xilinx.com> To: linux-arm-kernel@lists.infradead.org --- V2: - Use PM_MMIO_WRITE to clear SD_xTAPDLYx bitfields and work around the IOCTL_SET_SD_TAPDELAY design defect. - Update commit message accordingly. V3: - Move SD_ITAPDLY, SD_OTAPDLYSEL to include/linux/firmware/xlnx-zynqmp.h --- drivers/firmware/xilinx/zynqmp.c | 27 +++++++++++++++++++++++++-- include/linux/firmware/xlnx-zynqmp.h | 4 ++++ 2 files changed, 29 insertions(+), 2 deletions(-)