Date   

Re: [PATCH 4.19.y-cip 1/6] arm64: dts: renesas: r8a774c0-cat874: Add LEDs support

Pavel Machek
 

Hi!

+ 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?
It is labelled as LED0 label on the board and green colour.

Basically this board is as per 96boards CE specification
System and User LEDs
The following LEDs shall be present on the board.
The LEDs shall be of the specified size, color and location.
The User LEDs shall be directly programmable from the SoC.
1. WiFi activity LED Yellow Type: 0603 SMD
2. Bluetooth activity LED Blue Type: 0603 SMD
3. User LEDs x4 Green Type: 0603 SMD
Other LEDs and UI interfaces are optional.

As a LED maintainer, What is your recommendation for mainline?

1) label = "LED0"; --> based on the label on the board

2) label = " gren:LED0 "; --> based on the colour and label on the board.

3) label = " green:user1";--> based on the colour and label as per 96 boards CE specification.
Lets make it "green:user1".

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


Re: [PATCH 4.4.y-cip 03/10] rtc: pcf85363: set time accurately

Biju Das <biju.das@...>
 

Hi Pavel,

Thanks for the feedback.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: Tuesday, July 16, 2019 10:04 PM
To: Biju Das <biju.das@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] [PATCH 4.4.y-cip 03/10] rtc: pcf85363: set time
accurately

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.
Please see the document [1] and [2] section 8, that have the details related to wrap around.
[1] https://www.nxp.com/docs/en/data-sheet/PCF85363A.pdf
[2] https://www.nxp.com/docs/en/data-sheet/PCF85263A.pdf

Regards,
Biju

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


Re: [PATCH 4.19.y-cip 2/6] arm64: dts: renesas: r8a774c0-cat874: Add RWDT support

Biju Das <biju.das@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y-cip 2/6] arm64: dts: renesas: r8a774c0-
cat874: Add RWDT support

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?
Yes, if you enable watchdog in user space and there is no ping activity for 60 sec.
We can verify this by using the below command

cat > /dev/watchdog0 & for i in $(seq 100); do echo $i; sleep 1; done

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

Do we care?
As per [1]
- timeout-sec : Contains the watchdog timeout in seconds
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt?h=v5.2

If time-out is not specified, then it uses the default timeout mentioned by the driver.

Regards,
Biju

@@ -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


Re: [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add support for NXP pcf85263 rtc

Biju Das <biju.das@...>
 

Hi Nobuhiro,

Thanks for the feedback.

Subject: RE: [cip-dev] [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add support for
NXP pcf85263 rtc

Hi,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Biju Das
Sent: Tuesday, July 16, 2019 5:15 PM
To: cip-dev@...
Cc: Biju Das <biju.das@...>
Subject: [cip-dev] [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add support
for NXP pcf85263 rtc

commit fc979933bcf162595b6004d0de4effb64c323152 upstream.

Add support for NXP pcf85263 real-time clock. pcf85263 rtc is
compatible with pcf85363,except that pcf85363 has additional 64 bytes of
RAM.

1 byte of nvmem is supported and exposed in sysfs (# is the instance
number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem

Signed-off-by: Biju Das <biju.das@...> [ Removed rtc nvmem
support. Added I2C ID table for rtc-pcf85263 ]
You've deleted Alexandre's Signed-off-by tag from original patch.
Thanks for pointing this out. It is a mistake. Can you please fix this while applying to the tree?

Or

Do you want me to send another patch fixing this? Please let me know.

Regards,
Biju

[>]
---
drivers/rtc/rtc-pcf85363.c | 40
++++++++++++++++++++++++++++++++--------
1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
index dc57a6f..64217f1 100644
--- a/drivers/rtc/rtc-pcf85363.c
+++ b/drivers/rtc/rtc-pcf85363.c
@@ -87,6 +87,11 @@ struct pcf85363 {
struct regmap *regmap;
};

+struct pcf85x63_config {
+ struct regmap_config regmap;
+ unsigned int num_nvram;
+};
+
static int pcf85363_rtc_read_time(struct device *dev, struct rtc_time
*tm) {
struct pcf85363 *pcf85363 = dev_get_drvdata(dev); @@ -148,16
+153,33 @@ static const struct rtc_class_ops rtc_ops = {
.set_time = pcf85363_rtc_set_time,
};

-static const struct regmap_config regmap_config = {
- .reg_bits = 8,
- .val_bits = 8,
- .max_register = 0x7f,
+static const struct pcf85x63_config pcf_85263_config = {
+ .regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x2f,
+ },
+ .num_nvram = 1
+};
+
+static const struct pcf85x63_config pcf_85363_config = {
+ .regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x7f,
+ },
+ .num_nvram = 2
};

static int pcf85363_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct pcf85363 *pcf85363;
+ const struct pcf85x63_config *config = &pcf_85363_config;
+ const void *data = of_device_get_match_data(&client->dev);
+
+ if (data)
+ config = data;

if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
@@ -167,7 +189,7 @@ static int pcf85363_probe(struct i2c_client *client,
if (!pcf85363)
return -ENOMEM;

- pcf85363->regmap = devm_regmap_init_i2c(client,
&regmap_config);
+ pcf85363->regmap = devm_regmap_init_i2c(client,
&config->regmap);
if (IS_ERR(pcf85363->regmap)) {
dev_err(&client->dev, "regmap allocation failed\n");
return PTR_ERR(pcf85363->regmap);
@@ -185,12 +207,14 @@ static int pcf85363_probe(struct i2c_client
*client,

static const struct i2c_device_id pcf85363_id[] = {
{ "pcf85363", 0 },
+ { "pcf85263", 0 },
{ }
};

static const struct of_device_id dev_ids[] = {
- { .compatible = "nxp,pcf85363" },
- {}
+ { .compatible = "nxp,pcf85263", .data = &pcf_85263_config },
+ { .compatible = "nxp,pcf85363", .data = &pcf_85363_config },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, dev_ids);

@@ -206,5 +230,5 @@ static struct i2c_driver pcf85363_driver = {
module_i2c_driver(pcf85363_driver);

MODULE_AUTHOR("Eric Nelson");
-MODULE_DESCRIPTION("pcf85363 I2C RTC driver");
+MODULE_DESCRIPTION("pcf85263/pcf85363 I2C RTC driver");
MODULE_LICENSE("GPL");
--
2.7.4

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


Re: [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add support for NXP pcf85263 rtc

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Biju Das
Sent: Tuesday, July 16, 2019 5:15 PM
To: cip-dev@...
Cc: Biju Das <biju.das@...>
Subject: [cip-dev] [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add support
for NXP pcf85263 rtc

commit fc979933bcf162595b6004d0de4effb64c323152 upstream.

Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
with pcf85363,except that pcf85363 has additional 64 bytes of RAM.

1 byte of nvmem is supported and exposed in sysfs (# is the instance
number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem

Signed-off-by: Biju Das <biju.das@...> [ Removed rtc nvmem
support. Added I2C ID table for rtc-pcf85263 ]
You've deleted Alexandre's Signed-off-by tag from original patch.

Best regards,
Nobuhiro

---
drivers/rtc/rtc-pcf85363.c | 40
++++++++++++++++++++++++++++++++--------
1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
index dc57a6f..64217f1 100644
--- a/drivers/rtc/rtc-pcf85363.c
+++ b/drivers/rtc/rtc-pcf85363.c
@@ -87,6 +87,11 @@ struct pcf85363 {
struct regmap *regmap;
};

+struct pcf85x63_config {
+ struct regmap_config regmap;
+ unsigned int num_nvram;
+};
+
static int pcf85363_rtc_read_time(struct device *dev, struct rtc_time
*tm) {
struct pcf85363 *pcf85363 = dev_get_drvdata(dev); @@ -148,16
+153,33 @@ static const struct rtc_class_ops rtc_ops = {
.set_time = pcf85363_rtc_set_time,
};

-static const struct regmap_config regmap_config = {
- .reg_bits = 8,
- .val_bits = 8,
- .max_register = 0x7f,
+static const struct pcf85x63_config pcf_85263_config = {
+ .regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x2f,
+ },
+ .num_nvram = 1
+};
+
+static const struct pcf85x63_config pcf_85363_config = {
+ .regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x7f,
+ },
+ .num_nvram = 2
};

static int pcf85363_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct pcf85363 *pcf85363;
+ const struct pcf85x63_config *config = &pcf_85363_config;
+ const void *data = of_device_get_match_data(&client->dev);
+
+ if (data)
+ config = data;

if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
@@ -167,7 +189,7 @@ static int pcf85363_probe(struct i2c_client *client,
if (!pcf85363)
return -ENOMEM;

- pcf85363->regmap = devm_regmap_init_i2c(client,
&regmap_config);
+ pcf85363->regmap = devm_regmap_init_i2c(client,
&config->regmap);
if (IS_ERR(pcf85363->regmap)) {
dev_err(&client->dev, "regmap allocation failed\n");
return PTR_ERR(pcf85363->regmap);
@@ -185,12 +207,14 @@ static int pcf85363_probe(struct i2c_client
*client,

static const struct i2c_device_id pcf85363_id[] = {
{ "pcf85363", 0 },
+ { "pcf85263", 0 },
{ }
};

static const struct of_device_id dev_ids[] = {
- { .compatible = "nxp,pcf85363" },
- {}
+ { .compatible = "nxp,pcf85263", .data = &pcf_85263_config },
+ { .compatible = "nxp,pcf85363", .data = &pcf_85363_config },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, dev_ids);

@@ -206,5 +230,5 @@ static struct i2c_driver pcf85363_driver =
{ module_i2c_driver(pcf85363_driver);

MODULE_AUTHOR("Eric Nelson");
-MODULE_DESCRIPTION("pcf85363 I2C RTC driver");
+MODULE_DESCRIPTION("pcf85263/pcf85363 I2C RTC driver");
MODULE_LICENSE("GPL");
--
2.7.4

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


Re: [PATCH 4.19.y-cip 1/6] arm64: dts: renesas: r8a774c0-cat874: Add LEDs support

Biju Das <biju.das@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y-cip 1/6] arm64: dts: renesas: r8a774c0-
cat874: Add LEDs support

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?
It is labelled as LED0 label on the board and green colour.

Basically this board is as per 96boards CE specification
System and User LEDs
The following LEDs shall be present on the board.
The LEDs shall be of the specified size, color and location.
The User LEDs shall be directly programmable from the SoC.
1. WiFi activity LED Yellow Type: 0603 SMD
2. Bluetooth activity LED Blue Type: 0603 SMD
3. User LEDs x4 Green Type: 0603 SMD
Other LEDs and UI interfaces are optional.

As a LED maintainer, What is your recommendation for mainline?

1) label = "LED0"; --> based on the label on the board

2) label = " gren:LED0 "; --> based on the colour and label on the board.

3) label = " green:user1";--> based on the colour and label as per 96 boards CE specification.

Regards,
Biju


Re: [ANNOUNCE] 4.4.176-cip31-rt23

Daniel Wagner <wagi@...>
 

Good Morning,

On 7/16/19 10:14 PM, Pavel Machek wrote:
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?
I got a private one at home for development and I am also using the one sponsored by LinuxFoundation:

https://ci-rt.linutronix.de/RT-Test/

I used to push the CIP version for testing to this CI system as well (see cip-4.4.y-rt branch). If you are interested to get access to the CI system you have to talk to Anna-Maria.

If sources are available somewhere, I can try to help with testing.
I've just uploaded the v4.4.180-rt182 version. Announcement is coming later. I continue with the merging. I keep you updated.

Thanks,
Daniel


Re: [PATCH 4.19.y-cip 4/6] rtc: rx8581: Add support for Epson rx8571 RTC

Biju Das <biju.das@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [cip-dev] [PATCH 4.19.y-cip 4/6] rtc: rx8581: Add support for
Epson rx8571 RTC

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.
As per the discussion we had in ML. Any validation to be done at nvmem framework level.

Probably best done in mainline first...
We need to fix this issue at nvmem frame work level. Which involves API changes.
Please see the mail discussion related to this.

https://patchwork.kernel.org/patch/10723299/

May be at some point, we will have a fix for this issues.

regards,
Biju


Re: [PATCH 4.4.y-cip 03/10] rtc: pcf85363: set time accurately

Pavel Machek
 

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


Re: [PATCH 4.19.y-cip 0/6] Add RTC support

Pavel Machek
 

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


Re: [PATCH 4.19.y-cip 2/6] arm64: dts: renesas: r8a774c0-cat874: Add RWDT support

Pavel Machek
 

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


Re: [PATCH 4.19.y-cip 1/6] arm64: dts: renesas: r8a774c0-cat874: Add LEDs support

Pavel Machek
 

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


Re: [PATCH 4.19.y-cip 4/6] rtc: rx8581: Add support for Epson rx8571 RTC

Pavel Machek
 

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


Re: [ANNOUNCE] 4.4.176-cip31-rt23

Pavel Machek
 

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


Re: [PATCH 4.4.y-cip 0/5] Add QSPI support

Pavel Machek
 

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


Re: [PATCH 4.19.y-cip 00/12] Add USB Host support

Pavel Machek
 

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


Re: [ANNOUNCE] 4.4.176-cip31-rt23

Daniel Wagner <wagi@...>
 

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.


Re: [PATCH 4.19.y-cip 04/12] phy: renesas: rcar-gen3-usb2: unify OBINTEN handling

Biju Das <biju.das@...>
 

Hi Pavel,

Thanks for the feedback.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: Tuesday, July 16, 2019 1:03 PM
To: Biju Das <biju.das@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] [PATCH 4.19.y-cip 04/12] phy: renesas: rcar-gen3-usb2:
unify OBINTEN handling

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
I agree, it removes optimization compared to the old code, But on the hand, this code is not frequently used and the code is much cleaner.

Regards,
Biju


Re: [PATCH 4.19.y-cip 05/12] phy: renesas: rcar-gen3-usb2: add conditions for uses_otg_pins == false

Biju Das <biju.das@...>
 

HI Pavel,

Thanks for the feedback.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: Tuesday, July 16, 2019 1:05 PM
To: Biju Das <biju.das@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] [PATCH 4.19.y-cip 05/12] phy: renesas: rcar-gen3-usb2:
add conditions for uses_otg_pins == false

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.
Yes I agree. There is a room for improvement in future.

Regards,
Biju


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

Biju Das <biju.das@...>
 

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);

?

6481 - 6500 of 9202