Date   

[PATCH 4.19.y-cip 04/23] clk: renesas: rcar-gen3: Add HS400 quirk for SD clock

Biju Das <biju.das@...>
 

From: Niklas Söderlund <niklas.soderlund+renesas@...>

commit 36c4da4f552a126bb29a95dc5c9608795491e32a upstream.

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 <niklas.soderlund+renesas@...>
Tested-by: Wolfram Sang <wsa+renesas@...>
Acked-by: Wolfram Sang <wsa+renesas@...>
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Biju Das <biju.das@...>
---
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 00e41de..3ba5076 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -245,6 +245,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) */
@@ -355,6 +359,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_CKSEL BIT(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)
@@ -380,6 +390,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);
@@ -407,23 +422,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_CKSEL BIT(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.7.4


[PATCH 4.19.y-cip 03/23] clk: renesas: rcar-gen3: Add documentation for SD clocks

Biju Das <biju.das@...>
 

From: Niklas Söderlund <niklas.soderlund+renesas@...>

commit e2f4dd1f5b51b4dab813aa6e4db44e87aa750393 upstream.

Document the known use cases of the different clock settings. This is
useful as different SoC and ES versions use different settings to do
the same thing as there is more than one combination to achieve the
same SDn clock speed.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@...>
Reviewed-by: Wolfram Sang <wsa+renesas@...>
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Biju Das <biju.das@...>
---
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 d6f5bd1..00e41de 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -235,13 +235,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.7.4


[PATCH 4.19.y-cip 02/23] clk: renesas: rcar-gen3: Set state when registering SD clocks

Biju Das <biju.das@...>
 

From: Niklas Söderlund <niklas.soderlund+renesas@...>

commit ecda0a09fa9933bcd67e33c952f778f0872392ed upstream.

The driver tries to figure out which state a SD clock is in when the
clock is registered, instead of setting a known state. This can be
problematic for two reasons.

1. If the clock driver can't figure out the state of the clock,
registration of the clock fails, and setting of a known state by a
clock user is not possible.

2. The state of the clock depends on if and how the bootloader
configured it. The driver only checks that the rate is known, not if
the clock is stopped or not for example.

Fix this by setting a known state and making sure the clock is stopped.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@...>
Tested-by: Wolfram Sang <wsa+renesas@...>
Acked-by: Wolfram Sang <wsa+renesas@...>
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Biju Das <biju.das@...>
---
drivers/clk/renesas/rcar-gen3-cpg.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c b/drivers/clk/renesas/rcar-gen3-cpg.c
index 4346fde..d6f5bd1 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -363,7 +363,7 @@ static struct clk * __init cpg_sd_clk_register(const struct cpg_core_clk *core,
struct sd_clock *clock;
struct clk *clk;
unsigned int i;
- u32 sd_fc;
+ u32 val;

clock = kzalloc(sizeof(*clock), GFP_KERNEL);
if (!clock)
@@ -380,17 +380,9 @@ 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);

- sd_fc = readl(clock->csn.reg) & CPG_SD_FC_MASK;
- for (i = 0; i < clock->div_num; i++)
- if (sd_fc == (clock->div_table[i].val & CPG_SD_FC_MASK))
- break;
-
- if (WARN_ON(i >= clock->div_num)) {
- kfree(clock);
- return ERR_PTR(-EINVAL);
- }
-
- clock->cur_div_idx = i;
+ 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);

clock->div_max = clock->div_table[0].div;
clock->div_min = clock->div_max;
--
2.7.4


[PATCH 4.19.y-cip 01/23] clk: renesas: r8a774a1: Add CPEX clock

Biju Das <biju.das@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

commit f845b01d478a4d139fe3493f1e6ec8d9110ce56c upstream.

Implement support for the CPEX clock on RZ/G2M. This clock can be
selected as a clock source for CMT1 (Compare Match Timer Type 1).

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Acked-by: Stephen Boyd <sboyd@...>
Signed-off-by: Biju Das <biju.das@...>
---
drivers/clk/renesas/r8a774a1-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a774a1-cpg-mssr.c b/drivers/clk/renesas/r8a774a1-cpg-mssr.c
index b0da342..10e8525 100644
--- a/drivers/clk/renesas/r8a774a1-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a774a1-cpg-mssr.c
@@ -100,6 +100,7 @@ static const struct cpg_core_clk r8a774a1_core_clks[] __initconst = {

DEF_FIXED("cl", R8A774A1_CLK_CL, CLK_PLL1_DIV2, 48, 1),
DEF_FIXED("cp", R8A774A1_CLK_CP, CLK_EXTAL, 2, 1),
+ DEF_FIXED("cpex", R8A774A1_CLK_CPEX, CLK_EXTAL, 2, 1),

DEF_DIV6P1("csi0", R8A774A1_CLK_CSI0, CLK_PLL1_DIV4, 0x00c),
DEF_DIV6P1("mso", R8A774A1_CLK_MSO, CLK_PLL1_DIV4, 0x014),
--
2.7.4


[PATCH 4.19.y-cip 00/23] Clock enhancements

Biju Das <biju.das@...>
 

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.

Biju Das (2):
clk: renesas: rcar-gen3: Parameterise Z and Z2 clock fixed divisor
clk: renesas: rcar-gen3: Parameterise Z and Z2 clock offset

Fabrizio Castro (3):
clk: renesas: r8a774a1: Add missing CANFD clock
clk: renesas: r8a774a1: Fix LAST_DT_CORE_CLK
arm64: dts: renesas: r8a774c0: Add OPPs table for cpu devices

Geert Uytterhoeven (2):
clk: renesas: r8a774a1: Add CPEX clock
clk: renesas: rcar-gen3: Pass name/offset to cpg_sd_clk_register()

Kazuya Mizuguchi (2):
clk: renesas: rcar-gen3: Correct parent clock of EHCI/OHCI
clk: renesas: rcar-gen3: Correct parent clock of HS-USB

Niklas Söderlund (3):
clk: renesas: rcar-gen3: Set state when registering SD clocks
clk: renesas: rcar-gen3: Add documentation for SD clocks
clk: renesas: rcar-gen3: Add HS400 quirk for SD clock

Sergei Shtylyov (2):
clk: renesas: rcar-gen3: Factor out cpg_reg_modify()
clk: renesas: rcar-gen3: Add spinlock

Simon Horman (4):
clk: renesas: rcar-gen3: Remove CLK_TYPE_GEN3_Z2
math64: New DIV64_U64_ROUND_CLOSEST helper
clk: renesas: rcar-gen3: Support Z and Z2 clocks with high frequency
parents
clk: renesas: r8a774c0: Add Z2 clock

Stephen Boyd (2):
clk: renesas: Remove usage of CLK_IS_BASIC
clk: renesas: rcar-gen3: Remove unused variable

Takeshi Kihara (3):
clk: renesas: rcar-gen3: Correct parent clock of SYS-DMAC
clk: renesas: rcar-gen3: Correct parent clock of Audio-DMAC
clk: renesas: rcar-gen3: Fix cpg_sd_clock_round_rate() return value

arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 25 ++++
drivers/clk/renesas/clk-div6.c | 2 +-
drivers/clk/renesas/clk-mstp.c | 2 +-
drivers/clk/renesas/r8a774a1-cpg-mssr.c | 23 ++--
drivers/clk/renesas/r8a774c0-cpg-mssr.c | 7 +-
drivers/clk/renesas/r8a7795-cpg-mssr.c | 25 ++--
drivers/clk/renesas/r8a7796-cpg-mssr.c | 19 +--
drivers/clk/renesas/r8a77965-cpg-mssr.c | 16 +--
drivers/clk/renesas/r8a77990-cpg-mssr.c | 6 +-
drivers/clk/renesas/r8a77995-cpg-mssr.c | 2 +-
drivers/clk/renesas/rcar-gen3-cpg.c | 174 ++++++++++++++------------
drivers/clk/renesas/rcar-gen3-cpg.h | 5 +-
drivers/clk/renesas/renesas-cpg-mssr.c | 2 +-
include/dt-bindings/clock/r8a774a1-cpg-mssr.h | 1 +
include/linux/math64.h | 13 ++
15 files changed, 193 insertions(+), 129 deletions(-)

--
2.7.4


Re: [ANNOUNCE] 4.4.176-cip31-rt23

Pavel Machek
 

Hi!

I'm pleased to announce the 4.4.176-cip31-rt23 stable release.

This release is just an update to the new stable 4.4.176-cip31 version
and no RT specific changes have been made.

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git

branch: linux-4.4.y-cip-rt
Head SHA1: b51a171ad762ba4a78b0ed0c7ec83fb9f6fb135f
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?
I'm looking into it. I have -rt-rebase based on
v4.4.179-rt181-cip34-rebase (close to what you want but not quite
there; I can publish it if it would be useful), but duplicating same
result with merges might be tricky.

Best regards,
Pavel

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


Re: RT testing

Pavel Machek
 

Hi!

(List added to the cc).

Here are the links I was pasting into the Zoom chat regarding RT testing.
Thanks for all the help!

I got -cip-rt kernel to work on EBV Socrates, and it seems to be
suitable machine for testing. Latencies are under 70 usec under normal
loads. They go up-to 150 usec in longer tests and under very heavy
loads... These results are also consistent with osdal data:
https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s5.0.html?shadow=1

On iwg20m, I was getting 299 usec on cyclictest alone (job/1726) and
some mysterious 2000usec+ latencies on 4.19.50-cip3-rt1 (job/1797). I verified
Thinkpad X60 is not suitable due to hwlat. Thinkpad T40p is somehow
more promising (nothing detected by hwlat), but latencies cyclictest
is often in 500 usec range, and I have seen 755 usec with
4.4.176-cip31-rt23.

So.. EBV Socrates seems like best board to test on. Fortunately we
have very similar board in the lab:
https://lava.ciplatform.org/scheduler/device_type/Altera-Terasic-Deo-Nano
.

I believe we should do the following steps:

1) Add -rt configuration for socfpga to cip-kernel-config repositories
(me)

2) Enable CONFIG_HIGH_RES_TIMERS=y in all configs (realtime or not) so
we have comparison (me)

3) Prepare rt and non-rt kernels for socfpga. (I can do it one time,
but it would be good to do it automatically as part of checkin tests).

4) Tune cyclictest (length of test, background load) so that it
reproduces cca 100 usec latency on socfpga. If we set threshold to
cca 200 usec, it should consistently fail on non-RT_FULL
configurations. (I'll need help).

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


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Biju Das <biju.das@...>
 

Hi Nobuhiro,

Thanks for the feedback.

.feghali.xb@...>; cip-
dev@...
Subject: RE: [cip-dev] Regarding backporting RTC PCF85263 driver to cip 4.4
kernel

Hi,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Pavel
Machek
Sent: Monday, July 15, 2019 6:46 AM
To: Biju Das <biju.das@...>
Cc: Christopher Feghali <christopher.feghali.xb@...>;
cip-dev@...
Subject: Re: [cip-dev] Regarding backporting RTC PCF85263 driver to
cip
4.4 kernel

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have
upstreamed this driver support on 4.19 kernel [1] [1].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4
ef
fb64c323152

This driver is based on RTC PCF 85363 driver which has rtc
nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc6
36
cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support.
we have already done this work and patches are available at [3] [3].
https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-r
egistering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality
from [2] .
So we basically get this one, and few patches on top, local to the new
files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-f
or-NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.
I think that option 2 is good.
OK. Will send patch based on option 2.

Regards,
Biju


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Biju Das <biju.das@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] Regarding backporting RTC PCF85263 driver to cip 4.4
kernel

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have
upstreamed this driver support on 4.19 kernel [1] [1].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4ef
fb64c323152

This driver is based on RTC PCF 85363 driver which has rtc
nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
mit/drivers/rtc/rtc-
pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc636
cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support.
we have already done this work and patches are available at [3] [3].
https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-
registering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality from
[2] .
So we basically get this one, and few patches on top, local to the new files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-for-
NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.
Ok. I will send patch based on option 2.

Regards,
Biju


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Pavel
Machek
Sent: Monday, July 15, 2019 6:46 AM
To: Biju Das <biju.das@...>
Cc: Christopher Feghali <christopher.feghali.xb@...>;
cip-dev@...
Subject: Re: [cip-dev] Regarding backporting RTC PCF85263 driver to cip
4.4 kernel

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have
upstreamed this driver support on 4.19 kernel [1] [1].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4
ef
fb64c323152

This driver is based on RTC PCF 85363 driver which has rtc
nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2].
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
om
mit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc6
36
cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support.
we have already done this work and patches are available at [3] [3].
https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-r
egistering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality from
[2] .
So we basically get this one, and few patches on top, local to the new
files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-f
or-NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.
I think that option 2 is good.

Best regards,
Nobuhiro


Re: Request for guidance: removal of old config files [was: Kernel configurations for 4.19?]

Nobuhiro Iwamatsu
 

Hi Ben,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Ben
Hutchings
Sent: Saturday, July 13, 2019 1:35 AM
To: Jan Kiszka <jan.kiszka@...>
Cc: takehisa.katayama.bx@...; sz.lin@...;
cip-dev@...
Subject: Re: [cip-dev] Request for guidance: removal of old config files
[was: Kernel configurations for 4.19?]

On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
[...]
4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig
Those can go, I'm not aware of their usage on 4.19. But do we have one
for the am335-x-based BBB, our reference board?
Good point. I have not yet tried running 4.19 on the BBB, but I can look
at adding one - or perhaps Nobuhiro or Pavel already has a suitable config?
I have a BBB, but I do not try running 4.19 on BBB.
I will try this.


4.19/arm/toshiba_tegra_defconfig
4.19/arm/toshiba_zynq_defconfig
4.19/powerpc/toshiba_defconfig
4.19/x86/plathome_obsvx1.config
4.19/x86/siemens_i386-rt.config
I do not recall the history of that one anymore. We should have at
least one -rt config for x86 somewhere.
Yes, and also the build rules should check out -rt branches instead of
the main CIP branches when processing an -rt configuration.

4.19/x86/siemens_iot2000.config
4.19/x86/siemens_server_defconfig
Those two should stay.
But they need to be reviewed, as automatic config updates usually don't
cope with renaming of config symbols.
Best regards,
Nobuhiro


Re: Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Pavel Machek
 

Hi!

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform. We have upstreamed this driver support on 4.19 kernel [1]
[1]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4effb64c323152

This driver is based on RTC PCF 85363 driver which has rtc nvmem/alarm support [2] . Rtc nvmem framework is introduced in 4.13
[2]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc636cbeef5293d5

We are seeing the following options for backporting this driver to
4.4 kernel
First, you did a lot of work there...

Option 1:
Backport this driver[1] to 4.4 kernel along with nvmem/alarm support. we have already done this work and patches are available at [3]
[3]. https://gitlab.com/bijud/pcf85263/tree/master
Ok, this is rather long/big series, and some parts are quite scary:
https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-registering-the-nvmem-device-before-.patch

Option 2:
Backport RTC PCF85263 driver, removing Alarm/nvmem functionality
from [2] .
So we basically get this one, and few patches on top, local to the new files.
https://gitlab.com/bijud/pcf85263/blob/master/0015-rtc-add-support-for-NXP-PCF85363-real-time-clock.patch

I think I prefer option 2.

Option 3:
Don't backport RTC support at all.
Applying patch #15 is easy. We can do option 2 I believe.

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


Re: Request for guidance: removal of old config files [was: Kernel configurations for 4.19?]

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
[...]
4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig
Those can go, I'm not aware of their usage on 4.19. But do we have one for the
am335-x-based BBB, our reference board?
Good point. I have not yet tried running 4.19 on the BBB, but I can
look at adding one - or perhaps Nobuhiro or Pavel already has a
suitable config?

4.19/arm/toshiba_tegra_defconfig
4.19/arm/toshiba_zynq_defconfig
4.19/powerpc/toshiba_defconfig
4.19/x86/plathome_obsvx1.config
4.19/x86/siemens_i386-rt.config
I do not recall the history of that one anymore. We should have at least one -rt
config for x86 somewhere.
Yes, and also the build rules should check out -rt branches instead of
the main CIP branches when processing an -rt configuration.

4.19/x86/siemens_iot2000.config
4.19/x86/siemens_server_defconfig
Those two should stay.
But they need to be reviewed, as automatic config updates usually don't
cope with renaming of config symbols.

Ben.

4.19/x86/toshiba_defconfig

Ben.
Thanks,
Jan
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


[ANNOUNCE] Release 4.19.58-cip6 and 4.4.185-cip35

Nobuhiro Iwamatsu
 

Hi all,

CIP kernel team has released Linux kernel 4.19.58-cip6 and 4.4.185-cip35.

Linux-4.19.y-cip has been updated from base version from 4.19.56 to 4.19.58,
and linux-4.4.y-cip has been updated from 4.4.182 to 4.4.185 with pxa2xx's
spi fix.
And CIP's gitlab CI configuration file (.gitlab-ci.yml) has been added.

You can get this release via the git tree at:

4.19.58-cip6:

repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch: linux-4.19.y-cip
commit: 2be2d3f02499e9d3a68f9e2ad1b1c4a0c42189b2

4.4.185-cip35:

This release has updated the base version from 4.4.182 to 4.4.185.

repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch: linux-4.4.y-cip
commit: 7b3d18ad0155a525f36903fc950dd27fe7ef1443

Best regards,
Nobuhiro


Regarding backporting RTC PCF85263 driver to cip 4.4 kernel

Biju Das <biju.das@...>
 

Hi All,

 

RTC PCF85263 is used by iWave RZ/G1C SBC( iwg23s) platform.  We have upstreamed  this driver support  on 4.19 kernel [1]

[1]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=fc979933bcf162595b6004d0de4effb64c323152

 

This driver is based  on RTC PCF 85363 driver which has rtc nvmem/alarm support [2] .  Rtc nvmem framework is introduced in 4.13

[2]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85363.c?h=v5.2&id=a9687aa2764dd2669602bd19dc636cbeef5293d5

 

We are seeing the following options for backporting this driver to 4.4 kernel

 

Option 1:

Backport this driver[1] to 4.4 kernel along with nvmem/alarm support. we have already done this work and patches are available at [3]

[3]. https://gitlab.com/bijud/pcf85263/tree/master

 

Option 2:

Backport RTC PCF85263 driver, removing  Alarm/nvmem functionality from  [2] .

 

Option 3:

Don't backport RTC support at all.

 

Please share your views, so that I can work on this accordingly.

 

Regards,

Biju

 

 


Re: Kernel configurations for 4.19?

daniel.sangorrin@...
 

Hello Ben,

[Note] repeating the reply because I got some rejected mails.

From: Ben Hutchings
I have received new config files from most members, but no-one told me
if the old configs can be deleted. For reference, these are the files
we have for 4.19 that are based on those submitted for 4.4:
You can discard the 4.4 old configurations from Toshiba. At the moment, we only need support for this one:
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/blob/master/4.19/x86/toshiba_atom_baytrail_cip.config

[Note] we may send more configuration files in the near future.

Thanks,
Daniel

4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig
4.19/arm/toshiba_tegra_defconfig
4.19/arm/toshiba_zynq_defconfig
4.19/powerpc/toshiba_defconfig
4.19/x86/plathome_obsvx1.config
4.19/x86/siemens_i386-rt.config
4.19/x86/siemens_iot2000.config
4.19/x86/siemens_server_defconfig
4.19/x86/toshiba_defconfig

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [PATCH v3 4.19.y-cip] Add gitlab-ci.yaml

Pavel Machek
 

Hi!

This is configured to build and test the following configurations:

* BUILD_ARCH: arm
* CONFIG: renesas_shmobile_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

* BUILD_ARCH: arm64
* CONFIG: renesas_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a774c0-ek874
* DTBS: r8a774c0-ek874.dtb

* BUILD_ARCH: arm
* CONFIG: shmobile_defconfig
* CONFIG_LOC: intree
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future
I went ahead, and applied this to linux-4.19.y-cip-rt-rebase branch,
too. If it is easy to add that one to testing, it would be nice.

Best regards,
Pavel

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


Re: [PATCH v3 4.4.y-cip] Add gitlab-ci.yaml

Pavel Machek
 

On Mon 2019-07-08 14:16:03, Chris Paterson wrote:
This is configured to build and test the following configurations:

* BUILD_ARCH: arm
* CONFIG: renesas_shmobile_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

* BUILD_ARCH: arm
* CONFIG: shmobile_defconfig
* CONFIG_LOC: intree
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future
Thanks, applied to 4.4-cip, and pushed out.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH v3 4.19.y-cip] Add gitlab-ci.yaml

Pavel Machek
 

Hi!

This is configured to build and test the following configurations:

* BUILD_ARCH: arm
* CONFIG: renesas_shmobile_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

* BUILD_ARCH: arm64
* CONFIG: renesas_defconfig
* CONFIG_LOC: cip-kernel-config
* DEVICES: r8a774c0-ek874
* DTBS: r8a774c0-ek874.dtb

* BUILD_ARCH: arm
* CONFIG: shmobile_defconfig
* CONFIG_LOC: intree
* DEVICES: r8a7743-iwg20d-q7 r8a7745-iwg22d-sodimm
* DTBS: r8a7743-iwg20d-q7-dbcm-ca.dtb r8a7745-iwg22d-sodimm-dbhd-ca.dtb

Over time support will be added for all CIP supported architectures and
configurations.
Thanks, applied and pushed out. Sorry for the delay.

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


Re: [ANNOUNCE] 4.4.176-cip31-rt23

Jan Kiszka
 

Hi Pavel,

On 29.03.19 12:06, Daniel Wagner wrote:
Hello CIP RT Folks!

I'm pleased to announce the 4.4.176-cip31-rt23 stable release.

This release is just an update to the new stable 4.4.176-cip31 version
and no RT specific changes have been made.

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git

branch: linux-4.4.y-cip-rt
Head SHA1: b51a171ad762ba4a78b0ed0c7ec83fb9f6fb135f
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?

Thanks,
Jan

PS: Please make it -rt24 then. ;)

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

7541 - 7560 of 10158