[ANNOUNCE] Renesas tree closed for v4.21
Hi, I would like to stop accepting non-bug-fix patches for v4.21 and get the last pull requests posted by the end of this week. This is in order for them to be sent before the release of v4.20-rc6, the deadline set by the ARM SoC maintainers. As patches should ideally progress from the renesas tree into linux-next before sending pull requests there is a few days lead time involved. I intend to begin queueing up patches for v4.22 as they are ready.
Re: [PATCH] gpio: rcar: reference device instead of platform device
On Thu, Nov 22, 2018 at 9:19 PM Vladimir Zapolskiy wrote: > The change simplifies dereferences to the mediated struct device, also > it allows to limit the scope of the platform device usage to probe and > remove functions only. > > Non-functional change. > > Signed-off-by: Vladimir Zapolskiy Patch applied with Geert's review tag. Yours, Linus Walleij
Re: [RFC v3 1/2] pinctrl: core: Add pinctrl_mux_gpio_request_enable
On Tue, Nov 20, 2018 at 4:19 PM Fabrizio Castro wrote: > Sometimes there is the need to change the muxing of a pin to make it > a GPIO without going through gpiolib. > This patch adds pinctrl_mux_gpio_request_enable to deal with this new > use case from code that has nothing to do with pinctrl. It has a lot to do with pinctrl I think, so I get confused by this commit message. > extern int pinctrl_gpio_request(unsigned gpio); > +extern int pinctrl_mux_gpio_request_enable(unsigned gpio); What's wrong with just using the existing call pinctrl_gpio_request() right above your new one? It's not like we're reference counting or something, it's just a callback. Sprinkle some comments to show what's going on. If you for some reason need a new call for this specific use case, it needs to be named after the use case, like pinctrl_gpio_request_for_irq() so it is obvious what the function is doing. Yours, Linus Walleij
[PATCH v2 1/2] ARM: dts: r7s9210: Initial SoC device tree
Basic support for the RZ/A2 (R7S9210) SoC.
Signed-off-by: Chris Brandt
---
v2:
* Fixed cpg node name to match reg address
* Removed the clocks subnode
* SCIF register range 18 to 0x18
* Removed 'reset-cells' from cpg because resets not supported (yet?)
* Sorted nodes by address (per group of device
---
arch/arm/boot/dts/r7s9210.dtsi | 204 +
1 file changed, 204 insertions(+)
create mode 100644 arch/arm/boot/dts/r7s9210.dtsi
diff --git a/arch/arm/boot/dts/r7s9210.dtsi b/arch/arm/boot/dts/r7s9210.dtsi
new file mode 100644
index ..2b589226895e
--- /dev/null
+++ b/arch/arm/boot/dts/r7s9210.dtsi
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the R7S9210 SoC
+ *
+ * Copyright (C) 2018 Renesas Electronics Corporation
+ *
+ */
+
+#include
+#include
+
+/ {
+ compatible = "renesas,r7s9210";
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bsid: chipid@fcfe8004 {
+ compatible = "renesas,bsid";
+ reg = <0xfcfe8004 4>;
+ };
+
+ /* External clocks */
+ extal_clk: extal {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ /* Value must be set by board */
+ clock-frequency = <0>;
+ };
+
+ rtc_x1_clk: rtc_x1 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ /* If clk present, value (32678) must be set by board */
+ clock-frequency = <0>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ clock-frequency = <52800>;
+ next-level-cache = <>;
+ };
+ };
+
+ L2: cache-controller@1f003000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x1f003000 0x1000>;
+ interrupts = ;
+ arm,early-bresp-disable;
+ arm,full-line-zero-disable;
+ cache-unified;
+ cache-level = <2>;
+ };
+
+ gic: interrupt-controller@e8221000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0xe8221000 0x1000>,
+ <0xe8222000 0x1000>;
+ };
+
+ cpg: clock-controller@fcfe0010 {
+ compatible = "renesas,r7s9210-cpg-mssr";
+ reg = <0xfcfe0010 0x455>;
+ clocks = <_clk>;
+ clock-names = "extal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ };
+
+ wdt: watchdog@fcfe7000 {
+ compatible = "renesas,r7s9210-wdt", "renesas,rza-wdt";
+ reg = <0xfcfe7000 0x26>;
+ interrupts = ;
+ clocks = < CPG_CORE R7S9210_CLK_P0>;
+ };
+
+ pinctrl: pin-controller@fcffe000 {
+ compatible = "renesas,r7s9210-pinctrl";
+ reg = <0xfcffe000 0x1000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = < 0 0 176>;
+ };
+
+ scif0: serial@e8007000 {
+ compatible = "renesas,scif-r7s9210";
+ reg = <0xe8007000 0x18>;
+ interrupts = ,
+,
+,
+,
+,
+;
+ interrupt-names = "eri", "rxi", "txi", "bri", "dri", "tei";
+ clocks = < CPG_MOD 47>;
+ clock-names = "fck";
+ power-domains = <>;
+ status = "disabled";
+ };
+
+ scif1: serial@e8007800 {
+ compatible = "renesas,scif-r7s9210";
+ reg = <0xe8007800 0x18>;
+ interrupts = ,
+,
+,
+,
+,
+;
+ interrupt-names = "eri", "rxi", "txi", "bri", "dri", "tei";
+ clocks = < CPG_MOD 46>;
+ clock-names = "fck";
+ power-domains = <>;
+ status = "disabled";
+ };
+
+ scif2: serial@e8008000 {
+ compatible = "renesas,scif-r7s9210";
+ reg = <0xe8008000 0x18>;
+ interrupts = ,
+,
+,
+,
+,
+;
+ interrupt-names = "eri", "rxi", "txi", "bri", "dri", "tei";
+ clocks = < CPG_MOD 45>;
+ clock-names = "fck";
+
[PATCH v2 0/2] Add Initial Device Tree for RZ/A2
Add a Device Tree for RZ/A2 and the existing eval board. Once these get approved, I'll start piling on the other drivers in another patch series. NOTE: Since Rob is in the middle of converting shmobile.txt to renesas.yaml, I'll wait till that is finisehd before I add this RZ/A2M EVB board. Chris Brandt (2): ARM: dts: r7s9210: Initial SoC device tree ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/r7s9210-rza2mevb.dts | 98 arch/arm/boot/dts/r7s9210.dtsi | 204 + 3 files changed, 303 insertions(+) create mode 100644 arch/arm/boot/dts/r7s9210-rza2mevb.dts create mode 100644 arch/arm/boot/dts/r7s9210.dtsi -- 2.16.1
[PATCH v2 2/2] ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB
Add support for Renesas RZ/A2M evaluation board.
Signed-off-by: Chris Brandt
---
v2:
* Removed patch for shmobile.txt
* Added SPDX
* Removed earlycon from bootargs
* Fixed address in memory node name
* Removed un-needed "okay" from leds node
* Added green LED node
* Dropped this blank line in pinctrl node
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r7s9210-rza2mevb.dts | 98 ++
2 files changed, 99 insertions(+)
create mode 100644 arch/arm/boot/dts/r7s9210-rza2mevb.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1ef2133a18c2..9665694b6494 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -824,6 +824,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r7s72100-genmai.dtb \
r7s72100-gr-peach.dtb \
r7s72100-rskrza1.dtb \
+ r7s9210-rza2mevb.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
r8a7743-iwg20d-q7.dtb \
diff --git a/arch/arm/boot/dts/r7s9210-rza2mevb.dts
b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
new file mode 100644
index ..8d0842a46d4f
--- /dev/null
+++ b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the RZA2MEVB board
+ *
+ * Copyright (C) 2018 Renesas Electronics
+ *
+ */
+
+/dts-v1/;
+#include "r7s9210.dtsi"
+#include
+#include
+
+/ {
+ model = "RZA2MEVB";
+ compatible = "renesas,rza2mevb", "renesas,r7s9210";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel rootfstype=cramfs root=mtd:rootfs";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0x4000 0x0080>; /* HyperRAM */
+ };
+
+ lbsc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ red {
+ gpios = < RZA2_PIN(PORT6, 0) GPIO_ACTIVE_HIGH>;
+ };
+ green {
+ gpios = < RZA2_PIN(PORTC, 1) GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /* Cramfs XIP File System in QSPI */
+ qspi@2000 {
+ compatible = "mtd-rom";
+ probe-type = "direct-mapped"; /* XIP from QSPI */
+ reg = <0x2000 0x400>; /* 64 MB*/
+ bank-width = <4>;
+ device-width = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@80 {
+ label ="rootfs";
+ reg = <0x080 0x100>; /* 16MB @ 0x2080 */
+ read-only;
+ };
+ };
+};
+
+/* EXTAL */
+_clk {
+ clock-frequency = <2400>; /* 24MHz */
+};
+
+/* RTC_X1 */
+_x1_clk {
+ clock-frequency = <32768>;
+};
+
+ {
+ /* Serial Console */
+ scif4_pins: serial4 {
+ pinmux = ,/* TxD4 */
+;/* RxD4 */
+ };
+};
+
+/* High resolution System tick timers */
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+/* Serial Console */
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+};
--
2.16.1
Re: [PATCH v2 0/4] I2C0/3/5 pin control for H3 and M3-W
Hi Uli,
> pinctrl: sh-pfc: r8a7795: Add I2C{0,3,5} pins, groups and functions
> pinctrl: sh-pfc: r8a7795-es1: Add I2C{0,3,5} pins, groups and
> functions
> pinctrl: sh-pfc: r8a7796: Add I2C{0,3,5} pins, groups and functions
The BSP also has a similar patch for r8a77965. Could you also take care
of that?
Happy hacking,
Wolfram
signature.asc
Description: PGP signature
Re: [PATCH v2 3/5] ARM: dts: r8a7744: Add DU support
On Wed, Dec 05, 2018 at 09:06:53AM +, Biju Das wrote:
> Add du node to r8a7744 SoC DT. Boards that want to enable the DU
> need to specify the output topology.
>
> Signed-off-by: Biju Das
> ---
> V1-->V2
> * Removed LVDS encoder definition from DU node.
I would like this and the remaining patches in this series to
receive some review before I apply them. This likely means they
will be accepted for v4.22 as I am planning to close the
renesas tree for non-bugfixes for v4.21 later today.
b
> ---
> arch/arm/boot/dts/r8a7744.dtsi | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
> index 04148d6..6a51b16 100644
> --- a/arch/arm/boot/dts/r8a7744.dtsi
> +++ b/arch/arm/boot/dts/r8a7744.dtsi
> @@ -1645,8 +1645,14 @@
> };
>
> du: display@feb0 {
> - reg = <0 0xfeb0 0 0x4>,
> - <0 0xfeb9 0 0x1c>;
> + compatible = "renesas,du-r8a7744";
> + reg = <0 0xfeb0 0 0x4>;
> + interrupts = ,
> + ;
> + clocks = < CPG_MOD 724>,
> + < CPG_MOD 723>;
> + clock-names = "du.0", "du.1";
> + status = "disabled";
>
> ports {
> #address-cells = <1>;
> @@ -1663,7 +1669,6 @@
> };
> };
> };
> - /* placeholder */
> };
>
> prr: chipid@ff44 {
> --
> 2.7.4
>
Re: [PATCH v2 1/5] ARM: dts: iwg20d-q7-common: Move cmt/rwdt node out of RZ/G1M SOM
On Wed, Dec 05, 2018 at 09:06:51AM +, Biju Das wrote: > The iWave RZ/G1N board is almost identical to RZ/G1M. cmt and rwdt modules > are SoC specific and should be part of board dts rather than SoM dtsi. By > moving these nodes to the common dtsi it allows cmt and rwdt to be enabled > on both of these boards with less lines of code. > > Signed-off-by: Biju Das > Reviewed-by: Simon Horman > Reviewed-by: Geert Uytterhoeven Thanks, I have this in my tree for v4.21.
Re: [PATCH v2 2/5] ARM: dts: r8a7744-iwg20m: Add SPI NOR support
On Wed, Dec 05, 2018 at 09:06:52AM +, Biju Das wrote: > Add support for the SPI NOR device used to boot up the system > to the iWave RZ/G1N Qseven System On Module DT. > > Signed-off-by: Biju Das > Reviewed-by: Geert Uytterhoeven > --- > V1-->V2 > * Removed compatible string "sst,sst25vf016b". Thanks, applied for v4.21.
Re: [PATCH 1/2] arm64: dts: renesas: r8a77965: Add CAN controller nodes
On 11/21/2018 08:37 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Wed, Nov 21, 2018 at 12:33 AM Marek Vasut wrote:
>> On 11/19/2018 10:00 AM, Geert Uytterhoeven wrote:
>>> On Mon, Nov 19, 2018 at 12:46 AM Marek Vasut wrote:
On 11/19/2018 12:02 AM, Wolfram Sang wrote:
> On Sun, Nov 18, 2018 at 06:33:26PM +0100, Marek Vasut wrote:
>> From: Takeshi Kihara
>>
>> This patch adds CAN{0,1} controller nodes for the R8A77965 SoC.
>>
>> Based on several similar patches of the R8A7795 device tree
>> by Ramesh Shanmugasundaram
>> and Geert Uytterhoeven .
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Marc Kleine-Budde
>> Cc: Rob Herring
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: linux-renesas-soc@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>
> Were you able to do some testing using EXIO connectors? Would be nice to
> know what was tested.
Not on the M3N, since I don't see it broken out on the EXIO ; is it
really there ? It'd be easy to test on M3NSK with KF, but I don't have
either KF or M3NSK.
>>>
>>> Please have a look at EXIO Connector D, pins 13/14/15.
>>
>> That's LBSC WE1n/WE0n/CS0n on S-XS . Is there something I obviously
>> don't see ?
>
> Unless you connect an expansion card to the Ex Memory Connector,
> these signals are free to use, and can be pinmuxed to a CAN function.
Tested-by: Marek Vasut
on M3N Salvator-XS with a rats-nest MCP2551 setup on EXIO-D and Peak
CANFD USB.
--
Best regards,
Marek Vasut
[RFC PATCH 7/7] soc: renesas: r8a77990-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
E3, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77990-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77990-sysc.c
b/drivers/soc/renesas/r8a77990-sysc.c
index 664b244eb1dd9d95..1d2432020b7a15d2 100644
--- a/drivers/soc/renesas/r8a77990-sysc.c
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2018 Renesas Electronics Corp.
*/
+#include
#include
#include
#include
@@ -50,4 +51,6 @@ const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
.init = r8a77990_sysc_init,
.areas = r8a77990_areas,
.num_areas = ARRAY_SIZE(r8a77990_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 6/7] soc: renesas: r8a77980-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
V3H, to prevent conflicts between internal and external power requests.
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77980-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77980-sysc.c
b/drivers/soc/renesas/r8a77980-sysc.c
index a8dbe55e8ba82d7e..e3b5ee1b3091dee1 100644
--- a/drivers/soc/renesas/r8a77980-sysc.c
+++ b/drivers/soc/renesas/r8a77980-sysc.c
@@ -6,6 +6,7 @@
* Copyright (C) 2018 Cogent Embedded, Inc.
*/
+#include
#include
#include
@@ -49,4 +50,6 @@ static const struct rcar_sysc_area r8a77980_areas[]
__initconst = {
const struct rcar_sysc_info r8a77980_sysc_info __initconst = {
.areas = r8a77980_areas,
.num_areas = ARRAY_SIZE(r8a77980_areas),
+ .extmask_offs = 0x138,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 1/7] soc: renesas: rcar-sysc: Prepare for fixing power request conflicts
Recent R-Car Gen3 SoCs added an External Request Mask Register to the
System Controller (SYSC). This register allows to mask external power
requests for CPU or 3DG domains, to prevent conflicts when Linux changes
the state of a power domain through SYSC, which could lead to system
lock-ups.
Add support for making use of this register. Take into account that the
register is optional, and that its location and contents are
SoC-specific.
Inspired by a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/rcar-sysc.c | 16
drivers/soc/renesas/rcar-sysc.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 0c80fab4f8de6bc8..b28955e21a9868e0 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -63,6 +63,7 @@ struct rcar_sysc_ch {
static void __iomem *rcar_sysc_base;
static DEFINE_SPINLOCK(rcar_sysc_lock); /* SMP CPUs + I/O devices */
+static u32 rcar_sysc_extmask_offs, rcar_sysc_extmask_val;
static int rcar_sysc_pwr_on_off(const struct rcar_sysc_ch *sysc_ch, bool on)
{
@@ -105,6 +106,14 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
*sysc_ch, bool on)
spin_lock_irqsave(_sysc_lock, flags);
+ /*
+* Mask external power requests for CPU or 3DG domains
+*/
+ if (rcar_sysc_extmask_val) {
+ iowrite32(rcar_sysc_extmask_val,
+ rcar_sysc_base + rcar_sysc_extmask_offs);
+ }
+
/*
* The interrupt source needs to be enabled, but masked, to prevent the
* CPU from receiving it.
@@ -148,6 +157,9 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
*sysc_ch, bool on)
iowrite32(isr_mask, rcar_sysc_base + SYSCISCR);
out:
+ if (rcar_sysc_extmask_val)
+ iowrite32(0, rcar_sysc_base + rcar_sysc_extmask_offs);
+
spin_unlock_irqrestore(_sysc_lock, flags);
pr_debug("sysc power %s domain %d: %08x -> %d\n", on ? "on" : "off",
@@ -361,6 +373,10 @@ static int __init rcar_sysc_pd_init(void)
rcar_sysc_base = base;
+ /* Optional External Request Mask Register */
+ rcar_sysc_extmask_offs = info->extmask_offs;
+ rcar_sysc_extmask_val = info->extmask_val;
+
domains = kzalloc(sizeof(*domains), GFP_KERNEL);
if (!domains) {
error = -ENOMEM;
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 485520a5b295c13e..21ee3ff8620bbafe 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -44,6 +44,9 @@ struct rcar_sysc_info {
int (*init)(void); /* Optional */
const struct rcar_sysc_area *areas;
unsigned int num_areas;
+ /* Optional External Request Mask Register */
+ u32 extmask_offs; /* SYSCEXTMASK register offset */
+ u32 extmask_val;/* SYSCEXTMASK register mask value */
};
extern const struct rcar_sysc_info r8a7743_sysc_info;
--
2.17.1
[RFC PATCH 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts
Hi Simon, Magnus,
Recent R-Car Gen3 SoCs added an External Request Mask Register to the
System Controller (SYSC). This register allows to mask external power
requests for CPU or 3DG domains, to prevent conflicts when Linux changes
the state of a power domain through SYSC, which could lead to system
lock-ups.
This RFC patch series starts making use of this register. Note that the
register is optional, and that its location and contents are
SoC-specific.
This was inspired by a patch in the BSP by Dien Pham
.
This has been boot-tested on R-Car H3 ES1.0, H3 ES2.0, M3-W ES1.0, M3-N,
V3M, and E3 (only the last 3 have this register!), and regression-tested
on R-Car Gen2.
This has not been tested on R-Car H3 ES3.0, M3-W ES2.0, and V3H.
Thanks for your comments!
Geert Uytterhoeven (7):
soc: renesas: rcar-sysc: Prepare for fixing power request conflicts
soc: renesas: r8a7795-sysc: Fix power request conflicts
soc: renesas: r8a7796-sysc: Fix power request conflicts
soc: renesas: r8a77965-sysc: Fix power request conflicts
soc: renesas: r8a77970-sysc: Fix power request conflicts
soc: renesas: r8a77980-sysc: Fix power request conflicts
soc: renesas: r8a77990-sysc: Fix power request conflicts
drivers/soc/renesas/r8a7795-sysc.c | 32 -
drivers/soc/renesas/r8a7796-sysc.c | 22 +++-
drivers/soc/renesas/r8a77965-sysc.c | 3 +++
drivers/soc/renesas/r8a77970-sysc.c | 3 +++
drivers/soc/renesas/r8a77980-sysc.c | 3 +++
drivers/soc/renesas/r8a77990-sysc.c | 3 +++
drivers/soc/renesas/rcar-sysc.c | 16 +++
drivers/soc/renesas/rcar-sysc.h | 7 +--
8 files changed, 81 insertions(+), 8 deletions(-)
--
2.17.1
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
[RFC PATCH 3/7] soc: renesas: r8a7796-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
M3-W, to prevent conflicts between internal and external power requests.
This register does not exist on R-Car M3-W ES1.x.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a7796-sysc.c | 22 +-
drivers/soc/renesas/rcar-sysc.h| 2 +-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/renesas/r8a7796-sysc.c
b/drivers/soc/renesas/r8a7796-sysc.c
index 1b06f868b6e81c79..a4eaa8d1f5d0f49d 100644
--- a/drivers/soc/renesas/r8a7796-sysc.c
+++ b/drivers/soc/renesas/r8a7796-sysc.c
@@ -5,8 +5,10 @@
* Copyright (C) 2016 Glider bvba
*/
+#include
#include
#include
+#include
#include
@@ -39,7 +41,25 @@ static const struct rcar_sysc_area r8a7796_areas[]
__initconst = {
{ "a3ir", 0x180, 0, R8A7796_PD_A3IR, R8A7796_PD_ALWAYS_ON },
};
-const struct rcar_sysc_info r8a7796_sysc_info __initconst = {
+
+/* Fixups for R-Car M3-W ES1.x revision */
+static const struct soc_device_attribute r8a7796es1[] __initconst = {
+ { .soc_id = "r8a7796", .revision = "ES1.*" },
+ { /* sentinel */ }
+};
+
+static int __init r8a7796_sysc_init(void)
+{
+ if (soc_device_match(r8a7796es1))
+ r8a7796_sysc_info.extmask_val = 0;
+
+ return 0;
+}
+
+struct rcar_sysc_info r8a7796_sysc_info __initdata = {
+ .init = r8a7796_sysc_init,
.areas = r8a7796_areas,
.num_areas = ARRAY_SIZE(r8a7796_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 499797a9e18c2f10..64c2a0fa7945d80b 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -60,7 +60,7 @@ extern const struct rcar_sysc_info r8a7791_sysc_info;
extern const struct rcar_sysc_info r8a7792_sysc_info;
extern const struct rcar_sysc_info r8a7794_sysc_info;
extern struct rcar_sysc_info r8a7795_sysc_info;
-extern const struct rcar_sysc_info r8a7796_sysc_info;
+extern struct rcar_sysc_info r8a7796_sysc_info;
extern const struct rcar_sysc_info r8a77965_sysc_info;
extern const struct rcar_sysc_info r8a77970_sysc_info;
extern const struct rcar_sysc_info r8a77980_sysc_info;
--
2.17.1
[RFC PATCH 5/7] soc: renesas: r8a77970-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
V3M, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77970-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77970-sysc.c
b/drivers/soc/renesas/r8a77970-sysc.c
index 280c48b80f240424..b3033e3f0fd0b0ff 100644
--- a/drivers/soc/renesas/r8a77970-sysc.c
+++ b/drivers/soc/renesas/r8a77970-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2017 Cogent Embedded Inc.
*/
+#include
#include
#include
@@ -32,4 +33,6 @@ static const struct rcar_sysc_area r8a77970_areas[]
__initconst = {
const struct rcar_sysc_info r8a77970_sysc_info __initconst = {
.areas = r8a77970_areas,
.num_areas = ARRAY_SIZE(r8a77970_areas),
+ .extmask_offs = 0x1b0,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 4/7] soc: renesas: r8a77965-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
M3-N, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77965-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77965-sysc.c
b/drivers/soc/renesas/r8a77965-sysc.c
index e0533beb50fd7063..b5d8230d4bbc1b87 100644
--- a/drivers/soc/renesas/r8a77965-sysc.c
+++ b/drivers/soc/renesas/r8a77965-sysc.c
@@ -7,6 +7,7 @@
* Copyright (C) 2016 Glider bvba
*/
+#include
#include
#include
@@ -33,4 +34,6 @@ static const struct rcar_sysc_area r8a77965_areas[]
__initconst = {
const struct rcar_sysc_info r8a77965_sysc_info __initconst = {
.areas = r8a77965_areas,
.num_areas = ARRAY_SIZE(r8a77965_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 2/7] soc: renesas: r8a7795-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
H3, to prevent conflicts between internal and external power requests.
This register does not exist on R-Car H3 ES1.x and ES2.x.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a7795-sysc.c | 32 +-
drivers/soc/renesas/rcar-sysc.h| 2 +-
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/renesas/r8a7795-sysc.c
b/drivers/soc/renesas/r8a7795-sysc.c
index cda27a67de9876af..7e15cd09c4eb4780 100644
--- a/drivers/soc/renesas/r8a7795-sysc.c
+++ b/drivers/soc/renesas/r8a7795-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2016-2017 Glider bvba
*/
+#include
#include
#include
#include
@@ -51,25 +52,46 @@ static struct rcar_sysc_area r8a7795_areas[] __initdata = {
/*
-* Fixups for R-Car H3 revisions after ES1.x
+* Fixups for R-Car H3 revisions
*/
-static const struct soc_device_attribute r8a7795es1[] __initconst = {
- { .soc_id = "r8a7795", .revision = "ES1.*" },
+#define HAS_A2VC0 BIT(0) /* Power domain A2VC0 is present */
+#define NO_EXTMASK BIT(1) /* Missing SYSCEXTMASK register */
+
+static const struct soc_device_attribute r8a7795_quirks_match[] __initconst = {
+ {
+ .soc_id = "r8a7795", .revision = "ES1.*",
+ .data = (void *)(HAS_A2VC0 | NO_EXTMASK),
+ }, {
+ .soc_id = "r8a7795", .revision = "ES2.*",
+ .data = (void *)(NO_EXTMASK),
+ },
{ /* sentinel */ }
};
static int __init r8a7795_sysc_init(void)
{
- if (!soc_device_match(r8a7795es1))
+ const struct soc_device_attribute *attr;
+ u32 quirks = 0;
+
+ attr = soc_device_match(r8a7795_quirks_match);
+ if (attr)
+ quirks = (uintptr_t)attr->data;
+
+ if (!(quirks & HAS_A2VC0))
rcar_sysc_nullify(r8a7795_areas, ARRAY_SIZE(r8a7795_areas),
R8A7795_PD_A2VC0);
+ if (quirks & NO_EXTMASK)
+ r8a7795_sysc_info.extmask_val = 0;
+
return 0;
}
-const struct rcar_sysc_info r8a7795_sysc_info __initconst = {
+struct rcar_sysc_info r8a7795_sysc_info __initdata = {
.init = r8a7795_sysc_init,
.areas = r8a7795_areas,
.num_areas = ARRAY_SIZE(r8a7795_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 21ee3ff8620bbafe..499797a9e18c2f10 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -59,7 +59,7 @@ extern const struct rcar_sysc_info r8a7790_sysc_info;
extern const struct rcar_sysc_info r8a7791_sysc_info;
extern const struct rcar_sysc_info r8a7792_sysc_info;
extern const struct rcar_sysc_info r8a7794_sysc_info;
-extern const struct rcar_sysc_info r8a7795_sysc_info;
+extern struct rcar_sysc_info r8a7795_sysc_info;
extern const struct rcar_sysc_info r8a7796_sysc_info;
extern const struct rcar_sysc_info r8a77965_sysc_info;
extern const struct rcar_sysc_info r8a77970_sysc_info;
--
2.17.1
Re: [PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
On 12/05/2018 03:39 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Sun, Dec 2, 2018 at 8:36 PM Marek Vasut wrote:
>> It is possible that the PCA953x is powered down during suspend.
>> Use regmap cache to assure the registers in the PCA953x are in
>> line with the driver state after resume.
>>
>> Signed-off-by: Marek Vasut
>
>> +static int pca953x_suspend(struct device *dev)
>> +{
>> + struct pca953x_chip *chip = dev_get_drvdata(dev);
>> +
>> + regcache_mark_dirty(chip->regmap);
>> + pca953x_regcache_sync(dev);
>> + regcache_cache_only(chip->regmap, true);
>
> Based on the discussion about adding suspend/resume support to the VC5
> clock driver, I guess the two sync calls above are not needed here?
Yes
--
Best regards,
Marek Vasut
Re: [PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
Hi Marek,
On Sun, Dec 2, 2018 at 8:36 PM Marek Vasut wrote:
> It is possible that the PCA953x is powered down during suspend.
> Use regmap cache to assure the registers in the PCA953x are in
> line with the driver state after resume.
>
> Signed-off-by: Marek Vasut
> +static int pca953x_suspend(struct device *dev)
> +{
> + struct pca953x_chip *chip = dev_get_drvdata(dev);
> +
> + regcache_mark_dirty(chip->regmap);
> + pca953x_regcache_sync(dev);
> + regcache_cache_only(chip->regmap, true);
Based on the discussion about adding suspend/resume support to the VC5
clock driver, I guess the two sync calls above are not needed here?
> +
> + regulator_disable(chip->regulator);
> +
> + return 0;
> +}
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] clk: vc5: Add suspend/resume support
On 12/05/2018 02:54 PM, Laurent Pinchart wrote:
> Hi Marek,
Hi,
> On Wednesday, 5 December 2018 14:29:22 EET Marek Vasut wrote:
>> On 12/05/2018 06:21 AM, Laurent Pinchart wrote:
>>> On Wednesday, 5 December 2018 01:48:01 EET Marek Vasut wrote:
On 12/04/2018 09:52 PM, Stephen Boyd wrote:
> Quoting Marek Vasut (2018-12-04 10:27:21)
>
>> diff --git a/drivers/clk/clk-versaclock5.c
>> b/drivers/clk/clk-versaclock5.c
>> index decffb3826ec..ac90fb36af1a 100644
>> --- a/drivers/clk/clk-versaclock5.c
>> +++ b/drivers/clk/clk-versaclock5.c
>> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_PM_SLEEP
>> +static int vc5_suspend(struct device *dev)
>
> Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
>
>> +{
>> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + ret = regcache_sync(vc5->regmap);
>> + if (ret != 0) {
>> + dev_err(dev, "Failed to save register map: %d\n", ret);
>> + return ret;
>
> Do we need to block suspend if we can't save the register map away? Or
> can we just throw up our hands and not restore on resume?
Some hardware will fail on resume, so I'd say -- yes ?
>>>
>>> But why do you need to sync on suspend in the first place ? What could
>>> cause the map to be dirty at this stage, and require syncing before
>>> suspend, that couldn't work with the sync be delayed to resume time ?
>>
>> Possibly a configuration coming from eg. bootloader time , or some other
>> configuration not done by Linux.
>
> I still don't get it. As far as I know, regcache_sync() will write the
> content
> of the regmap to the hardware, not the other way around. You call it at
> resume
> time, so the hardware should be programmed properly, regardless of what the
> boot loader or the firmware does when resuming.
>
> Could you please explain why this is needed at suspend time ?
It is not, can be dropped.
--
Best regards,
Marek Vasut
Re: [PATCH v3 0/3] mmc: renesas_sdhi: extend quirk selection to handle ES revisions
On Wed, 28 Nov 2018 at 17:19, Niklas Söderlund wrote: > > 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.[012] > > 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 > Applied for next, thanks! Kind regards Uffe
Re: [PATCH v2] mmc: document 'Reliable Write' bit in uapi header
On Mon, 3 Dec 2018 at 20:56, Wolfram Sang
wrote:
>
> If we use it this way, people should know about it. Also, replace
> true/false with nonzero/zero because the flag is not strictly a bool
> anymore.
>
> Signed-off-by: Wolfram Sang
> Reviewed-by: Geert Uytterhoeven
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> Change since V1:
> * reworded first line of comment as well. Thanks, Geert!
>
> Still not super happy about shifting into the sign bit, but yeah...
> don't break userspace, I guess.
>
> include/uapi/linux/mmc/ioctl.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
> index 45f369dc0a42..00c08120f3ba 100644
> --- a/include/uapi/linux/mmc/ioctl.h
> +++ b/include/uapi/linux/mmc/ioctl.h
> @@ -5,7 +5,10 @@
> #include
>
> struct mmc_ioc_cmd {
> - /* Implies direction of data. true = write, false = read */
> + /*
> +* Direction of data: nonzero = write, zero = read.
> +* Bit 31 selects 'Reliable Write' for RPMB.
> +*/
> int write_flag;
>
> /* Application-specific command. true = precede with CMD55 */
> --
> 2.11.0
>
Re: [PATCH v4 0/3] mmc: tmio: fix reset operation
On Mon, 26 Nov 2018 at 18:03, Niklas Söderlund wrote: > > 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 | 27 +++ > 3 files changed, 20 insertions(+), 12 deletions(-) > > -- > 2.19.1 > Applied for next, thanks! Kind regards Uffe
Re: [PATCH 1/2] mmc: core: use mrq->sbc when sending CMD23 for RPMB
On Mon, 26 Nov 2018 at 14:38, Wolfram Sang
wrote:
>
> When sending out CMD23 in the blk preparation, the comment there
> rightfully says:
>
> * However, it is not sufficient to just send CMD23,
> * and avoid the final CMD12, as on an error condition
> * CMD12 (stop) needs to be sent anyway. This, coupled
> * with Auto-CMD23 enhancements provided by some
> * hosts, means that the complexity of dealing
> * with this is best left to the host. If CMD23 is
> * supported by card and host, we'll fill sbc in and let
> * the host deal with handling it correctly.
>
> Let's do this behaviour for RPMB as well, and not send CMD23
> independently. Otherwise IP cores (like Renesas SDHI) may timeout
> because of automatic CMD23/CMD12 handling.
>
> Reported-by: Masaharu Hayakawa
> Signed-off-by: Wolfram Sang
> Tested-by: Clément Péron
Applied for next and by adding a stable tag, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/core/block.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index c35b5b08bb33..111934838da2 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -472,7 +472,7 @@ static int ioctl_do_sanitize(struct mmc_card *card)
> static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data
> *md,
>struct mmc_blk_ioc_data *idata)
> {
> - struct mmc_command cmd = {};
> + struct mmc_command cmd = {}, sbc = {};
> struct mmc_data data = {};
> struct mmc_request mrq = {};
> struct scatterlist sg;
> @@ -550,10 +550,15 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card,
> struct mmc_blk_data *md,
> }
>
> if (idata->rpmb) {
> - err = mmc_set_blockcount(card, data.blocks,
> - idata->ic.write_flag & (1 << 31));
> - if (err)
> - return err;
> + sbc.opcode = MMC_SET_BLOCK_COUNT;
> + /*
> +* We don't do any blockcount validation because the max size
> +* may be increased by a future standard. We just copy the
> +* 'Reliable Write' bit here.
> +*/
> + sbc.arg = data.blocks | (idata->ic.write_flag & BIT(31));
> + sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
> + mrq.sbc =
> }
>
> if ((MMC_EXTRACT_INDEX_FROM_ARG(cmd.arg) == EXT_CSD_SANITIZE_START) &&
> --
> 2.11.0
>
Re: [PATCH 2/2] mmc: core: remove obsolete mmc_set_blockcount() function
On Mon, 26 Nov 2018 at 14:38, Wolfram Sang
wrote:
>
> The only user was converted to fill a sbc command which is the proper
> way to do it because of AutoCMD23 feature of some hosts.
>
> Signed-off-by: Wolfram Sang
> Tested-by: Clément Péron
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/core/core.c | 14 --
> drivers/mmc/core/core.h | 2 --
> 2 files changed, 16 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 50a5c340307b..d3085f70e9a4 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2413,20 +2413,6 @@ int mmc_set_blocklen(struct mmc_card *card, unsigned
> int blocklen)
> }
> EXPORT_SYMBOL(mmc_set_blocklen);
>
> -int mmc_set_blockcount(struct mmc_card *card, unsigned int blockcount,
> - bool is_rel_write)
> -{
> - struct mmc_command cmd = {};
> -
> - cmd.opcode = MMC_SET_BLOCK_COUNT;
> - cmd.arg = blockcount & 0x;
> - if (is_rel_write)
> - cmd.arg |= 1 << 31;
> - cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
> - return mmc_wait_for_cmd(card->host, , 5);
> -}
> -EXPORT_SYMBOL(mmc_set_blockcount);
> -
> static void mmc_hw_reset_for_init(struct mmc_host *host)
> {
> mmc_pwrseq_reset(host);
> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> index 087ba68b2920..8fb6bc37f808 100644
> --- a/drivers/mmc/core/core.h
> +++ b/drivers/mmc/core/core.h
> @@ -118,8 +118,6 @@ int mmc_erase_group_aligned(struct mmc_card *card,
> unsigned int from,
> unsigned int mmc_calc_max_discard(struct mmc_card *card);
>
> int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen);
> -int mmc_set_blockcount(struct mmc_card *card, unsigned int blockcount,
> - bool is_rel_write);
>
> int __mmc_claim_host(struct mmc_host *host, struct mmc_ctx *ctx,
> atomic_t *abort);
> --
> 2.11.0
>
Re: [PATCH] clk: vc5: Add suspend/resume support
Hi Marek,
On Wednesday, 5 December 2018 14:29:22 EET Marek Vasut wrote:
> On 12/05/2018 06:21 AM, Laurent Pinchart wrote:
> > On Wednesday, 5 December 2018 01:48:01 EET Marek Vasut wrote:
> >> On 12/04/2018 09:52 PM, Stephen Boyd wrote:
> >>> Quoting Marek Vasut (2018-12-04 10:27:21)
> >>>
> diff --git a/drivers/clk/clk-versaclock5.c
> b/drivers/clk/clk-versaclock5.c
> index decffb3826ec..ac90fb36af1a 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int vc5_suspend(struct device *dev)
> >>>
> >>> Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
> >>>
> +{
> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = regcache_sync(vc5->regmap);
> + if (ret != 0) {
> + dev_err(dev, "Failed to save register map: %d\n", ret);
> + return ret;
> >>>
> >>> Do we need to block suspend if we can't save the register map away? Or
> >>> can we just throw up our hands and not restore on resume?
> >>
> >> Some hardware will fail on resume, so I'd say -- yes ?
> >
> > But why do you need to sync on suspend in the first place ? What could
> > cause the map to be dirty at this stage, and require syncing before
> > suspend, that couldn't work with the sync be delayed to resume time ?
>
> Possibly a configuration coming from eg. bootloader time , or some other
> configuration not done by Linux.
I still don't get it. As far as I know, regcache_sync() will write the content
of the regmap to the hardware, not the other way around. You call it at resume
time, so the hardware should be programmed properly, regardless of what the
boot loader or the firmware does when resuming.
Could you please explain why this is needed at suspend time ?
--
Regards,
Laurent Pinchart
RE: [PATCH v2 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Hi Geert,
Thanks for the feedback.
> Subject: Re: [PATCH v2 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
>
> Hi Biju,
>
> On Thu, Nov 29, 2018 at 6:03 PM Biju Das wrote:
> > 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
> > ---
> > V1-->V2 Incorporated Alexandre and Geert's review comment.
>
> Thanks for the update!
>
> > --- a/drivers/rtc/rtc-pcf85363.c
> > +++ b/drivers/rtc/rtc-pcf85363.c
>
> > @@ -321,15 +344,25 @@ static int pcf85363_probe(struct i2c_client *client,
> > const struct i2c_device_id *id) {
> > struct pcf85363 *pcf85363;
> > - struct nvmem_config nvmem_cfg = {
> > - .name = "pcf85363-",
> > - .word_size = 1,
> > - .stride = 1,
> > - .size = NVRAM_SIZE,
> > - .reg_read = pcf85363_nvram_read,
> > - .reg_write = pcf85363_nvram_write,
> > + const struct regmap_config *regmap_config =
> _85363_regmap_config;
> > + struct nvmem_config nvmem_cfg[] = {
>
> static?
>
> Although the nvmem_config is copied, and thus static is not needed, I guess
> using static will decrease kernel size.
>
> > + {
> > + .name = "pcf85x63-",
> > + .word_size = 1,
> > + .stride = 1,
> > + .size = 1,
> > + .reg_read = pcf85x63_nvram_read,
> > + .reg_write = pcf85x63_nvram_write,
> > + }, {
> > + .name = "pcf85363-",
> > + .word_size = 1,
> > + .stride = 1,
> > + .size = NVRAM_SIZE,
> > + .reg_read = pcf85363_nvram_read,
> > + .reg_write = pcf85363_nvram_write,
> > + },
> > };
> > - int ret;
> > + int ret, i, num_nvmem = 2;
> >
> > if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> > return -ENODEV;
> > @@ -339,7 +372,13 @@ static int pcf85363_probe(struct i2c_client *client,
> > if (!pcf85363)
> > return -ENOMEM;
> >
> > - pcf85363->regmap = devm_regmap_init_i2c(client, _config);
> > + if (of_device_get_match_data(>dev) ==
> > + _85263_regmap_config) {
> > + regmap_config = _85263_regmap_config;
> > + num_nvmem = 1;
>
> I think it's cleaner if you store the full config (regmap_config + num_nvmem)
> in of_device_id.data, instead of just the regmap_config, using
>
> struct pcf85x63_config {
> struct regmap_config regmap;
> unsigned int num_nvram;
> };
>
> static const struct pcf85x63_config pcf85263_config = { ... };
> static const struct pcf85x63_config pcf85363_config = { ... };
>
> static const struct of_device_id dev_ids[] = {
> { .compatible = "nxp,pcf85263", .data = _85263_config },
> { .compatible = "nxp,pcf85363", .data = _85363_config },
> { /* sentinel */ }
> };
>
> Then you can just do
>
> struct pcf85x63_config *config = _config; /* default for
> non-DT
> */
> void *data = of_device_get_match_data(>dev);
> if (data)
> config = data;
>
> > + }
Will send V3 with above changes.
Regards,
Biju
[https://www2.renesas.eu/media/email/unicef.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have
decided to support Unicef with a donation. For further details click
here
RE: [PATCH v2 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Hi Geert and Alexandre,
Thanks for the feedback.
> Subject: Re: [PATCH v2 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
>
> Hi Alexandre,
>
> On Fri, Nov 30, 2018 at 1:32 PM Alexandre Belloni
> wrote:
> > On 30/11/2018 12:05:16+0100, Geert Uytterhoeven wrote:
> > > On Thu, Nov 29, 2018 at 6:03 PM Biju Das
> wrote:
> > > > 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
> > > > ---
> > > > V1-->V2 Incorporated Alexandre and Geert's review comment.
> > >
> > > Thanks for the update!
> > >
> > > > --- a/drivers/rtc/rtc-pcf85363.c
> > > > +++ b/drivers/rtc/rtc-pcf85363.c
> > >
> > > > @@ -321,15 +344,25 @@ static int pcf85363_probe(struct i2c_client
> *client,
> > > > const struct i2c_device_id *id) {
> > > > struct pcf85363 *pcf85363;
> > > > - struct nvmem_config nvmem_cfg = {
> > > > - .name = "pcf85363-",
> > > > - .word_size = 1,
> > > > - .stride = 1,
> > > > - .size = NVRAM_SIZE,
> > > > - .reg_read = pcf85363_nvram_read,
> > > > - .reg_write = pcf85363_nvram_write,
> > > > + const struct regmap_config *regmap_config =
> _85363_regmap_config;
> > > > + struct nvmem_config nvmem_cfg[] = {
> > >
> > > static?
> > >
> > > Although the nvmem_config is copied, and thus static is not needed,
> > > I guess using static will decrease kernel size.
> > >
> >
> > Hum, I don't think, this is on the stack anyway.
>
> If you make it static, it's no longer allocated on the stack, and gcc has no
> longer to emit code to initialize all members.
>
I have used "size" command to check the size of vmlinux with and without
static. Please find the results.
Without static
===
$ size vmlinux
text databssdechexfilename
71473602625982 29260810065950 99981evmlinux
With static variable
==
$ size vmlinux
text databssdechexfilename
71472002626110 29260810065918 9997fevmlinux
So overall with static, there is a reduction in kernel size. I will send V3
with declaring it as static.
Regards,
Biju
[https://www2.renesas.eu/media/email/unicef.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have
decided to support Unicef with a donation. For further details click
here
Hello My Beloved One
Assalamu alaikum, I came across your e-mail contact prior a private search while in need of a trusted person. My name is Mrs. Aisha Gaddafi, a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi)I have a business Proposal for you worth $5.8Million dollars and I need mutual respect, trust, honesty, transparency, adequate support and assistance, Hope to hear from you for more details. Warmest regards Mrs Aisha Gaddafi
Re: [PATCH] clk: vc5: Add suspend/resume support
On 12/05/2018 06:21 AM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Wednesday, 5 December 2018 01:48:01 EET Marek Vasut wrote:
>> On 12/04/2018 09:52 PM, Stephen Boyd wrote:
>>> Quoting Marek Vasut (2018-12-04 10:27:21)
>>>
diff --git a/drivers/clk/clk-versaclock5.c
b/drivers/clk/clk-versaclock5.c
index decffb3826ec..ac90fb36af1a 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int vc5_suspend(struct device *dev)
>>>
>>> Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
>>>
+{
+ struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
+ int ret;
+
+ ret = regcache_sync(vc5->regmap);
+ if (ret != 0) {
+ dev_err(dev, "Failed to save register map: %d\n", ret);
+ return ret;
>>>
>>> Do we need to block suspend if we can't save the register map away? Or
>>> can we just throw up our hands and not restore on resume?
>>
>> Some hardware will fail on resume, so I'd say -- yes ?
>
> But why do you need to sync on suspend in the first place ? What could cause
> the map to be dirty at this stage, and require syncing before suspend, that
> couldn't work with the sync be delayed to resume time ?
Possibly a configuration coming from eg. bootloader time , or some other
configuration not done by Linux.
--
Best regards,
Marek Vasut
[PATCH v2 0/5] Add more support to RZ/G1N
This patch series aims to add support for some more interfaces to RZ/G1N SoC/iwg20d based board (Display and QSPI). This patch series tested against renesas-dev. V1--> V2 * Add SPI NOR support : Incorporated Geert's review comment. * Add DU support : Removed LVDS definition from DU node. Biju Das (5): ARM: dts: iwg20d-q7-common: Move cmt/rwdt node out of RZ/G1M SOM ARM: dts: r8a7744-iwg20m: Add SPI NOR support ARM: dts: r8a7744: Add DU support ARM: dts: r8a7743: Remove LVDS encoder from du node ARM: dts: r8a7744: Fix sorting of vsp and msiof nodes arch/arm/boot/dts/iwg20d-q7-common.dtsi | 9 ++ arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 9 -- arch/arm/boot/dts/r8a7743.dtsi | 9 +- arch/arm/boot/dts/r8a7744-iwg20m.dtsi | 26 ++ arch/arm/boot/dts/r8a7744.dtsi | 161 5 files changed, 121 insertions(+), 93 deletions(-) -- 2.7.4
[PATCH v2 4/5] ARM: dts: r8a7743: Remove LVDS encoder from du node
The internal LVDS encoder now has DT bindings separate from the DU.
So remove it from du node.
Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver")
Signed-off-by: Biju Das
---
V1-->V2
* Removed LVDS encoder definition from DU node.
---
arch/arm/boot/dts/r8a7743.dtsi | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 3cc33f7..3ad1efc 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1681,15 +1681,12 @@
du: display@feb0 {
compatible = "renesas,du-r8a7743";
- reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
- reg-names = "du", "lvds.0";
+ reg = <0 0xfeb0 0 0x4>;
interrupts = ,
;
clocks = < CPG_MOD 724>,
-< CPG_MOD 723>,
-< CPG_MOD 726>;
- clock-names = "du.0", "du.1", "lvds.0";
+< CPG_MOD 723>;
+ clock-names = "du.0", "du.1";
status = "disabled";
ports {
--
2.7.4
[PATCH v2 3/5] ARM: dts: r8a7744: Add DU support
Add du node to r8a7744 SoC DT. Boards that want to enable the DU
need to specify the output topology.
Signed-off-by: Biju Das
---
V1-->V2
* Removed LVDS encoder definition from DU node.
---
arch/arm/boot/dts/r8a7744.dtsi | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 04148d6..6a51b16 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -1645,8 +1645,14 @@
};
du: display@feb0 {
- reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
+ compatible = "renesas,du-r8a7744";
+ reg = <0 0xfeb0 0 0x4>;
+ interrupts = ,
+;
+ clocks = < CPG_MOD 724>,
+< CPG_MOD 723>;
+ clock-names = "du.0", "du.1";
+ status = "disabled";
ports {
#address-cells = <1>;
@@ -1663,7 +1669,6 @@
};
};
};
- /* placeholder */
};
prr: chipid@ff44 {
--
2.7.4
[PATCH v2 5/5] ARM: dts: r8a7744: Fix sorting of vsp and msiof nodes
This patch fixes sorting of vsp and msiof nodes.
Signed-off-by: Biju Das
---
V1-->V2
* No change. It is a new patch.
---
arch/arm/boot/dts/r8a7744.dtsi | 150 -
1 file changed, 75 insertions(+), 75 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 6a51b16..83804aa 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -998,6 +998,54 @@
status = "disabled";
};
+ msiof0: spi@e6e2 {
+ compatible = "renesas,msiof-r8a7744",
+"renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e2 0 0x0064>;
+ interrupts = ;
+ clocks = < CPG_MOD 000>;
+ dmas = < 0x51>, < 0x52>,
+ < 0x51>, < 0x52>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A7744_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 000>;
+ status = "disabled";
+ };
+
+ msiof1: spi@e6e1 {
+ compatible = "renesas,msiof-r8a7744",
+"renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e1 0 0x0064>;
+ interrupts = ;
+ clocks = < CPG_MOD 208>;
+ dmas = < 0x55>, < 0x56>,
+ < 0x55>, < 0x56>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A7744_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 208>;
+ status = "disabled";
+ };
+
+ msiof2: spi@e6e0 {
+ compatible = "renesas,msiof-r8a7744",
+"renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e0 0 0x0064>;
+ interrupts = ;
+ clocks = < CPG_MOD 205>;
+ dmas = < 0x41>, < 0x42>,
+ < 0x41>, < 0x42>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A7744_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 205>;
+ status = "disabled";
+ };
+
pwm0: pwm@e6e3 {
compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
reg = <0 0xe6e3 0 0x8>;
@@ -1068,54 +1116,6 @@
status = "disabled";
};
- msiof0: spi@e6e2 {
- compatible = "renesas,msiof-r8a7744",
-"renesas,rcar-gen2-msiof";
- reg = <0 0xe6e2 0 0x0064>;
- interrupts = ;
- clocks = < CPG_MOD 000>;
- dmas = < 0x51>, < 0x52>,
- < 0x51>, < 0x52>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = < R8A7744_PD_ALWAYS_ON>;
- #address-cells = <1>;
- #size-cells = <0>;
- resets = < 000>;
- status = "disabled";
- };
-
- msiof1: spi@e6e1 {
- compatible = "renesas,msiof-r8a7744",
-"renesas,rcar-gen2-msiof";
- reg = <0 0xe6e1 0 0x0064>;
- interrupts = ;
- clocks = < CPG_MOD 208>;
- dmas = < 0x55>, < 0x56>,
- < 0x55>, < 0x56>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = < R8A7744_PD_ALWAYS_ON>;
- #address-cells = <1>;
- #size-cells = <0>;
- resets = < 208>;
- status = "disabled";
- };
-
- msiof2: spi@e6e0 {
- compatible = "renesas,msiof-r8a7744",
-"renesas,rcar-gen2-msiof";
- reg = <0 0xe6e0 0 0x0064>;
- interrupts = ;
- clocks = < CPG_MOD 205>;
- dmas = < 0x41>, < 0x42>,
- < 0x41>, < 0x42>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = < R8A7744_PD_ALWAYS_ON>;
- #address-cells = <1>;
-
[PATCH v2 2/5] ARM: dts: r8a7744-iwg20m: Add SPI NOR support
Add support for the SPI NOR device used to boot up the system
to the iWave RZ/G1N Qseven System On Module DT.
Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
---
V1-->V2
* Removed compatible string "sst,sst25vf016b".
---
arch/arm/boot/dts/r8a7744-iwg20m.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
b/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
index 503583e..82ee3c1 100644
--- a/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
@@ -36,6 +36,11 @@
function = "mmc";
};
+ qspi_pins: qspi {
+ groups = "qspi_ctrl", "qspi_data2";
+ function = "qspi";
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -53,6 +58,27 @@
status = "okay";
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WARNING - This device contains the bootloader. Handle with care. */
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ m25p,fast-read;
+ spi-cpol;
+ spi-cpha;
+ };
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
--
2.7.4
