Thread (11 messages) 11 messages, 5 authors, 2018-07-20

RE: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT

From: Manish Narani <hidden>
Date: 2018-07-20 06:23:32
Also in: linux-arm-kernel, linux-mmc, lkml

Hi Uffe,
-----Original Message-----
From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
Sent: Tuesday, July 10, 2018 2:02 PM
To: Manish Narani <redacted>
Cc: Rob Herring <robh+dt@kernel.org>; Mark Rutland
[off-list ref]; Catalin Marinas [off-list ref]; Will
Deacon [off-list ref]; Moritz Fischer [off-list ref];
stefan.krsmanovic@aggios.com; Linux ARM <linux-arm-
kernel@lists.infradead.org>; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>; linux-mmc@vger.kernel.org;
devicetree@vger.kernel.org; Adrian Hunter [off-list ref];
Michal Simek [off-list ref]
Subject: Re: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay
values from DT

On 7 June 2018 at 14:11, Manish Narani [off-list ref] wrote:
quoted
This patch adds support for reading Tap Delay values from Device Tree
and write them via eemi calls. The macros containing these tap delay
values are removed from the driver.

Signed-off-by: Manish Narani <redacted>
---
 drivers/mmc/host/sdhci-of-arasan.c | 131
+++++++++++++++++++++++++++++++++++++
 1 file changed, 131 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index e3332a5..fc0fd01 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -36,6 +36,8 @@

 #define PHY_CLK_TOO_SLOW_HZ            400000

+#define MMC_BANK2              0x2
+
 /*
  * On some SoCs the syscon area has a feature where the upper 16-bits of
  * each 32-bit register act as a write mask for the lower 16-bits.
This allows @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
        struct sdhci_host *host;
        struct clk      *clk_ahb;
        struct phy      *phy;
+       u32 mio_bank;
+       u32 device_id;
+       u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
+       u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
        bool            is_phy_on;

        bool            has_cqe;
@@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct
sdhci_host *host,
quoted
        return ret;
 }

+/**
+ * arasan_zynqmp_set_tap_delay - Program the tap delays.
+ * @deviceid:          Unique Id of device
+ * @itap_delay:                Input Tap Delay
+ * @oitap_delay:       Output Tap Delay
+ */
+static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay,
+u8 otap_delay) {
+       const struct zynqmp_eemi_ops *eemi_ops =
+zynqmp_pm_get_eemi_ops();
No thanks!

Isn't there a more generic framework we can use to change the tap values,
rather than calling SoC specific functions from the driver?
Yes, Thanks for your suggestion. I will work on the generic framework which will be used to change tap values
Via SoC drivers.
BTW, what is a tap value, more exactly?
What does changing a tap value mean and where does the property belong,
really?
Tap Value is the delay of clock phase which is used to adjust phase to the working value. The auto tuning
process generally sets tap values internally in controller in SD UHS modes. But for other modes where
auto tuning is applicable, we are determining tap values via trial & error method for specific SoC.
quoted
Of course this doesn't even compile, as you have a dependency to another
series. Next time, please clarify that in a cover-letter (maybe you did, but I
can't find it).
quoted
+       u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
+
+       if (!eemi_ops || !eemi_ops->ioctl)
+               return;
+
+       if (itap_delay)
+               eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
+                               PM_TAPDELAY_INPUT, itap_delay, NULL);
+
+       if (otap_delay)
+               eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
+                               PM_TAPDELAY_OUTPUT, otap_delay, NULL);
+}
Another overall comment for the series.

I would recommend to change the order of the patches in the series.
Let the DT doc change come first, next the driver change and finally the change
to the DTS file(s). This makes it easier to follow and review.
Sure, I will do that.

Thanks & Regards,
Manish
[...]

Kind regards
Uffe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help