Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1472004pxb; Sun, 22 Aug 2021 18:35:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygO+UFmb8FtXxfMjOZRK4eLrT6YNaopBFgkibSxV80xoJX0Ly0bgo4U4v7VbppEDWbFfaV X-Received: by 2002:a17:906:f11:: with SMTP id z17mr34206144eji.385.1629682527222; Sun, 22 Aug 2021 18:35:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629682527; cv=none; d=google.com; s=arc-20160816; b=zx1wwj6mOHualP1dHK7d/YW9L89xPVmtdAuOGJBzAYcUyza6HfdTEnTpwzOiBmeCz+ GYa0mwoDm/9sSsu83195Sv/bYvmQW+Y64QcoShdmfu0Tlia1wa3I+OcVEIsLo7wA7UUe Z+0bgXZng0QCUOGG1fpU/aYsMk9ftxU4csH/L1jH6oCnuqz4Jv4acvwnvbt3pLuIUWGR kPATF+ZzYIGXR0ZhHgUrn23ZHHyMGl+HWdNjDrYM8f0OsC+am57e4yHqiE2dUhWb0qAV ZryvrEAzyf92hrbd97+kaEgSB2OjF/Z5+u+4WeZgXAx+eJTCWjRFPfTo+qJrSjF4S2ku lTXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=OtC0NlDRXaPHiOms/x7ErI2iV6V0C0fYS2A76I1nV/k=; b=lBAmiUJgM0E/nS+RFY7MNOSn6RwIdQhCF8Y1/M0yw9XMWX+gfY5zxsrKrc4U0lQU0a XqDrvU4WzTAU4A0Yl0o33Ogcyigd6QBMb1wiK6QabnIMsQ2fkXAZst5LV0G7C+ZH6J9u eBVuctiXb9OHovHOJzcmmfgbfX/KshL7zCRMoFosV5TyeVthaIT9oFneKnUYh1hpMGA1 H8431kCwBy9vIM3KqyzYGKFEE7Vz3Oo7rUuvBX0CXMky3oxq8qJkYurHHTZnIyT2Oje0 bAlXmlzM6Rq9VkBkieHzWSlSTMSIIJ5/YcquzHejCvTaQaT3YyU1OAHJqGkaeCmQM7zk 9G6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@pensando.io header.s=google header.b=X4DBOBf2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k12si12663635eds.497.2021.08.22.18.35.03; Sun, 22 Aug 2021 18:35:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@pensando.io header.s=google header.b=X4DBOBf2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229746AbhHWBcb (ORCPT + 99 others); Sun, 22 Aug 2021 21:32:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231452AbhHWBcb (ORCPT ); Sun, 22 Aug 2021 21:32:31 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CC84C061756 for ; Sun, 22 Aug 2021 18:31:49 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id d6so23738984edt.7 for ; Sun, 22 Aug 2021 18:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pensando.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OtC0NlDRXaPHiOms/x7ErI2iV6V0C0fYS2A76I1nV/k=; b=X4DBOBf28h5df5hk21oGJWvsdMuI8PBKQcBrPuAY2M4HDdDqEBpbSyW44QV2zS1FRO /Nkg3FYrhppGV0aT6TQQj++5SY0t1HqHGQV3RjY3sGpepJnStvDMjUNSClXIi7Reiyf1 /qBzQGOw01pvHPANXJYerYNTk1ctKno5A5gB3U1meEETdNthXkwHFk9FnpT1LZ9ui7rf t/ZJo0Ih4SafJyuvjgXv6DXbjTYA0LjpUQUhAhulTH8jTT1UgkjjJm/xehVZ5L8w7e/n 3S/r/BR0XxNOZVFV76ecqodkFBP5sZn12ytdEc8lLd7KqU594XvovIsa7b9OhzU3Zbog vZmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OtC0NlDRXaPHiOms/x7ErI2iV6V0C0fYS2A76I1nV/k=; b=LPLLgPgxYb0dp/fYj0ueaF4iHsUOx3jRXte6Ub/WwrCCQsdZpRmPk/UGmbvwYm5HDh ug9IkH4umOyILulOO70eE67m0Kz5PipcZ6hZqTpqHx7MlIDoVBeMWWl0XJ7DNDaQVRh6 VPXPAm19DnwYLmsJE7sL4gGcYwfAkE53qF3Udh0sT60thXPaY+hjpeWv15z0Kvt6TBCb stOfh1i7mUZa7Tu4GYXuKFw8ZTLGAVD9e/yTmstxFNYIiwAi+LI1/Wmwul/MNqOlJslI p03YdIKk0OqFb9ZFdMR4ox5nARn5rLW08qS0beiTlCU4Eu5/0pmS/ov4zq62a6EYrByX 7OHw== X-Gm-Message-State: AOAM5316GcVstTLt3qjAgqq5ikiSMu5l2JIeV8tUxq2C0Gte9yrOGWZ4 IOEP/6U6sUe7N7MU5MU5R5pK8ds5FMAvHbQZcspnBQ== X-Received: by 2002:a05:6402:4cb:: with SMTP id n11mr34347934edw.292.1629682307653; Sun, 22 Aug 2021 18:31:47 -0700 (PDT) MIME-Version: 1.0 References: <20210329015938.20316-1-brad@pensando.io> <20210329015938.20316-6-brad@pensando.io> In-Reply-To: From: Brad Larson Date: Sun, 22 Aug 2021 18:31:37 -0700 Message-ID: Subject: Re: [PATCH v2 05/13] mmc: sdhci-cadence: Add Pensando Elba SoC support To: Masahiro Yamada Cc: Ulf Hansson , Adrian Hunter , linux-mmc , Linux ARM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yamada-san, On Fri, Apr 9, 2021 at 1:25 AM Masahiro Yamada wrote: > > On Tue, Mar 30, 2021 at 7:31 PM Ulf Hansson wrote: > > > > + Masahiro Yamada (main author of the driver) > > > > On Mon, 29 Mar 2021 at 03:59, Brad Larson wrote: > > > > > > Add support for Pensando Elba SoC which explicitly controls > > > byte-lane enables on writes. Refactor to allow platform > > > specific write ops. > > > > > > Signed-off-by: Brad Larson > > > --- > > > drivers/mmc/host/Kconfig | 15 +++ > > > drivers/mmc/host/Makefile | 1 + > > > drivers/mmc/host/sdhci-cadence-elba.c | 137 ++++++++++++++++++++++++++ > > > > By looking at the amount of code changes that seem to be needed to > > support the Pensando Elba variant, I don't think it's necessary to > > split this into a separate file. > > > > Unless Yamada-san has a different opinion, I would rather just stick > > with using sdhci-cadence.c. > > > I agree with Ulf. I've folded Elba SoC support into sdhci-cadence.c. > BTW, this patch cannot probe > "pensando,elba-emmc" > when CONFIG_MMC_SDHCI_CADENCE_ELBA=m. Right, that issue is gone now. There is no separate sdhci-cadence-elba.c > > > +#define SDIO_REG_HRS4 0x10 > > This is the same as SDHCI_CDNS_HRS04 > > > > > > +#define REG_DELAY_HS 0x00 > > This is the same as SDHCI_CDNS_PHY_DLY_SD_HS > > > > > +#define REG_DELAY_DEFAULT 0x01 > > > This is the same as SDHCI_CDNS_PHY_DLY_SD_DEFAULT > > > > > > +#define REG_DELAY_UHSI_SDR50 0x04 > > This is the same as SDHCI_CDNS_PHY_DLY_UHS_SDR50 > > > > > > +#define REG_DELAY_UHSI_DDR50 0x05 > > > This is the same as SDHCI_CDNS_PHY_DLY_UHS_DDR50 > All of those redundant definitions are gone, I'm now using the existing definitions you're identifying. > > > + > > > +static void elba_write_l(struct sdhci_host *host, u32 val, int reg) > > > +{ > > > + struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host); > > > + unsigned long flags; > > > + > > > + spin_lock_irqsave(&priv->wrlock, flags); > > > + writel(0x78, priv->ctl_addr); > > > + writel(val, host->ioaddr + reg); > > > + spin_unlock_irqrestore(&priv->wrlock, flags); > > > +} [...] > > > +static void elba_priv_write_l(struct sdhci_cdns_priv *priv, > > > + u32 val, void __iomem *reg) > > > +{ > > > + unsigned long flags; > > > + > > > + spin_lock_irqsave(&priv->wrlock, flags); > > > + writel(0x78, priv->ctl_addr); > > > + writel(val, reg); > > > + spin_unlock_irqrestore(&priv->wrlock, flags); > > > +} > > > Maybe, can this avoid code duplication? > > static void elba_hrs_write_l(struct sdhci_cdns_priv *priv, > u32 val, int reg) > { > unsigned long flags; > > spin_lock_irqsave(&priv->wrlock, flags); > writel(0x78, priv->ctl_addr); > writel(val, priv->hrs_addr + reg); > spin_unlock_irqrestore(&priv->wrlock, flags); > } > > static void elba_write_l(struct sdhci_host *host, u32 val, int reg) > { > elba_hrs_write_l(sdhci_cdns_priv(host), val, SDHCI_CDNS_SRS_BASE + reg); > } Yes, some code can be reduced. This is the current implementation I propose to include with the v3 patchset /* * The Pensando Elba SoC explicitly controls byte-lane enables on writes * which includes writes to the HRS registers. */ static void elba_priv_write_l(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg) { unsigned long flags; spin_lock_irqsave(&priv->wrlock, flags); writel(0x78, priv->ctl_addr); writel(val, reg); spin_unlock_irqrestore(&priv->wrlock, flags); } static void elba_write_l(struct sdhci_host *host, u32 val, int reg) { elba_priv_write_l(sdhci_cdns_priv(host), val, host->ioaddr + reg); } > > > +static void sd4_set_dlyvr(struct sdhci_host *host, > > > + unsigned char addr, unsigned char data) > > > > Please, try to think of a better function name that's more > > descriptive. Moreover, please use a common prefix for functions that > > is used on elba. This function is removed and the existing sdhci_cdns_phy_init() is used with DT properties > > > +{ > > > + unsigned long dlyrv_reg; > > > + > > > + dlyrv_reg = ((unsigned long)data << 8); > > > + dlyrv_reg |= addr; > > > + > > > + // set data and address > > > + writel(dlyrv_reg, host->ioaddr + SDIO_REG_HRS4); > > > + dlyrv_reg |= (1uL << 24uL); > > > + // send write request > > > + writel(dlyrv_reg, host->ioaddr + SDIO_REG_HRS4); > > > + dlyrv_reg &= ~(1uL << 24); > > > + // clear write request > > > + writel(dlyrv_reg, host->ioaddr + SDIO_REG_HRS4); > > > This seems to be equivalent to sdhci_cdns_write_phy_reg(). Yes after looking at the implementation it is, there was nothing special required for Elba. I've refactored and the function sdhci_cdns_write_phy_reg() which is used in sdhci_cdns_phy_init() dependent on DT properties is now used for Elba phy init. > > > +static void phy_config(struct sdhci_host *host) > > > > Ditto. > > > > > +{ > > > + sd4_set_dlyvr(host, REG_DELAY_DEFAULT, 0x04); > > > + sd4_set_dlyvr(host, REG_DELAY_HS, 0x04); > > > + sd4_set_dlyvr(host, REG_DELAY_UHSI_SDR50, 0x06); > > > + sd4_set_dlyvr(host, REG_DELAY_UHSI_DDR50, 0x16); > > > Hard-code board (or chip) specific parameters to the driver? > > This should go to DT properties. > > See Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml Exactly, v3 of the patchset will incorporate this recommendation. In the case of Elba SoC these are the DT properties being used cdns,phy-input-delay-sd-highspeed = <0x4>; cdns,phy-input-delay-legacy = <0x4>; cdns,phy-input-delay-sd-uhs-sdr50 = <0x6>; cdns,phy-input-delay-sd-uhs-ddr50 = <0x16>; > > > +static int elba_drv_init(struct platform_device *pdev) > > > +{ > > > + struct sdhci_host *host = platform_get_drvdata(pdev); > > > + struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host); > > > + struct resource *iomem; > > > + void __iomem *ioaddr; > > > + > > > + host->mmc->caps |= (MMC_CAP_1_8V_DDR | MMC_CAP_8_BIT_DATA); > > > + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 1); > > > + if (!iomem) > > > + return -ENOMEM; > > > + ioaddr = devm_ioremap_resource(&pdev->dev, iomem); > > > + if (IS_ERR(ioaddr)) > > > + return PTR_ERR(ioaddr); > > > > Use devm_platform_ioremap_resource(pdev, 1) Replaced devm_ioremap_resource(&pdev->dev, iomem) with devm_platform_ioremap_resource(pdev, 1). The change will be in v3 of the patchset. Regards, Brad