Re: [PATCH v2 00/30] v4l: add support for multiplexed streams
Hi Sakari, Thanks for your feedback. On 2018-12-04 00:16:29 +0200, Sakari Ailus wrote: > Hi Niklas, > > On Fri, Nov 02, 2018 at 12:31:14AM +0100, Niklas Söderlund wrote: > > Hi all, > > > > This series adds support for multiplexed streams within a media device > > link. The use-case addressed in this series covers CSI-2 Virtual > > Channels on the Renesas R-Car Gen3 platforms. The v4l2 changes have been > > a joint effort between Sakari and Laurent and floating around for some > > time [1]. > > > > I have added driver support for the devices used on the Renesas Gen3 > > platforms, a ADV7482 connected to the R-Car CSI-2 receiver. With these > > changes I can control which of the analog inputs of the ADV7482 the > > video source is captured from and on which CSI-2 virtual channel the > > video is transmitted on to the R-Car CSI-2 receiver. > > > > The series adds two new subdev IOCTLs [GS]_ROUTING which allows > > user-space to get and set routes inside a subdevice. I have added RFC > > support for these to v4l-utils [2] which can be used to test this > > series, example: > > > > Check the internal routing of the adv748x csi-2 transmitter: > > v4l2-ctl -d /dev/v4l-subdev24 --get-routing > > 0/0 -> 1/0 [ENABLED] > > 0/0 -> 1/1 [] > > 0/0 -> 1/2 [] > > 0/0 -> 1/3 [] > > > > > > Select that video should be outputed on VC 2 and check the result: > > $ v4l2-ctl -d /dev/v4l-subdev24 --set-routing '0/0 -> 1/2 [1]' > > > > $ v4l2-ctl -d /dev/v4l-subdev24 --get-routing > > 0/0 -> 1/0 [] > > 0/0 -> 1/1 [] > > 0/0 -> 1/2 [ENABLED] > > 0/0 -> 1/3 [] > > > > This series is tested on R-Car M3-N and for your testing needs this > > series is available at > > > > git://git.ragnatech.se/linux v4l2/mux > > > > * Changes since v1 > > - Rebased on latest media-tree. > > - Incorporated changes to patch 'v4l: subdev: compat: Implement handling > > for VIDIOC_SUBDEV_[GS]_ROUTING' by Sakari. > > - Added review tags. > > I was looking at the patches and they seem very nice to me. It's not that > I've written most of them, but I still. X-) :-) > > I noticed that the new [GS]_ROUTING interface has no documentation > currently. Could you write it? Will add it for the next version. Thanks for pointing this out. > > Also what I'd like to see is the media graph of a device that is driven by > these drivers. That'd help to better understand the use case also for those > who haven't worked with the patches. I will attach the media graph for this simple use-case with the adv7482 and a more complex case using 8 cameras and GMSL in the next version. -- Regards, Niklas Söderlund
[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 v2 2/2] dt-binding: spi: Document Renesas R-Car Gen3 RPC controller bindings
On 12/05/2018 07:56 PM, Sergei Shtylyov wrote: > On 12/04/2018 09:19 PM, Marek Vasut wrote: > >>> Document the bindings used by the Renesas R-Car Gen3 RPC SPI controller. >> >> RPC is SPI and HF controller, it is not a pure SPI controller. >> >> How does this deal with the HF part ? Keep in mind the bindings are ABI >> and it will be difficult to redo them later. > >Perhaps we need a "mode" prop, maybe w/vendor prefix? Or, like I said last time, discern it based on the DT subnode. It can be either SPI NOR or CFI NOR. >>> Signed-off-by: Mason Yang > [...] > > MBR, Sergei > -- Best regards, Marek Vasut
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 = <&gic>;
+ #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>;
+ };
+ };
+
+ 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 = <&extal_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 CPG_CORE R7S9210_CLK_P0>;
+ };
+
+ pinctrl: pin-controller@fcffe000 {
+ compatible = "renesas,r7s9210-pinctrl";
+ reg = <0xfcffe000 0x1000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 0 176>;
+ };
+
+ scif0: serial@e8007000 {
+ compatible = "renesas,scif-r7s9210";
+ reg = <0xe8007000 0x18>;
+ interrupts = ,
+,
+,
+,
+,
+;
+ interrupt-names = "eri", "rxi", "txi", "bri", "dri", "tei";
+ clocks = <&cpg CPG_MOD 47>;
+ clock-names = "fck";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ scif1: serial@e8007800 {
+ compatible = "renesas,scif-r7s9210";
+ reg = <0xe8007800 0x18>;
+ interrupts = ,
+,
+,
+,
+,
+;
+ interrupt-names = "eri", "rxi", "txi", "bri", "dri", "tei";
+ clocks = <&cpg CPG_MOD 46>;
+ clock-names = "fck";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ scif2: serial@e8008000 {
+ compatible = "renesas,scif-r7s9210";
+ reg = <0xe8008000 0x18>;
+ interrupts = ,
+,
+,
+,
+,
+;
+ interrupt-names = "eri", "rxi", "txi", "bri", "dri", "tei";
+ clocks = <&cpg CPG_MOD 45>;
+
[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 = &scif4;
+ };
+
+ 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 = <&pinctrl RZA2_PIN(PORT6, 0) GPIO_ACTIVE_HIGH>;
+ };
+ green {
+ gpios = <&pinctrl 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 */
+&extal_clk {
+ clock-frequency = <2400>; /* 24MHz */
+};
+
+/* RTC_X1 */
+&rtc_x1_clk {
+ clock-frequency = <32768>;
+};
+
+&pinctrl {
+ /* Serial Console */
+ scif4_pins: serial4 {
+ pinmux = ,/* TxD4 */
+;/* RxD4 */
+ };
+};
+
+/* High resolution System tick timers */
+&ostm0 {
+ status = "okay";
+};
+
+&ostm1 {
+ status = "okay";
+};
+
+/* Serial Console */
+&scif4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&scif4_pins>;
+
+ status = "okay";
+};
--
2.16.1
Re: [PATCH] arm64: dts: renesas: enable HS400 on R-Car Gen3
Hi Wolfram, On 2018-12-05 21:46:28 +0100, Wolfram Sang wrote: > On Fri, Nov 02, 2018 at 12:57:19PM +0100, Simon Horman wrote: > > On Thu, Nov 01, 2018 at 08:45:29PM +0100, Wolfram Sang wrote: > > > > > > > This patch have quiet a few dependencies I'm afraid, let me know if you > > > > wish to be notified once they all upstream. I don't think it's a good > > > > idea to pick this up before all dependencies are resolved. > > > > > > Yes, we should do that. Ping Simon once all dependencies are in next. It > > > is still fine to have this patch here in case people want to test. BTW > > > did you mention your branch somewhere where you collected all these > > > patches to make HS400 working/enabled? > > > > > > For this patch already: > > > > > > Reviewed-by: Wolfram Sang > > > Tested-by: Wolfram Sang > > > > Thanks, I am marking this as deferred. > > > > Please repost or ping me once the dependencies are present in > > an rc release. > > Niklas, are we done now, so we can ask Simon to pick up the DTS change? > Almost :-) I'm waiting for Geert to take the SD quirk patches before pinging Simon to take this one. Spoke to him today about that so I hope it will not be to long. -- Regards, Niklas Söderlund
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 0/4] soc: renesas: rcar-sysc: Miscellaneous fixes and cleanups
On Wed, Dec 05, 2018 at 04:39:41PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This series (against renesas-devel-20181204-v4.20-rc5) contains > miscellaneous fixes and cleanups for the R-Car SYSC driver. > > This has been tested on R-Car Gen2 (H2 and M2-W) and R-Car Gen3 (H3 > ES1.0, H3 ES2.0, M3-W, M3-N, D3, E3, and V3M) (without 3DG). > > This not been tested on R-Car H1 and R-Car V3H. Thanks, applied for v4.21.
Re: [PATCH 4/4] soc: renesas: rcar-sysc: Fix power domain control after system resume
On Wed, Dec 05, 2018 at 04:39:45PM +0100, Geert Uytterhoeven wrote:
> To control power to a power domain, the System Controller (SYSC) needs
> the corresponding interrupt source to be enabled, but masked, to prevent
> the CPU from receiving it.
>
> Currently this is handled in the driver's probe() routine, and set up
> for every domain present, even if it will not be controlled directly by
> SYSC (CPU domains are powered through the APMU on R-Car Gen2 and later).
>
> On R-Car Gen3, PSCI powers down the SoC during system suspend, thus
> loosing any configured interrupt state. Hence after system resume, power
> domains not controlled through the APMU (e.g. A3IR, A3VC, A3VP) fail to
> power up.
I corrected the spelling of losing when applying this patch.
>
> Fix this by replacing the global interrupt setup in the probe() routine
> by a domain-specific interrupt setup in rcar_sysc_power(), where the
> domain's power is actually controlled. This brings the code more in
> line with the flowchart in the Hardware User's Manual.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/soc/renesas/rcar-sysc.c | 28 +---
> 1 file changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
> index 123e553510e826f5..0c80fab4f8de6bc8 100644
> --- a/drivers/soc/renesas/rcar-sysc.c
> +++ b/drivers/soc/renesas/rcar-sysc.c
> @@ -105,6 +105,15 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
> *sysc_ch, bool on)
>
> spin_lock_irqsave(&rcar_sysc_lock, flags);
>
> + /*
> + * The interrupt source needs to be enabled, but masked, to prevent the
> + * CPU from receiving it.
> + */
> + iowrite32(ioread32(rcar_sysc_base + SYSCIMR) | isr_mask,
> + rcar_sysc_base + SYSCIMR);
> + iowrite32(ioread32(rcar_sysc_base + SYSCIER) | isr_mask,
> + rcar_sysc_base + SYSCIER);
> +
> iowrite32(isr_mask, rcar_sysc_base + SYSCISCR);
>
> /* Submit power shutoff or resume request until it was accepted */
> @@ -324,7 +333,6 @@ static int __init rcar_sysc_pd_init(void)
> const struct of_device_id *match;
> struct rcar_pm_domains *domains;
> struct device_node *np;
> - u32 syscier, syscimr;
> void __iomem *base;
> unsigned int i;
> int error;
> @@ -363,24 +371,6 @@ static int __init rcar_sysc_pd_init(void)
> domains->onecell_data.num_domains = ARRAY_SIZE(domains->domains);
> rcar_sysc_onecell_data = &domains->onecell_data;
>
> - for (i = 0, syscier = 0; i < info->num_areas; i++)
> - syscier |= BIT(info->areas[i].isr_bit);
> -
> - /*
> - * Mask all interrupt sources to prevent the CPU from receiving them.
> - * Make sure not to clear reserved bits that were set before.
> - */
> - syscimr = ioread32(base + SYSCIMR);
> - syscimr |= syscier;
> - pr_debug("%pOF: syscimr = 0x%08x\n", np, syscimr);
> - iowrite32(syscimr, base + SYSCIMR);
> -
> - /*
> - * SYSC needs all interrupt sources enabled to control power.
> - */
> - pr_debug("%pOF: syscier = 0x%08x\n", np, syscier);
> - iowrite32(syscier, base + SYSCIER);
> -
> for (i = 0; i < info->num_areas; i++) {
> const struct rcar_sysc_area *area = &info->areas[i];
> struct rcar_sysc_pd *pd;
> --
> 2.17.1
>
Re: [PATCH] clk: Use of_node_name_eq for node name comparisons
On Wed, Dec 5, 2018 at 8:50 PM Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> For instances using of_node_cmp, this has the side effect of now using
> case sensitive comparisons. This should not matter for any FDT based
> system which all of these are.
>
> Cc: Geert Uytterhoeven
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Tero Kristo
> Cc: Ulf Hansson
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Rob Herring
Reviewed-by: Geert Uytterhoeven
> ---
> drivers/clk/renesas/clk-mstp.c | 2 +-
> drivers/clk/ti/clkctrl.c | 2 +-
> drivers/clk/ti/dpll.c| 2 +-
> drivers/clk/ux500/u8500_of_clk.c | 10 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
For drivers/clk/renesas/clk-mstp.c :
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: renesas: enable HS400 on R-Car Gen3
On Fri, Nov 02, 2018 at 12:57:19PM +0100, Simon Horman wrote: > On Thu, Nov 01, 2018 at 08:45:29PM +0100, Wolfram Sang wrote: > > > > > This patch have quiet a few dependencies I'm afraid, let me know if you > > > wish to be notified once they all upstream. I don't think it's a good > > > idea to pick this up before all dependencies are resolved. > > > > Yes, we should do that. Ping Simon once all dependencies are in next. It > > is still fine to have this patch here in case people want to test. BTW > > did you mention your branch somewhere where you collected all these > > patches to make HS400 working/enabled? > > > > For this patch already: > > > > Reviewed-by: Wolfram Sang > > Tested-by: Wolfram Sang > > Thanks, I am marking this as deferred. > > Please repost or ping me once the dependencies are present in > an rc release. Niklas, are we done now, so we can ask Simon to pick up the DTS change? signature.asc Description: PGP signature
Re: [PATCH] clk: Use of_node_name_eq for node name comparisons
Quoting Rob Herring (2018-12-05 11:50:21) > Convert string compares of DT node names to use of_node_name_eq helper > instead. This removes direct access to the node name pointer. > > For instances using of_node_cmp, this has the side effect of now using > case sensitive comparisons. This should not matter for any FDT based > system which all of these are. > > Cc: Geert Uytterhoeven > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Tero Kristo > Cc: Ulf Hansson > Cc: linux-renesas-soc@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Rob Herring > --- Looks ok at a glance. I'll wait for some people to ack or test it.
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 CPG_MOD 724>,
> + <&cpg 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.
[PATCH] clk: Use of_node_name_eq for node name comparisons
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.
For instances using of_node_cmp, this has the side effect of now using
case sensitive comparisons. This should not matter for any FDT based
system which all of these are.
Cc: Geert Uytterhoeven
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Tero Kristo
Cc: Ulf Hansson
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Rob Herring
---
drivers/clk/renesas/clk-mstp.c | 2 +-
drivers/clk/ti/clkctrl.c | 2 +-
drivers/clk/ti/dpll.c| 2 +-
drivers/clk/ux500/u8500_of_clk.c | 10 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/renesas/clk-mstp.c b/drivers/clk/renesas/clk-mstp.c
index 1c1768c2cc82..765175d1148a 100644
--- a/drivers/clk/renesas/clk-mstp.c
+++ b/drivers/clk/renesas/clk-mstp.c
@@ -280,7 +280,7 @@ int cpg_mstp_attach_dev(struct generic_pm_domain *unused,
struct device *dev)
goto found;
/* BSC on r8a73a4/sh73a0 uses zb_clk instead of an mstp clock */
- if (!strcmp(clkspec.np->name, "zb_clk"))
+ if (of_node_name_eq(clkspec.np, "zb_clk"))
goto found;
of_node_put(clkspec.np);
diff --git a/drivers/clk/ti/clkctrl.c b/drivers/clk/ti/clkctrl.c
index 469f560ae1cf..40630eb950fc 100644
--- a/drivers/clk/ti/clkctrl.c
+++ b/drivers/clk/ti/clkctrl.c
@@ -448,7 +448,7 @@ static void __init _ti_omap4_clkctrl_setup(struct
device_node *node)
char *c;
if (!(ti_clk_get_features()->flags & TI_CLK_CLKCTRL_COMPAT) &&
- !strcmp(node->name, "clk"))
+ of_node_name_eq(node, "clk"))
ti_clk_features.flags |= TI_CLK_CLKCTRL_COMPAT;
addrp = of_get_address(node, 0, NULL, NULL);
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 92e28af7afba..6c3329bc116f 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -410,7 +410,7 @@ static void __init of_ti_omap3_dpll_setup(struct
device_node *node)
if ((of_machine_is_compatible("ti,omap3630") ||
of_machine_is_compatible("ti,omap36xx")) &&
- !strcmp(node->name, "dpll5_ck"))
+of_node_name_eq(node, "dpll5_ck"))
of_ti_dpll_setup(node, &omap3_dpll5_ck_ops, &dd);
else
of_ti_dpll_setup(node, &omap3_dpll_ck_ops, &dd);
diff --git a/drivers/clk/ux500/u8500_of_clk.c b/drivers/clk/ux500/u8500_of_clk.c
index d5888591e1a9..18a3c4522831 100644
--- a/drivers/clk/ux500/u8500_of_clk.c
+++ b/drivers/clk/ux500/u8500_of_clk.c
@@ -545,21 +545,21 @@ static void u8500_clk_init(struct device_node *np)
for_each_child_of_node(np, child) {
static struct clk_onecell_data clk_data;
- if (!of_node_cmp(child->name, "prcmu-clock")) {
+ if (of_node_name_eq(child, "prcmu-clock")) {
clk_data.clks = prcmu_clk;
clk_data.clk_num = ARRAY_SIZE(prcmu_clk);
of_clk_add_provider(child, of_clk_src_onecell_get,
&clk_data);
}
- if (!of_node_cmp(child->name, "prcc-periph-clock"))
+ if (of_node_name_eq(child, "prcc-periph-clock"))
of_clk_add_provider(child, ux500_twocell_get,
prcc_pclk);
- if (!of_node_cmp(child->name, "prcc-kernel-clock"))
+ if (of_node_name_eq(child, "prcc-kernel-clock"))
of_clk_add_provider(child, ux500_twocell_get,
prcc_kclk);
- if (!of_node_cmp(child->name, "rtc32k-clock"))
+ if (of_node_name_eq(child, "rtc32k-clock"))
of_clk_add_provider(child, of_clk_src_simple_get,
rtc_clk);
- if (!of_node_cmp(child->name, "smp-twd-clock"))
+ if (of_node_name_eq(child, "smp-twd-clock"))
of_clk_add_provider(child, of_clk_src_simple_get,
twd_clk);
}
}
--
2.19.1
Re: [PATCH 4/5] arm64: dts: renesas: r8a77995: draak: Add backlight
Hi Laurent,
On Tue, Dec 04, 2018 at 06:57:10PM +0200, Laurent Pinchart wrote:
> Hi Simon,
>
> Could you please consider taking this patch in your tree ? It's independent
> from the rest of the series.
sure, applied for v4.21.
>
> On Sunday, 25 November 2018 16:40:30 EET Laurent Pinchart wrote:
> > Add the backlight device for the LVDS1 output, in preparation for panel
> > support.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > .../arm64/boot/dts/renesas/r8a77995-draak.dts | 20 +++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index
> > 2405eaad0296..cd067319e6f3 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -24,6 +24,17 @@
> > stdout-path = "serial0:115200n8";
> > };
> >
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm1 0 5>;
> > +
> > + brightness-levels = <256 128 64 16 8 4 0>;
> > + default-brightness-level = <6>;
> > +
> > + power-supply = <®_12p0v>;
> > + enable-gpios = <&gpio4 0 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> > composite-in {
> > compatible = "composite-video-connector";
> >
> > @@ -104,6 +115,15 @@
> > regulator-always-on;
> > };
> >
> > + reg_12p0v: regulator1 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "D12.0V";
> > + regulator-min-microvolt = <1200>;
> > + regulator-max-microvolt = <1200>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > vga {
> > compatible = "vga-connector";
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema
On Tue, Dec 04, 2018 at 09:08:57AM -0600, Rob Herring wrote: > On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven > wrote: > > > > Hi Simon, > > > > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman wrote: > > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote: > > > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > > > > > > Cc: Simon Horman > > > > Cc: Magnus Damm > > > > Cc: Mark Rutland > > > > Cc: linux-renesas-soc@vger.kernel.org > > > > Cc: devicet...@vger.kernel.org > > > > Signed-off-by: Rob Herring > > > > --- > > > > .../devicetree/bindings/arm/shmobile.txt | 151 > > > > .../devicetree/bindings/arm/shmobile.yaml | 218 ++ > > > > 2 files changed, 218 insertions(+), 151 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > > > > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml > > > > > > Hi Rob, > > > > > > what is this based on? I get a conflict when applying the .txt change > > > and if I knew the base for this patch it would be rather easy to work > > > out what has changed. > > 4.20-rc2 > > > > > > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS? > > Yes. Though it was pointed out that get_maintainers.pl can pull emails > out of this file. We'd need to get that to work by default though. > > > Probably even s/shmobile.yaml/renesas.yaml/, while at it? > > Sure, if that's what you all want. How about this? From: Rob Herring Subject: [PATCH v2.1] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema Convert Renesas SoC bindings to DT schema format using json-schema. v2.1 [Simon Horman] - rebased on renesas-devel-20181204-v4.20-rc5 + Added r8a7744 development platform and SoM + Correct RZ/G2E part number - Update MAINTAINERS Signed-off-by: Rob Herring Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/arm/renesas.yaml | 228 + Documentation/devicetree/bindings/arm/shmobile.txt | 155 -- MAINTAINERS| 4 +- 3 files changed, 230 insertions(+), 157 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/renesas.yaml delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml new file mode 100644 index ..5e9d4864a600 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -0,0 +1,228 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/shmobile.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings + +maintainers: + - Geert Uytterhoeven + +properties: + $nodename: +const: '/' + compatible: +oneOf: + - description: Emma Mobile EV2 +items: + - enum: + - renesas,kzm9d # Kyoto Microcomputer Co. KZM-A9-Dual + - const: renesas,emev2 + + - description: RZ/A1H (R7S72100) +items: + - enum: + - renesas,genmai # Genmai (RTK772100BC0BR) + - renesas,gr-peach # GR-Peach (X28A-M01-E/F) + - renesas,rskrza1 # RSKRZA1 (YR0K77210C000BE) + - const: renesas,r7s72100 + + - description: RZ/A2 (R7S9210) +items: + - const: renesas,r7s9210 + + - description: SH-Mobile AG5 (R8A73A00/SH73A0) +items: + - enum: + - renesas,kzm9g # Kyoto Microcomputer Co. KZM-A9-GT + - const: renesas,sh73a0 + + - description: R-Mobile APE6 (R8A73A40) +items: + - enum: + - renesas,ape6evm + - const: renesas,r8a73a4 + + - description: R-Mobile A1 (R8A77400) +items: + - enum: + - renesas,armadillo800eva # Atmark Techno Armadillo-800 EVA + - const: renesas,r8a7740 + + - description: RZ/G1H (R8A77420) +items: + - const: renesas,r8a7742 + + - description: RZ/G1M (R8A77430) +items: + - enum: + # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) + - iwave,g20d + - const: iwave,g20m + - const: renesas,r8a7743 + + - items: + - enum: + # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) + - iwave,g20m + - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE) + - const: renesas,r8a7743 + + - description: RZ/G1N (R8A77440) +items: + - enum: + # iWave Systems RZ/G1N Qseven Development Platform (iW-RainboW-G20D-Qseven) + - iwave,g20d + - const: iwave,g20m + - const: renesas,r8a7744 + + - items: + - enum: + # iWave Systems RZ/G1N Qse
Re: [PATCH 17/22] ARM: dts: iwg20d-q7-common: Move cmt/rwdt node out of RZ/G1M SOM
On Tue, Dec 04, 2018 at 03:55:28PM +0100, Geert Uytterhoeven wrote: > On Tue, Nov 27, 2018 at 1:05 PM 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: Geert Uytterhoeven Thanks, applied for v4.21.
Re: [PATCH v2 2/2] dt-binding: spi: Document Renesas R-Car Gen3 RPC controller bindings
On 12/04/2018 09:19 PM, Marek Vasut wrote: >> Document the bindings used by the Renesas R-Car Gen3 RPC SPI controller. > > RPC is SPI and HF controller, it is not a pure SPI controller. > > How does this deal with the HF part ? Keep in mind the bindings are ABI > and it will be difficult to redo them later. Perhaps we need a "mode" prop, maybe w/vendor prefix? >> Signed-off-by: Mason Yang [...] MBR, Sergei
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(&rcar_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(&rcar_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
[PATCH 2/4] soc: renesas: rcar-sysc: Remove rcar_sysc_power_{down,up}() helpers
Until commit 7e8a50df26f4e700 ("soc: renesas: rcar-sysc: Drop legacy
handling"), the rcar_sysc_power_{down,up}() helpers were public, as they
were called by the legacy (pre-DT) CPU power management code on R-Car H1
and R-Car Gen2 before.
As they are just one-line wrappers around rcar_sysc_power(), it makes
sense to just remove them.
This also avoids a bool/helper/bool conversion in rcar_sysc_power_cpu(),
where a bool is checked to call one of two helper functions, which
just call rcar_sysc_power() with hardcoded boolean values again.
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/rcar-sysc.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index af53363eda0374ce..73fae6a9728df9ae 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -146,16 +146,6 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
*sysc_ch, bool on)
return ret;
}
-static int rcar_sysc_power_down(const struct rcar_sysc_ch *sysc_ch)
-{
- return rcar_sysc_power(sysc_ch, false);
-}
-
-static int rcar_sysc_power_up(const struct rcar_sysc_ch *sysc_ch)
-{
- return rcar_sysc_power(sysc_ch, true);
-}
-
static bool rcar_sysc_power_is_off(const struct rcar_sysc_ch *sysc_ch)
{
unsigned int st;
@@ -184,7 +174,7 @@ static int rcar_sysc_pd_power_off(struct generic_pm_domain
*genpd)
struct rcar_sysc_pd *pd = to_rcar_pd(genpd);
pr_debug("%s: %s\n", __func__, genpd->name);
- return rcar_sysc_power_down(&pd->ch);
+ return rcar_sysc_power(&pd->ch, false);
}
static int rcar_sysc_pd_power_on(struct generic_pm_domain *genpd)
@@ -192,7 +182,7 @@ static int rcar_sysc_pd_power_on(struct generic_pm_domain
*genpd)
struct rcar_sysc_pd *pd = to_rcar_pd(genpd);
pr_debug("%s: %s\n", __func__, genpd->name);
- return rcar_sysc_power_up(&pd->ch);
+ return rcar_sysc_power(&pd->ch, true);
}
static bool has_cpg_mstp;
@@ -252,7 +242,7 @@ static int __init rcar_sysc_pd_setup(struct rcar_sysc_pd
*pd)
goto finalize;
}
- rcar_sysc_power_up(&pd->ch);
+ rcar_sysc_power(&pd->ch, true);
finalize:
error = pm_genpd_init(genpd, gov, false);
@@ -478,8 +468,7 @@ static int rcar_sysc_power_cpu(unsigned int idx, bool on)
if (!(pd->flags & PD_CPU) || pd->ch.chan_bit != idx)
continue;
- return on ? rcar_sysc_power_up(&pd->ch)
- : rcar_sysc_power_down(&pd->ch);
+ return rcar_sysc_power(&pd->ch, on);
}
return -ENOENT;
--
2.17.1
[PATCH 3/4] soc: renesas: rcar-sysc: Merge PM Domain registration and linking
Commit 977d5ba4507dfe5b ("soc: renesas: rcar-sysc: Make PM domain
initialization more robust") split PM Domain registration and the
linking of children to their parents, to accommodate PM Domain tables
that list child domains before their parents.
However, this failed to realize that parent power domains must be
powered up before their children anyway, and that this thus must be
reflected by the order in the PM Domain tables.
Revert the split, as it did not help anyway.
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/rcar-sysc.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 73fae6a9728df9ae..123e553510e826f5 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -381,9 +381,6 @@ static int __init rcar_sysc_pd_init(void)
pr_debug("%pOF: syscier = 0x%08x\n", np, syscier);
iowrite32(syscier, base + SYSCIER);
- /*
-* First, create all PM domains
-*/
for (i = 0; i < info->num_areas; i++) {
const struct rcar_sysc_area *area = &info->areas[i];
struct rcar_sysc_pd *pd;
@@ -411,22 +408,17 @@ static int __init rcar_sysc_pd_init(void)
goto out_put;
domains->domains[area->isr_bit] = &pd->genpd;
- }
- /*
-* Second, link all PM domains to their parents
-*/
- for (i = 0; i < info->num_areas; i++) {
- const struct rcar_sysc_area *area = &info->areas[i];
-
- if (!area->name || area->parent < 0)
+ if (area->parent < 0)
continue;
error = pm_genpd_add_subdomain(domains->domains[area->parent],
- domains->domains[area->isr_bit]);
- if (error)
+ &pd->genpd);
+ if (error) {
pr_warn("Failed to add PM subdomain %s to parent %u\n",
area->name, area->parent);
+ goto out_put;
+ }
}
error = of_genpd_add_provider_onecell(np, &domains->onecell_data);
--
2.17.1
[PATCH 0/4] soc: renesas: rcar-sysc: Miscellaneous fixes and cleanups
Hi Simon, Magnus,
This series (against renesas-devel-20181204-v4.20-rc5) contains
miscellaneous fixes and cleanups for the R-Car SYSC driver.
This has been tested on R-Car Gen2 (H2 and M2-W) and R-Car Gen3 (H3
ES1.0, H3 ES2.0, M3-W, M3-N, D3, E3, and V3M) (without 3DG).
This not been tested on R-Car H1 and R-Car V3H.
Thanks!
Geert Uytterhoeven (4):
soc: renesas: r8a77990-sysc: Fix initialization order of 3DG-{A,B}
soc: renesas: rcar-sysc: Remove rcar_sysc_power_{down,up}() helpers
soc: renesas: rcar-sysc: Merge PM Domain registration and linking
soc: renesas: rcar-sysc: Fix power domain control after system resume
drivers/soc/renesas/r8a77990-sysc.c | 23 ++
drivers/soc/renesas/rcar-sysc.c | 65 -
2 files changed, 22 insertions(+), 66 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
[PATCH 1/4] soc: renesas: r8a77990-sysc: Fix initialization order of 3DG-{A,B}
The workaround for the wrong hierarchy of the 3DG-{A,B} power
domains on R-Car E3 ES1.0 corrected the parent domains.
However, the 3DG-{A,B} power domains were still initialized and powered
in the wrong order, causing 3DG operation to fail.
Fix this by changing the order in the table at runtime, when running on
an affected SoC.
Fixes: 086b399965a7ee7e ("soc: renesas: r8a77990-sysc: Add workaround for
3DG-{A,B}")
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77990-sysc.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/soc/renesas/r8a77990-sysc.c
b/drivers/soc/renesas/r8a77990-sysc.c
index 15579ebc5ed2059d..664b244eb1dd9d95 100644
--- a/drivers/soc/renesas/r8a77990-sysc.c
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -28,19 +28,6 @@ static struct rcar_sysc_area r8a77990_areas[] __initdata = {
{ "3dg-b", 0x100, 1, R8A77990_PD_3DG_B,R8A77990_PD_3DG_A },
};
-static void __init rcar_sysc_fix_parent(struct rcar_sysc_area *areas,
- unsigned int num_areas, u8 id,
- int new_parent)
-{
- unsigned int i;
-
- for (i = 0; i < num_areas; i++)
- if (areas[i].isr_bit == id) {
- areas[i].parent = new_parent;
- return;
- }
-}
-
/* Fixups for R-Car E3 ES1.0 revision */
static const struct soc_device_attribute r8a77990[] __initconst = {
{ .soc_id = "r8a77990", .revision = "ES1.0" },
@@ -50,12 +37,10 @@ static const struct soc_device_attribute r8a77990[]
__initconst = {
static int __init r8a77990_sysc_init(void)
{
if (soc_device_match(r8a77990)) {
- rcar_sysc_fix_parent(r8a77990_areas,
-ARRAY_SIZE(r8a77990_areas),
-R8A77990_PD_3DG_A, R8A77990_PD_3DG_B);
- rcar_sysc_fix_parent(r8a77990_areas,
-ARRAY_SIZE(r8a77990_areas),
-R8A77990_PD_3DG_B, R8A77990_PD_ALWAYS_ON);
+ /* Fix incorrect 3DG hierarchy */
+ swap(r8a77990_areas[7], r8a77990_areas[8]);
+ r8a77990_areas[7].parent = R8A77990_PD_ALWAYS_ON;
+ r8a77990_areas[8].parent = R8A77990_PD_3DG_B;
}
return 0;
--
2.17.1
[PATCH 4/4] soc: renesas: rcar-sysc: Fix power domain control after system resume
To control power to a power domain, the System Controller (SYSC) needs
the corresponding interrupt source to be enabled, but masked, to prevent
the CPU from receiving it.
Currently this is handled in the driver's probe() routine, and set up
for every domain present, even if it will not be controlled directly by
SYSC (CPU domains are powered through the APMU on R-Car Gen2 and later).
On R-Car Gen3, PSCI powers down the SoC during system suspend, thus
loosing any configured interrupt state. Hence after system resume, power
domains not controlled through the APMU (e.g. A3IR, A3VC, A3VP) fail to
power up.
Fix this by replacing the global interrupt setup in the probe() routine
by a domain-specific interrupt setup in rcar_sysc_power(), where the
domain's power is actually controlled. This brings the code more in
line with the flowchart in the Hardware User's Manual.
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/rcar-sysc.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 123e553510e826f5..0c80fab4f8de6bc8 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -105,6 +105,15 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
*sysc_ch, bool on)
spin_lock_irqsave(&rcar_sysc_lock, flags);
+ /*
+* The interrupt source needs to be enabled, but masked, to prevent the
+* CPU from receiving it.
+*/
+ iowrite32(ioread32(rcar_sysc_base + SYSCIMR) | isr_mask,
+ rcar_sysc_base + SYSCIMR);
+ iowrite32(ioread32(rcar_sysc_base + SYSCIER) | isr_mask,
+ rcar_sysc_base + SYSCIER);
+
iowrite32(isr_mask, rcar_sysc_base + SYSCISCR);
/* Submit power shutoff or resume request until it was accepted */
@@ -324,7 +333,6 @@ static int __init rcar_sysc_pd_init(void)
const struct of_device_id *match;
struct rcar_pm_domains *domains;
struct device_node *np;
- u32 syscier, syscimr;
void __iomem *base;
unsigned int i;
int error;
@@ -363,24 +371,6 @@ static int __init rcar_sysc_pd_init(void)
domains->onecell_data.num_domains = ARRAY_SIZE(domains->domains);
rcar_sysc_onecell_data = &domains->onecell_data;
- for (i = 0, syscier = 0; i < info->num_areas; i++)
- syscier |= BIT(info->areas[i].isr_bit);
-
- /*
-* Mask all interrupt sources to prevent the CPU from receiving them.
-* Make sure not to clear reserved bits that were set before.
-*/
- syscimr = ioread32(base + SYSCIMR);
- syscimr |= syscier;
- pr_debug("%pOF: syscimr = 0x%08x\n", np, syscimr);
- iowrite32(syscimr, base + SYSCIMR);
-
- /*
-* SYSC needs all interrupt sources enabled to control power.
-*/
- pr_debug("%pOF: syscier = 0x%08x\n", np, syscier);
- iowrite32(syscier, base + SYSCIER);
-
for (i = 0; i < info->num_areas; i++) {
const struct rcar_sysc_area *area = &info->areas[i];
struct rcar_sysc_pd *pd;
--
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] mmc: tmio: introduce mask for 'always 1' bits
On Mon, 19 Nov 2018 at 14:14, Wolfram Sang
wrote:
>
> Some variants (namely Renesas SDHI) have bits in the STATS and IRQ_MASK
> registers which are 'always 1' and should be written as such. Introduce
> a seperate mask for this and apply it whenever such a register is
> written.
>
> Signed-off-by: Wolfram Sang
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> This is my response to BSP patches modifying all the register writes directly
> (BSP commits 2d339800bbc73d and f73d5eb86097df). This seems much more future
> proof to me.
>
> Yamada-san: could you check if your HW has 'always 1' bits, too?
>
> Tested on a R-Car M3-N. No regression and no performance impacts when reading
> large files from eMMC or UHS-SD cards.
>
> drivers/mmc/host/renesas_sdhi_core.c | 1 +
> drivers/mmc/host/tmio_mmc.h | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> b/drivers/mmc/host/renesas_sdhi_core.c
> index a049b01206f1..31a351a20dc0 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -722,6 +722,7 @@ int renesas_sdhi_probe(struct platform_device *pdev,
> host->ops.card_busy = renesas_sdhi_card_busy;
> host->ops.start_signal_voltage_switch =
> renesas_sdhi_start_signal_voltage_switch;
> + host->sdcard_irq_setbit_mask = TMIO_STAT_ALWAYS_SET_27;
> }
>
> /* Orginally registers were 16 bit apart, could be 32 or 64 nowadays
> */
> diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> index 5f6dfb86e43e..c03529e3f01a 100644
> --- a/drivers/mmc/host/tmio_mmc.h
> +++ b/drivers/mmc/host/tmio_mmc.h
> @@ -70,6 +70,7 @@
> #define TMIO_STAT_DAT0 BIT(23) /* only known on R-Car so far */
> #define TMIO_STAT_RXRDY BIT(24)
> #define TMIO_STAT_TXRQ BIT(25)
> +#define TMIO_STAT_ALWAYS_SET_27BIT(27) /* only known on R-Car 2+ so
> far */
> #define TMIO_STAT_ILL_FUNC BIT(29) /* only when !TMIO_MMC_HAS_IDLE_WAIT
> */
> #define TMIO_STAT_SCLKDIVEN BIT(29) /* only when TMIO_MMC_HAS_IDLE_WAIT
> */
> #define TMIO_STAT_CMD_BUSY BIT(30)
> @@ -154,6 +155,7 @@ struct tmio_mmc_host {
> u32 sdcard_irq_mask;
> u32 sdio_irq_mask;
> unsigned intclk_cache;
> + u32 sdcard_irq_setbit_mask;
>
> spinlock_t lock; /* protect host private data
> */
> unsigned long last_req_ts;
> @@ -268,6 +270,9 @@ static inline void sd_ctrl_write16_rep(struct
> tmio_mmc_host *host, int addr,
> static inline void sd_ctrl_write32_as_16_and_16(struct tmio_mmc_host *host,
> int addr, u32 val)
> {
> + if (addr == CTL_IRQ_MASK || addr == CTL_STATUS)
> + val |= host->sdcard_irq_setbit_mask;
> +
> iowrite16(val & 0x, host->ctl + (addr << host->bus_shift));
> iowrite16(val >> 16, host->ctl + ((addr + 2) << host->bus_shift));
> }
> --
> 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 = &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, &cmd, 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 =
> &pcf_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, ®map_config);
> > + if (of_device_get_match_data(&client->dev) ==
> > + &pcf_85263_regmap_config) {
> > + regmap_config = &pcf_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 = &pcf_85263_config },
> { .compatible = "nxp,pcf85363", .data = &pcf_85363_config },
> { /* sentinel */ }
> };
>
> Then you can just do
>
> struct pcf85x63_config *config = &pcf85363_config; /* default for
> non-DT
> */
> void *data = of_device_get_match_data(&client->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 =
> &pcf_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
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
On 12/05/2018 02:31 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Wed, Dec 5, 2018 at 2:25 PM Marek Vasut wrote:
>> On 12/05/2018 02:15 PM, Geert Uytterhoeven wrote:
>>> On Wed, Dec 5, 2018 at 1:57 PM Marek Vasut wrote:
On 12/05/2018 08:44 AM, masonccy...@mxic.com.tw wrote:
>> "Marek Vasut"
>> 2018/12/05 上午 10:04
>> On 12/03/2018 10:18 AM, Mason Yang wrote:
>>> Add a driver for Renesas R-Car Gen3 RPC SPI controller.
>>>
>>> Signed-off-by: Mason Yang
>>>
>>> +static void rpc_spi_hw_init(struct rpc_spi *rpc)
>>> +{
>>> + /*
>>> +* NOTE: The 0x260 are undocumented bits, but they must be set.
>>> +* RPC_PHYCNT_STRTIM is strobe timing adjustment bit,
>>> +* 0x0 : the delay is biggest,
>>> +* 0x1 : the delay is 2nd biggest,
>>> +* 0x3 or 0x6 is a recommended value.
>>> +*/
>>
>> Doesn't this vary by SoC ? I think H3 ES1.0 had different value here,
>> but I might be wrong.
>
> I check the Renesas bare-metal code, mini_monitor v4.01.
> It set 0x03 or 0x0 and I test them w/ 0x0, 0x3 and 0x6 are all OK.
Shouldn't this somehow use the soc_device_match() then and configure it
accordingly for various chips ? Like eg. the r8a7795-cpg-mssr driver does.
>>>
>>> Please don't use soc_device_match() for per-SoC configuration, if
>>> you already have of_device_id.data.
>>
>> I mean, the value is different on H3 ES1 and ES2 iirc, that's what
>> soc_device_match() is for, right ?
>
> Oh, it differs between revisions, too?
> Yes, in that case you need soc_device_match().
>
>>> BTW, this drivers support r8a7795 only (for now), as per the compatible
>>> value.
>>
>> 77995
>
> Sorry, typo on my side. So H3 is not yet supported ;-)
It's coming the minute this lands mainline, so we should make it easy to
add.
>>> +#ifdef CONFIG_RESET_CONTROLLER
>>
>> Just make the driver depend on reset controller.
>
> ?
> please refer to
> https://github.com/torvalds/linux/blob/master/drivers/clk/renesas/renesas-cpg-mssr.c
>
> line 124 ~ 126
This seems like a stopgap measure for systems which do not have a reset
api compatible controller. Geert ?
>>>
>>> So far CONFIG_RESET_CONTROLLER is optional.
>>
>> My understanding is that for this IP, it can well be mandatory, since
>> all the chips have a reset wired to the IP internally.
>
> That's what I was trying to find out, hence my question about the purpose.
>
>>> + regmap_write(rpc->regmap, RPC_SMWDR0,
>>> + *(u32 *)(tx_buf + pos));
>>
>> *(u32 *) cast is probably not needed , fix casts globally.
>
> It must have it!
Why ?
>>>
>>> Else you get a compiler warning, as tx_bug is void *.
>>
>> Don't you need some get_unaligned() in that case ? txbuf+pos can well be
>> unaligned if it's void * .
>
> True, but IIRC, arm64 can handle that, right?
> Don't know about SuperH.
Oh, that's right, there are SH systems with RPC. Right.
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int rpc_spi_suspend(struct device *dev)
>>> +{
>>> + struct platform_device *pdev = to_platform_device(dev);
>>> + struct spi_master *master = platform_get_drvdata(pdev);
>>> +
>>> + return spi_master_suspend(master);
>>
>> Won't the SPI NOR lose state across suspend ? Is that a problem ?
>
> I don't think so.
> Because when the device is not in operation and CS# is high,
> it is put in stand-by mode.
Is the power to the SPI NOR retained ?
>>>
>>> Not if PSCI system suspend turns of power to the SoC.
>>
>> And is that a problem ?
>
> Good question!
That's what we need an answer to :)
--
Best regards,
Marek Vasut
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
Hi Marek,
On Wed, Dec 5, 2018 at 2:25 PM Marek Vasut wrote:
> On 12/05/2018 02:15 PM, Geert Uytterhoeven wrote:
> > On Wed, Dec 5, 2018 at 1:57 PM Marek Vasut wrote:
> >> On 12/05/2018 08:44 AM, masonccy...@mxic.com.tw wrote:
> "Marek Vasut"
> 2018/12/05 上午 10:04
> On 12/03/2018 10:18 AM, Mason Yang wrote:
> > Add a driver for Renesas R-Car Gen3 RPC SPI controller.
> >
> > Signed-off-by: Mason Yang
> >
> > +static void rpc_spi_hw_init(struct rpc_spi *rpc)
> > +{
> > + /*
> > +* NOTE: The 0x260 are undocumented bits, but they must be set.
> > +* RPC_PHYCNT_STRTIM is strobe timing adjustment bit,
> > +* 0x0 : the delay is biggest,
> > +* 0x1 : the delay is 2nd biggest,
> > +* 0x3 or 0x6 is a recommended value.
> > +*/
>
> Doesn't this vary by SoC ? I think H3 ES1.0 had different value here,
> but I might be wrong.
> >>>
> >>> I check the Renesas bare-metal code, mini_monitor v4.01.
> >>> It set 0x03 or 0x0 and I test them w/ 0x0, 0x3 and 0x6 are all OK.
> >>
> >> Shouldn't this somehow use the soc_device_match() then and configure it
> >> accordingly for various chips ? Like eg. the r8a7795-cpg-mssr driver does.
> >
> > Please don't use soc_device_match() for per-SoC configuration, if
> > you already have of_device_id.data.
>
> I mean, the value is different on H3 ES1 and ES2 iirc, that's what
> soc_device_match() is for, right ?
Oh, it differs between revisions, too?
Yes, in that case you need soc_device_match().
> > BTW, this drivers support r8a7795 only (for now), as per the compatible
> > value.
>
> 77995
Sorry, typo on my side. So H3 is not yet supported ;-)
> > +#ifdef CONFIG_RESET_CONTROLLER
>
> Just make the driver depend on reset controller.
> >>>
> >>> ?
> >>> please refer to
> >>> https://github.com/torvalds/linux/blob/master/drivers/clk/renesas/renesas-cpg-mssr.c
> >>>
> >>> line 124 ~ 126
> >>
> >> This seems like a stopgap measure for systems which do not have a reset
> >> api compatible controller. Geert ?
> >
> > So far CONFIG_RESET_CONTROLLER is optional.
>
> My understanding is that for this IP, it can well be mandatory, since
> all the chips have a reset wired to the IP internally.
That's what I was trying to find out, hence my question about the purpose.
> > + regmap_write(rpc->regmap, RPC_SMWDR0,
> > + *(u32 *)(tx_buf + pos));
>
> *(u32 *) cast is probably not needed , fix casts globally.
> >>>
> >>> It must have it!
> >>
> >> Why ?
> >
> > Else you get a compiler warning, as tx_bug is void *.
>
> Don't you need some get_unaligned() in that case ? txbuf+pos can well be
> unaligned if it's void * .
True, but IIRC, arm64 can handle that, right?
Don't know about SuperH.
> > +#ifdef CONFIG_PM_SLEEP
> > +static int rpc_spi_suspend(struct device *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct spi_master *master = platform_get_drvdata(pdev);
> > +
> > + return spi_master_suspend(master);
>
> Won't the SPI NOR lose state across suspend ? Is that a problem ?
> >>>
> >>> I don't think so.
> >>> Because when the device is not in operation and CS# is high,
> >>> it is put in stand-by mode.
> >>
> >> Is the power to the SPI NOR retained ?
> >
> > Not if PSCI system suspend turns of power to the SoC.
>
> And is that a problem ?
Good question!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
On 12/05/2018 02:15 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Wed, Dec 5, 2018 at 1:57 PM Marek Vasut wrote:
>> On 12/05/2018 08:44 AM, masonccy...@mxic.com.tw wrote:
"Marek Vasut"
2018/12/05 上午 10:04
On 12/03/2018 10:18 AM, Mason Yang wrote:
> Add a driver for Renesas R-Car Gen3 RPC SPI controller.
>
> Signed-off-by: Mason Yang
>
> +static void rpc_spi_hw_init(struct rpc_spi *rpc)
> +{
> + /*
> +* NOTE: The 0x260 are undocumented bits, but they must be set.
> +* RPC_PHYCNT_STRTIM is strobe timing adjustment bit,
> +* 0x0 : the delay is biggest,
> +* 0x1 : the delay is 2nd biggest,
> +* 0x3 or 0x6 is a recommended value.
> +*/
Doesn't this vary by SoC ? I think H3 ES1.0 had different value here,
but I might be wrong.
>>>
>>> I check the Renesas bare-metal code, mini_monitor v4.01.
>>> It set 0x03 or 0x0 and I test them w/ 0x0, 0x3 and 0x6 are all OK.
>>
>> Shouldn't this somehow use the soc_device_match() then and configure it
>> accordingly for various chips ? Like eg. the r8a7795-cpg-mssr driver does.
>
> Please don't use soc_device_match() for per-SoC configuration, if
> you already have of_device_id.data.
I mean, the value is different on H3 ES1 and ES2 iirc, that's what
soc_device_match() is for, right ?
> BTW, this drivers support r8a7795 only (for now), as per the compatible
> value.
77995
> +#ifdef CONFIG_RESET_CONTROLLER
Just make the driver depend on reset controller.
>>>
>>> ?
>>> please refer to
>>> https://github.com/torvalds/linux/blob/master/drivers/clk/renesas/renesas-cpg-mssr.c
>>>
>>> line 124 ~ 126
>>
>> This seems like a stopgap measure for systems which do not have a reset
>> api compatible controller. Geert ?
>
> So far CONFIG_RESET_CONTROLLER is optional.
My understanding is that for this IP, it can well be mandatory, since
all the chips have a reset wired to the IP internally.
> +static int rpc_spi_io_xfer(struct rpc_spi *rpc,
> +const void *tx_buf, void *rx_buf)
> +{
> + u32 smenr, smcr, data, pos = 0;
> + int ret = 0;
> +
> + regmap_write(rpc->regmap, RPC_CMNCR, RPC_CMNCR_MD | RPC_CMNCR_SFDE |
> + RPC_CMNCR_MOIIO_HIZ | RPC_CMNCR_IOFV_HIZ |
> + RPC_CMNCR_BSZ(0));
> + regmap_write(rpc->regmap, RPC_SMDRENR, 0x0);
> + regmap_write(rpc->regmap, RPC_SMCMR, rpc->cmd);
> + regmap_write(rpc->regmap, RPC_SMDMCR, rpc->dummy);
> + regmap_write(rpc->regmap, RPC_SMADR, rpc->addr);
> +
> + if (tx_buf) {
> + smenr = rpc->smenr;
> +
> + while (pos < rpc->xferlen) {
> + u32 nbytes = rpc->xferlen - pos;
> +
> + regmap_write(rpc->regmap, RPC_SMWDR0,
> + *(u32 *)(tx_buf + pos));
*(u32 *) cast is probably not needed , fix casts globally.
>>>
>>> It must have it!
>>
>> Why ?
>
> Else you get a compiler warning, as tx_bug is void *.
Don't you need some get_unaligned() in that case ? txbuf+pos can well be
unaligned if it's void * .
> +#ifdef CONFIG_PM_SLEEP
> +static int rpc_spi_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct spi_master *master = platform_get_drvdata(pdev);
> +
> + return spi_master_suspend(master);
Won't the SPI NOR lose state across suspend ? Is that a problem ?
>>>
>>> I don't think so.
>>> Because when the device is not in operation and CS# is high,
>>> it is put in stand-by mode.
>>
>> Is the power to the SPI NOR retained ?
>
> Not if PSCI system suspend turns of power to the SoC.
And is that a problem ?
--
Best regards,
Marek Vasut
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
Hi Marek,
On Wed, Dec 5, 2018 at 1:57 PM Marek Vasut wrote:
> On 12/05/2018 08:44 AM, masonccy...@mxic.com.tw wrote:
> >> "Marek Vasut"
> >> 2018/12/05 上午 10:04
> >> On 12/03/2018 10:18 AM, Mason Yang wrote:
> >> > Add a driver for Renesas R-Car Gen3 RPC SPI controller.
> >> >
> >> > Signed-off-by: Mason Yang
> >> > +static void rpc_spi_hw_init(struct rpc_spi *rpc)
> >> > +{
> >> > + /*
> >> > +* NOTE: The 0x260 are undocumented bits, but they must be set.
> >> > +* RPC_PHYCNT_STRTIM is strobe timing adjustment bit,
> >> > +* 0x0 : the delay is biggest,
> >> > +* 0x1 : the delay is 2nd biggest,
> >> > +* 0x3 or 0x6 is a recommended value.
> >> > +*/
> >>
> >> Doesn't this vary by SoC ? I think H3 ES1.0 had different value here,
> >> but I might be wrong.
> >
> > I check the Renesas bare-metal code, mini_monitor v4.01.
> > It set 0x03 or 0x0 and I test them w/ 0x0, 0x3 and 0x6 are all OK.
>
> Shouldn't this somehow use the soc_device_match() then and configure it
> accordingly for various chips ? Like eg. the r8a7795-cpg-mssr driver does.
Please don't use soc_device_match() for per-SoC configuration, if
you already have of_device_id.data.
BTW, this drivers support r8a7795 only (for now), as per the compatible
value.
> >> > +#ifdef CONFIG_RESET_CONTROLLER
> >>
> >> Just make the driver depend on reset controller.
> >
> > ?
> > please refer to
> > https://github.com/torvalds/linux/blob/master/drivers/clk/renesas/renesas-cpg-mssr.c
> >
> > line 124 ~ 126
>
> This seems like a stopgap measure for systems which do not have a reset
> api compatible controller. Geert ?
So far CONFIG_RESET_CONTROLLER is optional.
> >> > +static int rpc_spi_io_xfer(struct rpc_spi *rpc,
> >> > +const void *tx_buf, void *rx_buf)
> >> > +{
> >> > + u32 smenr, smcr, data, pos = 0;
> >> > + int ret = 0;
> >> > +
> >> > + regmap_write(rpc->regmap, RPC_CMNCR, RPC_CMNCR_MD | RPC_CMNCR_SFDE |
> >> > + RPC_CMNCR_MOIIO_HIZ | RPC_CMNCR_IOFV_HIZ |
> >> > + RPC_CMNCR_BSZ(0));
> >> > + regmap_write(rpc->regmap, RPC_SMDRENR, 0x0);
> >> > + regmap_write(rpc->regmap, RPC_SMCMR, rpc->cmd);
> >> > + regmap_write(rpc->regmap, RPC_SMDMCR, rpc->dummy);
> >> > + regmap_write(rpc->regmap, RPC_SMADR, rpc->addr);
> >> > +
> >> > + if (tx_buf) {
> >> > + smenr = rpc->smenr;
> >> > +
> >> > + while (pos < rpc->xferlen) {
> >> > + u32 nbytes = rpc->xferlen - pos;
> >> > +
> >> > + regmap_write(rpc->regmap, RPC_SMWDR0,
> >> > + *(u32 *)(tx_buf + pos));
> >>
> >> *(u32 *) cast is probably not needed , fix casts globally.
> >
> > It must have it!
>
> Why ?
Else you get a compiler warning, as tx_bug is void *.
> >> > +#ifdef CONFIG_PM_SLEEP
> >> > +static int rpc_spi_suspend(struct device *dev)
> >> > +{
> >> > + struct platform_device *pdev = to_platform_device(dev);
> >> > + struct spi_master *master = platform_get_drvdata(pdev);
> >> > +
> >> > + return spi_master_suspend(master);
> >>
> >> Won't the SPI NOR lose state across suspend ? Is that a problem ?
> >
> > I don't think so.
> > Because when the device is not in operation and CS# is high,
> > it is put in stand-by mode.
>
> Is the power to the SPI NOR retained ?
Not if PSCI system suspend turns of power to the SoC.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 2/2] dt-binding: spi: Document Renesas R-Car Gen3 RPC controller bindings
On 12/05/2018 09:39 AM, masonccy...@mxic.com.tw wrote: > Hi Marek, Hi, >> "Marek Vasut" >> 2018/12/05 上午 10:04 >> >> To >> >> "Mason Yang" , broo...@kernel.org, linux- >> ker...@vger.kernel.org, linux-...@vger.kernel.org, >> boris.brezil...@bootlin.com, linux-renesas-soc@vger.kernel.org, >> "Geert Uytterhoeven" , >> >> cc >> >> julie...@mxic.com.tw, "Simon Horman" , >> zhengxu...@mxic.com.tw >> >> Subject >> >> Re: [PATCH v2 2/2] dt-binding: spi: Document Renesas R-Car Gen3 RPC >> controller bindings >> >> On 12/03/2018 10:18 AM, Mason Yang wrote: >> > Document the bindings used by the Renesas R-Car Gen3 RPC SPI controller. >> >> RPC is SPI and HF controller, it is not a pure SPI controller. >> >> How does this deal with the HF part ? Keep in mind the bindings are ABI >> and it will be difficult to redo them later. > > After checking HF datasheet, > 512_MBIT_256_MBIT_128_MBIT_HYPERFLASH_FAMILY_Datasheet.pdf. > > > > From my point of view, > HyperFlash is a kind of standard NOR Flash with high-speed SPI interface. > But I might be wrong. It behaves as a Parallel CFI NOR internally, and so it fits and works with the CFI NOR drivers (see the U-Boot driver), except the interface between the HF controller and the chip is custom. It's not SPI per-se. -- Best regards, Marek Vasut
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
On 12/05/2018 10:11 AM, Geert Uytterhoeven wrote:
> Hi Mason,
>
> On Wed, Dec 5, 2018 at 8:44 AM wrote:
>>> "Marek Vasut"
>>> 2018/12/05 上午 10:04
>>> On 12/03/2018 10:18 AM, Mason Yang wrote:
Add a driver for Renesas R-Car Gen3 RPC SPI controller.
Signed-off-by: Mason Yang
>
+static u8 rpc_bits_xfer(u32 nbytes)
+{
+ if (nbytes > 4)
+ nbytes = 4;
>>>
>>> Use clamp() ?
>>>
>>
>> nbytes = clamp(nbytes, 1, 4);
>>
>> got many warnings, something like,
>> ./include/linux/kernel.h:845:29: warning: comparison of distinct pointer
>> types lacks a cast
>
> You can either make the constants unsigned (1U and 4U), or
> use clamp_t(u32, ...).
>
+ rpc->smenr |= RPC_SMENR_SPIDE(rpc_bits_xfer
+ (op->data.nbytes)) | RPC_SMENR_SPIDB
+ (fls(op->data.buswidth >> 1));
>>>
>>> Drop parenthesis around fls()
>>
>> ?
>> no way.
>
> Please split the line before RPC_SMENR_SPIDB, and join the next line
> with the parameters, so it becomes obvious the parentheses are needed
> because RPC_SMENR_SPIDB() is a macro taking parameters.
Oh, I didn't notice that, right.
--
Best regards,
Marek Vasut
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
On 12/05/2018 08:44 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
> thanks for your review.
>
>> "Marek Vasut"
>> 2018/12/05 上午 10:04
>>
>> To
>>
>> "Mason Yang" , broo...@kernel.org, linux-
>> ker...@vger.kernel.org, linux-...@vger.kernel.org,
>> boris.brezil...@bootlin.com, linux-renesas-soc@vger.kernel.org,
>> "Geert Uytterhoeven" ,
>>
>> cc
>>
>> julie...@mxic.com.tw, "Simon Horman" ,
>> zhengxu...@mxic.com.tw
>>
>> Subject
>>
>> Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
>>
>> On 12/03/2018 10:18 AM, Mason Yang wrote:
>> > Add a driver for Renesas R-Car Gen3 RPC SPI controller.
>> >
>> > Signed-off-by: Mason Yang
>>
>> What changed in this V2 ?
>>
>> [...]
>
> see some description in [PATH v2 0/2]
I don't see any V2: list there.
>> > +struct rpc_spi {
>> > + struct clk *clk_rpc;
>> > + void __iomem *base;
>> > + struct {
>> > + void __iomem *map;
>> > + dma_addr_t dma;
>> > + size_t size;
>> > + } linear;
>>
>> This is still here, see my review comments on the previous version.
>>
>> > + struct regmap *regmap;
>> > + u32 cur_speed_hz;
>> > + u32 cmd;
>> > + u32 addr;
>> > + u32 dummy;
>> > + u32 smcr;
>> > + u32 smenr;
>> > + u32 xferlen;
>> > + u32 totalxferlen;
>> > + enum spi_mem_data_dir xfer_dir;
>> > +#ifdef CONFIG_RESET_CONTROLLER
>> > + struct reset_control *rstc;
>> > +#endif
>> > +};
>> > +
>> > +static int rpc_spi_set_freq(struct rpc_spi *rpc, unsigned long freq)
>> > +{
>> > + int ret;
>> > +
>> > + if (rpc->cur_speed_hz == freq)
>> > + return 0;
>> > +
>> > + ret = clk_set_rate(rpc->clk_rpc, freq);
>> > + if (ret)
>> > + return ret;
>> > +
>> > + rpc->cur_speed_hz = freq;
>> > + return ret;
>> > +}
>> > +
>> > +static void rpc_spi_hw_init(struct rpc_spi *rpc)
>> > +{
>> > + /*
>> > + * NOTE: The 0x260 are undocumented bits, but they must be set.
>> > + * RPC_PHYCNT_STRTIM is strobe timing adjustment bit,
>> > + * 0x0 : the delay is biggest,
>> > + * 0x1 : the delay is 2nd biggest,
>> > + * 0x3 or 0x6 is a recommended value.
>> > + */
>>
>> Doesn't this vary by SoC ? I think H3 ES1.0 had different value here,
>> but I might be wrong.
>
> I check the Renesas bare-metal code, mini_monitor v4.01.
> It set 0x03 or 0x0 and I test them w/ 0x0, 0x3 and 0x6 are all OK.
Shouldn't this somehow use the soc_device_match() then and configure it
accordingly for various chips ? Like eg. the r8a7795-cpg-mssr driver does.
>> > + regmap_write(rpc->regmap, RPC_PHYCNT, RPC_PHYCNT_CAL |
>> > + RPC_PHYCNT_STRTIM(0x6) | 0x260);
>> > +
>> > + /*
>> > + * NOTE: The 0x31511144 and 0x431 are undocumented bits,
>> > + * but they must be set for RPC_PHYOFFSET1 & RPC_PHYOFFSET2.
>> > + */
>> > + regmap_write(rpc->regmap, RPC_PHYOFFSET1, 0x31511144);
>> > + regmap_write(rpc->regmap, RPC_PHYOFFSET2, 0x431);
>> > +
>> > + regmap_write(rpc->regmap, RPC_SSLDR, RPC_SSLDR_SPNDL(7) |
>> > + RPC_SSLDR_SLNDL(7) | RPC_SSLDR_SCKDL(7));
>> > +}
>> > +
>> > +#ifdef CONFIG_RESET_CONTROLLER
>>
>> Just make the driver depend on reset controller.
>
> ?
> please refer to
> https://github.com/torvalds/linux/blob/master/drivers/clk/renesas/renesas-cpg-mssr.c
>
> line 124 ~ 126
This seems like a stopgap measure for systems which do not have a reset
api compatible controller. Geert ?
>> > +static int rpc_spi_do_reset(struct rpc_spi *rpc)
>> > +{
>> > + int i, ret;
>> > +
>> > + ret = reset_control_reset(rpc->rstc);
>> > + if (ret)
>> > + return ret;
>> > +
>> > + for (i = 0; i < LOOP_TIMEOUT; i++) {
>> > + ret = reset_control_status(rpc->rstc);
>> > + if (ret == 0)
>> > + return 0;
>> > + usleep_range(0, 1);
>> > + }
>> > +
>> > + return -ETIMEDOUT;
>> > +}
>> > +#else
>> > +static int rpc_spi_do_reset(struct rpc_spi *rpc)
>> > +{
>> > + return -ETIMEDOUT;
>> > +}
>> > +#endif
>> > +
>> > +static int wait_msg_xfer_end(struct rpc_spi *rpc)
>> > +{
>> > + u32 sts;
>> > +
>> > + return regmap_read_poll_timeout(rpc->regmap, RPC_CMNSR, sts,
>> > + sts & RPC_CMNSR_TEND, 0, USEC_PER_SEC);
>> > +}
>> > +
>> > +static u8 rpc_bits_xfer(u32 nbytes)
>> > +{
>> > + if (nbytes > 4)
>> > + nbytes = 4;
>>
>> Use clamp() ?
>>
>
> nbytes = clamp(nbytes, 1, 4);
>
> got many warnings, something like,
> ./include/linux/kernel.h:845:29: warning: comparison of distinct pointer
> types lacks a cast
Geert already replied.
>> > +
>> > + return GENMASK(3, 4 - nbytes);
>>
>> Nice ;-)
>>
>> > +}
>> > +
>> > +static int rpc_spi_io_xfer(struct rpc_spi *rpc,
>> > + const void *tx_buf, void *rx_buf)
>> > +{
>> > + u32 smenr, smcr, data, pos = 0;
>> > + int ret = 0;
>> > +
>> > + regmap_write(rpc->regmap, RPC_CMNCR, RPC_CMNCR_MD | RPC_CMNCR_SFDE |
>> > + RPC_CMNCR_MOIIO_HIZ | RPC_CMNCR_IOFV_HIZ |
>> > + RPC_CMNCR_BSZ(0));
>> > + regmap_write(rpc->regmap, RPC_SMDRENR, 0
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 CPG_MOD 724>,
-<&cpg CPG_MOD 723>,
-<&cpg CPG_MOD 726>;
- clock-names = "du.0", "du.1", "lvds.0";
+<&cpg 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 CPG_MOD 724>,
+<&cpg 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 1/5] ARM: dts: iwg20d-q7-common: Move cmt/rwdt node out of RZ/G1M SOM
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
---
V1-->v2
* No change
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 9 +
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index ca9154dd..e2b1ab9 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -116,6 +116,10 @@
status = "okay";
};
+&cmt0 {
+ status = "okay";
+};
+
&hsusb {
status = "okay";
pinctrl-0 = <&usb0_pins>;
@@ -230,6 +234,11 @@
};
};
+&rwdt {
+ timeout-sec = <60>;
+ status = "okay";
+};
+
&scif0 {
pinctrl-0 = <&scif0_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index 0e2e033..b3fee1d 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -31,10 +31,6 @@
};
};
-&cmt0 {
- status = "okay";
-};
-
&extal_clk {
clock-frequency = <2000>;
};
@@ -88,11 +84,6 @@
};
};
-&rwdt {
- timeout-sec = <60>;
- status = "okay";
-};
-
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
pinctrl-names = "default";
--
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 CPG_MOD 000>;
+ dmas = <&dmac0 0x51>, <&dmac0 0x52>,
+ <&dmac1 0x51>, <&dmac1 0x52>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7744_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = <&cpg 000>;
+ status = "disabled";
+ };
+
+ msiof1: spi@e6e1 {
+ compatible = "renesas,msiof-r8a7744",
+"renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e1 0 0x0064>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 208>;
+ dmas = <&dmac0 0x55>, <&dmac0 0x56>,
+ <&dmac1 0x55>, <&dmac1 0x56>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7744_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = <&cpg 208>;
+ status = "disabled";
+ };
+
+ msiof2: spi@e6e0 {
+ compatible = "renesas,msiof-r8a7744",
+"renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e0 0 0x0064>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 205>;
+ dmas = <&dmac0 0x41>, <&dmac0 0x42>,
+ <&dmac1 0x41>, <&dmac1 0x42>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7744_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = <&cpg 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 CPG_MOD 000>;
- dmas = <&dmac0 0x51>, <&dmac0 0x52>,
- <&dmac1 0x51>, <&dmac1 0x52>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7744_PD_ALWAYS_ON>;
- #address-cells = <1>;
- #size-cells = <0>;
- resets = <&cpg 000>;
- status = "disabled";
- };
-
- msiof1: spi@e6e1 {
- compatible = "renesas,msiof-r8a7744",
-"renesas,rcar-gen2-msiof";
- reg = <0 0xe6e1 0 0x0064>;
- interrupts = ;
- clocks = <&cpg CPG_MOD 208>;
- dmas = <&dmac0 0x55>, <&dmac0 0x56>,
- <&dmac1 0x55>, <&dmac1 0x56>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7744_PD_ALWAYS_ON>;
- #address-cells = <1>;
- #size-cells = <0>;
- resets = <&cpg 208>;
- status = "disabled";
- };
-
- msiof2: spi@e6e0 {
- compatible = "renesas,msiof-r8a7744",
-"renesas,rcar-gen2-msiof";
- reg = <0 0xe6e0 0 0x0064>;
- interrupts = ;
- clocks = <&cpg CPG_MOD 205>;
- dmas = <&dmac0 0x41>, <&dmac0 0x42>,
-
[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";
};
+&qspi {
+ pinctrl-0 = <&qspi_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;
+ };
+};
+
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
pinctrl-names = "default";
--
2.7.4
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
Hi Mason,
On Wed, Dec 5, 2018 at 8:44 AM wrote:
> > "Marek Vasut"
> > 2018/12/05 上午 10:04
> > On 12/03/2018 10:18 AM, Mason Yang wrote:
> > > Add a driver for Renesas R-Car Gen3 RPC SPI controller.
> > >
> > > Signed-off-by: Mason Yang
> > > +static u8 rpc_bits_xfer(u32 nbytes)
> > > +{
> > > + if (nbytes > 4)
> > > + nbytes = 4;
> >
> > Use clamp() ?
> >
>
> nbytes = clamp(nbytes, 1, 4);
>
> got many warnings, something like,
> ./include/linux/kernel.h:845:29: warning: comparison of distinct pointer
> types lacks a cast
You can either make the constants unsigned (1U and 4U), or
use clamp_t(u32, ...).
> > > + rpc->smenr |= RPC_SMENR_SPIDE(rpc_bits_xfer
> > > + (op->data.nbytes)) | RPC_SMENR_SPIDB
> > > + (fls(op->data.buswidth >> 1));
> >
> > Drop parenthesis around fls()
>
> ?
> no way.
Please split the line before RPC_SMENR_SPIDB, and join the next line
with the parameters, so it becomes obvious the parentheses are needed
because RPC_SMENR_SPIDB() is a macro taking parameters.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
Hi Mason,
On Mon, Dec 3, 2018 at 10:19 AM Mason Yang wrote:
> Add a driver for Renesas R-Car Gen3 RPC SPI controller.
>
> Signed-off-by: Mason Yang
Thanks for your patch!
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -528,6 +528,12 @@ config SPI_RSPI
> help
> SPI driver for Renesas RSPI and QSPI blocks.
>
> +config SPI_RENESAS_RPC
> + tristate "Renesas R-Car Gen3 RPC SPI controller"
> + depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
So this driver is intended for SuperH SoCs, too?
If not, please drop the dependency.
> --- /dev/null
> +++ b/drivers/spi/spi-renesas-rpc.c
> +#ifdef CONFIG_RESET_CONTROLLER
> +static int rpc_spi_do_reset(struct rpc_spi *rpc)
What's the purpose of the reset routine?
Given the #ifdef, is it optional or required?
> +{
> + int i, ret;
> +
> + ret = reset_control_reset(rpc->rstc);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < LOOP_TIMEOUT; i++) {
> + ret = reset_control_status(rpc->rstc);
> + if (ret == 0)
> + return 0;
> + usleep_range(0, 1);
> + }
Why do you need this loop?
The delay in cpg_mssr_reset() should be sufficient.
> +
> + return -ETIMEDOUT;
> +}
> +#else
> +static int rpc_spi_do_reset(struct rpc_spi *rpc)
> +{
> + return -ETIMEDOUT;
> +}
> +#endif
> +static int rpc_spi_transfer_one_message(struct spi_master *master,
> + struct spi_message *msg)
> +{
> + struct rpc_spi *rpc = spi_master_get_devdata(master);
> + struct spi_transfer *t;
> + int ret;
> +
> + rpc_spi_transfer_setup(rpc, msg);
> +
> + list_for_each_entry(t, &msg->transfers, transfer_list) {
> + if (!list_is_last(&t->transfer_list, &msg->transfers))
> + continue;
> + ret = rpc_spi_xfer_message(rpc, t);
rpc_spi_xfer_message() sounds like a bad name to me, given it operates
on a transfer, not on a message.
> + if (ret)
> + goto out;
> + }
> +
> + msg->status = 0;
> + msg->actual_length = rpc->totalxferlen;
> +out:
> + spi_finalize_current_message(master);
> + return 0;
> +}
> +static int rpc_spi_probe(struct platform_device *pdev)
> +{
> + rpc->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> + if (IS_ERR(rpc->rstc))
> + return PTR_ERR(rpc->rstc);
This will return an error if CONFIG_RESET_CONTROLLER is not set, hence
the #ifdef above is moot.
> +
> + pm_runtime_enable(&pdev->dev);
> + master->auto_runtime_pm = true;
> +
> + master->num_chipselect = 1;
> + master->mem_ops = &rpc_spi_mem_ops;
> + master->transfer_one_message = rpc_spi_transfer_one_message;
Is there any reason you cannot use the standard
spi_transfer_one_message, i.e. provide spi_controller.transfer_one()
instead of spi_controller.transfer_one_message()?
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
