[PATCH v3 2/3] mmc: tmio: fix reset operation
From: Niklas Söderlund
SD / MMC did not operate properly when suspend transition failed.
Because the SCC was not reset at resume, issue of the command failed.
Call the host specific reset function and reset the hardware in order to
add reset of SCC. This change also fixes tuning on some stubborn cards
on Gen2.
Based on work from Masaharu Hayakawa.
Signed-off-by: Niklas Söderlund
---
* Changes sine v1
- Merge tmio_mmc_reset() into tmio_mmc_hw_reset() as it's now the only
caller.
* Changes since v2
- Rebased on mmc/next caused small refactoring of the code.
---
drivers/mmc/host/tmio_mmc_core.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 953562a12a0d6ebc..662161be03b6d52e 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -171,6 +171,18 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
}
}
+static void tmio_mmc_hw_reset(struct mmc_host *mmc)
+{
+ struct tmio_mmc_host *host = mmc_priv(mmc);
+
+ host->reset(host);
+
+ tmio_mmc_abort_dma(host);
+
+ if (host->hw_reset)
+ host->hw_reset(host);
+}
+
static void tmio_mmc_reset_work(struct work_struct *work)
{
struct tmio_mmc_host *host = container_of(work, struct tmio_mmc_host,
@@ -209,7 +221,7 @@ static void tmio_mmc_reset_work(struct work_struct *work)
spin_unlock_irqrestore(>lock, flags);
- host->reset(host);
+ tmio_mmc_hw_reset(host->mmc);
/* Ready for new calls */
host->mrq = NULL;
@@ -696,14 +708,6 @@ static int tmio_mmc_start_data(struct tmio_mmc_host *host,
return 0;
}
-static void tmio_mmc_hw_reset(struct mmc_host *mmc)
-{
- struct tmio_mmc_host *host = mmc_priv(mmc);
-
- if (host->hw_reset)
- host->hw_reset(host);
-}
-
static int tmio_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
{
struct tmio_mmc_host *host = mmc_priv(mmc);
@@ -1228,7 +1232,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
_host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
_host->set_clock(_host, 0);
- _host->reset(_host);
+ tmio_mmc_hw_reset(mmc);
_host->sdcard_irq_mask = sd_ctrl_read16_and_16_as_32(_host,
CTL_IRQ_MASK);
tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL);
@@ -1329,7 +1333,7 @@ int tmio_mmc_host_runtime_resume(struct device *dev)
struct tmio_mmc_host *host = dev_get_drvdata(dev);
tmio_mmc_clk_enable(host);
- host->reset(host);
+ tmio_mmc_hw_reset(host->mmc);
if (host->clk_cache)
host->set_clock(host, host->clk_cache);
--
2.19.1
[PATCH v3 0/3] mmc: tmio: fix reset operation
From: Niklas Söderlund Hi, While looking at the Renesas BSP kernel I found patches which improves the state of the hardware at probe and after runtime resume. Patch 1/3 make sure the module clock is enabled after resuming before register are accessed. Patch 2/3 is the real change in this series and brings in reset of the vendor specific callback when resetting (SCC in the Renesas case). While 3/3 simply make sure that the IRQ mask for Renesas boards (Gen2 and later) are in a good shape after probe (and reset). In addition to addressing the state after resuming it helped unbreak a SD card I have which are very problematic on Koelsch. Without this series inserting the card results in: sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) sh_mobile_sdhi ee10.sd: Tuning procedure failed mmc0: tuning execution failed: -5 mmc0: error -5 whilst initialising SD card sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) While with this series applied (patch 2/3): sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19) mmc0: new ultra high speed SDR50 SDHC card at address mmcblk0: mmc0: SU04G 3.69 GiB mmcblk0: p1 p2 Patch 1/3 was previously part of 2/3 but as it deals with a unrelated issue it's here broken out to a separate patch. Patch 3/3 have once been posted outside this series bit after comments from Wolfram it's brought back as it now deepens on 2/3. Most changes in this series are based on similar work from Masaharu Hayakawa but for this version all changes now differ quiet a lot from his work. All mails sent to him bounce with a "Undelivered Mail Returned to Sender" error. I therefor felt the need to claim authorship as I don't want to post blame of my (potential) mistakes on some else. Niklas Söderlund (3): mmc: tmio: enable module clock before resetting when resuming mmc: tmio: fix reset operation mmc: renesas_sdhi: add initial setting of interrupt mask register drivers/mmc/host/renesas_sdhi_core.c | 4 drivers/mmc/host/tmio_mmc.h | 1 + drivers/mmc/host/tmio_mmc_core.c | 26 +++--- 3 files changed, 20 insertions(+), 11 deletions(-) -- 2.19.1
[PATCH v3 1/3] mmc: tmio: enable module clock before resetting when resuming
From: Niklas Söderlund
On runtime power management resume, the host clock needs to be
enabled before calling tmio_mmc_reset. If the mmc device has a power
domain entry, the host clock is enabled via genpd_runtime_resume,
running before tmio_mmc_host_runtime_resume. If the mmc device has no
power domain entry, however, genpd_runtime_resume is not called. This
patch changes tmio_mmc_host_runtime_resume to enable the host clock
before calling tmio_mmc_reset.
Based on work from Masaharu Hayakawa.
Signed-off-by: Niklas Söderlund
---
drivers/mmc/host/tmio_mmc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 8d64f6196f33e882..953562a12a0d6ebc 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1328,8 +1328,8 @@ int tmio_mmc_host_runtime_resume(struct device *dev)
{
struct tmio_mmc_host *host = dev_get_drvdata(dev);
- host->reset(host);
tmio_mmc_clk_enable(host);
+ host->reset(host);
if (host->clk_cache)
host->set_clock(host, host->clk_cache);
--
2.19.1
[PATCH v3 3/3] mmc: renesas_sdhi: add initial setting of interrupt mask register
From: Niklas Söderlund The initial value of the interrupt mask register may be different from the H/W manual at the startup of the kernel by setting from the bootloader. Since the error interrupts may be unmasked, the driver sets initial value. The initial value is only known for R-Car Gen2 and Gen3 platforms so limit the initialization to those platforms. Based on work from Masaharu Hayakawa. Signed-off-by: Niklas Söderlund --- * Changes since v1 - Limit the initialization to Gen2+ platforms by checking the TMIO_MMC_MIN_RCAR2 flag. - Rename the constant for the initialization value to reflect it's only for R-Car Gen2+ platforms. - Move setting of the initial mask to renesas_sdhi. --- drivers/mmc/host/renesas_sdhi_core.c | 4 drivers/mmc/host/tmio_mmc.h | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c index d3ac43c3d0b655dc..f2162f2b7de3ae05 100644 --- a/drivers/mmc/host/renesas_sdhi_core.c +++ b/drivers/mmc/host/renesas_sdhi_core.c @@ -532,6 +532,10 @@ static void renesas_sdhi_hw_reset(struct tmio_mmc_host *host) sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL, ~SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN & sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL)); + + if (host->pdata->flags & TMIO_MMC_MIN_RCAR2) + sd_ctrl_write32_as_16_and_16(host, CTL_IRQ_MASK, +TMIO_MASK_INIT_RCAR2); } static int renesas_sdhi_wait_idle(struct tmio_mmc_host *host, u32 bit) diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h index 1e317027bf534612..5f6dfb86e43e8208 100644 --- a/drivers/mmc/host/tmio_mmc.h +++ b/drivers/mmc/host/tmio_mmc.h @@ -96,6 +96,7 @@ /* Define some IRQ masks */ /* This is the mask used at reset by the chip */ +#define TMIO_MASK_INIT_RCAR2 0x8b7f031d /* Initial value for R-Car Gen2+ */ #define TMIO_MASK_ALL 0x837f031d #define TMIO_MASK_READOP (TMIO_STAT_RXRDY | TMIO_STAT_DATAEND) #define TMIO_MASK_WRITEOP (TMIO_STAT_TXRQ | TMIO_STAT_DATAEND) -- 2.19.1
[PATCH] arm64: dts: renesas: enable HS400 on R-Car Gen3
From: Niklas Söderlund Successfully tested on H3 ES2.0 and M3-N ES1.0. Transfer rates where >160MB/s for H3 and >200MB/s for M3-N. Signed-off-by: Niklas Söderlund --- arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 + arch/arm64/boot/dts/renesas/ulcb.dtsi| 1 + 2 files changed, 2 insertions(+) --- Hi Simon, This patch have quiet a few dependencies I'm afraid, let me know if you wish to be notified once they all upstream. I don't think it's a good idea to pick this up before all dependencies are resolved. - [PATCH] mmc: renesas_sdhi: remove workaround for HS400 clock - [PATCH v3 0/3] mmc: tmio: fix reset operation - [PATCH v2 0/3] mmc: renesas_sdhi: extend quirk selection to handle ES revisions - [PATCH 0/2] renesas: rcar-gen3: add HS400 quirk for SD clock diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi index d28ae95405f1152b..6bc041cc63bdc81b 100644 --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi @@ -762,6 +762,7 @@ vqmmc-supply = <_1p8v>; bus-width = <8>; mmc-hs200-1_8v; + mmc-hs400-1_8v; non-removable; fixed-emmc-driver-type = <1>; status = "okay"; diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi index 7e6078508ba0ba19..88d03177ae2b327c 100644 --- a/arch/arm64/boot/dts/renesas/ulcb.dtsi +++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi @@ -430,6 +430,7 @@ vqmmc-supply = <_1p8v>; bus-width = <8>; mmc-hs200-1_8v; + mmc-hs400-1_8v; non-removable; status = "okay"; }; -- 2.19.1
[PATCH 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
From: Niklas Söderlund
On H3 (ES1.0,ES2.0) and M3-W (ES1.0,ES1.1) the clock setting for HS400
needs a quirk to function properly. The reason for the quirk is that
there are two settings which produces same divider vale for the SDn
clock. On the effected boards the one currently selected results in HS00
not working.
This change uses the same method as the Gen2 CPG driver and simply
ignores the first clock setting as this is the offending one when
selecting the settings. Which of the two possible settings is used have
no effect for SDR104.
Signed-off-by: Niklas Söderlund
---
drivers/clk/renesas/rcar-gen3-cpg.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c
b/drivers/clk/renesas/rcar-gen3-cpg.c
index ff56ac6134111c38..8cc524a29c855dd2 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -227,6 +227,7 @@ struct sd_clock {
unsigned int div_min;
unsigned int div_max;
unsigned int cur_div_idx;
+ bool skip_first;
};
/* SDn divider
@@ -243,6 +244,10 @@ struct sd_clock {
* 1 0 2 (4) 0 (2) 8
* 1 0 3 (8) 0 (2) 16
* 1 0 4 (16) 0 (2) 32
+ *
+ * NOTE: There is a quirk option to ignore the first row of the dividers
+ * table when searching for suitable settings. This is because HS400 on
+ * early ES versions of H3 and M3-W requires a specific setting to work.
*/
static const struct sd_div_table cpg_sd_div_table[] = {
/* CPG_SD_DIV_TABLE_DATA(stp_hck, stp_ck, sd_srcfc, sd_fc, sd_div) */
@@ -327,7 +332,7 @@ static int cpg_sd_clock_set_rate(struct clk_hw *hw,
unsigned long rate,
u32 val;
unsigned int i;
- for (i = 0; i < clock->div_num; i++)
+ for (i = clock->skip_first ? 1 : 0; i < clock->div_num; i++)
if (div == clock->div_table[i].div)
break;
@@ -355,7 +360,7 @@ static const struct clk_ops cpg_sd_clock_ops = {
static struct clk * __init cpg_sd_clk_register(const struct cpg_core_clk *core,
void __iomem *base, const char *parent_name,
- struct raw_notifier_head *notifiers)
+ struct raw_notifier_head *notifiers, bool skip_first)
{
struct clk_init_data init;
struct sd_clock *clock;
@@ -377,6 +382,7 @@ static struct clk * __init cpg_sd_clk_register(const struct
cpg_core_clk *core,
clock->hw.init =
clock->div_table = cpg_sd_div_table;
clock->div_num = ARRAY_SIZE(cpg_sd_div_table);
+ clock->skip_first = skip_first;
sd_fc = readl(clock->csn.reg) & CPG_SD_FC_MASK;
for (i = 0; i < clock->div_num; i++)
@@ -417,19 +423,28 @@ static u32 cpg_quirks __initdata;
#define PLL_ERRATA BIT(0) /* Missing PLL0/2/4 post-divider */
#define RCKCR_CKSELBIT(1) /* Manual RCLK parent selection */
+#define SD_SKIP_FIRST BIT(2) /* Skip first clock in SD table */
static const struct soc_device_attribute cpg_quirks_match[] __initconst = {
{
.soc_id = "r8a7795", .revision = "ES1.0",
- .data = (void *)(PLL_ERRATA | RCKCR_CKSEL),
+ .data = (void *)(PLL_ERRATA | RCKCR_CKSEL | SD_SKIP_FIRST),
},
{
.soc_id = "r8a7795", .revision = "ES1.*",
- .data = (void *)RCKCR_CKSEL,
+ .data = (void *)(RCKCR_CKSEL | SD_SKIP_FIRST),
+ },
+ {
+ .soc_id = "r8a7795", .revision = "ES2.0",
+ .data = (void *)SD_SKIP_FIRST,
},
{
.soc_id = "r8a7796", .revision = "ES1.0",
- .data = (void *)RCKCR_CKSEL,
+ .data = (void *)(RCKCR_CKSEL | SD_SKIP_FIRST),
+ },
+ {
+ .soc_id = "r8a7796", .revision = "ES1.1",
+ .data = (void *)SD_SKIP_FIRST,
},
{ /* sentinel */ }
};
@@ -504,7 +519,8 @@ struct clk * __init rcar_gen3_cpg_clk_register(struct
device *dev,
case CLK_TYPE_GEN3_SD:
return cpg_sd_clk_register(core, base, __clk_get_name(parent),
- notifiers);
+ notifiers,
+ cpg_quirks & SD_SKIP_FIRST);
case CLK_TYPE_GEN3_R:
if (cpg_quirks & RCKCR_CKSEL) {
--
2.19.1
[PATCH 0/2] renesas: rcar-gen3: add HS400 quirk for SD clock
From: Niklas Söderlund
Hi Geert,
This is the result of the SDHI hackathon for a possible solution to the
clock issue on early ES versions. It is based on the Gen2 solution where
a row of the possible clock settings are ignored on the effected SoC+ES
versions. The first row is not effected when reading settings left by
the bootloader, only when the setting the clock.
This is tested on H3 (ES1.0, ES2.0), M3-W (ES1.0) and M3-N together with
patches to enable HS400 with great results. No regressions found for
eMMC HS200/HS400 modes nor for SDR{25,50,104} on any of the SoCs.
Patch 1/2 adds documentation on which settings is used while 2/2 is the
real change where the quirk is implemented.
Niklas Söderlund (2):
clk: renesas: rcar-gen3: add documentation for SD clocks
clk: renesas: rcar-gen3: add HS400 quirk for SD clock
drivers/clk/renesas/rcar-gen3-cpg.c | 38 -
1 file changed, 27 insertions(+), 11 deletions(-)
--
2.19.1
[PATCH 1/2] clk: renesas: rcar-gen3: add documentation for SD clocks
From: Niklas Söderlund
Document the known use cases of the different clock settings. This is
useful as different SoC and ES versions uses different settings to do
the same thing as there are more then one combination to achieve the
same SDn clock speed.
Signed-off-by: Niklas Söderlund
---
drivers/clk/renesas/rcar-gen3-cpg.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c
b/drivers/clk/renesas/rcar-gen3-cpg.c
index 628b63b85d3f09c5..ff56ac6134111c38 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -233,13 +233,13 @@ struct sd_clock {
* sd_srcfc sd_fc div
* stp_hck stp_ck(div) (div) = sd_srcfc x sd_fc
*---
- * 0 0 0 (1) 1 (4) 4
- * 0 0 1 (2) 1 (4) 8
- * 1 0 2 (4) 1 (4) 16
- * 1 0 3 (8) 1 (4) 32
+ * 0 0 0 (1) 1 (4) 4 : SDR104 / HS200 / HS400 (8
TAP)
+ * 0 0 1 (2) 1 (4) 8 : SDR50
+ * 1 0 2 (4) 1 (4) 16 : HS / SDR25
+ * 1 0 3 (8) 1 (4) 32 : NS / SDR12
* 1 0 4 (16) 1 (4) 64
* 0 0 0 (1) 0 (2) 2
- * 0 0 1 (2) 0 (2) 4
+ * 0 0 1 (2) 0 (2) 4 : SDR104 / HS200 / HS400 (4
TAP)
* 1 0 2 (4) 0 (2) 8
* 1 0 3 (8) 0 (2) 16
* 1 0 4 (16) 0 (2) 32
--
2.19.1
[PATCH v2 3/3] mmc: renesas_sdhi: disable HS400 on H3 ES1.x and M3-W ES1.x
From: Niklas Söderlund
The Renesas BSP confirms that H3 ES1.x and M3-W ES1.x do not properly
support HS400. Add a quirk to indicate this and disable HS400 in the MMC
capabilities if the quirk is set.
Signed-off-by: Niklas Söderlund
---
drivers/mmc/host/renesas_sdhi_core.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_core.c
b/drivers/mmc/host/renesas_sdhi_core.c
index 19d89b4dda64c13c..ed2c406fd62b5c7d 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -47,6 +47,7 @@
#define SDHI_VER_GEN3_SDMMC0xcd10
struct renesas_sdhi_quirks {
+ bool hs400_disabled;
bool hs400_4taps;
};
@@ -607,15 +608,21 @@ static void renesas_sdhi_enable_dma(struct tmio_mmc_host
*host, bool enable)
renesas_sdhi_sdbuf_width(host, enable ? width : 16);
}
-static const struct renesas_sdhi_quirks sdhi_quirks_h3_m3w = {
+static const struct renesas_sdhi_quirks sdhi_quirks_h3_m3w_es1 = {
+ .hs400_disabled = true,
+ .hs400_4taps = true,
+};
+
+static const struct renesas_sdhi_quirks sdhi_quirks_h3_es2 = {
+ .hs400_disabled = false,
.hs400_4taps = true,
};
static const struct soc_device_attribute sdhi_quirks_match[] = {
- { .soc_id = "r8a7795", .revision = "ES1.*", .data = _quirks_h3_m3w
},
- { .soc_id = "r8a7795", .revision = "ES2.0", .data = _quirks_h3_m3w
},
- { .soc_id = "r8a7796", .revision = "ES1.0", .data = _quirks_h3_m3w
},
- { .soc_id = "r8a7796", .revision = "ES1.1", .data = _quirks_h3_m3w
},
+ { .soc_id = "r8a7795", .revision = "ES1.*", .data =
_quirks_h3_m3w_es1 },
+ { .soc_id = "r8a7795", .revision = "ES2.0", .data = _quirks_h3_es2
},
+ { .soc_id = "r8a7796", .revision = "ES1.0", .data =
_quirks_h3_m3w_es1 },
+ { .soc_id = "r8a7796", .revision = "ES1.1", .data =
_quirks_h3_m3w_es1 },
{ /* Sentinel. */ },
};
@@ -704,6 +711,9 @@ int renesas_sdhi_probe(struct platform_device *pdev,
host->multi_io_quirk= renesas_sdhi_multi_io_quirk;
host->dma_ops = dma_ops;
+ if (quirks && quirks->hs400_disabled)
+ host->mmc->caps2 &= ~(MMC_CAP2_HS400 | MMC_CAP2_HS400_ES);
+
if (quirks && quirks->hs400_4taps)
mmc_data->flags |= TMIO_MMC_HAVE_4TAP_HS400;
--
2.19.1
[PATCH v2 0/3] mmc: renesas_sdhi: extend quirk selection to handle ES revisions
From: Niklas Söderlund Hi, Recent datasheet updates have made it clear that some quirks are not SoC specific but SoC + ES version specific. Currently the quirks are selected using compatibility values but whit this new information that is not enough. Patch 1/3 adds support to select quirks based on SoC + ES revision using soc_device_match() and converts the only existing quirk. Patch 2/3 Removes the old method to select quirk based on compatibility string. While Patch 3/3 adds a new quirk from the BSP which blacklists some known problematic ES versions for HS400. HS400 is not yet enabled upstream so blacklisting these ES versions is not a regression of functionality. Based on mmc/next and tested on H3 and M3-N. Niklas Söderlund (3): mmc: renesas_sdhi: handle 4tap hs400 mode quirk based on SoC revision mmc: renesas_sdhi: align compatibility properties for H3 and M3-W mmc: renesas_sdhi: disable HS400 on H3 ES1.x and M3-W ES1.x drivers/mmc/host/renesas_sdhi_core.c | 36 +++ drivers/mmc/host/renesas_sdhi_internal_dmac.c | 20 ++- drivers/mmc/host/renesas_sdhi_sys_dmac.c | 20 ++- 3 files changed, 41 insertions(+), 35 deletions(-) -- 2.19.1
[PATCH v2 1/3] mmc: renesas_sdhi: handle 4tap hs400 mode quirk based on SoC revision
From: Niklas Söderlund
Latest datasheet makes it clear that not all ES revisions of the H3 and
M3-W have the 4-tap HS400 mode quirk, currently the quirk is set
unconditionally for these two SoCs. Prepare to handle the quirk based on
SoC revision instead of compatibility value by using soc_device_match()
and set the TMIO_MMC_HAVE_4TAP_HS400 flag explicitly.
The reason for adding a new quirks struct instead of just a flag is that
looking ahead it seems more quirks needs to be handled in a SoC revision
basis.
Signed-off-by: Niklas Söderlund
---
drivers/mmc/host/renesas_sdhi_core.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/mmc/host/renesas_sdhi_core.c
b/drivers/mmc/host/renesas_sdhi_core.c
index d3ac43c3d0b655dc..19d89b4dda64c13c 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "renesas_sdhi.h"
#include "tmio_mmc.h"
@@ -45,6 +46,10 @@
#define SDHI_VER_GEN3_SD 0xcc10
#define SDHI_VER_GEN3_SDMMC0xcd10
+struct renesas_sdhi_quirks {
+ bool hs400_4taps;
+};
+
static void renesas_sdhi_sdbuf_width(struct tmio_mmc_host *host, int width)
{
u32 val;
@@ -602,11 +607,25 @@ static void renesas_sdhi_enable_dma(struct tmio_mmc_host
*host, bool enable)
renesas_sdhi_sdbuf_width(host, enable ? width : 16);
}
+static const struct renesas_sdhi_quirks sdhi_quirks_h3_m3w = {
+ .hs400_4taps = true,
+};
+
+static const struct soc_device_attribute sdhi_quirks_match[] = {
+ { .soc_id = "r8a7795", .revision = "ES1.*", .data = _quirks_h3_m3w
},
+ { .soc_id = "r8a7795", .revision = "ES2.0", .data = _quirks_h3_m3w
},
+ { .soc_id = "r8a7796", .revision = "ES1.0", .data = _quirks_h3_m3w
},
+ { .soc_id = "r8a7796", .revision = "ES1.1", .data = _quirks_h3_m3w
},
+ { /* Sentinel. */ },
+};
+
int renesas_sdhi_probe(struct platform_device *pdev,
const struct tmio_mmc_dma_ops *dma_ops)
{
struct tmio_mmc_data *mmd = pdev->dev.platform_data;
+ const struct renesas_sdhi_quirks *quirks = NULL;
const struct renesas_sdhi_of_data *of_data;
+ const struct soc_device_attribute *attr;
struct tmio_mmc_data *mmc_data;
struct tmio_mmc_dma *dma_priv;
struct tmio_mmc_host *host;
@@ -616,6 +635,10 @@ int renesas_sdhi_probe(struct platform_device *pdev,
of_data = of_device_get_match_data(>dev);
+ attr = soc_device_match(sdhi_quirks_match);
+ if (attr)
+ quirks = attr->data;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -EINVAL;
@@ -681,6 +704,9 @@ int renesas_sdhi_probe(struct platform_device *pdev,
host->multi_io_quirk= renesas_sdhi_multi_io_quirk;
host->dma_ops = dma_ops;
+ if (quirks && quirks->hs400_4taps)
+ mmc_data->flags |= TMIO_MMC_HAVE_4TAP_HS400;
+
/* For some SoC, we disable internal WP. GPIO may override this */
if (mmc_can_gpio_ro(host->mmc))
mmc_data->capabilities2 &= ~MMC_CAP2_NO_WRITE_PROTECT;
--
2.19.1
[PATCH v2 2/3] mmc: renesas_sdhi: align compatibility properties for H3 and M3-W
From: Niklas Söderlund
It was though all ES revisions of H3 and M3-W SoCs required the
TMIO_MMC_HAVE_4TAP_HS400 flag. Recent datasheet updates tells us this is
not true, only early ES revisions of the SoC do.
Since quirk matching based on ES revisions is now used to handle the
flag it's possible to align all Gen3 compatibility properties. This will
allow later ES revisions of H3 and M3-W to use the correct 8-tap HS400
mode.
Signed-off-by: Niklas Söderlund
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 20 ++-
drivers/mmc/host/renesas_sdhi_sys_dmac.c | 20 +++
2 files changed, 5 insertions(+), 35 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index b6f54102bfdd3a76..68abe042e9f765ad 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -81,22 +81,6 @@ static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
},
};
-static const struct renesas_sdhi_of_data of_rcar_r8a7795_compatible = {
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL |
- TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2 |
- TMIO_MMC_HAVE_4TAP_HS400,
- .capabilities = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
- MMC_CAP_CMD23,
- .capabilities2 = MMC_CAP2_NO_WRITE_PROTECT,
- .bus_shift = 2,
- .scc_offset = 0x1000,
- .taps = rcar_gen3_scc_taps,
- .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
- /* DMAC can handle 0x blk count but only 1 segment */
- .max_blk_count = 0x,
- .max_segs = 1,
-};
-
static const struct renesas_sdhi_of_data of_rcar_gen3_compatible = {
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL |
TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
@@ -114,8 +98,8 @@ static const struct renesas_sdhi_of_data
of_rcar_gen3_compatible = {
static const struct of_device_id renesas_sdhi_internal_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-mmc-r8a77470", .data =
_rcar_gen3_compatible, },
- { .compatible = "renesas,sdhi-r8a7795", .data =
_rcar_r8a7795_compatible, },
- { .compatible = "renesas,sdhi-r8a7796", .data =
_rcar_r8a7795_compatible, },
+ { .compatible = "renesas,sdhi-r8a7795", .data =
_rcar_gen3_compatible, },
+ { .compatible = "renesas,sdhi-r8a7796", .data =
_rcar_gen3_compatible, },
{ .compatible = "renesas,rcar-gen3-sdhi", .data =
_rcar_gen3_compatible, },
{},
};
diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index 1a4016f635d398c2..8471160316e073c5 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -75,19 +75,6 @@ static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
},
};
-static const struct renesas_sdhi_of_data of_rcar_r8a7795_compatible = {
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL |
- TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2 |
- TMIO_MMC_HAVE_4TAP_HS400,
- .capabilities = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
- MMC_CAP_CMD23,
- .capabilities2 = MMC_CAP2_NO_WRITE_PROTECT,
- .bus_shift = 2,
- .scc_offset = 0x1000,
- .taps = rcar_gen3_scc_taps,
- .taps_num = ARRAY_SIZE(rcar_gen3_scc_taps),
-};
-
static const struct renesas_sdhi_of_data of_rcar_gen3_compatible = {
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL |
TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
@@ -114,8 +101,8 @@ static const struct of_device_id
renesas_sdhi_sys_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-r8a7792", .data =
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7793", .data =
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7794", .data =
_rcar_gen2_compatible, },
- { .compatible = "renesas,sdhi-r8a7795", .data =
_rcar_r8a7795_compatible, },
- { .compatible = "renesas,sdhi-r8a7796", .data =
_rcar_r8a7795_compatible, },
+ { .compatible = "renesas,sdhi-r8a7795", .data =
_rcar_gen3_compatible, },
+ { .compatible = "renesas,sdhi-r8a7796", .data =
_rcar_gen3_compatible, },
{ .compatible = "renesas,rcar-gen1-sdhi", .data =
_rcar_gen1_compatible, },
{ .compatible = "renesas,rcar-gen2-sdhi", .data =
_rcar_gen2_compatible, },
{ .compatible = "renesas,rcar-gen3-sdhi", .data =
_rcar_gen3_compatible, },
@@ -493,8 +480,7 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
static int renesas_sdhi_sys_dmac_probe(struct platform_device *pdev)
{
- if ((of_device_get_match_data(>dev) == _rcar_gen3_compatible ||
-
[PATCH] mmc: tmio: delete wait in tuning process
From: Masaharu Hayakawa The manual does not contain information that a wait is needed in the tuning process, this might be a leftover from early development. Removing the wait don't have any effect on operation so delete the wait to shorten the initialization time. Signed-off-by: Masaharu Hayakawa Signed-off-by: Takeshi Saito [Niklas: fixup commit message] Signed-off-by: Niklas Söderlund --- drivers/mmc/host/tmio_mmc_core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c index 8d64f6196f33e882..a8f917f744fb9f63 100644 --- a/drivers/mmc/host/tmio_mmc_core.c +++ b/drivers/mmc/host/tmio_mmc_core.c @@ -734,8 +734,6 @@ static int tmio_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode) ret = mmc_send_tuning(mmc, opcode, NULL); if (ret == 0) set_bit(i, host->taps); - - usleep_range(1000, 1200); } ret = host->select_tuning(host); -- 2.19.1
[PATCH] mmc: renesas_sdhi: remove workaround for HS400 clock
From: Niklas Söderlund The driver sets an incorrect clock and depends on the clock driver knowledge of this incorrect setting to still set a 200Mhz SDn clock. Instead of spreading the workaround between the two drivers the clock driver should be made aware of the ES versions where the special clock handling is needed no need to keep this workaround in the SDHI driver. Signed-off-by: Niklas Söderlund --- drivers/mmc/host/renesas_sdhi_core.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c index d3ac43c3d0b655dc..78bd117bbe65de46 100644 --- a/drivers/mmc/host/renesas_sdhi_core.c +++ b/drivers/mmc/host/renesas_sdhi_core.c @@ -163,15 +163,6 @@ static void renesas_sdhi_set_clock(struct tmio_mmc_host *host, if (new_clock == 0) goto out; - /* -* Both HS400 and HS200/SD104 set 200MHz, but some devices need to -* set 400MHz to distinguish the CPG settings in HS400. -*/ - if (host->mmc->ios.timing == MMC_TIMING_MMC_HS400 && - host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400 && - new_clock == 2) - new_clock = 4; - clock = renesas_sdhi_clk_update(host, new_clock) / 512; for (clk = 0x8080; new_clock >= (clock << 1); clk >>= 1) -- 2.19.1
Re: [PATCH] arm64: dts: renesas: condor: switch from EtherAVB to GEther
On 10/31/2018 5:30 PM, Simon Horman wrote:
The "official" Condor boards have always been wired to mount NFS via
GEther, not EtherAVB -- the boards resoldered for EtherAVB were local
to Cogent Embedded, so we've been having an unpleasant situation where
a "normal" Condor board still can't mount NFS (unless an EtherAVB PHY
extension board is plugged in). Switch from EtherAVB to GEther at last!
Fixes: 8091788f3d38 ("arm64: dts: renesas: condor: add EtherAVB support")
Signed-off-by: Sergei Shtylyov
Thanks, applied for v4.21.
Wait, this was intended as a fix for 4.20...
MBR, Sergei
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
On Wed, Oct 31, 2018 at 02:18:40PM +0100, jacopo mondi wrote:
> Hi Simon,
>
> On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> > On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > > Hi Jacopo,
> > >
> > > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > > > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > > > >> From: Koji Matsuoka
> > > > >>
> > > > >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device
> > > > >> tree.
> > > > >>
> > > > >> Signed-off-by: Koji Matsuoka
> > > > >> Signed-off-by: Takeshi Kihara
> > > > >> Signed-off-by: Jacopo Mondi
> > > > >> ---
> > > > >>
> > > > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > > > >>
> > > > >> 1 file changed, 79 insertions(+)
> > > > >>
> > > > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe
> > > > >> 100644
> > > > >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > >> @@ -337,6 +337,85 @@
> > > > >>
> > > > >> status = "disabled";
> > > > >>
> > > > >> };
> > > > >>
> > > > >> +csi40: csi2@feaa {
> > > > >
> > > > > I believe Simon would like to keep the nodes sorted by address
> > > > >
> > > > >> +compatible = "renesas,r8a77990-csi2",
> > > > >> "renesas,rcar-gen3-csi2";
> > > > >> +reg = <0 0xfeaa 0 0x1>;
> > > > >
> > > > > 0x1 seems pretty large to me.
> > > >
> > > > It seems to me that all Gen3 SoC have this lenght specified
> > > >
> > > > $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ |
> > > > grep reg
> > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0
> > > > 0x1>;
> > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0
> > > > 0x1>;
> > > >
> > > > Am I missing something?
> > >
> > > Cargo-cult programming ? :-) This will likely not hurt, but such a large
> > > memory area is not required, and we'll save a bit of memory if we reduce
> > > the
> > > mapping from 64kB to 4kB (or less)
> >
> > Can we please update this patch, and existing dtsi files,
> > to use an appropriately small register window?
> >
>
> What if we keep this one as it is and we change all the DTSIs in one
> go?
I would rather we correct this patch than add it with a known problem.
>
> > >
> > > > > Apart from that,
> > > >
> > > > I will include the upporting of the following patch to fix the VIN
> > > > endpoint numbering in forthcoming v3:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> > > > /?id=1b1b73f7558d867d72e198901b84bec1e6ef1405
> > > >
> > > > As this has already been applied to simon's tree.
> > > >
> > > > > Reviewed-by: Laurent Pinchart
> > > > >
> > > > >> +interrupts = ;
> > > > >> +clocks = < CPG_MOD 716>;
> > > > >> +power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > >> +resets = < 716>;
> > > > >> +status = "disabled";
> > > > >> +
> > > > >> +ports {
> > > > >> +#address-cells = <1>;
> > > > >> +#size-cells = <0>;
> > > > >> +
> > > > >> +port@1 {
> > > > >> +#address-cells = <1>;
> > > > >> +#size-cells = <0>;
> > > > >> +
> > > > >> +reg = <1>;
> > > > >> +
> > > > >> +csi40vin4: endpoint@0 {
> > > > >> +reg = <0>;
> > > > >> +remote-endpoint =
> > > > >> <>;
> > > > >> +};
> > > > >> +csi40vin5: endpoint@1 {
> > > > >> +
Re: [PATCH 4/4] arm64: dts: renesas: ebisu: Enable Audio
On Mon, Oct 15, 2018 at 11:59:24AM +0200, Simon Horman wrote: > From: Takeshi Kihara > > This patch enables Audio for the Ebisu board on R8A77990 SoC. > > Signed-off-by: Takeshi Kihara > [simon: rebased] > Signed-off-by: Simon Horman Applied for v4.21.
Re: [PATCH 3/4] arm64: dts: renesas: r8a77990: Add Audio-DMAC and Sound device nodes
On Mon, Oct 15, 2018 at 11:59:23AM +0200, Simon Horman wrote: > From: Yoshihiro Kaneko > > This patch adds Audio-DMAC0 device node and Sound device node > for the R8A77990 SoC. > > Based on work by Takeshi Kihara and Hai Nguyen Pham. > > Signed-off-by: Yoshihiro Kaneko > [simon: dropped include update, which is already present] > Signed-off-by: Simon Horman Applied for v4.21.
Re: [PATCH 2/4] arm64: renesas_defconfig: Enable scu-simple-card driver
On Mon, Oct 15, 2018 at 11:59:22AM +0200, Simon Horman wrote: > Enable the scu-simple-card which is used by > the R-Car E3 (r8a77990) based Ebisu board. > > Signed-off-by: Simon Horman > --- > N.B: This is targeted at the devel branch of the renesas tree > but not upstream where renesas_defconfig does not currently exist Applied to topic/renesas-defconfig, which is included in the devel branch but not targeted at upstream.
Re: [PATCH 1/4] arm64: defconfig: Enable scu-simple-card driver
On Mon, Oct 15, 2018 at 11:59:21AM +0200, Simon Horman wrote: > Enable the scu-simple-card which is used by > the R-Car E3 (r8a77990) based Ebisu board. > > Signed-off-by: Simon Horman Applied for v4.21.
Re: [PATCH] arm64: dts: renesas: condor: switch from EtherAVB to GEther
On Thu, Oct 18, 2018 at 07:48:53PM +0300, Sergei Shtylyov wrote:
> The "official" Condor boards have always been wired to mount NFS via
> GEther, not EtherAVB -- the boards resoldered for EtherAVB were local
> to Cogent Embedded, so we've been having an unpleasant situation where
> a "normal" Condor board still can't mount NFS (unless an EtherAVB PHY
> extension board is plugged in). Switch from EtherAVB to GEther at last!
>
> Fixes: 8091788f3d38 ("arm64: dts: renesas: condor: add EtherAVB support")
> Signed-off-by: Sergei Shtylyov
Thanks, applied for v4.21.
Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT support
On Wed, Oct 31, 2018 at 01:55:16PM +0100, Simon Horman wrote: > On Fri, Oct 26, 2018 at 09:48:19AM +, Fabrizio Castro wrote: > > > Subject: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT > > > support > > > > > > Document SoC specific compatible strings for r8a77470. No driver change > > > is needed as the fallback strings will activate the right code. > > > > > > Signed-off-by: Biju Das > > > > Reviewed-by: Fabrizio Castro > > Thanks, applied for v4.21. On second thoughts, I think this should either go through Daniel's tree or be acked by him.
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Simon,
On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > > >> From: Koji Matsuoka
> > > >>
> > > >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device
> > > >> tree.
> > > >>
> > > >> Signed-off-by: Koji Matsuoka
> > > >> Signed-off-by: Takeshi Kihara
> > > >> Signed-off-by: Jacopo Mondi
> > > >> ---
> > > >>
> > > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > > >>
> > > >> 1 file changed, 79 insertions(+)
> > > >>
> > > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe
> > > >> 100644
> > > >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > >> @@ -337,6 +337,85 @@
> > > >>
> > > >>status = "disabled";
> > > >>
> > > >>};
> > > >>
> > > >> + csi40: csi2@feaa {
> > > >
> > > > I believe Simon would like to keep the nodes sorted by address
> > > >
> > > >> + compatible = "renesas,r8a77990-csi2",
> > > >> "renesas,rcar-gen3-csi2";
> > > >> + reg = <0 0xfeaa 0 0x1>;
> > > >
> > > > 0x1 seems pretty large to me.
> > >
> > > It seems to me that all Gen3 SoC have this lenght specified
> > >
> > > $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ | grep
> > > reg
> > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > >
> > > Am I missing something?
> >
> > Cargo-cult programming ? :-) This will likely not hurt, but such a large
> > memory area is not required, and we'll save a bit of memory if we reduce the
> > mapping from 64kB to 4kB (or less)
>
> Can we please update this patch, and existing dtsi files,
> to use an appropriately small register window?
>
What if we keep this one as it is and we change all the DTSIs in one
go?
> >
> > > > Apart from that,
> > >
> > > I will include the upporting of the following patch to fix the VIN
> > > endpoint numbering in forthcoming v3:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> > > /?id=1b1b73f7558d867d72e198901b84bec1e6ef1405
> > >
> > > As this has already been applied to simon's tree.
> > >
> > > > Reviewed-by: Laurent Pinchart
> > > >
> > > >> + interrupts = ;
> > > >> + clocks = < CPG_MOD 716>;
> > > >> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > >> + resets = < 716>;
> > > >> + status = "disabled";
> > > >> +
> > > >> + ports {
> > > >> + #address-cells = <1>;
> > > >> + #size-cells = <0>;
> > > >> +
> > > >> + port@1 {
> > > >> + #address-cells = <1>;
> > > >> + #size-cells = <0>;
> > > >> +
> > > >> + reg = <1>;
> > > >> +
> > > >> + csi40vin4: endpoint@0 {
> > > >> + reg = <0>;
> > > >> + remote-endpoint =
> > > >> <>;
> > > >> + };
> > > >> + csi40vin5: endpoint@1 {
> > > >> + reg = <1>;
> > > >> + remote-endpoint =
> > > >> <>;
> > > >> + };
> > > >> + };
> > > >> + };
> > > >> + };
> > > >> +
> > > >> + vin4: video@e6ef4000 {
> > > >>
Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
> But can we discuss this in the context of describing the hardware? The SDHI node needs two kinds of pinmux settings, one for normal speeds and one for highspeeds. They might differ in supplied voltage, i.e. 3v3 and 1v8. This eMMC always works with 1v8, so both settings needed by the SDHI node are the same currently. That might change if we add new features to pinmux nodes like TDSEL/capacity support. My guess is that this is not so likely to happen so I suggested using just one node. But it has a taste of bike-shedding to it :) signature.asc Description: PGP signature
Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
On 10/31/2018 01:46 PM, Simon Horman wrote: > On Mon, Oct 29, 2018 at 08:57:21AM +, Wolfram Sang wrote: >> <_pins>;". So, basically the same phandles for both pinctrls. We can re-add the second one when we need it. >>> >>> I wonder if removing the sdhi2_pins_uhs is what we want to do, given >>> that we might need to adjust TDSEL or pull resistor configurations for >>> the HS200/HS400 modes in the future. >> >> Well, quoting myself "We can re-add the second one when we need it". It >> is possible but a tad unlikely. That's my take on it but it is >> ultimately up to Simon, of course. > > I agree we can add stuff later if we need it. > But can we discuss this in the context of describing the hardware? I'm not sure I understand this remark. Anyway, I'll be spinning a V2 of the patchset, which will be a single patch. -- Best regards, Marek Vasut
Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT support
On Fri, Oct 26, 2018 at 09:48:19AM +, Fabrizio Castro wrote: > > Subject: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT > > support > > > > Document SoC specific compatible strings for r8a77470. No driver change > > is needed as the fallback strings will activate the right code. > > > > Signed-off-by: Biju Das > > Reviewed-by: Fabrizio Castro Thanks, applied for v4.21.
Re: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable cmt0
On Tue, Oct 30, 2018 at 04:48:30PM +, Biju Das wrote:
> Hi Simon,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable cmt0
> >
> > On Fri, Oct 26, 2018 at 09:48:29AM +0100, Biju Das wrote:
> > > This patch enables cmt0 support on the iWave iwg23s sbc.
> > >
> > > Signed-off-by: Biju Das
> >
> > Thanks, I applied this for v4.21, resolving a conflict.
> > The result is as follows:
> >
> > From: Biju Das
> > Date: Fri, 26 Oct 2018 09:48:29 +0100
> > Subject: [PATCH] ARM: dts: iwg23s-sbc: Enable cmt0
> >
> > This patch enables cmt0 support on the iWave iwg23s sbc.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Fabrizio Castro
> > Signed-off-by: Simon Horman
> > ---
> > arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> > b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> > index ffd8216f28c3..295f11afac21 100644
> > --- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> > +++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> > @@ -77,6 +77,10 @@
> > clock-frequency = <2000>;
> > };
> >
> > + {
> > +status = "okay";
> > +};
>
> I believe as per our process, the nodes should be in alphabetical order,
> If it is the case, it should be above extal_clk
>
> _clk {
> clock-frequency = <2000>;
> };
>
> > {
> > mmc_pins_uhs: mmc_uhs {
> > groups = "mmc_data8", "mmc_ctrl";
Yes, indeed. That was my intention but I messed things up.
I've updated the patch accordingly.
From: Biju Das
Date: Fri, 26 Oct 2018 09:48:29 +0100
Subject: [PATCH] ARM: dts: iwg23s-sbc: Enable cmt0
This patch enables cmt0 support on the iWave iwg23s sbc.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index ffd8216f28c3..18d22631e188 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -73,6 +73,10 @@
};
};
+ {
+ status = "okay";
+};
+
_clk {
clock-frequency = <2000>;
};
--
2.11.0
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > >> From: Koji Matsuoka
> > >>
> > >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device
> > >> tree.
> > >>
> > >> Signed-off-by: Koji Matsuoka
> > >> Signed-off-by: Takeshi Kihara
> > >> Signed-off-by: Jacopo Mondi
> > >> ---
> > >>
> > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > >> 1 file changed, 79 insertions(+)
> > >>
> > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe
> > >> 100644
> > >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > >> @@ -337,6 +337,85 @@
> > >>
> > >> status = "disabled";
> > >>
> > >> };
> > >>
> > >> +csi40: csi2@feaa {
> > >
> > > I believe Simon would like to keep the nodes sorted by address
> > >
> > >> +compatible = "renesas,r8a77990-csi2",
> > >> "renesas,rcar-gen3-csi2";
> > >> +reg = <0 0xfeaa 0 0x1>;
> > >
> > > 0x1 seems pretty large to me.
> >
> > It seems to me that all Gen3 SoC have this lenght specified
> >
> > $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ | grep reg
> > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0 0x1>;
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0 0x1>;
> >
> > Am I missing something?
>
> Cargo-cult programming ? :-) This will likely not hurt, but such a large
> memory area is not required, and we'll save a bit of memory if we reduce the
> mapping from 64kB to 4kB (or less)
Can we please update this patch, and existing dtsi files,
to use an appropriately small register window?
>
> > > Apart from that,
> >
> > I will include the upporting of the following patch to fix the VIN
> > endpoint numbering in forthcoming v3:
> > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> > /?id=1b1b73f7558d867d72e198901b84bec1e6ef1405
> >
> > As this has already been applied to simon's tree.
> >
> > > Reviewed-by: Laurent Pinchart
> > >
> > >> +interrupts = ;
> > >> +clocks = < CPG_MOD 716>;
> > >> +power-domains = < R8A77990_PD_ALWAYS_ON>;
> > >> +resets = < 716>;
> > >> +status = "disabled";
> > >> +
> > >> +ports {
> > >> +#address-cells = <1>;
> > >> +#size-cells = <0>;
> > >> +
> > >> +port@1 {
> > >> +#address-cells = <1>;
> > >> +#size-cells = <0>;
> > >> +
> > >> +reg = <1>;
> > >> +
> > >> +csi40vin4: endpoint@0 {
> > >> +reg = <0>;
> > >> +remote-endpoint =
> > >> <>;
> > >> +};
> > >> +csi40vin5: endpoint@1 {
> > >> +reg = <1>;
> > >> +remote-endpoint =
> > >> <>;
> > >> +};
> > >> +};
> > >> +};
> > >> +};
> > >> +
> > >> +vin4: video@e6ef4000 {
> > >> +compatible = "renesas,vin-r8a77990";
> > >> +reg = <0 0xe6ef4000 0 0x1000>;
> > >> +interrupts = ;
> > >> +clocks = < CPG_MOD 807>;
> > >> +power-domains = < R8A77990_PD_ALWAYS_ON>;
> > >> +resets = < 807>;
> > >>
Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
On Mon, Oct 29, 2018 at 08:57:21AM +, Wolfram Sang wrote: > > > > <_pins>;". So, basically the same phandles for both pinctrls. We > > > can re-add the second one when we need it. > > > > I wonder if removing the sdhi2_pins_uhs is what we want to do, given > > that we might need to adjust TDSEL or pull resistor configurations for > > the HS200/HS400 modes in the future. > > Well, quoting myself "We can re-add the second one when we need it". It > is possible but a tad unlikely. That's my take on it but it is > ultimately up to Simon, of course. I agree we can add stuff later if we need it. But can we discuss this in the context of describing the hardware?
