On Tue 2019-07-16 09:15:14, Biju Das wrote:

commit 188306ac9536ec47674ffa9dd330f69927679aeb upstream.

As per 8.2.6 Setting and reading the time in RTC mode, first stop the clok,
then reset it before setting the date and time registers. Finally, start
the clock.

This uses register address wrap around from 0x2f to 0x00 for
efficiency.

How does wrap around work? AFAICT it is supposed to have ram at 0x40.

Does it really provide increased efficiency (given regmap layer in
between) and will such trick cause problems in future? If regmap is
not aware of register mirrors it might get confused and provide stale
values, for example...

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Mon 2019-07-15 15:17:19, Biju Das wrote:

This patch series add RTC support for EK874 platform.

This patch series is based on linux-4.19.y-cip and all the patches
in this series are cherry-picked from linux rc tree.

This patch series is depend on the below patch series
https://patchwork.kernel.org/project/cip-dev/list/?series=145931

Thanks for the series, applied, and pushed out.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Mon 2019-07-15 15:28:46, Biju Das wrote:

From: Fabrizio Castro <fabrizio.castro@...>

commit 79223ca1f57776d2770da9561c26cc2f2dd42205 upstream.

Enable RWDT and use 60 seconds as default timeout.

So this will reboot machine if userspace does not ping it within 60
seconds by default?

Will that break user configurations that worked up till now, but do
not contain watchdog support?

Do we care?

Thanks,
Pavel

@@ -137,6 +137,11 @@
};
};

+&rwdt {
+ timeout-sec = <60>;
+ status = "okay";
+};
+
&scif2 {
pinctrl-0 = <&scif2_pins>;
pinctrl-names = "default";

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hi!

index f08778e..af396bb 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
@@ -22,6 +22,30 @@
stdout-path = "serial0:115200n8";
};

+ leds {
+ compatible = "gpio-leds";
+
+ led0 {
+ gpios = <&gpio5 19 GPIO_ACTIVE_HIGH>;
+ label = "LED0";
+ };
+
+ led1 {
+ gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
+ label = "LED1";
+ };
+
+ led2 {
+ gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>;
+ label = "LED2";
+ };
+
+ led3 {
+ gpios = <&gpio6 4 GPIO_ACTIVE_HIGH>;
+ label = "LED3";
+ };
+ };

With my LED maintainer hat on... these are not exactly useful LED
names. Do they have any fixed meaning? Are they labeled on the board?
What color are they?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hi!

+static int rx85x1_nvram_read(void *priv, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct rx8581 *rx8581 = priv;
+ unsigned int tmp_val;
+ int ret;
+
+ ret = regmap_read(rx8581->regmap, RX8581_REG_RAM, &tmp_val);
+ (*(unsigned char *)val) = (unsigned char) tmp_val;
+
+ return ret;
+}
+
+static int rx85x1_nvram_write(void *priv, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct rx8581 *rx8581 = priv;
+ unsigned char tmp_val;
+
+ tmp_val = *((unsigned char *)val);
+ return regmap_write(rx8581->regmap, RX8581_REG_RAM,
+ (unsigned int)tmp_val);
+}

I see that 85x1 has single byte of RAM. I'd still expect return of
error in case of offset != 0 or bytes != 1.

Probably best done in mainline first...

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hi!

Is there a chance to update 4.4-rt based on Daniel' 4.4.179-rt181 release, but
then to 4.4.182 in order to have SACK fixes in?

Do you want 4.4.184, too, which fixes the SACK fixes? :-).

I'm up-to 4.4.179-rt181-cip32.

If I attempt to move forward to 4.4.181-cip3, I get some conflicts in
rather core files.

Auto-merging kernel/cpu.c
CONFLICT (content): Merge conflict in kernel/cpu.c
Auto-merging include/linux/sched.h
CONFLICT (content): Merge conflict in include/linux/sched.h
Auto-merging arch/x86/include/asm/thread_info.h
CONFLICT (content): Merge conflict in

I can attempt something, but I'd feel safer waiting for -stable-rt to
solve it for me.

FWIW, I am updating the stable-rt tree right now. As noted there are a
couple of merge conflicts ahead. Right now I am testing the result of the
v4.4.180 merge. So far all looks good and now I am waiting for the test
results from the CI system. After that I keep merging.

Thanks for good news. You have privat CI system, right?

If sources are available somewhere, I can try to help with testing.

Best regards,
Pavl
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hi!

This patch series add QSPI support for iWave iwg23s sbc based on RZ/G1C.

This patch series is based on linux-4.4.y-cip and all the patches
in this series are cherry-picked from linux rc tree.

Thanks for the series. It looks fine to me.

Applied, and pushed out.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hi!

This patch series add USB host support for EK874 platform.

This patch series is based on linux-4.19.y-cip and all the patches
in this series are cherry-picked from linux rc tree.

This patch series is depend on the below patch series
https://patchwork.kernel.org/project/cip-dev/list/?series=145929

I'll note that english in comment in 11/12 could use some improvement,
too.

Thanks, applied, and I'll push it out soon.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Is there a chance to update 4.4-rt based on Daniel' 4.4.179-rt181 release, but
then to 4.4.182 in order to have SACK fixes in?

Do you want 4.4.184, too, which fixes the SACK fixes? :-).
I'm up-to 4.4.179-rt181-cip32.
If I attempt to move forward to 4.4.181-cip3, I get some conflicts in
rather core files.
Auto-merging kernel/cpu.c
CONFLICT (content): Merge conflict in kernel/cpu.c
Auto-merging include/linux/sched.h
CONFLICT (content): Merge conflict in include/linux/sched.h
Auto-merging arch/x86/include/asm/thread_info.h
CONFLICT (content): Merge conflict in
I can attempt something, but I'd feel safer waiting for -stable-rt to
solve it for me.

FWIW, I am updating the stable-rt tree right now. As noted there are a couple of merge conflicts ahead. Right now I am testing the result of the v4.4.180 merge. So far all looks good and now I am waiting for the test results from the CI system. After that I keep merging.

In case you are wondering how the workflow works. We stable-rt maintainer merge the latest stable release and make a release if there is no merge conflict. If there is a merge conflict, that particular stable merge will be released as separate version. That allows to review the merge conflicts more easily.

Hi Pavel,

Thanks for the feedback.

HI Pavel,

Thanks for the feedback.

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y-cip 08/12] phy: renesas: rcar-gen3-usb2:
follow the hardware manual procedure

Hi!

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>

commit 72c0339c115b31b3c0b22b1809854136cadd49be upstream.

This patch modifies rcar_gen3_init_otg() procedure to follow Figure
73.4 of "R-Car Series, 3rd Generation User's Manual: Hardware Rev.1.00".

@@ -310,16 +310,21 @@ static void rcar_gen3_init_otg(struct

rcar_gen3_chan *ch)

void __iomem *usb2_base = ch->base;
u32 val;

+ /* Should not use functions of read-modify-write a register */
+ val = readl(usb2_base + USB2_LINECTRL1);
+ val = (val & ~USB2_LINECTRL1_DP_RPD) |

USB2_LINECTRL1_DPRPD_EN |

+ USB2_LINECTRL1_DMRPD_EN | USB2_LINECTRL1_DM_RPD;
+ writel(val, usb2_base + USB2_LINECTRL1);
+

I don't understand the comment here. Actually having function to set/clear
bits in arbitrary register might be a nice cleanup.

As mentioned in the commit message, "procedure to follow Figure
73.4 of "R-Car Series, 3rd Generation User's Manual: Hardware Rev.1.00".

The hardware manual mentions about a flow chart(Figure 73.4) describing " OTG Initial Setting Procedure"
The patch is made according to the flow chart.

While reviewing that I noticed:

static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch) ...
val = readl(usb2_base + USB2_LINECTRL1);
rcar_gen3_set_linectrl(ch, 0, 0);
writel(val | USB2_LINECTRL1_DPRPD_EN |
USB2_LINECTRL1_DMRPD_EN,
usb2_base + USB2_LINECTRL1);


AFAICT it modifies the register only to undo those chanes immediately. Is it
intentional? Is it worth a comment? Can the block be replaced with

The "rcar_gen3_init_otg "routine has to be aligned with the procedure mentioned in the flow chart.
There is a Wait for at least 20 ms is mentioned in the flow chart.

static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch) ...
rcar_gen3_set_linectrl(ch, 0, 0);
rcar_gen3_set_linectrl(ch, 1, 1);

?

Hi!

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...>

commit 72c0339c115b31b3c0b22b1809854136cadd49be upstream.

This patch modifies rcar_gen3_init_otg() procedure to follow Figure
73.4 of "R-Car Series, 3rd Generation User's Manual: Hardware Rev.1.00".

@@ -310,16 +310,21 @@ static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
void __iomem *usb2_base = ch->base;
u32 val;

+ /* Should not use functions of read-modify-write a register */
+ val = readl(usb2_base + USB2_LINECTRL1);
+ val = (val & ~USB2_LINECTRL1_DP_RPD) | USB2_LINECTRL1_DPRPD_EN |
+ USB2_LINECTRL1_DMRPD_EN | USB2_LINECTRL1_DM_RPD;
+ writel(val, usb2_base + USB2_LINECTRL1);
+

I don't understand the comment here. Actually having function to
set/clear bits in arbitrary register might be a nice cleanup.

While reviewing that I noticed:

static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
...
val = readl(usb2_base + USB2_LINECTRL1);
rcar_gen3_set_linectrl(ch, 0, 0);
writel(val | USB2_LINECTRL1_DPRPD_EN | USB2_LINECTRL1_DMRPD_EN,
usb2_base + USB2_LINECTRL1);


AFAICT it modifies the register only to undo those chanes
immediately. Is it intentional? Is it worth a comment? Can the block
be replaced with

static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
...
rcar_gen3_set_linectrl(ch, 0, 0);
rcar_gen3_set_linectrl(ch, 1, 1);

?

Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi!

@@ -212,6 +212,9 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)

static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
{
+ if (!ch->uses_otg_pins)
+ return (ch->dr_mode == USB_DR_MODE_HOST) ? false : true;

I'd write this as

"return ch->dr_mode != USB_DR_MODE_HOST;"

I'll take the patch, anyway, but there's room for future cleanup.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi!

commit 7ab0305d4d7725699169e21cdc4f6c8759c32feb upstream.

This patch unifies the OBINTEN handling to clean-up the code.

@@ -145,6 +145,18 @@ static void rcar_gen3_enable_vbus_ctrl(struct rcar_gen3_chan *ch, int vbus)
writel(val, usb2_base + USB2_ADPCTRL);
}

+static void rcar_gen3_control_otg_irq(struct rcar_gen3_chan *ch, int enable)
+{
+ void __iomem *usb2_base = ch->base;
+ u32 val = readl(usb2_base + USB2_OBINTEN);
+
+ if (enable)
+ val |= USB2_OBINT_BITS;
+ else
+ val &= ~USB2_OBINT_BITS;
+ writel(val, usb2_base + USB2_OBINTEN);
+}
+

static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
{
- void __iomem *usb2_base = ch->base;
- u32 val;
-
- val = readl(usb2_base + USB2_OBINTEN);
- writel(val & ~USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
+ rcar_gen3_control_otg_irq(ch, 0);

rcar_gen3_enable_vbus_ctrl(ch, 1);
rcar_gen3_init_for_host(ch);

- writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
+ rcar_gen3_control_otg_irq(ch, 1);
}

This actually removes optimalization: old code would avoid
reading USB2_OBINTEN twice. I guess it is not a problem.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y-cip 15/23] clk: renesas: rcar-gen3:
Support Z and Z2 clocks with high frequency parents

Hi!

Support Z and Z2 clocks with parent frequencies greater than
UINT32_MAX Hz (~4.29GHz).

The DIV_ROUND_CLOSEST_ULL() macro accepts a 64bit dividend and 32bit
divisor. This leads to truncation of the divisor, which is the Z or Z2
parent clock frequency in HZ, on platforms where frequency of that
clock is greater than UINT32_MAX Hz.

To resolve this problem the DIV64_U64_ROUND_CLOSEST() macro, which
takes on an unsigned 64bit dividend and divisor, is used.

An earlier version of this patch made use of the existing
DIV_ROUND_CLOSEST() macro, which accepts the prevailing type of the
dividend and divisor. However, this does not compile on 32bit systems,
such as i386 and mips, when called with the types used at this call
site, an unsigned long long dividend and unsigned long divisor.

This work is in preparation for supporting the Z2 clock on the R-Car
Gen3 E3 (r8a77990) SoC which has a 4.8GHz parent clock.

You still store "parent_rate" in "unsigned long". That is going to overflow on
32-bit systems, right?

Gen3 SoC's are aarch64. So I think it is ok.

Regards,
Biju

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y-cip 21/23] clk: renesas: rcar-gen3: Fix
cpg_sd_clock_round_rate() return value

Hi!

This is not conform the clk API design.

This patch fixes that by making sure cpg_sd_clock_calc_div() considers
only the division values defined in cpg_sd_div_table[].
With this fix, the cpg_sd_clock_round_rate() always return a support
clock rate.

This is not quite correct english, but I guess it is too late to fix that.

Yes, I agree with you. It is too late to fix it.

Regards,
Biju

On Mon 2019-07-15 14:47:59, Biju Das wrote:

This patch series add CAN support to CAT875 sub board.
Also it fixes cpu node style.

This patch series is based on linux-4.19.y-cip and all the patches
in this series are cherry-picked from linux rc tree.

Thanks; applied and pushed out.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi!

This patch series add OPP tables,HS400 quirk for SD clock,
add support Z2 clock and fix some of parent clocks.

This patch series is based on linux-4.19.y-cip and all the patches
in this series are cherry-picked from linux rc tree.

Thanks. Applied and pushed out.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi!

This is not conform the clk API design.

This patch fixes that by making sure cpg_sd_clock_calc_div() considers
only the division values defined in cpg_sd_div_table[].
With this fix, the cpg_sd_clock_round_rate() always return a support
clock rate.

This is not quite correct english, but I guess it is too late to fix
that.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html