From patchwork Thu Dec 15 15:20:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Vasut X-Patchwork-Id: 13074295 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E35E4C2D0CC for ; Thu, 15 Dec 2022 15:21:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=ObCSTl/EfNpatQfGxKxU/ZFOOH27MY3U6YgM0yIQ02g=; b=FbM6DJNL+LDWwp hN09B/FRUhM+uGDS2PRkA7lM3J2HmH/yN+kBanR4TQB1yCrOMuyFeZb35Ez1++ulnEJYTZT2tgLZX gCNAU8ZCKhI3my3QgmeDPrWLngiDgtO/ccE3GXVBzpM0p8Ifywzpm7eNAh2lasqfR5aNLiAxq1ZR5 YxnsomDGj4JDoV9taNPU48U1PiBmmIzZ7KiW8uxi5DFdMPrcKjR+NPijDh0uh9UU/GYkolKyEMRRC 58Bgd9EhxwfGvRN+62k5PNhKuVoMNRhvlL8uk1Cn+SMQRXF2SkSL2VObXVe7sUun7p/gYvT4jo2U9 Ldk0GfPLoHlRO6FM7ASg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5q2L-00A2af-3u; Thu, 15 Dec 2022 15:20:41 +0000 Received: from phobos.denx.de ([85.214.62.61]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5q2H-00A2YH-JS for linux-arm-kernel@lists.infradead.org; Thu, 15 Dec 2022 15:20:39 +0000 Received: from tr.lan (ip-86-49-120-218.bb.vodafone.cz [86.49.120.218]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 5762D83E2B; Thu, 15 Dec 2022 16:20:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1671117635; bh=YA2nJCGPzE9bmzcS01/3S4RrQtPK0gDHnB8MmBYJcfc=; h=From:To:Cc:Subject:Date:From; b=YX587Qz/eI7YQECxTMn/gilaEFnelFMIKX8Nt8vt0cpb1/FsXuW3EMEQIlgmCMn6W UAzskDzG9UIXP9uMEooBnhpGXzfF+4UoF0Ylul/Hu+5e485s+qLjqhzZtgw/XzIe7+ yxQfmSkwizeRdf6rMVStbQBlxWCfobDDIv2VMA8MHcLT+z+cwyMTDXTI57+DXOp+G1 wvcfI/JaVpJmycgb7lZQJi82KS0aG2AoEtk6xxhGKXTlYBRpP+0V97etZOH9O4rVMS VI3x03V1dvJk6kZ0+azm2mg6hhQAB4UgSJpWK7EKYUwZ7QEnjACwDLCS0p8+atz7cv 4/eiQf2LSKtbw== From: Marek Vasut To: linux-arm-kernel@lists.infradead.org Cc: Marek Vasut , Abhyuday Godhasara , Harsha , Michal Simek , Rajan Vaja , Ronak Jain , Tanmay Shah Subject: [PATCH v3] firmware: xilinx: Clear IOCTL_SET_SD_TAPDELAY using PM_MMIO_WRITE Date: Thu, 15 Dec 2022 16:20:23 +0100 Message-Id: <20221215152023.8387-1-marex@denx.de> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221215_072038_051759_0D3DBF82 X-CRM114-Status: GOOD ( 16.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 --- Cc: Abhyuday Godhasara Cc: Harsha Cc: Michal Simek Cc: Rajan Vaja Cc: Ronak Jain Cc: Tanmay Shah 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,