Re: [PATCH v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
On Thu, Nov 29, 2018 at 1:41 AM Niklas Söderlund
wrote:
> On H3 (ES1.x, 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 value for the SDn
> clock. On the effected boards the one currently selected results in
> HS400 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
>
> ---
> * Changes since v1
> - Fixed spelling in commit message, thanks Sergei and Geert!
> - Reworked the whole patch per Geerts suggestion. Instead of only
> skipping the first row on the effected boards when setting the clock
> rete totally ignore it. This is made possible by another change to the
> clock driver posted separately from this series and which this patch
> now depends on [1].
>
> 1. [PATCH] clk: renesas: rcar-gen3: set state when registering SD clocks
Thanks for the update!
With s/rete/rate/:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Wolfram,
On Fri, Nov 30, 2018 at 12:47 PM Wolfram Sang wrote:
> > That should have been rate :-) To elaborate a bit more:
> >
> > The patch is different from v1 as a different approach to solve the
> > issue have been found. Instead of only ignoring the first row of the
> > list of possible settings when selecting which divider to use also
> > ignore it when examining which state the hardware is in. That is the
> > driver is no longer aware the first row exists with this patch.
> >
> > This was in v1 not possible as the first row might be a state the
> > bootloader left the hardware in and then the clock failed to register as
> > it would need to update its own state to match the hardware.
> >
> > As the driver needed to know about the state the hardware was in when
> > probing but not use it when selecting a divider the more complex v1 was
> > needed. When selecting a divider we wish for it to select the second
> > option for the divider value '4' when running on a SoC which needs the
> > quirk.
> >
> > With v2 which depends on [1] this is not needed as the clock driver now
> > sets a know state when registering the clock so this patch can be made
> > much simpler by simply 'removing' the first row from all operations.
>
> Thanks for the elaboration. I still think the above is the way to go and
> I still wonder a little why it was implemented differently beforehand.
Probably the initial implementation didn't care at all about selecting clock
speeds (no fancy SDR/HS modes supported), so just used whatever U-Boot
had set up.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Niklas, > That should have been rate :-) To elaborate a bit more: > > The patch is different from v1 as a different approach to solve the > issue have been found. Instead of only ignoring the first row of the > list of possible settings when selecting which divider to use also > ignore it when examining which state the hardware is in. That is the > driver is no longer aware the first row exists with this patch. > > This was in v1 not possible as the first row might be a state the > bootloader left the hardware in and then the clock failed to register as > it would need to update its own state to match the hardware. > > As the driver needed to know about the state the hardware was in when > probing but not use it when selecting a divider the more complex v1 was > needed. When selecting a divider we wish for it to select the second > option for the divider value '4' when running on a SoC which needs the > quirk. > > With v2 which depends on [1] this is not needed as the clock driver now > sets a know state when registering the clock so this patch can be made > much simpler by simply 'removing' the first row from all operations. Thanks for the elaboration. I still think the above is the way to go and I still wonder a little why it was implemented differently beforehand. > > Hmm, why didn't you add it to the series then? > > Since it is unrelated to this series I thought it best to post it as a > separate patch as I think it has value to create a known starting state > disregarding where this series ends up :-) Yes, can be argued. Thanks, Wolfram signature.asc Description: PGP signature
Re: [PATCH v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
On Thu, Nov 29, 2018 at 01:39:49AM +0100, Niklas Söderlund wrote: > On H3 (ES1.x, 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 value for the SDn > clock. On the effected boards the one currently selected results in > HS400 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 Tested on H3 ES1.0 and ES2.0, M3W ES1.0, and M3N with eMMC and UHS-SD cards. Proper clock speeds were selected and performance matches. Tested-by: Wolfram Sang Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Wolfram, Thanks for your feedback. On 2018-11-29 17:54:34 +0100, Wolfram Sang wrote: > Hi Niklas, > > thanks for the patches! > > On Thu, Nov 29, 2018 at 01:39:49AM +0100, Niklas Söderlund wrote: > > On H3 (ES1.x, 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 value for the SDn > > clock. On the effected boards the one currently selected results in > > HS400 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 > > > > --- > > * Changes since v1 > > - Fixed spelling in commit message, thanks Sergei and Geert! > > - Reworked the whole patch per Geerts suggestion. Instead of only > > skipping the first row on the effected boards when setting the clock > > rete totally ignore it. This is made possible by another change to the > > "rete"? I don't get this sentence and I think it is important to > understand when reviewing these patches :) That should have been rate :-) To elaborate a bit more: The patch is different from v1 as a different approach to solve the issue have been found. Instead of only ignoring the first row of the list of possible settings when selecting which divider to use also ignore it when examining which state the hardware is in. That is the driver is no longer aware the first row exists with this patch. This was in v1 not possible as the first row might be a state the bootloader left the hardware in and then the clock failed to register as it would need to update its own state to match the hardware. As the driver needed to know about the state the hardware was in when probing but not use it when selecting a divider the more complex v1 was needed. When selecting a divider we wish for it to select the second option for the divider value '4' when running on a SoC which needs the quirk. With v2 which depends on [1] this is not needed as the clock driver now sets a know state when registering the clock so this patch can be made much simpler by simply 'removing' the first row from all operations. > > > clock driver posted separately from this series and which this patch > > now depends on [1]. > > Hmm, why didn't you add it to the series then? Since it is unrelated to this series I thought it best to post it as a separate patch as I think it has value to create a known starting state disregarding where this series ends up :-) > > Still, all in all, seems we are on a nice track for having HS400 in the > next release \o/ Now, if that doesn't justify the 5.0 jump... ;D I sure hope so! -- Regards, Niklas Söderlund
Re: [PATCH v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Niklas, thanks for the patches! On Thu, Nov 29, 2018 at 01:39:49AM +0100, Niklas Söderlund wrote: > On H3 (ES1.x, 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 value for the SDn > clock. On the effected boards the one currently selected results in > HS400 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 > > --- > * Changes since v1 > - Fixed spelling in commit message, thanks Sergei and Geert! > - Reworked the whole patch per Geerts suggestion. Instead of only > skipping the first row on the effected boards when setting the clock > rete totally ignore it. This is made possible by another change to the "rete"? I don't get this sentence and I think it is important to understand when reviewing these patches :) > clock driver posted separately from this series and which this patch > now depends on [1]. Hmm, why didn't you add it to the series then? Still, all in all, seems we are on a nice track for having HS400 in the next release \o/ Now, if that doesn't justify the 5.0 jump... ;D Regards, Wolfram
[PATCH v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
On H3 (ES1.x, 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 value for the SDn
clock. On the effected boards the one currently selected results in
HS400 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
---
* Changes since v1
- Fixed spelling in commit message, thanks Sergei and Geert!
- Reworked the whole patch per Geerts suggestion. Instead of only
skipping the first row on the effected boards when setting the clock
rete totally ignore it. This is made possible by another change to the
clock driver posted separately from this series and which this patch
now depends on [1].
1. [PATCH] clk: renesas: rcar-gen3: set state when registering SD clocks
---
drivers/clk/renesas/rcar-gen3-cpg.c | 33 +++--
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c
b/drivers/clk/renesas/rcar-gen3-cpg.c
index bca6c7f51de18db7..bad062150cd486f6 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -242,6 +242,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) */
@@ -352,6 +356,12 @@ static const struct clk_ops cpg_sd_clock_ops = {
.set_rate = cpg_sd_clock_set_rate,
};
+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 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)
@@ -377,6 +387,11 @@ static struct clk * __init cpg_sd_clk_register(const
struct cpg_core_clk *core,
clock->div_table = cpg_sd_div_table;
clock->div_num = ARRAY_SIZE(cpg_sd_div_table);
+ if (cpg_quirks & SD_SKIP_FIRST) {
+ clock->div_table++;
+ clock->div_num--;
+ }
+
val = readl(clock->csn.reg) & ~CPG_SD_FC_MASK;
val |= CPG_SD_STP_MASK | (clock->div_table[0].val & CPG_SD_FC_MASK);
writel(val, clock->csn.reg);
@@ -406,23 +421,27 @@ static struct clk * __init cpg_sd_clk_register(const
struct cpg_core_clk *core,
static const struct rcar_gen3_cpg_pll_config *cpg_pll_config __initdata;
static unsigned int cpg_clk_extalr __initdata;
static u32 cpg_mode __initdata;
-static u32 cpg_quirks __initdata;
-
-#define PLL_ERRATA BIT(0) /* Missing PLL0/2/4 post-divider */
-#define RCKCR_CKSELBIT(1) /* Manual RCLK parent selection */
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 */ }
};
--
2.19.1
