Re: [PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Dirk Behme]

On 01.06.2016 21:20, Geert Uytterhoeven wrote:

Hi all,

Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
state of the mode pins either by a call from the board code, or directly
by using a hardcoded register access. This is a bit messy, and creates a
dependency between driver and platform code.

This RFC patch series converts the various Renesas R-Car clock drivers
and support code from reading the mode pin states using a hardcoded
register access to using a new R-Car RST driver.

This series consists of 5 parts:
  A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
 driver,
  B. Patches 3-10 add device nodes for the RST modules to the R-Car DTS
 files,
  C. Patches 11-16 convert the clock drivers to call into the new R-Car
 RST driver,
  D. Patches 17-19 remove passing mode pin state to the clock drivers
 from the board code,
  E. Patches 20-22 remove dead code from the clock drivers.

I've kept all parts together as this is an RFC, and to avoid losing the
bigger picture. I will split it in series per maintainer, when we have
decided how to handle the dependencies (see below).

After this, there are still a few users of rcar_gen2_read_mode_pins()
left in board code, which should be converted in one way or another.
However, all R-Car clock drivers will rely on the presence in DT of a
device node for the RST module.  Backwards compatibility with old DTBs
is retained only for R-Car Gen2, which has fallback code calling into
rcar_gen2_read_mode_pins().

As is usually the case with moving functionality from board code to DT,
there are lots of hard dependencies:
  - The DT updates in Part B can be merged as soon as the DT bindings in
Part A have been approved,
  - The clock driver updates in Part C depend functionally on the driver
code in Part A,
  - The board code cleanups in Part D depend on the clock driver updates
in Part C,
  - The block driver cleanups in part E depend on the board code
cleanups in part D.

This series has evolved over time, cfr.
  - "[PATCH/RFC 00/11] ARM: shmobile: Let CPG use syscon for MD pin
values" (http://www.spinics.net/lists/linux-clk/msg01478.html),
  - "[PATCH 00/10] arm64: renesas: Obtain MD pin values using
syscon/regmap".
(http://www.spinics.net/lists/linux-sh/msg44757.html)

Changes compared to v2:
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value and "renesas,modemr" property, use a
real driver instead,
  - Add support for R-Car M1A, H1, and M3-W.

Changes compared to v1:
  - Add support for R-Car H3.

An alternative and broader solution was proposed by Simon Horman as
"[PATCH/RFC 0/6] boot-mode-reg: Add core"
(http://www.spinics.net/lists/linux-sh/msg45969.html).

This patch series is against renesas-drivers.
It has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
and r8a7795/salvator-x.

Thanks for your comments!

Geert Uytterhoeven (22):
  reset: Add renesas,rst DT bindings
  soc: renesas: Add R-Car RST driver
  ARM: dts: r8a7778: Add device node for RESET/WDT module
  ARM: dts: r8a7779: Add device node for RESET/WDT module
  ARM: dts: r8a7790: Add device node for RST module
  ARM: dts: r8a7791: Add device node for RST module
  ARM: dts: r8a7793: Add device node for RST module
  ARM: dts: r8a7794: Add device node for RST module
  arm64: renesas: r8a7795 dtsi: Add device node for RST module
  arm64: renesas: r8a7796 dtsi: Add device node for RST module
  clk: renesas: r8a7778: Obtain mode pin values using R-Car RST driver
  clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen2: Obtain mode pin values using RST driver
  clk: renesas: r8a7795: Obtain mode pin values from R-Car RST driver
  clk: renesas: r8a7796: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen3-cpg: Remove obsolete
rcar_gen3_read_mode_pins()
  ARM: shmobile: r8a7778: Stop passing mode pins state to clock driver
  ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver
  ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver
  clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()
  clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()
  clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

 .../devicetree/bindings/reset/renesas,rst.txt  | 35 
 arch/arm/boot/dts/r8a7778.dtsi |  5 ++
 arch/arm/boot/dts/r8a7779.dtsi |  5 ++
 arch/arm/boot/dts/r8a7790.dtsi |  5 ++
 arch/arm/boot/dts/r8a7791.dtsi |  5 ++
 arch/arm/boot/dts/r8a7793.dtsi |  5 ++
 arch/arm/boot/dts/r8a7794.dtsi |  5 ++
 arch/arm/mach-shmobile/setup-r8a7778.c | 15 
 arch/arm/mach-shmobile/setup-r8a7779.c | 27 ---
 arch/arm/mach-shmobile/setup-rcar-gen2.c   |  6 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  5 

Re: [PATCH/RFC v3 20/22] clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()

[Dirk Behme]

On 01.06.2016 21:21, Geert Uytterhoeven wrote:

The R-Car M1A board code no longer calls r8a7778_clocks_init().

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7778.c | 13 -
 include/linux/clk/renesas.h   |  1 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7778.c 
b/drivers/clk/renesas/clk-r8a7778.c
index 07ea411098a75ad1..886a8380e91247a1 100644
--- a/drivers/clk/renesas/clk-r8a7778.c
+++ b/drivers/clk/renesas/clk-r8a7778.c
@@ -143,16 +143,3 @@ static void __init r8a7778_cpg_clocks_init(struct 
device_node *np)

 CLK_OF_DECLARE(r8a7778_cpg_clks, "renesas,r8a7778-cpg-clocks",
   r8a7778_cpg_clocks_init);
-
-void __init r8a7778_clocks_init(u32 mode)
-{
-   BUG_ON(!(mode & BIT(19)));
-
-   cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
-(!!(mode & BIT(12)) << 1) |
-(!!(mode & BIT(11)));
-   cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
-   (!!(mode & BIT(1)));
-
-   of_clk_init(NULL);
-}



Just a question on how you structured the patches: Is there a special 
reason why you do the adding of new code and the removal of dead code in 
two patches?


Having both in one patch normally makes it more obvious which old code 
is replaced by which new code.


An example: In patch

[PATCH/RFC v3 11/22] clk: renesas: r8a7778: Obtain mode pin values using 
R-Car RST driver


I wondered where the section

+   BUG_ON(!(mode & BIT(19)));
+
+   cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
+(!!(mode & BIT(12)) << 1) |
+(!!(mode & BIT(11)));
+   cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
+   (!!(mode & BIT(1)));

comes from. This becomes obvious with this patch 20/22. But it's 9 
patches later ;) So why don't make the whole replacement visible in one 
patch?


Best regards

Dirk

Re: [PATCH/RFC v3 02/22] soc: renesas: Add R-Car RST driver

[Dirk Behme]

On 01.06.2016 21:21, Geert Uytterhoeven wrote:

Add a driver for the Renesas R-Car Gen1 RESET/WDT and R-Car Gen2/Gen3
RST module.

For now this driver just provides an API to obtain the state of the mode
pins, as latched at reset time.  As this is typically called from the
probe function of a clock driver, which can run much earlier than any
initcall, calling rcar_rst_read_mode_pins() may force an early
initialization of the driver.

Despite the current simple and almost identical handling for all
supported SoCs, the driver matches against SoC-specific compatible
values only, as the features provided by the hardware module differ a
lot across the various SoC families and members.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/soc/renesas/Makefile |  5 ++
 drivers/soc/renesas/rcar-rst.c   | 94 
 include/linux/soc/renesas/rcar-rst.h |  6 +++
 3 files changed, 105 insertions(+)
 create mode 100644 drivers/soc/renesas/rcar-rst.c
 create mode 100644 include/linux/soc/renesas/rcar-rst.h

diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index f32a001c65c3ab44..0d732ff893dd8fba 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,8 @@
+obj-$(CONFIG_ARCH_RCAR_GEN1)   += rcar-rst.o
+obj-$(CONFIG_ARCH_RCAR_GEN2)   += rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7795) += rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7796) += rcar-rst.o
+
 obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
 obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
 obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
new file mode 100644
index ..1997c348c0853254
--- /dev/null
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -0,0 +1,94 @@
+/*
+ * R-Car Gen1 RESET/WDT and R-Car Gen2/Gen3 RST Driver
+ *
+ * Copyright (C) 2016 Glider bvba
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct rst_config {
+   unsigned int modemr;/* Mode Monitoring Register Offset */
+};
+
+static const struct rst_config rcar_rst_gen1 __initconst = {
+   .modemr = 0x20,
+};
+
+static const struct rst_config rcar_rst_gen2 __initconst = {
+   .modemr = 0x60,
+};
+
+static const struct rst_config rcar_rst_gen3 __initconst = {
+   .modemr = 0x60,
+};
+
+static const struct of_device_id rcar_rst_matches[] __initconst = {
+   { .compatible = "renesas,r8a7778-reset-wdt", .data = _rst_gen1 },
+   { .compatible = "renesas,r8a7779-reset-wdt", .data = _rst_gen1 },
+   { .compatible = "renesas,r8a7790-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7791-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7792-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7793-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7794-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7795-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a7796-rst", .data = _rst_gen3 },
+   { /* sentinel */ }
+};
+
+static void __iomem *rcar_rst_base __initdata;
+static u32 saved_mode __initdata;
+
+static int __init rcar_rst_init(void)
+{
+   const struct of_device_id *match;
+   const struct rst_config *cfg;
+   struct device_node *np;
+   void __iomem *base;
+   int error = 0;
+
+   if (rcar_rst_base)
+   return 0;
+
+   np = of_find_matching_node_and_match(NULL, rcar_rst_matches, );
+   if (!np)
+   return -ENODEV;
+
+   base = of_iomap(np, 0);
+   if (!base) {
+   pr_warn("%s: Cannot map regs\n", np->full_name);
+   error = -ENOMEM;
+   goto out_put;
+   }
+
+   rcar_rst_base = base;
+   cfg = match->data;
+   saved_mode = ioread32(base + cfg->modemr);
+
+   pr_debug("%s: MODE = 0x%08x\n", np->full_name, saved_mode);
+
+out_put:
+   of_node_put(np);
+   return error;
+}
+arch_initcall(rcar_rst_init);
+
+int __init rcar_rst_read_mode_pins(u32 *mode)



Just a style issue: Is the string 'pins' in the function name still 
relevant? I.e. what's about just 'rcar_rst_read_mode()'?



Best regards

Dirk

Re: [PATCH/RFC v3 01/22] reset: Add renesas,rst DT bindings

[Dirk Behme]

On 01.06.2016 21:20, Geert Uytterhoeven wrote:

Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
RESET/WDT and R-Car Gen2/Gen3 RST).

As the features provided by the hardware module differ a lot across the
various SoC families and members, only SoC-specific compatible values
are defined.

For now we use the RST only for providing access to the state of the
mode pins.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Magnus Damm 
---
v3:
  - Clarify current usage,
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value,
  - Add R-Car M3-W,
  - Add R-Car Gen1,

v2:
  - Add Acked-by.
---
 .../devicetree/bindings/reset/renesas,rst.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt

diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt 
b/Documentation/devicetree/bindings/reset/renesas,rst.txt
new file mode 100644
index ..488c72e1ee849cd3
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
@@ -0,0 +1,35 @@
+DT bindings for the Renesas R-Car Reset Controller
+
+The R-Car Reset Controller provides reset control, and implements the following
+functions:
+  - Latching of the levels on mode pins when PRESET# is negated,
+  - Mode monitoring register,
+  - Reset control of peripheral devices (on R-Car Gen1),
+  - Watchdog timer (on R-Car Gen1).



Quite minor nit: s/./,/

Or drop all the ',' completely?



+  - Register-based reset control and boot address registers for the various CPU
+cores (on R-Car Gen2/Gen3),


Best regards

Dirk

RE: [PATCH v2 0/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Yoshihiro Shimoda]

Hi,

> From: Mathias Nyman
> Sent: Wednesday, June 01, 2016 8:42 PM
> 
> >>> isn't the following enough?
> >>>
> >>> @@ -4886,7 +4886,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
> >>> xhci_get_quirks_t get_quirks)
> >>>   xhci->hcc_params2 = readl(>cap_regs->hcc_params2);
> >>>   xhci_print_registers(xhci);
> >>>
> >>> - xhci->quirks = quirks;
> >>> + xhci->quirks |= quirks;
> >>>
> >>>   get_quirks(dev, xhci);
> >>
> >> Thank you for the comment!
> >> You're correct. This also can resolve the issue.
> >> Do you prefer such a simple patch?
> >> At least, I prefer such a simple patch :)
> >
> > I'll defer that to Mathias :-)
> >
> 
> I think that xhci->quirks |= quirks will do as a rc fix.

Thank you very much for the comment and submitting such a patch!

> looks like setting xhci->quirks need some generic cleanup for usb-next.
> Now in 4.7-rc1 we set xhci->quirks before xhci_gen_setup in 
> xhci_priv_init_quirk(),
> and during xhci_gen_setup() when copying module parameters quirk, and when 
> calling
> the get_quirk() callback.
> 
> There is nothing special happening between xhci_priv_init_quirk and when 
> calling
> get_quirks() in xhci_gen_setup() that need quirks to be set in two stages.
> 
> xhci pci drivers only use the get_quirk callback, platform drivers use both.
> 
> Looks like the get_quirk() callback is a legacy thing from when the memory for
> the xhci struct was allocated in xhci_gen_setup, and xhci->quirks could only 
> be
> set after that.
> 
> Now xhci struct is part of the usb_hcd, so we could probably get rid of the 
> get_quirk
> callback alltogether by setting the pci quirks in xhci_pci_setup

I understood it.

Best regards,
Yoshihiro Shimoda

> -Mathias

Re: [PATCH net-next] ravb: Add SET_RUNTIME_PM_OPS macro

[David Miller]

From: Yoshihiro Kaneko 
Date: Mon, 30 May 2016 05:25:43 +0900

> From: Kazuya Mizuguchi 
> 
> Use SET_RUNTIME_PM_OPS macro instead of assigning a member of
> dev_pm_ops directly.
> 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Yoshihiro Kaneko 

Applied.

Re: [PATCH net-next v2] ravb: Add ESF in RCR for enabling separation filter

[David Miller]

From: Yoshihiro Kaneko 
Date: Wed,  1 Jun 2016 03:01:28 +0900

> From: Masaru Nagai 
> 
> The H/W manual recommends B'10 or B'11 in a value of the separation
> filtering select bits in the receive configuration register (RCR.ESF).
> When B'10 is set, frames from non-matching streams are discarded.
> When B'11 is set, frames from non-matching streams are processed in
> reception queue 0 (best effort).
> This patch sets B'11 in ESF.
> 
> [ykaneko0...@gmail.com: revised this commit message]
> Signed-off-by: Masaru Nagai 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Yoshihiro Kaneko 
> Acked-by: Sergei Shtylyov 

Applied.

[PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility

[Geert Uytterhoeven]

Hi all,

When moving functionality from C code to DT, we're regularly faced with
stable DT issues: old DTBs should keep on working. This requires keeping
workaround code in the kernel.

An alternative solution to having workaround C code, would be to
dynamically modify the DT, to add missing device nodes and phandle links.
This has several advantages:
  - All workarounds are kept together,
  - Workarounds can be enabled/disabled using a single Kconfig option,
  - Individual driver code is not polluted by workaround code.

Examples of missing support in DT are:
  - A device node for the R-Car RST (Reset Controller), which a.o.
provides access to the Mode Pins (currently handled using an
hardcoded address in platform/driver code), cfr. the series
"[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for
obtaining mode pin state" I've just sent
(http://www.spinics.net/lists/linux-renesas-soc/msg04289.html),
  - A device node for the R-Car SYSC (System Controller), to link CPUs
to their respective power domains (On R-Car Gen2 CPUs can be
auto-detected, as there's a register indicating which CPU cores are
present),
  - Add a device node for the R-Car Gen2 APMU (Advanced Power
Management Unit), for modern CPU bringup using "enable-method".
Note that the method from this RFC doesn't work for
"enable-method", as that is parsed in arm_dt_init_cpu_maps(),
immediately after unflatten_device_tree(), long before initcalls
run.

However, there are other possible uses:
  - Workarounds for hardware bugs: early engineering samples of an SoC
may have non-functional devices. This would allow to describe the
latest (functional) hardware in the .dtsi, knowing that the fixup
code will disable non-functional devices when running on an early
engineering sample, based on reading the PRR (Product Revision
Register).
  - Handle other differences between SoC versions, e.g. change
compatible values for an early engineering sample that needs special
handling, or limit the features of a device.
  - Add SoC-specific compatible values to all device nodes (e.g. add
"renesas,r8a7795-wdt" to a node already having
"renesas,rcar-gen3-wdt" when running on r8a7795). This would make
it easier to share .dtsi files within the same SoC family, without
relying on e.g. C preprocessor tricks.

This proof-of-concept implements this for the missing R-Car RST (Reset
Controller) node. This poc is not suitable for all of the above, as some
DT structures (e.g. the CPU's "enable-method) are parsed long before
early_initcall(), and would need a different workaround.

What do you think?
Should this be handled at another level? E.g. operate on the FDT?

Thanks!

Geert Uytterhoeven (1):
  soc: renesas: Add DT fixup code for missing r8a7791 RST

 drivers/soc/renesas/Makefile   |   4 +
 drivers/soc/renesas/renesas-dt-fixup.c | 159 +
 2 files changed, 163 insertions(+)
 create mode 100644 drivers/soc/renesas/renesas-dt-fixup.c

-- 
1.9.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/RFC v3 06/22] ARM: dts: r8a7791: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7791.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 1985bd0dc32ce738..f8f1371f3621d1a3 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1493,6 +1493,11 @@
};
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7791-rst";
+   reg = <0 0xe616 0 0x0100>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7791-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH/RFC v3 19/22] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car Gen2 CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just call of_clk_init() instead.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Drop "select MFD_SYSCON", as the clock driver no longer uses syscon,

v2:
  - Kill compiler warning if CONFIG_ARM_ARCH_TIMER is not enabled.
---
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c 
b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index 1c6fd11c2f824019..755ce7a940c11848 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -15,7 +15,7 @@
  * GNU General Public License for more details.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -51,8 +51,8 @@ u32 rcar_gen2_read_mode_pins(void)
 
 void __init rcar_gen2_timer_init(void)
 {
-   u32 mode = rcar_gen2_read_mode_pins();
 #ifdef CONFIG_ARM_ARCH_TIMER
+   u32 mode = rcar_gen2_read_mode_pins();
void __iomem *base;
int extal_mhz = 0;
u32 freq;
@@ -127,7 +127,7 @@ void __init rcar_gen2_timer_init(void)
iounmap(base);
 #endif /* CONFIG_ARM_ARCH_TIMER */
 
-   rcar_gen2_clocks_init(mode);
+   of_clk_init(NULL);
clocksource_probe();
 }
 
-- 
1.9.1

[PATCH/RFC v3 04/22] ARM: dts: r8a7779: Add device node for RESET/WDT module

[Geert Uytterhoeven]

Add a device node for the RESET/WDT module, which provides a.o. reset
control, mode pin monitoring, and watchdog control.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 arch/arm/boot/dts/r8a7779.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index b9bbcce69dfbd5b9..4a30b232624e1d24 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -595,4 +595,9 @@
reg = <0xffd85000 0x0200>;
#power-domain-cells = <1>;
};
+
+   rst: reset-controller@ffcc {
+   compatible = "renesas,r8a7779-reset-wdt";
+   reg = <0xffcc 0x48>;
+   };
 };
-- 
1.9.1

[PATCH/RFC v3 15/22] clk: renesas: r8a7796: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index c84b549c14d2e57d..3db2d1cfc8cd788e 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -159,7 +160,12 @@ static const struct rcar_gen3_cpg_pll_config 
cpg_pll_configs[16] __initconst = {
 static int __init r8a7796_cpg_mssr_init(struct device *dev)
 {
const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
-   u32 cpg_mode = rcar_gen3_read_mode_pins();
+   u32 cpg_mode;
+   int error;
+
+   error = rcar_rst_read_mode_pins(_mode);
+   if (error)
+   return error;
 
cpg_pll_config = _pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
if (!cpg_pll_config->extal_div) {
-- 
1.9.1

[PATCH/RFC v3 03/22] ARM: dts: r8a7778: Add device node for RESET/WDT module

[Geert Uytterhoeven]

Add a device node for the RESET/WDT module, which provides a.o. reset
control, mode pin monitoring, and watchdog control.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 arch/arm/boot/dts/r8a7778.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index e571d66ea0fe1721..3d0a18abd408c76d 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -626,4 +626,9 @@
"sru-src6", "sru-src7", "sru-src8";
};
};
+
+   rst: reset-controller@ffcc {
+   compatible = "renesas,r8a7778-reset-wdt";
+   reg = <0xffcc 0x40>;
+   };
 };
-- 
1.9.1

[PATCH/RFC v3 22/22] clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

[Geert Uytterhoeven]

The R-Car Gen2 board code no longer calls rcar_gen2_clocks_init().

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - rebased,

v2:
  - No changes.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 7 ---
 include/linux/clk/renesas.h | 2 --
 2 files changed, 9 deletions(-)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c 
b/drivers/clk/renesas/clk-rcar-gen2.c
index 436fc7a7714e4bd7..4860022627bb455f 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -430,10 +430,3 @@ static void __init rcar_gen2_cpg_clocks_init(struct 
device_node *np)
 }
 CLK_OF_DECLARE(rcar_gen2_cpg_clks, "renesas,rcar-gen2-cpg-clocks",
   rcar_gen2_cpg_clocks_init);
-
-void __init rcar_gen2_clocks_init(u32 mode)
-{
-   cpg_mode = mode;
-
-   of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 9e969941f3f62878..9ebf1f8243bb57af 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,8 +20,6 @@ struct device;
 struct device_node;
 struct generic_pm_domain;
 
-void rcar_gen2_clocks_init(u32 mode);
-
 void cpg_mstp_add_clk_domain(struct device_node *np);
 #ifdef CONFIG_CLK_RENESAS_CPG_MSTP
 int cpg_mstp_attach_dev(struct generic_pm_domain *unused, struct device *dev);
-- 
1.9.1

[PATCH/RFC v3 07/22] ARM: dts: r8a7793: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7793.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 9b55c1c6ee31a49d..5a6c9808410761ce 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1264,6 +1264,11 @@
};
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7793-rst";
+   reg = <0 0xe616 0 0x0100>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7793-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH/RFC v3 05/22] ARM: dts: r8a7790: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7790.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 9997e7dfabe2250c..0c548e9b180b6c1d 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1481,6 +1481,11 @@
};
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7790-rst";
+   reg = <0 0xe616 0 0x0100>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7790-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH/RFC v3 08/22] ARM: dts: r8a7794: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7794.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 685f986cf962752f..ce98f358ce731798 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1249,6 +1249,11 @@
};
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7794-rst";
+   reg = <0 0xe616 0 0x0100>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7794-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH/RFC v3 20/22] clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()

[Geert Uytterhoeven]

The R-Car M1A board code no longer calls r8a7778_clocks_init().

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7778.c | 13 -
 include/linux/clk/renesas.h   |  1 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7778.c 
b/drivers/clk/renesas/clk-r8a7778.c
index 07ea411098a75ad1..886a8380e91247a1 100644
--- a/drivers/clk/renesas/clk-r8a7778.c
+++ b/drivers/clk/renesas/clk-r8a7778.c
@@ -143,16 +143,3 @@ static void __init r8a7778_cpg_clocks_init(struct 
device_node *np)
 
 CLK_OF_DECLARE(r8a7778_cpg_clks, "renesas,r8a7778-cpg-clocks",
   r8a7778_cpg_clocks_init);
-
-void __init r8a7778_clocks_init(u32 mode)
-{
-   BUG_ON(!(mode & BIT(19)));
-
-   cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
-(!!(mode & BIT(12)) << 1) |
-(!!(mode & BIT(11)));
-   cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
-   (!!(mode & BIT(1)));
-
-   of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index ba6fa4148515e5c9..2b663bba1adcc7c1 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,7 +20,6 @@ struct device;
 struct device_node;
 struct generic_pm_domain;
 
-void r8a7778_clocks_init(u32 mode);
 void r8a7779_clocks_init(u32 mode);
 void rcar_gen2_clocks_init(u32 mode);
 
-- 
1.9.1

[PATCH/RFC v3 09/22] arm64: renesas: r8a7795 dtsi: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Use "renesas,-rst" instead of "renesas,rst-",
  - Drop "syscon" compatible value,

v2:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 9297658534803f43..fca68d7b047dfa1d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -319,6 +319,11 @@
#power-domain-cells = <0>;
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7795-rst";
+   reg = <0 0xe616 0 0x0200>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7795-sysc";
reg = <0 0xe618 0 0x0400>;
-- 
1.9.1

[PATCH/RFC v3 11/22] clk: renesas: r8a7778: Obtain mode pin values using R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RESET/WDT module.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7778.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/clk/renesas/clk-r8a7778.c 
b/drivers/clk/renesas/clk-r8a7778.c
index 40e3a501a50e200f..07ea411098a75ad1 100644
--- a/drivers/clk/renesas/clk-r8a7778.c
+++ b/drivers/clk/renesas/clk-r8a7778.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct r8a7778_cpg {
struct clk_onecell_data data;
@@ -83,6 +84,18 @@ static void __init r8a7778_cpg_clocks_init(struct 
device_node *np)
struct clk **clks;
unsigned int i;
int num_clks;
+   u32 mode;
+
+   if (rcar_rst_read_mode_pins())
+   return;
+
+   BUG_ON(!(mode & BIT(19)));
+
+   cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
+(!!(mode & BIT(12)) << 1) |
+(!!(mode & BIT(11)));
+   cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
+   (!!(mode & BIT(1)));
 
num_clks = of_property_count_strings(np, "clock-output-names");
if (num_clks < 0) {
-- 
1.9.1

[PATCH/RFC v3 10/22] arm64: renesas: r8a7796 dtsi: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index fab61eddede3818c..cb7cd9dceafe4c40 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -107,6 +107,11 @@
#power-domain-cells = <0>;
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7796-rst";
+   reg = <0 0xe616 0 0x0200>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7796-sysc";
reg = <0 0xe618 0 0x0400>;
-- 
1.9.1

[PATCH/RFC v3 16/22] clk: renesas: rcar-gen3-cpg: Remove obsolete rcar_gen3_read_mode_pins()

[Geert Uytterhoeven]

All R-Car Gen3 clock drivers now obtain the values of the mode pins from
the R-Car RST driver.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/clk/renesas/rcar-gen3-cpg.c | 17 -
 drivers/clk/renesas/rcar-gen3-cpg.h |  1 -
 2 files changed, 18 deletions(-)

diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c 
b/drivers/clk/renesas/rcar-gen3-cpg.c
index bb4f2f9a8c2f5ba8..9d76076da4948fc4 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -333,23 +333,6 @@ struct clk * __init rcar_gen3_cpg_clk_register(struct 
device *dev,
 __clk_get_name(parent), 0, mult, div);
 }
 
-/*
- * Reset register definitions.
- */
-#define MODEMR 0xe6160060
-
-u32 __init rcar_gen3_read_mode_pins(void)
-{
-   void __iomem *modemr = ioremap_nocache(MODEMR, 4);
-   u32 mode;
-
-   BUG_ON(!modemr);
-   mode = ioread32(modemr);
-   iounmap(modemr);
-
-   return mode;
-}
-
 int __init rcar_gen3_cpg_init(const struct rcar_gen3_cpg_pll_config *config,
  unsigned int clk_extalr)
 {
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.h 
b/drivers/clk/renesas/rcar-gen3-cpg.h
index f699085147d1aece..f788f481dd42cdf6 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.h
+++ b/drivers/clk/renesas/rcar-gen3-cpg.h
@@ -33,7 +33,6 @@ struct rcar_gen3_cpg_pll_config {
 
 #define CPG_RCKCR  0x240
 
-u32 rcar_gen3_read_mode_pins(void);
 struct clk *rcar_gen3_cpg_clk_register(struct device *dev,
const struct cpg_core_clk *core, const struct cpg_mssr_info *info,
struct clk **clks, void __iomem *base);
-- 
1.9.1

[PATCH/RFC v3 21/22] clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()

[Geert Uytterhoeven]

The R-Car H1 board code no longer calls r8a7779_clocks_init().

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 -
 include/linux/clk/renesas.h   | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c 
b/drivers/clk/renesas/clk-r8a7779.c
index ca7551bcb1153c3d..27fbfafaf2cd0353 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -89,8 +89,6 @@ static const unsigned int cpg_plla_mult[4] __initconst = { 
42, 48, 56, 64 };
  * Initialization
  */
 
-static u32 cpg_mode __initdata;
-
 static struct clk * __init
 r8a7779_cpg_register_clock(struct device_node *np, struct r8a7779_cpg *cpg,
   const struct cpg_clk_config *config,
@@ -178,10 +176,3 @@ static void __init r8a7779_cpg_clocks_init(struct 
device_node *np)
 }
 CLK_OF_DECLARE(r8a7779_cpg_clks, "renesas,r8a7779-cpg-clocks",
   r8a7779_cpg_clocks_init);
-
-void __init r8a7779_clocks_init(u32 mode)
-{
-   cpg_mode = mode;
-
-   of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 2b663bba1adcc7c1..9e969941f3f62878 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,7 +20,6 @@ struct device;
 struct device_node;
 struct generic_pm_domain;
 
-void r8a7779_clocks_init(u32 mode);
 void rcar_gen2_clocks_init(u32 mode);
 
 void cpg_mstp_add_clk_domain(struct device_node *np);
-- 
1.9.1

[PATCH/RFC v3 02/22] soc: renesas: Add R-Car RST driver

[Geert Uytterhoeven]

Add a driver for the Renesas R-Car Gen1 RESET/WDT and R-Car Gen2/Gen3
RST module.

For now this driver just provides an API to obtain the state of the mode
pins, as latched at reset time.  As this is typically called from the
probe function of a clock driver, which can run much earlier than any
initcall, calling rcar_rst_read_mode_pins() may force an early
initialization of the driver.

Despite the current simple and almost identical handling for all
supported SoCs, the driver matches against SoC-specific compatible
values only, as the features provided by the hardware module differ a
lot across the various SoC families and members.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/soc/renesas/Makefile |  5 ++
 drivers/soc/renesas/rcar-rst.c   | 94 
 include/linux/soc/renesas/rcar-rst.h |  6 +++
 3 files changed, 105 insertions(+)
 create mode 100644 drivers/soc/renesas/rcar-rst.c
 create mode 100644 include/linux/soc/renesas/rcar-rst.h

diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index f32a001c65c3ab44..0d732ff893dd8fba 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,8 @@
+obj-$(CONFIG_ARCH_RCAR_GEN1)   += rcar-rst.o
+obj-$(CONFIG_ARCH_RCAR_GEN2)   += rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7795) += rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7796) += rcar-rst.o
+
 obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
 obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
 obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
new file mode 100644
index ..1997c348c0853254
--- /dev/null
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -0,0 +1,94 @@
+/*
+ * R-Car Gen1 RESET/WDT and R-Car Gen2/Gen3 RST Driver
+ *
+ * Copyright (C) 2016 Glider bvba
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct rst_config {
+   unsigned int modemr;/* Mode Monitoring Register Offset */
+};
+
+static const struct rst_config rcar_rst_gen1 __initconst = {
+   .modemr = 0x20,
+};
+
+static const struct rst_config rcar_rst_gen2 __initconst = {
+   .modemr = 0x60,
+};
+
+static const struct rst_config rcar_rst_gen3 __initconst = {
+   .modemr = 0x60,
+};
+
+static const struct of_device_id rcar_rst_matches[] __initconst = {
+   { .compatible = "renesas,r8a7778-reset-wdt", .data = _rst_gen1 },
+   { .compatible = "renesas,r8a7779-reset-wdt", .data = _rst_gen1 },
+   { .compatible = "renesas,r8a7790-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7791-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7792-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7793-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7794-rst", .data = _rst_gen2 },
+   { .compatible = "renesas,r8a7795-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a7796-rst", .data = _rst_gen3 },
+   { /* sentinel */ }
+};
+
+static void __iomem *rcar_rst_base __initdata;
+static u32 saved_mode __initdata;
+
+static int __init rcar_rst_init(void)
+{
+   const struct of_device_id *match;
+   const struct rst_config *cfg;
+   struct device_node *np;
+   void __iomem *base;
+   int error = 0;
+
+   if (rcar_rst_base)
+   return 0;
+
+   np = of_find_matching_node_and_match(NULL, rcar_rst_matches, );
+   if (!np)
+   return -ENODEV;
+
+   base = of_iomap(np, 0);
+   if (!base) {
+   pr_warn("%s: Cannot map regs\n", np->full_name);
+   error = -ENOMEM;
+   goto out_put;
+   }
+
+   rcar_rst_base = base;
+   cfg = match->data;
+   saved_mode = ioread32(base + cfg->modemr);
+
+   pr_debug("%s: MODE = 0x%08x\n", np->full_name, saved_mode);
+
+out_put:
+   of_node_put(np);
+   return error;
+}
+arch_initcall(rcar_rst_init);
+
+int __init rcar_rst_read_mode_pins(u32 *mode)
+{
+   int error;
+
+   if (!rcar_rst_base) {
+   error = rcar_rst_init();
+   if (error)
+   return error;
+   }
+
+   *mode = saved_mode;
+   return 0;
+}
diff --git a/include/linux/soc/renesas/rcar-rst.h 
b/include/linux/soc/renesas/rcar-rst.h
new file mode 100644
index ..a18e0783946b66ec
--- /dev/null
+++ b/include/linux/soc/renesas/rcar-rst.h
@@ -0,0 +1,6 @@
+#ifndef __LINUX_SOC_RENESAS_RCAR_RST_H__
+#define __LINUX_SOC_RENESAS_RCAR_RST_H__
+
+int rcar_rst_read_mode_pins(u32 *mode);
+
+#endif /* __LINUX_SOC_RENESAS_RCAR_RST_H__ */
-- 
1.9.1

[PATCH/RFC v3 12/22] clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RESET/WDT module.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c 
b/drivers/clk/renesas/clk-r8a7779.c
index cf2a37df03b15e60..ca7551bcb1153c3d 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -127,6 +128,10 @@ static void __init r8a7779_cpg_clocks_init(struct 
device_node *np)
struct clk **clks;
unsigned int i, plla_mult;
int num_clks;
+   u32 mode;
+
+   if (rcar_rst_read_mode_pins())
+   return;
 
num_clks = of_property_count_strings(np, "clock-output-names");
if (num_clks < 0) {
@@ -148,8 +153,8 @@ static void __init r8a7779_cpg_clocks_init(struct 
device_node *np)
cpg->data.clks = clks;
cpg->data.clk_num = num_clks;
 
-   config = _clk_configs[CPG_CLK_CONFIG_INDEX(cpg_mode)];
-   plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(cpg_mode)];
+   config = _clk_configs[CPG_CLK_CONFIG_INDEX(mode)];
+   plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(mode)];
 
for (i = 0; i < num_clks; ++i) {
const char *name;
-- 
1.9.1

[PATCH/RFC v3 17/22] ARM: shmobile: r8a7778: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car M1A CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just remove the .init_time() callback, the
generic ARM code will take care of calling of_clk_init().

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 arch/arm/mach-shmobile/setup-r8a7778.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c 
b/arch/arm/mach-shmobile/setup-r8a7778.c
index cf236db686a9dd47..7fa4a0b5f6549287 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -15,7 +15,6 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include 
 #include 
 
@@ -23,19 +22,6 @@
 
 #include "common.h"
 
-#define MODEMR 0xffcc0020
-
-static void __init r8a7778_timer_init(void)
-{
-   u32 mode;
-   void __iomem *modemr = ioremap_nocache(MODEMR, 4);
-
-   BUG_ON(!modemr);
-   mode = ioread32(modemr);
-   iounmap(modemr);
-   r8a7778_clocks_init(mode);
-}
-
 #define INT2SMSKCR00x82288 /* 0xfe782288 */
 #define INT2SMSKCR10x8228c /* 0xfe78228c */
 
@@ -70,6 +56,5 @@ DT_MACHINE_START(R8A7778_DT, "Generic R8A7778 (Flattened 
Device Tree)")
.init_early = shmobile_init_delay,
.init_irq   = r8a7778_init_irq_dt,
.init_late  = shmobile_init_late,
-   .init_time  = r8a7778_timer_init,
.dt_compat  = r8a7778_compat_dt,
 MACHINE_END
-- 
1.9.1

[PATCH/RFC v3 18/22] ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car H1 CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just remove the .init_time() callback, the
generic ARM code will take care of calling of_clk_init() and
clocksource_probe().

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 arch/arm/mach-shmobile/setup-r8a7779.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c 
b/arch/arm/mach-shmobile/setup-r8a7779.c
index 0007ff51d180379f..0686112f243525b6 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -14,8 +14,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -76,30 +74,6 @@ static void __init r8a7779_init_irq_dt(void)
__raw_writel(0x003fee3f, INT2SMSKCR4);
 }
 
-#define MODEMR 0xffcc0020
-
-static u32 __init r8a7779_read_mode_pins(void)
-{
-   static u32 mode;
-   static bool mode_valid;
-
-   if (!mode_valid) {
-   void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
-   BUG_ON(!modemr);
-   mode = ioread32(modemr);
-   iounmap(modemr);
-   mode_valid = true;
-   }
-
-   return mode;
-}
-
-static void __init r8a7779_init_time(void)
-{
-   r8a7779_clocks_init(r8a7779_read_mode_pins());
-   clocksource_probe();
-}
-
 static const char *const r8a7779_compat_dt[] __initconst = {
"renesas,r8a7779",
NULL,
@@ -109,7 +83,6 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8A7779 (Flattened 
Device Tree)")
.smp= smp_ops(r8a7779_smp_ops),
.map_io = r8a7779_map_io,
.init_early = shmobile_init_delay,
-   .init_time  = r8a7779_init_time,
.init_irq   = r8a7779_init_irq_dt,
.init_late  = shmobile_init_late,
.dt_compat  = r8a7779_compat_dt,
-- 
1.9.1

[PATCH/RFC v3 14/22] clk: renesas: r8a7795: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - New.
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c 
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index e53aff5b23ad4967..e1f2359a59feee7e 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -294,7 +295,12 @@ static const struct rcar_gen3_cpg_pll_config 
cpg_pll_configs[16] __initconst = {
 static int __init r8a7795_cpg_mssr_init(struct device *dev)
 {
const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
-   u32 cpg_mode = rcar_gen3_read_mode_pins();
+   u32 cpg_mode;
+   int error;
+
+   error = rcar_rst_read_mode_pins(_mode);
+   if (error)
+   return error;
 
cpg_pll_config = _pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
if (!cpg_pll_config->extal_div) {
-- 
1.9.1

[PATCH/RFC v3 13/22] clk: renesas: rcar-gen2: Obtain mode pin values using RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Fall back to calling rcar_gen2_read_mode_pins() in the R-Car Gen2
platform code for backward-compatibility with old DTs.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  -  Use the R-Car RST driver instead of syscon/regmap and the
 "renesas,modemr" property in DT,

v2:
  - drivers/clk/shmobile/ was renamed to drivers/clk/renesas/.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c 
b/drivers/clk/renesas/clk-rcar-gen2.c
index 00e6aba4b9c09596..436fc7a7714e4bd7 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct rcar_gen2_cpg {
struct clk_onecell_data data;
@@ -372,6 +373,15 @@ static void __init rcar_gen2_cpg_clocks_init(struct 
device_node *np)
unsigned int i;
int num_clks;
 
+   if (rcar_rst_read_mode_pins(_mode)) {
+   /* Backward-compatibility with old DT */
+   extern u32 rcar_gen2_read_mode_pins(void);
+
+   pr_warn("%s: failed to obtain mode pins from RST\n",
+   np->full_name);
+   cpg_mode = rcar_gen2_read_mode_pins();
+   }
+
num_clks = of_property_count_strings(np, "clock-output-names");
if (num_clks < 0) {
pr_err("%s: failed to count clocks\n", __func__);
-- 
1.9.1

[PATCH net-next] ravb: Remove manual pause frame transmit

[Yoshihiro Kaneko]

From: Masaru Nagai 

Writing a non-zero value to the manual PAUSE frame register (MPR) starts
the transmission of a PAUSE frame.
A PAUSE frame is sent in ravb_emac_init(), but it is not expected behavior.

Signed-off-by: Masaru Nagai 
Signed-off-by: Kazuya Mizuguchi 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is based on the master branch of David Miller's next networking
tree.

 drivers/net/ethernet/renesas/ravb_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 867caf6..37dd068 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -362,8 +362,6 @@ static void ravb_emac_init(struct net_device *ndev)
ravb_write(ndev,
   (ndev->dev_addr[4] << 8)  | (ndev->dev_addr[5]), MALR);
 
-   ravb_write(ndev, 1, MPR);
-
/* E-MAC status register clear */
ravb_write(ndev, ECSR_ICD | ECSR_MPD, ECSR);
 
-- 
1.9.1

Re: [PATCHv7 4/6] arm: dma-mapping: add {map, unmap}_resource for iommu ops

[Russell King - ARM Linux]

On Wed, Jun 01, 2016 at 05:22:27PM +0200, Niklas Söderlund wrote:
> +static dma_addr_t arm_iommu_map_resource(struct device *dev,
> + phys_addr_t phys_addr, size_t size,
> + enum dma_data_direction dir, struct dma_attrs *attrs)
> +{
> + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> + dma_addr_t dma_addr;
> + int ret, prot;
> + phys_addr_t addr = phys_addr & PAGE_MASK;
> + int offset = phys_addr & ~PAGE_MASK;
> + int len = PAGE_ALIGN(size + offset);

Shouldn't both of these be unsigned - preferably size_t for len?

> +
> + dma_addr = __alloc_iova(mapping, size);

Is this really correct?  What if size = 4095 and offset = 10?  Do we
really only need one IOVA page for such a mapping (I count two pages.)
Shouldn't this be "len" ?

> + if (dma_addr == DMA_ERROR_CODE)
> + return dma_addr;
> +
> + prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
> +
> + ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
> + if (ret < 0)
> + goto fail;
> +
> + return dma_addr + offset;
> +fail:
> + __free_iova(mapping, dma_addr, size);

Shouldn't this be "len" as well?

> + return DMA_ERROR_CODE;
> +}
> +
> +/**
> + * arm_iommu_unmap_resource - unmap a device DMA resource
> + * @dev: valid struct device pointer
> + * @dma_handle: DMA address to resource
> + * @size: size of resource to map
> + * @dir: DMA transfer direction
> + */
> +static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t 
> dma_handle,
> + size_t size, enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> + dma_addr_t iova = dma_handle & PAGE_MASK;
> + int offset = dma_handle & ~PAGE_MASK;
> + int len = PAGE_ALIGN(size + offset);

unsigned/size_t again.

> +
> + if (!iova)
> + return;
> +
> + iommu_unmap(mapping->domain, iova, len);
> + __free_iova(mapping, iova, len);

Here, you free "len" bytes of iova, which is different from above.

> +}
> +
>  static void arm_iommu_sync_single_for_cpu(struct device *dev,
>   dma_addr_t handle, size_t size, enum dma_data_direction dir)
>  {
> @@ -1994,6 +2051,9 @@ struct dma_map_ops iommu_ops = {
>   .unmap_sg   = arm_iommu_unmap_sg,
>   .sync_sg_for_cpu= arm_iommu_sync_sg_for_cpu,
>   .sync_sg_for_device = arm_iommu_sync_sg_for_device,
> +
> + .map_resource   = arm_iommu_map_resource,
> + .unmap_resource = arm_iommu_unmap_resource,
>  };
>  
>  struct dma_map_ops iommu_coherent_ops = {
> @@ -2007,6 +2067,9 @@ struct dma_map_ops iommu_coherent_ops = {
>  
>   .map_sg = arm_coherent_iommu_map_sg,
>   .unmap_sg   = arm_coherent_iommu_unmap_sg,
> +
> + .map_resource   = arm_iommu_map_resource,
> + .unmap_resource = arm_iommu_unmap_resource,
>  };
>  
>  /**
> -- 
> 2.8.2
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCHv7 5/6] dmaengine: rcar-dmac: group slave configuration

[Niklas Söderlund]

Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/dma/sh/rcar-dmac.c | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index dfb1792..b0c3bb2 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -118,14 +118,22 @@ struct rcar_dmac_desc_page {
sizeof(struct rcar_dmac_xfer_chunk))
 
 /*
+ * struct rcar_dmac_chan_slave - Slave configuration
+ * @slave_addr: slave memory address
+ * @xfer_size: size (in bytes) of hardware transfers
+ */
+struct rcar_dmac_chan_slave {
+   phys_addr_t slave_addr;
+   unsigned int xfer_size;
+};
+
+/*
  * struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
  * @chan: base DMA channel object
  * @iomem: channel I/O memory base
  * @index: index of this channel in the controller
- * @src_xfer_size: size (in bytes) of hardware transfers on the source side
- * @dst_xfer_size: size (in bytes) of hardware transfers on the destination 
side
- * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
  * @mid_rid: hardware MID/RID for the DMA client using this channel
  * @lock: protects the channel CHCR register and the desc members
  * @desc.free: list of free descriptors
@@ -142,10 +150,8 @@ struct rcar_dmac_chan {
void __iomem *iomem;
unsigned int index;
 
-   unsigned int src_xfer_size;
-   unsigned int dst_xfer_size;
-   dma_addr_t src_slave_addr;
-   dma_addr_t dst_slave_addr;
+   struct rcar_dmac_chan_slave src;
+   struct rcar_dmac_chan_slave dst;
int mid_rid;
 
spinlock_t lock;
@@ -793,13 +799,13 @@ static void rcar_dmac_chan_configure_desc(struct 
rcar_dmac_chan *chan,
case DMA_DEV_TO_MEM:
chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
 | RCAR_DMACHCR_RS_DMARS;
-   xfer_size = chan->src_xfer_size;
+   xfer_size = chan->src.xfer_size;
break;
 
case DMA_MEM_TO_DEV:
chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
 | RCAR_DMACHCR_RS_DMARS;
-   xfer_size = chan->dst_xfer_size;
+   xfer_size = chan->dst.xfer_size;
break;
 
case DMA_MEM_TO_MEM:
@@ -1038,7 +1044,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct 
scatterlist *sgl,
}
 
dev_addr = dir == DMA_DEV_TO_MEM
-? rchan->src_slave_addr : rchan->dst_slave_addr;
+? rchan->src.slave_addr : rchan->dst.slave_addr;
return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
  dir, flags, false);
 }
@@ -1093,7 +1099,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, 
dma_addr_t buf_addr,
}
 
dev_addr = dir == DMA_DEV_TO_MEM
-? rchan->src_slave_addr : rchan->dst_slave_addr;
+? rchan->src.slave_addr : rchan->dst.slave_addr;
desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
  dir, flags, true);
 
@@ -1110,10 +1116,10 @@ static int rcar_dmac_device_config(struct dma_chan 
*chan,
 * We could lock this, but you shouldn't be configuring the
 * channel, while using it...
 */
-   rchan->src_slave_addr = cfg->src_addr;
-   rchan->dst_slave_addr = cfg->dst_addr;
-   rchan->src_xfer_size = cfg->src_addr_width;
-   rchan->dst_xfer_size = cfg->dst_addr_width;
+   rchan->src.slave_addr = cfg->src_addr;
+   rchan->dst.slave_addr = cfg->dst_addr;
+   rchan->src.xfer_size = cfg->src_addr_width;
+   rchan->dst.xfer_size = cfg->dst_addr_width;
 
return 0;
 }
-- 
2.8.2

[PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Niklas Söderlund]

Hi,

[In this v7 series I have tried to address the questions raised by Christoph 
Hellwig and I hope it can awnser your concernes regarding dma-debug.]

This series tries to solve the problem with DMA with device registers
(MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
recent patch '9575632 (dmaengine: make slave address physical)'
clarifies that DMA slave address provided by clients is the physical
address. This puts the task of mapping the DMA slave address from a
phys_addr_t to a dma_addr_t on the DMA engine.

Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
the same and no special care is needed. However if you have a IOMMU you
need to map the DMA slave phys_addr_t to a dma_addr_t using something
like this.

This series is based on top of v4.7-rc1.

It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
/dev/mmcblk1, i2c and the serial console which are devices behind the
iommu.

Furthermore I have audited to the best of my ability all call paths
involved to make sure that the dma_addr_t obtained from
dma_map_resource() to is not used in a way where it would be expected
for the mapping to be RAM (have a struct page). Many thanks to Christoph
Hellwig and Laurent Pinchart for there input in this effort.

  * drivers/dma/sh/rcar-dmac.c
Once the phys_addr_t is mapped to a dma_addr_t using
dma_map_resource() it is only used to check that the transferee do not
cross 4GB boundaries and then only directly written to HW registers.

  * drivers/iommu/iommu.c
- iommu_map()
  Check that it's align to min page size or return -EINVAL then calls
  domain->ops->map()

  * drivers/iommu/ipmmu-vmsa.c
- ipmmu_map()
  No logic only calls domain->ops->map()

  * drivers/iommu/io-pgtable-arm.c
- arm_lpae_map()
  No logic only calls __arm_lpae_map()
- __arm_lpae_map()
  No logic only calls arm_lpae_init_pte()
- arm_lpae_init_pte()
  Used to get a pte:
pte |= pfn_to_iopte(paddr >> data->pg_shift, data);

  * drivers/iommu/io-pgtable-arm-v7s.c
- arm_v7s_map()
  No logic only calls __arm_v7s_map()
- __arm_v7s_map()
  No logic only calls arm_v7s_init_pte()
- arm_v7s_init_pte
  Used to get a pte:
pte |= paddr & ARM_V7S_LVL_MASK(lvl);

  * ARM dma-mapping
- dma_unmap_*
  Only valid unmap is dma_unmap_resource() all others are an invalid
  use case.
- dma_sync_single_*
  Invalid use case, memory that is mapped is device memory
- dma_common_mmap() and dma_mmap_attrs()
  Invalid use case
- dma_common_get_sgtable() and dma_get_sgtable_attrs()
  Invalid use case, only for dma_alloc_* allocated memory,
- dma_mapping_error()
  OK

* Changes since v6
- Use offset_in_page() and __pfn_to_phys(). This fixed a bug in the 
  lib/dma-debug.c. Thanks to Konrad Rzeszutek Wilk for finding it and Robin 
  Murphy for suggesting offset_in_page().
- Rebased on top of v4.7-rc1.
- Dropped DT patches which enabled the IPMMU on Renesas Koelsch and Lager. Will 
  post them separately at a later time.

* Changes since v5
- Add dma-debug work which adds a new mapping type for the resource
  mapping which correctly can be translated to a physical address.
- Drop patches from Robin Murphy since they now are accepted in the
  iommu repository and base the series on that tree instead.
- Add a review tag from Laurent.

* Changes since v4
- Move the mapping from phys_addr_t to dma_addr_t from slave_config to the
  prepare calls. This way we know the direction of the mapping and don't have
  to use DMA_BIDIRECTIONAL. Thanks Vinod for suggesting this.
- To be clear that the data type for slave addresses are changed add a patch
  that only changes the data type to phys_addr_t.
- Fixed up commit messages.

* Changes since v3
- Folded in a fix from Robin to his patch.
- Added a check to make sure dma_map_resource can not be used to map RAM as
  pointed out by Robin. I use BUG_ON to enforce this. It might not be the best
  method but I saw no other good way since DMA_ERROR_CODE might not be defined
  on all platforms.
- Added comment about that DTS changes will disable 2 DMA channels due to a HW
  (?) but in the DMAC.
- Dropped the use of dma_attrs, no longer needed.
- Collected Acked-by and Reviewed-by from Laurent.
- Various indentation fix ups.

* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
  'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
  since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
  attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
  inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we 

[PATCHv7 4/6] arm: dma-mapping: add {map,unmap}_resource for iommu ops

[Niklas Söderlund]

Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 arch/arm/mm/dma-mapping.c | 63 +++
 1 file changed, 63 insertions(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ff7ed56..8f12ec8 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1951,6 +1951,63 @@ static void arm_iommu_unmap_page(struct device *dev, 
dma_addr_t handle,
__free_iova(mapping, iova, len);
 }
 
+/**
+ * arm_iommu_map_resource - map a device resource for DMA
+ * @dev: valid struct device pointer
+ * @phys_addr: physical address of resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static dma_addr_t arm_iommu_map_resource(struct device *dev,
+   phys_addr_t phys_addr, size_t size,
+   enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+   struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+   dma_addr_t dma_addr;
+   int ret, prot;
+   phys_addr_t addr = phys_addr & PAGE_MASK;
+   int offset = phys_addr & ~PAGE_MASK;
+   int len = PAGE_ALIGN(size + offset);
+
+   dma_addr = __alloc_iova(mapping, size);
+   if (dma_addr == DMA_ERROR_CODE)
+   return dma_addr;
+
+   prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+
+   ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
+   if (ret < 0)
+   goto fail;
+
+   return dma_addr + offset;
+fail:
+   __free_iova(mapping, dma_addr, size);
+   return DMA_ERROR_CODE;
+}
+
+/**
+ * arm_iommu_unmap_resource - unmap a device DMA resource
+ * @dev: valid struct device pointer
+ * @dma_handle: DMA address to resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+   size_t size, enum dma_data_direction dir,
+   struct dma_attrs *attrs)
+{
+   struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+   dma_addr_t iova = dma_handle & PAGE_MASK;
+   int offset = dma_handle & ~PAGE_MASK;
+   int len = PAGE_ALIGN(size + offset);
+
+   if (!iova)
+   return;
+
+   iommu_unmap(mapping->domain, iova, len);
+   __free_iova(mapping, iova, len);
+}
+
 static void arm_iommu_sync_single_for_cpu(struct device *dev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
@@ -1994,6 +2051,9 @@ struct dma_map_ops iommu_ops = {
.unmap_sg   = arm_iommu_unmap_sg,
.sync_sg_for_cpu= arm_iommu_sync_sg_for_cpu,
.sync_sg_for_device = arm_iommu_sync_sg_for_device,
+
+   .map_resource   = arm_iommu_map_resource,
+   .unmap_resource = arm_iommu_unmap_resource,
 };
 
 struct dma_map_ops iommu_coherent_ops = {
@@ -2007,6 +2067,9 @@ struct dma_map_ops iommu_coherent_ops = {
 
.map_sg = arm_coherent_iommu_map_sg,
.unmap_sg   = arm_coherent_iommu_unmap_sg,
+
+   .map_resource   = arm_iommu_map_resource,
+   .unmap_resource = arm_iommu_unmap_resource,
 };
 
 /**
-- 
2.8.2

[PATCHv7 1/6] dma-mapping: add {map,unmap}_resource to dma_map_ops

[Niklas Söderlund]

Add methods to handle mapping of device resources from a physical
address. This is needed for example to be able to map MMIO FIFO
registers to a IOMMU.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 include/linux/dma-mapping.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c980a92..a11ff9d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -49,6 +49,12 @@ struct dma_map_ops {
 struct scatterlist *sg, int nents,
 enum dma_data_direction dir,
 struct dma_attrs *attrs);
+   dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
+  size_t size, enum dma_data_direction dir,
+  struct dma_attrs *attrs);
+   void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
+  size_t size, enum dma_data_direction dir,
+  struct dma_attrs *attrs);
void (*sync_single_for_cpu)(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction dir);
-- 
2.8.2

[PATCHv7 2/6] dma-debug: add support for resource mappings

[Niklas Söderlund]

A MMIO mapped resource can not be represented by a struct page so a new
debug type is needed to handle this. This patch add such type and
functionality to add/remove entries and how to translate them to a
physical address.

Signed-off-by: Niklas Söderlund 
---
 include/linux/dma-debug.h | 19 +
 lib/dma-debug.c   | 52 +--
 2 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/include/linux/dma-debug.h b/include/linux/dma-debug.h
index fe8cb61..c7d844f 100644
--- a/include/linux/dma-debug.h
+++ b/include/linux/dma-debug.h
@@ -56,6 +56,13 @@ extern void debug_dma_alloc_coherent(struct device *dev, 
size_t size,
 extern void debug_dma_free_coherent(struct device *dev, size_t size,
void *virt, dma_addr_t addr);
 
+extern void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+  size_t size, int direction,
+  dma_addr_t dma_addr);
+
+extern void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+size_t size, int direction);
+
 extern void debug_dma_sync_single_for_cpu(struct device *dev,
  dma_addr_t dma_handle, size_t size,
  int direction);
@@ -141,6 +148,18 @@ static inline void debug_dma_free_coherent(struct device 
*dev, size_t size,
 {
 }
 
+static inline void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+ size_t size, int direction,
+ dma_addr_t dma_addr)
+{
+}
+
+static inline void debug_dma_unmap_resource(struct device *dev,
+   dma_addr_t dma_addr, size_t size,
+   int direction)
+{
+}
+
 static inline void debug_dma_sync_single_for_cpu(struct device *dev,
 dma_addr_t dma_handle,
 size_t size, int direction)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 51a76af..ce75fba 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -43,6 +43,7 @@ enum {
dma_debug_page,
dma_debug_sg,
dma_debug_coherent,
+   dma_debug_resource,
 };
 
 enum map_err_types {
@@ -150,8 +151,9 @@ static const char *const maperr2str[] = {
[MAP_ERR_CHECKED] = "dma map error checked",
 };
 
-static const char *type2name[4] = { "single", "page",
-   "scather-gather", "coherent" };
+static const char *type2name[5] = { "single", "page",
+   "scather-gather", "coherent",
+   "resource" };
 
 static const char *dir2name[4] = { "DMA_BIDIRECTIONAL", "DMA_TO_DEVICE",
   "DMA_FROM_DEVICE", "DMA_NONE" };
@@ -397,6 +399,9 @@ static void hash_bucket_del(struct dma_debug_entry *entry)
 
 static unsigned long long phys_addr(struct dma_debug_entry *entry)
 {
+   if (entry->type == dma_debug_resource)
+   return __pfn_to_phys(entry->pfn) + entry->offset;
+
return page_to_phys(pfn_to_page(entry->pfn)) + entry->offset;
 }
 
@@ -1493,6 +1498,49 @@ void debug_dma_free_coherent(struct device *dev, size_t 
size,
 }
 EXPORT_SYMBOL(debug_dma_free_coherent);
 
+void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
+   int direction, dma_addr_t dma_addr)
+{
+   struct dma_debug_entry *entry;
+
+   if (unlikely(dma_debug_disabled()))
+   return;
+
+   entry = dma_entry_alloc();
+   if (!entry)
+   return;
+
+   entry->type = dma_debug_resource;
+   entry->dev  = dev;
+   entry->pfn  = __phys_to_pfn(addr);
+   entry->offset   = offset_in_page(addr);
+   entry->size = size;
+   entry->dev_addr = dma_addr;
+   entry->direction= direction;
+   entry->map_err_type = MAP_ERR_NOT_CHECKED;
+
+   add_dma_entry(entry);
+}
+EXPORT_SYMBOL(debug_dma_map_resource);
+
+void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+ size_t size, int direction)
+{
+   struct dma_debug_entry ref = {
+   .type   = dma_debug_resource,
+   .dev= dev,
+   .dev_addr   = dma_addr,
+   .size   = size,
+   .direction  = direction,
+   };
+
+   if (unlikely(dma_debug_disabled()))
+   return;
+
+   check_unmap();
+}
+EXPORT_SYMBOL(debug_dma_unmap_resource);
+
 void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
   size_t size, int direction)
 {
-- 
2.8.2

[PATCHv7 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Niklas Söderlund]

Enable slave transfers to a device behind a IPMMU by mapping the slave
addresses using the dma-mapping API.

Signed-off-by: Niklas Söderlund 
---
 drivers/dma/sh/rcar-dmac.c | 82 +-
 1 file changed, 74 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index b0c3bb2..8592598 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -128,6 +128,18 @@ struct rcar_dmac_chan_slave {
 };
 
 /*
+ * struct rcar_dmac_chan_map - Map of slave device phys to dma address
+ * @addr: slave dma address
+ * @dir: direction of mapping
+ * @slave: slave configuration that is mapped
+ */
+struct rcar_dmac_chan_map {
+   dma_addr_t addr;
+   enum dma_data_direction dir;
+   struct rcar_dmac_chan_slave slave;
+};
+
+/*
  * struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
  * @chan: base DMA channel object
  * @iomem: channel I/O memory base
@@ -152,6 +164,7 @@ struct rcar_dmac_chan {
 
struct rcar_dmac_chan_slave src;
struct rcar_dmac_chan_slave dst;
+   struct rcar_dmac_chan_map map;
int mid_rid;
 
spinlock_t lock;
@@ -1027,13 +1040,65 @@ rcar_dmac_prep_dma_memcpy(struct dma_chan *chan, 
dma_addr_t dma_dest,
  DMA_MEM_TO_MEM, flags, false);
 }
 
+static int rcar_dmac_map_slave_addr(struct dma_chan *chan,
+   enum dma_transfer_direction dir)
+{
+   struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+   struct rcar_dmac_chan_map *map = >map;
+   phys_addr_t dev_addr;
+   size_t dev_size;
+   enum dma_data_direction dev_dir;
+
+   if (dir == DMA_DEV_TO_MEM) {
+   dev_addr = rchan->src.slave_addr;
+   dev_size = rchan->src.xfer_size;
+   dev_dir = DMA_TO_DEVICE;
+   } else {
+   dev_addr = rchan->dst.slave_addr;
+   dev_size = rchan->dst.xfer_size;
+   dev_dir = DMA_FROM_DEVICE;
+   }
+
+   /* Reuse current map if possible. */
+   if (dev_addr == map->slave.slave_addr &&
+   dev_size == map->slave.xfer_size &&
+   dev_dir == map->dir)
+   return 0;
+
+   /* Remove old mapping if present. */
+   if (map->slave.xfer_size)
+   dma_unmap_resource(chan->device->dev, map->addr,
+  map->slave.xfer_size, map->dir, NULL);
+   map->slave.xfer_size = 0;
+
+   /* Create new slave address map. */
+   map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
+dev_dir, NULL);
+
+   if (dma_mapping_error(chan->device->dev, map->addr)) {
+   dev_err(chan->device->dev,
+   "chan%u: failed to map %zx@%pap", rchan->index,
+   dev_size, _addr);
+   return -EIO;
+   }
+
+   dev_dbg(chan->device->dev, "chan%u: map %zx@%pap to %pad dir: %s\n",
+   rchan->index, dev_size, _addr, >addr,
+   dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : "DMA_FROM_DEVICE");
+
+   map->slave.slave_addr = dev_addr;
+   map->slave.xfer_size = dev_size;
+   map->dir = dev_dir;
+
+   return 0;
+}
+
 static struct dma_async_tx_descriptor *
 rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction dir,
unsigned long flags, void *context)
 {
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
-   dma_addr_t dev_addr;
 
/* Someone calling slave DMA on a generic channel? */
if (rchan->mid_rid < 0 || !sg_len) {
@@ -1043,9 +1108,10 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct 
scatterlist *sgl,
return NULL;
}
 
-   dev_addr = dir == DMA_DEV_TO_MEM
-? rchan->src.slave_addr : rchan->dst.slave_addr;
-   return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
+   if (rcar_dmac_map_slave_addr(chan, dir))
+   return NULL;
+
+   return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
  dir, flags, false);
 }
 
@@ -1059,7 +1125,6 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, 
dma_addr_t buf_addr,
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
struct dma_async_tx_descriptor *desc;
struct scatterlist *sgl;
-   dma_addr_t dev_addr;
unsigned int sg_len;
unsigned int i;
 
@@ -1071,6 +1136,9 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, 
dma_addr_t buf_addr,
return NULL;
}
 
+   if (rcar_dmac_map_slave_addr(chan, dir))
+   return NULL;
+
sg_len = buf_len / period_len;
if (sg_len > RCAR_DMAC_MAX_SG_LEN) {
dev_err(chan->device->dev,
@@ -1098,9 +1166,7 @@ 

[PATCHv7 3/6] dma-mapping: add dma_{map,unmap}_resource

[Niklas Söderlund]

Map/Unmap a device MMIO resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.

Signed-off-by: Niklas Söderlund 
---
 Documentation/DMA-API.txt   | 22 +-
 include/linux/dma-mapping.h | 36 
 2 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 45ef3f2..c7e5f99 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -277,14 +277,26 @@ and  parameters are provided to do partial page 
mapping, it is
 recommended that you never use these unless you really know what the
 cache width is.
 
+dma_addr_t
+dma_map_resource(struct device *dev, phys_addr_t phys_addr, size_t size,
+enum dma_data_direction dir, struct dma_attrs *attrs)
+
+void
+dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size,
+  enum dma_data_direction dir, struct dma_attrs *attrs)
+
+API for mapping and unmapping for MMIO resources. All the notes and
+warnings for the other mapping APIs apply here. The API should only be
+used to map device MMIO resources, mapping of RAM is not permitted.
+
 int
 dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
 
-In some circumstances dma_map_single() and dma_map_page() will fail to create
-a mapping. A driver can check for these errors by testing the returned
-DMA address with dma_mapping_error(). A non-zero return value means the mapping
-could not be created and the driver should take appropriate action (e.g.
-reduce current DMA mapping usage or delay and try again later).
+In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
+will fail to create a mapping. A driver can check for these errors by testing
+the returned DMA address with dma_mapping_error(). A non-zero return value
+means the mapping could not be created and the driver should take appropriate
+action (e.g. reduce current DMA mapping usage or delay and try again later).
 
int
dma_map_sg(struct device *dev, struct scatterlist *sg,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index a11ff9d..4c381ba 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -218,6 +218,42 @@ static inline void dma_unmap_page(struct device *dev, 
dma_addr_t addr,
debug_dma_unmap_page(dev, addr, size, dir, false);
 }
 
+static inline dma_addr_t dma_map_resource(struct device *dev,
+ phys_addr_t phys_addr,
+ size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+   struct dma_map_ops *ops = get_dma_ops(dev);
+   unsigned long pfn = __phys_to_pfn(phys_addr);
+   dma_addr_t addr;
+
+   BUG_ON(!valid_dma_direction(dir));
+
+   /* Don't allow RAM to be mapped */
+   BUG_ON(pfn_valid(pfn));
+
+   addr = phys_addr;
+   if (ops->map_resource)
+   addr = ops->map_resource(dev, phys_addr, size, dir, attrs);
+
+   debug_dma_map_resource(dev, phys_addr, size, dir, addr);
+
+   return addr;
+}
+
+static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+   struct dma_map_ops *ops = get_dma_ops(dev);
+
+   BUG_ON(!valid_dma_direction(dir));
+   if (ops->unmap_resource)
+   ops->unmap_resource(dev, addr, size, dir, attrs);
+   debug_dma_unmap_resource(dev, addr, size, dir);
+}
+
 static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
   size_t size,
   enum dma_data_direction dir)
-- 
2.8.2

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

On 06/01/2016 10:22 AM, Geert Uytterhoeven wrote:


Add macros usable by the device tree sources to reference the R8A7792
clocks  by index.

Signed-off-by: Sergei Shtylyov 

---
 include/dt-bindings/clock/r8a7792-clock.h |  104 ++
 1 file changed, 104 insertions(+)

Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
===
--- /dev/null
+++ renesas/include/dt-bindings/clock/r8a7792-clock.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
+#define __DT_BINDINGS_CLOCK_R8A7792_H__
+
+/* CPG */
+#define R8A7792_CLK_MAIN   0
+#define R8A7792_CLK_PLL0   1
+#define R8A7792_CLK_PLL1   2
+#define R8A7792_CLK_PLL3   3
+#define R8A7792_CLK_LB 4
+#define R8A7792_CLK_QSPI   5
+#define R8A7792_CLK_SDH6
+#define R8A7792_CLK_SD07
+#define R8A7792_CLK_SD18


As Simon already pointed out, there are no ...SD* clocks on V2H.


   Right, looks like I shouldn't have trusted the original patch... :-/


+#define R8A7792_CLK_Z  9



+/* MSTP1 */
+#define R8A7792_CLK_TMU1   11
+#define R8A7792_CLK_TMU3   21
+#define R8A7792_CLK_TMU2   22
+#define R8A7792_CLK_CMT0   24
+#define R8A7792_CLK_TMU0   25
+#define R8A7792_CLK_VSP1DU127
+#define R8A7792_CLK_VSP1DU028
+#define R8A7792_CLK_VSP1_SY31


These are called ...VSP1_DU1, ...VSP1_DU0, and ...VSP1_S on all other
R-Car Gen2 SoCs.


   My naming comes from the 1.02 manual.


+/* MSTP2 */
+#define R8A7792_CLK_MSIOF1 8
+#define R8A7792_CLK_SYS_DMAC0  18


This is ...SYS_DMAC1


+#define R8A7792_CLK_SYS_DMAC1  19


... and this is ...SYS_DMAC0


   Thanks for catching!


+/* MSTP9 */
+#define R8A7792_CLK_GPIO7  4
+#define R8A7792_CLK_GPIO6  5
+#define R8A7792_CLK_GPIO5  7
+#define R8A7792_CLK_GPIO4  8
+#define R8A7792_CLK_GPIO3  9
+#define R8A7792_CLK_GPIO2  10
+#define R8A7792_CLK_GPIO1  11
+#define R8A7792_CLK_GPIO0  12
+#define R8A7792_CLK_GPIO11 13
+#define R8A7792_CLK_GPIO10 14
+#define R8A7792_CLK_CAN1   15
+#define R8A7792_CLK_CAN0   16


These are called ...RCAN1 and ...RCAR0 on all other R-Car Gen2 SoCs.


   Not in the 1.02 manual (they were called RCAN in some of the earlier 
manual revs). Dunno if it makes sense to rename them in the other .dts now...



Gr{oetje,eeting}s,

Geert


WBR, Sergei

Re: [PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Sergei Shtylyov]

On 06/01/2016 04:18 AM, Simon Horman wrote:


Describe the IRQC interrupt controller in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792.dtsi |   13 +
 1 file changed, 13 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -62,6 +62,19 @@
  IRQ_TYPE_LEVEL_HIGH)>;
};

+   irqc: interrupt-controller@e61c {


Could you consider using irqc0 as the node name for consistency with the
DT of other R-Car Gen2 SoCs?


   Frankly speaking I didn't get that name indexing thing at all. Could you 
share the reasoning behind it?



What follows looks correct to me.


   Thank you. :-)

MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/01/2016 03:57 AM, Simon Horman wrote:


The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
and the required  clock descriptions.

Signed-off-by: Sergei Shtylyov 


This is rather large for an initial DTSI. Did you give any consideration
to splitting it up: e.g. only providing what is needed to get to a serial
console?


   You mean dropping the majority of clocks, right?


With regards to SMP. Have you checked to make sure CPU hotplug works
on all CPUs? And that the system behaves sanely on suspend/resume.
If it is not possible to verify this at this stage then I would recommend
only enabling one CPU at this stage.


   No, the SMP support isn't ready yet.
   And I'll have to enable SMP on R8A7794 as well...

MBR, Sergei

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

On 06/01/2016 03:52 AM, Simon Horman wrote:


Add macros usable by the device tree sources to reference the R8A7792
clocks  by index.

Signed-off-by: Sergei Shtylyov 

---
 include/dt-bindings/clock/r8a7792-clock.h |  104 ++
 1 file changed, 104 insertions(+)

Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
===
--- /dev/null
+++ renesas/include/dt-bindings/clock/r8a7792-clock.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
+#define __DT_BINDINGS_CLOCK_R8A7792_H__
+
+/* CPG */
+#define R8A7792_CLK_MAIN   0
+#define R8A7792_CLK_PLL0   1
+#define R8A7792_CLK_PLL1   2
+#define R8A7792_CLK_PLL3   3
+#define R8A7792_CLK_LB 4
+#define R8A7792_CLK_QSPI   5
+#define R8A7792_CLK_SDH6
+#define R8A7792_CLK_SD07
+#define R8A7792_CLK_SD18
+#define R8A7792_CLK_Z  9


According to my copy of the documentation (v2.00) SDH, SD0 and SD1 do
not seem to be provided by the r8a7792 CPG.


   Right, should have checked the original patch against the manual in that 
part as well... :-/



It does, however, provide RCAN and ADSP which are supported by the CPG
driver. You may wish to add them now for completeness though from my point
of view they could also be added later when they are used.


   Hm, the gen2 manual rev1.02 doesn't mention either of these clocks for V2H...
I still don't have 2.00. :-(


I reviewed the values below. They appear to be complete and correct.


   Geert has found some bug there. :-)

MBR, Sergei

Re: [PATCH 11/13] DT: arm: shmobile: document Blanche board

[Sergei Shtylyov]

Hello.

On 06/01/2016 02:51 AM, Simon Horman wrote:


Document the Blanche device tree bindings, listing it as a supported board.

This allows to use checkpatch.pl to validate .dts files referring to the
Blanche board.

Signed-off-by: Sergei Shtylyov 


I think the prefix for patch 11 should be: "ARM: dts: blanche: "


Hm... why?


It also looks like it could be squashed into patch 12 but I don't
feel strongly about that.


   I'd prefer not to merge them.

[...]

MBR, Sergei

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 2:16 PM, Sergei Shtylyov
 wrote:
> On 6/1/2016 11:22 AM, Geert Uytterhoeven wrote:
>>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>>
>>> +   ethernet@1800 {
>>> +   compatible = "smsc,lan89218", "smsc,lan9115";
>>
>>
>> The "smsc,lan89218" needs to be documented in the device tree bindings.
>
>Have you looked at those bindings?

Now I did.

>> Google couldn't find any evidence you submitted a patch for that.
>
>Because the bindings document *any* LAN9115 compatible chip already.

Ah, generic wildcard, not listing valid values. Hence checkpatch complained...

Google predict-while-you-type suggests "lan89218aq"? Should you use that?
BTW, that's why we always want to document all valid values...

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 13/13] ARM: dts: blanche: add Ethernet support

[Sergei Shtylyov]

Hello.

On 6/1/2016 11:22 AM, Geert Uytterhoeven wrote:


--- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts



+   ethernet@1800 {
+   compatible = "smsc,lan89218", "smsc,lan9115";


The "smsc,lan89218" needs to be documented in the device tree bindings.


   Have you looked at those bindings?


Google couldn't find any evidence you submitted a patch for that.


   Because the bindings document *any* LAN9115 compatible chip already.


Gr{oetje,eeting}s,

Geert


MBR, Sergei

Re: [PATCH v2 0/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Mathias Nyman]

isn't the following enough?

@@ -4886,7 +4886,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t 
get_quirks)
xhci->hcc_params2 = readl(>cap_regs->hcc_params2);
xhci_print_registers(xhci);

-   xhci->quirks = quirks;
+   xhci->quirks |= quirks;

get_quirks(dev, xhci);


Thank you for the comment!
You're correct. This also can resolve the issue.
Do you prefer such a simple patch?
At least, I prefer such a simple patch :)


I'll defer that to Mathias :-)



I think that xhci->quirks |= quirks will do as a rc fix.

looks like setting xhci->quirks need some generic cleanup for usb-next.
Now in 4.7-rc1 we set xhci->quirks before xhci_gen_setup in 
xhci_priv_init_quirk(),
and during xhci_gen_setup() when copying module parameters quirk, and when 
calling
the get_quirk() callback.

There is nothing special happening between xhci_priv_init_quirk and when calling
get_quirks() in xhci_gen_setup() that need quirks to be set in two stages.

xhci pci drivers only use the get_quirk callback, platform drivers use both.

Looks like the get_quirk() callback is a legacy thing from when the memory for
the xhci struct was allocated in xhci_gen_setup, and xhci->quirks could only be
set after that.

Now xhci struct is part of the usb_hcd, so we could probably get rid of the 
get_quirk
callback alltogether by setting the pci quirks in xhci_pci_setup

-Mathias  

Re: [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Sergei Shtylyov]

Hello.

On 6/1/2016 10:04 AM, Geert Uytterhoeven wrote:


   Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
week separately...

[01/13] ARM: shmobile: r8a7792: add clock index macros
[02/13] ARM: shmobile: r8a7792: add power domain index macros
[03/13] soc: renesas: rcar-sysc: add R8A7792 support
[04/13] ARM: shmobile: r8a7792: basic SoC support
[05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
[06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
[07/13] ARM: dts: r8a7792: initial SoC device tree
[08/13] ARM: dts: r8a7792: add SYS-DMAC support
[09/13] ARM: dts: r8a7792: add [H]SCIF support
[10/13] ARM dts: r8a7792: add IRQC support
[11/13] DT: arm: shmobile: document Blanche board
[12/13] ARM: dts: blanche: initial device tree
[13/13] ARM: dts: blanche: add Ethernet support


Thanks for your series!

The subject doesn't seem to cover the contents, though:

[PATCH 00/13] Add R8A7794/SILK board eMMC DT support


   Oops. :-(
   Sorry about that...


Gr{oetje,eeting}s,

Geert


MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:24 AM, Sergei Shtylyov
 wrote:
> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
> and the required  clock descriptions.
>
> Signed-off-by: Sergei Shtylyov 
>
> ---
>  arch/arm/boot/dts/r8a7792.dtsi |  423 
> +
>  1 file changed, 423 insertions(+)
>
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===
> --- /dev/null
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -0,0 +1,423 @@
> +/*
> + * Device Tree Source for the r8a7792 SoC
> + *
> + * Copyright (C) 2016 Cogent Embedded Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include 
> +#include 

#include  is included
implicitly by the above.

> +#include 
> +
> +/ {
> +   compatible = "renesas,r8a7792";
> +   interrupt-parent = <>;
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   cpu0: cpu@0 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0>;
> +   clock-frequency = <10>;
> +   clocks = <_clocks R8A7792_CLK_Z>;
> +   power-domains = < R8A7792_PD_CA15_CPU0>;
> +   next-level-cache = <_CA15>;
> +   };
> +
> +   cpu1: cpu@1 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <1>;
> +   clock-frequency = <10>;
> +   power-domains = < R8A7792_PD_CA15_CPU1>;
> +   next-level-cache = <_CA15>;
> +   };
> +
> +   L2_CA15: cache-controller@0 {
> +   compatible = "cache";
> +   reg = <0>;
> +   cache-unified;
> +   cache-level = <2>;
> +   power-domains = < R8A7792_PD_CA15_SCU>;
> +   };
> +   };
> +
> +   gic: interrupt-controller@f1001000 {

It would be good to group all on-SoC devices under an "soc" node, like we
started doing for r8a7795.

> +   clocks {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   ranges;
> +
> +   /* External root clock */
> +   extal_clk: extal {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   /* This value must be overridden by the board. */
> +   clock-frequency = <0>;
> +   };

The fixed clocks should be at the root level these days.

> +   /* Special CPG clocks */
> +   cpg_clocks: cpg_clocks@e615 {
> +   compatible = "renesas,r8a7792-cpg-clocks",
> +"renesas,rcar-gen2-cpg-clocks";
> +   reg = <0 0xe615 0 0x1000>;
> +   clocks = <_clk>;
> +   #clock-cells = <1>;
> +   clock-output-names = "main", "pll0", "pll1", "pll3",
> +"lb", "qspi", "sdh", "sd0", 
> "sd1",
> +"z";

"sdh", "sd0", and "sd1" do not exist. Please remove them.

> +   z2_clk: z2 {
> +   compatible = "fixed-factor-clock";
> +   clocks = <_clocks R8A7792_CLK_PLL1>;
> +   #clock-cells = <0>;
> +   clock-div = <2>;
> +   clock-mult = <1>;
> +   };

V2H doesn't have Z2.

> +   i_clk: i {
> +   compatible = "fixed-factor-clock";
> +   clocks = <_clocks R8A7792_CLK_PLL1>;
> +   #clock-cells = <0>;
> +   clock-div = <2>;
> +   clock-mult = <1>;
> +   };

clock-div = <3>;

> +   cp_clk: cp {
> +   compatible = "fixed-factor-clock";
> +   clocks = <_clk>;
> +   #clock-cells = <0>;
> +   clock-div = <2>;
> +   clock-mult = <1>;
> +   };

On V2H, CP is derived from PLL1, cfr. CL.
The clock derived from EXTAL is called CPEX.

> +   mstp1_clks: mstp1_clks@e6150134 {
> +   compatible = "renesas,r8a7792-mstp-clocks",
> +"renesas,cpg-mstp-clocks";
> +   reg = <0 0xe6150134 0 

Re: [PATCH 0/4] ARM: Renesas: R-Car3: Add product register support

[Dirk Behme]

Hi Geert,

On 01.06.2016 10:26, Geert Uytterhoeven wrote:

Hi Dirk,

On Wed, Jun 1, 2016 at 9:38 AM, Dirk Behme  wrote:

Sorry, if that was unclear. I took the example and transferred it to R-Car3
where we have ES1 - ES3.

So, taking this example, on R-Car3 we might end up with

{
.compatible = "renesas,sata-r8a7795",
.data = (void *)RCAR_GEN2_SATA
},
{
.compatible = "renesas,sata-r8a7795-es1",
.data = (void *)RCAR_R8A7795_ES1_SATA
},
{
.compatible = "renesas,sata-r8a7795-es2",
.data = (void *)RCAR_R8A7795_ES2_SATA
},
{
.compatible = "renesas,sata-r8a7795-es3",
.data = (void *)RCAR_R8A7795_ES3_SATA
},


Are there known differences in the SATA implementations on R-Car H3 ES1, ES2,
and ES3?



It's just an *example* what *might* happen.



BTW having different compatible values in the driver makes it much easier to
audit kernel sources for support for ESx deviations.



Why?

Having these compatible values in the driver doesn't tell you if the 
drivers uses them at all. No?


So you have to look into the driver code (not the compatible values) if 
and how the ESx are handled. And there, I don't think it makes any 
difference if you look for


if (priv->type == RCAR_R8A7790_ES1_SATA)
ap->flags|= ATA_FLAG_NO_DIPM;

or

if (revision_is_rcar2_es1)
ap->flags|= ATA_FLAG_NO_DIPM;

?


Best regards

Dirk

Re: [PATCH 12/13] ARM: dts: blanche: initial device tree

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:32 AM, Sergei Shtylyov
 wrote:
> Add the initial device  tree for the R8A7792 SoC based Blanche board.
> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
> them,  so that  the serial console  can  work.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-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 0/4] ARM: Renesas: R-Car3: Add product register support

[Dirk Behme]

On 01.06.2016 10:40, Geert Uytterhoeven wrote:

Hi Dirk,

On Wed, Jun 1, 2016 at 10:36 AM, Dirk Behme  wrote:

On 01.06.2016 10:26, Geert Uytterhoeven wrote:

On Wed, Jun 1, 2016 at 9:38 AM, Dirk Behme 
wrote:

Sorry, if that was unclear. I took the example and transferred it to
R-Car3
where we have ES1 - ES3.

So, taking this example, on R-Car3 we might end up with

{
.compatible = "renesas,sata-r8a7795",
.data = (void *)RCAR_GEN2_SATA
},
{
.compatible = "renesas,sata-r8a7795-es1",
.data = (void *)RCAR_R8A7795_ES1_SATA
},
{
.compatible = "renesas,sata-r8a7795-es2",
.data = (void *)RCAR_R8A7795_ES2_SATA
},
{
.compatible = "renesas,sata-r8a7795-es3",
.data = (void *)RCAR_R8A7795_ES3_SATA
},


Are there known differences in the SATA implementations on R-Car H3 ES1,
ES2,
and ES3?


It's just an *example* what *might* happen.


BTW having different compatible values in the driver makes it much easier
to
audit kernel sources for support for ESx deviations.


Why?

Having these compatible values in the driver doesn't tell you if the drivers
uses them at all. No?


The clue is that we do not add "renesas,*-es%u" compatible values to
drivers, unless ES%u needs to be handled specially.


So you have to look into the driver code (not the compatible values) if and
how the ESx are handled. And there, I don't think it makes any difference if
you look for

if (priv->type == RCAR_R8A7790_ES1_SATA)
ap->flags   |= ATA_FLAG_NO_DIPM;

or

if (revision_is_rcar2_es1)
ap->flags   |= ATA_FLAG_NO_DIPM;

?


... so 'git grep "renesas,.*-es[0-9]"' is all you need.



'git grep "revision_is_rcar2_es[0-9]"'

;)

Re: [PATCH 0/4] ARM: Renesas: R-Car3: Add product register support

[Geert Uytterhoeven]

Hi Dirk,

On Wed, Jun 1, 2016 at 10:36 AM, Dirk Behme  wrote:
> On 01.06.2016 10:26, Geert Uytterhoeven wrote:
>> On Wed, Jun 1, 2016 at 9:38 AM, Dirk Behme 
>> wrote:
>>> Sorry, if that was unclear. I took the example and transferred it to
>>> R-Car3
>>> where we have ES1 - ES3.
>>>
>>> So, taking this example, on R-Car3 we might end up with
>>>
>>> {
>>> .compatible = "renesas,sata-r8a7795",
>>> .data = (void *)RCAR_GEN2_SATA
>>> },
>>> {
>>> .compatible = "renesas,sata-r8a7795-es1",
>>> .data = (void *)RCAR_R8A7795_ES1_SATA
>>> },
>>> {
>>> .compatible = "renesas,sata-r8a7795-es2",
>>> .data = (void *)RCAR_R8A7795_ES2_SATA
>>> },
>>> {
>>> .compatible = "renesas,sata-r8a7795-es3",
>>> .data = (void *)RCAR_R8A7795_ES3_SATA
>>> },
>>
>> Are there known differences in the SATA implementations on R-Car H3 ES1,
>> ES2,
>> and ES3?
>
> It's just an *example* what *might* happen.
>
>> BTW having different compatible values in the driver makes it much easier
>> to
>> audit kernel sources for support for ESx deviations.
>
> Why?
>
> Having these compatible values in the driver doesn't tell you if the drivers
> uses them at all. No?

The clue is that we do not add "renesas,*-es%u" compatible values to
drivers, unless ES%u needs to be handled specially.

> So you have to look into the driver code (not the compatible values) if and
> how the ESx are handled. And there, I don't think it makes any difference if
> you look for
>
> if (priv->type == RCAR_R8A7790_ES1_SATA)
> ap->flags   |= ATA_FLAG_NO_DIPM;
>
> or
>
> if (revision_is_rcar2_es1)
> ap->flags   |= ATA_FLAG_NO_DIPM;
>
> ?

... so 'git grep "renesas,.*-es[0-9]"' is all you need.

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: renesas: add R8A7792 support

[Geert Uytterhoeven]

On Wed, May 25, 2016 at 11:40 PM, Sergei Shtylyov
 wrote:
> Renesas R-Car V2H (R8A7792) clocks are handled by R-Car gen2 clock driver.
>
> Signed-off-by: Sergei Shtylyov 

Acked-by: Geert Uytterhoeven 

(I.e. will queue in clk-renesas-for-v4.8).

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: [RFC 0/4] ARM: dts: r8a7790: lager: use demuxer for I2C

[Simon Horman]

On Wed, Jun 01, 2016 at 12:17:29PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Tue, May 31, 2016 at 12:32 PM, Simon Horman
>  wrote:
> > the intention of this series is to extend use of the demuxer for I2C
> > on the lager/r8a7790 to cover all I2C IP blocks.
> >
> > This is based on work by Wolfram Sang.
> >
> > I have not included GPIO in the demux configuration. This is in keeping
> > with the existing usage for IIC0/I2C0.
> 
> Thanks for your efforts! Can you please include GPIO support in next
> version? This way we should in the future be able to use
> distro-kernels out of the box that may only have GPIO bitbang support
> enabled.

Sure, will do.

Re: [PATCH 0/4] ARM: Renesas: R-Car3: Add product register support

[Geert Uytterhoeven]

Hi Dirk,

On Wed, Jun 1, 2016 at 9:38 AM, Dirk Behme  wrote:
> Sorry, if that was unclear. I took the example and transferred it to R-Car3
> where we have ES1 - ES3.
>
> So, taking this example, on R-Car3 we might end up with
>
> {
> .compatible = "renesas,sata-r8a7795",
> .data = (void *)RCAR_GEN2_SATA
> },
> {
> .compatible = "renesas,sata-r8a7795-es1",
> .data = (void *)RCAR_R8A7795_ES1_SATA
> },
> {
> .compatible = "renesas,sata-r8a7795-es2",
> .data = (void *)RCAR_R8A7795_ES2_SATA
> },
> {
> .compatible = "renesas,sata-r8a7795-es3",
> .data = (void *)RCAR_R8A7795_ES3_SATA
> },

Are there known differences in the SATA implementations on R-Car H3 ES1, ES2,
and ES3? If not, just "renesas,sata-r8a7795" will do.

BTW having different compatible values in the driver makes it much easier to
audit kernel sources for support for ESx deviations.

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 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:33 AM, Sergei Shtylyov
 wrote:
> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts

> +   ethernet@1800 {
> +   compatible = "smsc,lan89218", "smsc,lan9115";

The "smsc,lan89218" needs to be documented in the device tree bindings.
Google couldn't find any evidence you submitted a patch for that.

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 11/13] DT: arm: shmobile: document Blanche board

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:30 AM, Sergei Shtylyov
 wrote:
> Document the Blanche device tree bindings, listing it as a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to the
> Blanche board.
>
> Signed-off-by: Sergei Shtylyov 

Acked-by: Geert Uytterhoeven 

I can't verify the correctness of the board product ID, though.

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 10/13] ARM: dts: r8a7792: add IRQC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:29 AM, Sergei Shtylyov
 wrote:
> Describe the IRQC interrupt controller in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-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 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:26 AM, Sergei Shtylyov
 wrote:
> Describe [H]SCIFs in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-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 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:25 AM, Sergei Shtylyov
 wrote:
> Describe SYS-DMAC0/1 in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-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 06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:21 AM, Sergei Shtylyov
 wrote:
> Renesas R8A7792 SoC also has the CPG MSTP clocks...
>
> Signed-off-by: Sergei Shtylyov 

If you use "clk: renesas: smtp: ..."

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 v2 0/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Felipe Balbi]

Hi,

Yoshihiro Shimoda  writes:
>> From: Felipe Balbi
>> Sent: Wednesday, June 01, 2016 4:01 PM
>> 
>> Yoshihiro Shimoda  writes:
>> 
>> > I'm afraid but I found a regression of xhci-rcar in v4.7-rc1.
>> > This regression is caused by the following commit:
>> >
>> > commit b1c127ae990bccf0187d741c1695a61e54de1943
>> > Author: Felipe Balbi 
>> > Date:   Fri Apr 22 13:17:16 2016 +0300
>> >
>> > usb: host: xhci: plat: make use of new methods in xhci_plat_priv
>> >
>> > Now that the code has been refactored enough,
>> > switching over to using ->plat_start() and
>> > ->init_quirk() becomes a very simple patch.
>> >
>> > After this patch, there are no further uses for
>> > xhci_plat_type_is() which will be removed in a
>> > follow-up patch.
>> >
>> > Acked-by: Yoshihiro Shimoda 
>> > Signed-off-by: Felipe Balbi 
>> > Signed-off-by: Mathias Nyman 
>> > Signed-off-by: Greg Kroah-Hartman 
>> >
>> > < Overview >
>> > The regression is the quirks flag "XHCI_NO_64BIT_SUPPORT" will be 
>> > overwritten
>> > by xhci_gen_setup(). Then, the driver will not work correctly.
>> >
>> > < Detail >
>> > Since the previous code will do the following, the quirks flag can be set:
>> >
>> > xhci_plat_setup()
>> >  -> xhci_gen_setup(hcd, xhci_plat_quirks);
>> >   -> xhci->quirks = quirks;
>> >-> get_quirks() [This is xhci_plat_quirks]
>> > -> xhci->quirks |= XHCI_NO_64BIT_SUPPORT
>> >
>> > However, after we applied the patch above, the quirks will disappear:
>> >
>> > xhci_plat_setup()
>> >  -> xhci_priv_init_quirk();
>> >   -> xhci_rcar_init_quirk();
>> >-> xhci->quirks |= XHCI_NO_64BIT_SUPPORT
>> >   -> xhci_gen_setup(hcd, xhci_plat_quirks);
>> >-> xhci->quirks = quirks; <- here
>> > -> get_quirks() [This is xhci_plat_quirks]
>> >
>> > So, I submitted incremental patches to resolve this issue like the 
>> > followings:
>> >
>> > xhci_plat_setup()
>> >  -> xhci_priv_init_quirk();
>> >   -> xhci_rcar_init_quirk();
>> >   -> xhci_gen_setup(hcd, xhci_plat_quirks);
>> >-> xhci->quirks = quirks;
>> > -> get_quirks() [This is xhci_plat_quirks]
>> >  -> xhci->quirks |= priv->quirks (XHCI_NO_64BIT_SUPPORT)
>> 
>> isn't the following enough?
>> 
>> @@ -4886,7 +4886,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
>> xhci_get_quirks_t get_quirks)
>>  xhci->hcc_params2 = readl(>cap_regs->hcc_params2);
>>  xhci_print_registers(xhci);
>> 
>> -xhci->quirks = quirks;
>> +xhci->quirks |= quirks;
>> 
>>  get_quirks(dev, xhci);
>
> Thank you for the comment!
> You're correct. This also can resolve the issue.
> Do you prefer such a simple patch?
> At least, I prefer such a simple patch :)

I'll defer that to Mathias :-)

> Why I wrote this patch set is I thought I should implement similar
> flow before regression.

understood :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Geert Uytterhoeven]

Hi Simon,

On Wed, Jun 1, 2016 at 2:25 AM, Simon Horman  wrote:
> On Wed, Jun 01, 2016 at 01:20:11AM +0300, Sergei Shtylyov wrote:
>> Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...
>>
>> Signed-off-by: Sergei Shtylyov 
>
> I think the prefix of this patch should be "clk: shmobile: rcar-gen2: "

Almost, "clk: renesas: rcar-gen: " ;-)

> I apologise if I have missed a discussion of this topic or if my analysis
> is wrong for some reason but I am curious to know what the intended way
> is for the rcar-gen2 CPG driver to handle differences in the availability
> of clocks across different SoCs.
>
> My possibly naïve expectation is that the implementation would use compat
> strings. But as it stands it appears that all clocks supported by the
> driver are available for all SoCs. This does not seem to reflect the
> documentation (v2.00).

Differentiaton is not done using compat strings, but using clock-output-names.
The driver only instantiates the clocks that are listed there.

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 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:20 AM, Sergei Shtylyov
 wrote:
> Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...
>
> Signed-off-by: Sergei Shtylyov 

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 v2 0/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Yoshihiro Shimoda]

Hi Felipe,

> From: Felipe Balbi
> Sent: Wednesday, June 01, 2016 4:01 PM
> 
> Yoshihiro Shimoda  writes:
> 
> > I'm afraid but I found a regression of xhci-rcar in v4.7-rc1.
> > This regression is caused by the following commit:
> >
> > commit b1c127ae990bccf0187d741c1695a61e54de1943
> > Author: Felipe Balbi 
> > Date:   Fri Apr 22 13:17:16 2016 +0300
> >
> > usb: host: xhci: plat: make use of new methods in xhci_plat_priv
> >
> > Now that the code has been refactored enough,
> > switching over to using ->plat_start() and
> > ->init_quirk() becomes a very simple patch.
> >
> > After this patch, there are no further uses for
> > xhci_plat_type_is() which will be removed in a
> > follow-up patch.
> >
> > Acked-by: Yoshihiro Shimoda 
> > Signed-off-by: Felipe Balbi 
> > Signed-off-by: Mathias Nyman 
> > Signed-off-by: Greg Kroah-Hartman 
> >
> > < Overview >
> > The regression is the quirks flag "XHCI_NO_64BIT_SUPPORT" will be 
> > overwritten
> > by xhci_gen_setup(). Then, the driver will not work correctly.
> >
> > < Detail >
> > Since the previous code will do the following, the quirks flag can be set:
> >
> > xhci_plat_setup()
> >  -> xhci_gen_setup(hcd, xhci_plat_quirks);
> >   -> xhci->quirks = quirks;
> >-> get_quirks() [This is xhci_plat_quirks]
> > -> xhci->quirks |= XHCI_NO_64BIT_SUPPORT
> >
> > However, after we applied the patch above, the quirks will disappear:
> >
> > xhci_plat_setup()
> >  -> xhci_priv_init_quirk();
> >   -> xhci_rcar_init_quirk();
> >-> xhci->quirks |= XHCI_NO_64BIT_SUPPORT
> >   -> xhci_gen_setup(hcd, xhci_plat_quirks);
> >-> xhci->quirks = quirks; <- here
> > -> get_quirks() [This is xhci_plat_quirks]
> >
> > So, I submitted incremental patches to resolve this issue like the 
> > followings:
> >
> > xhci_plat_setup()
> >  -> xhci_priv_init_quirk();
> >   -> xhci_rcar_init_quirk();
> >   -> xhci_gen_setup(hcd, xhci_plat_quirks);
> >-> xhci->quirks = quirks;
> > -> get_quirks() [This is xhci_plat_quirks]
> >  -> xhci->quirks |= priv->quirks (XHCI_NO_64BIT_SUPPORT)
> 
> isn't the following enough?
> 
> @@ -4886,7 +4886,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
> xhci_get_quirks_t get_quirks)
>   xhci->hcc_params2 = readl(>cap_regs->hcc_params2);
>   xhci_print_registers(xhci);
> 
> - xhci->quirks = quirks;
> + xhci->quirks |= quirks;
> 
>   get_quirks(dev, xhci);

Thank you for the comment!
You're correct. This also can resolve the issue.
Do you prefer such a simple patch?
At least, I prefer such a simple patch :)
Why I wrote this patch set is I thought I should implement similar flow before 
regression.

Best regards,
Yoshihiro Shimoda

Re: [PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:18 AM, Sergei Shtylyov
 wrote:
> --- renesas.orig/arch/arm/mach-shmobile/Kconfig
> +++ renesas/arch/arm/mach-shmobile/Kconfig
> @@ -86,6 +86,11 @@ config ARCH_R8A7791
> select ARCH_RCAR_GEN2
> select I2C
>
> +config ARCH_R8A7792
> +   bool "R-Car V2H (R8A77920)"
> +   select ARCH_RCAR_GEN2
> +   select I2C

I2c is selected for the other SoCs because of regulator-quirk-rcar-gen2.
I do not have schematics for Blanche, so I don't know if it has DA9063 and
DA9210 regulators sharing the same interrupt.
If yes, you should make sure regulator-quirk-rcar-gen2 is updated for Blanche,
and built.
If no, you should drop the select.

If the above is clarified:

Reviewed-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 0/4] ARM: Renesas: R-Car3: Add product register support

[Dirk Behme]

Hi Geert,

On 01.06.2016 09:27, Geert Uytterhoeven wrote:

Hi Dirk,

On Wed, Jun 1, 2016 at 9:19 AM, Dirk Behme  wrote:

On 01.06.2016 07:19, Magnus Damm wrote:

On Fri, May 27, 2016 at 4:56 PM, Dirk Behme 
wrote:

On 27.05.2016 05:13, Magnus Damm wrote:

I don't think anyone disagrees that it makes sense to be able to
determine ES version during runtime. The questions in my mind are how
to do it


I've made a proposal ;) And I'm happy to discuss technically about it.


Thanks! It would be interesting to know the reason behind your
interest in these things. For instance, if you are interested in
reducing run time memory usage, or general source code duplication
reduction. Do you have any target platform that you can upstream board
support for?


and the urgency.


Regarding the urgency: Someone has accepted the hard coded PRODUCT
register
(and MODEMR) being in renesas-drivers, now:

https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/drivers/gpu/drm/rcar-du/rcar_du_crtc.c?h=topic/gen3-latest#n177

This does really hurts us.

Therefore, I try to get this removed as soon as possible to hopefully get
a
Renesas BSP without this, the next time.

If anybody finds an other way to remove that, that would be fine, too.


Please share the underlying issue so we can fix that.


So far we have decided to use the compatible string since it is a
common driver model abstraction already used by device drivers and
hardware description in DT. Using DT compat string matching we can
have logic in the drivers to handle ES differences if needed. As for
how to enable the workaround, my opinion is that the missing piece
consists of ES workaround code that appends ES suffix information to
the DT compat strings automatically during boot.


Technically this sounds slightly too complicated to me. As I have to
advocate my proposal (inspired from an other mainline SoC family) I'd
think
that my proposal is easier.


It may indeed be easier in the short term, but I feel we need to
consider how to support a wide range of SoCs in a consistent way.


I suppose the workaround is not yet implemented because no one has
deemed this topic as particularly urgent. Until it becomes urgent or a
new ES version appears the affected users can simply adjust the DT
binding themselves. This is what happened to the "sata-r8a7790-es1"
case above.


Can you see any technical reason why using DT compat strings wouldn't
solve your case?


I'll try to explain my understanding. Please re-ask or correct me if I fail
;)

First of all, I can talk only about R-Car3. There, at the moment, we have
ES1, ES2 and ES3 documented, already. We don't know, yet, if these are
really needed in the code, but it might be.

Taking the example above, we then would have

compatible = "renesas,sata-r8a7790", "sata-r8a7790-es1", "sata-r8a7790-es2",
"sata-r8a7790-es3";

in the device tree. Do we want that? No! Because its no run time detection.


You would only have "renesas,sata-r8a7790" for normal parts.
ES1 needs "renesas,sata-r8a7790-es1".
"esX" compatible values are the exception, not the rule.



Yes.



If we don't want that, and we want runtime detection, I think anywhere in
this thread it was mentioned that the "es1" string is appended to
sata-r8a7790 at runtime? If so, could you point us to the code for that?


The PoC is on my local SSD. Will send out soon.


Then we have anything like

if(PRODUCT_REG & ES1 == ES1)
append ES1 to the compatible string

in the boot code. This is one additional indirection to my proposal, needing
boot time. In the driver you then add

{
.compatible = "renesas,sata-r8a7790-es1",
.data = (void *)RCAR_R8A7790_ES1_SATA
},
{
.compatible = "renesas,sata-r8a7790-es2",
.data = (void *)RCAR_R8A7790_ES2_SATA
},
{
.compatible = "renesas,sata-r8a7790-es3",
.data = (void *)RCAR_R8A7790_ES3_SATA
},


No, only "renesas,sata-r8a7790" and "renesas,sata-r8a7790-es1", like we
already have.



Sorry, if that was unclear. I took the example and transferred it to 
R-Car3 where we have ES1 - ES3.


So, taking this example, on R-Car3 we might end up with

{
.compatible = "renesas,sata-r8a7795",
.data = (void *)RCAR_GEN2_SATA
},
{
.compatible = "renesas,sata-r8a7795-es1",
.data = (void *)RCAR_R8A7795_ES1_SATA
},
{
.compatible = "renesas,sata-r8a7795-es2",
.data = (void *)RCAR_R8A7795_ES2_SATA
},
{
.compatible = "renesas,sata-r8a7795-es3",
.data = (void *)RCAR_R8A7795_ES3_SATA
},

?

Best regards

Dirk

Re: [PATCH 03/13] soc: renesas: rcar-sysc: add R8A7792 support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:15 AM, Sergei Shtylyov
 wrote:
> Add support for R-Car V2H (R8A7792) SoC power areas to the SYSC driver.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-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 02/13] ARM: shmobile: r8a7792: add power domain index macros

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:11 AM, Sergei Shtylyov
 wrote:
> Add macros usable by the device tree sources to reference R8A7792 SYSC power
> domains by index.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-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 00/13] Add R8A7794/SILK board eMMC DT support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:06 AM, Sergei Shtylyov
 wrote:
>Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
> the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
> week separately...
>
> [01/13] ARM: shmobile: r8a7792: add clock index macros
> [02/13] ARM: shmobile: r8a7792: add power domain index macros
> [03/13] soc: renesas: rcar-sysc: add R8A7792 support
> [04/13] ARM: shmobile: r8a7792: basic SoC support
> [05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
> [06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
> [07/13] ARM: dts: r8a7792: initial SoC device tree
> [08/13] ARM: dts: r8a7792: add SYS-DMAC support
> [09/13] ARM: dts: r8a7792: add [H]SCIF support
> [10/13] ARM dts: r8a7792: add IRQC support
> [11/13] DT: arm: shmobile: document Blanche board
> [12/13] ARM: dts: blanche: initial device tree
> [13/13] ARM: dts: blanche: add Ethernet support

Thanks for your series!

The subject doesn't seem to cover the contents, though:
> [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

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 0/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Felipe Balbi]

Yoshihiro Shimoda  writes:

> I'm afraid but I found a regression of xhci-rcar in v4.7-rc1.
> This regression is caused by the following commit:
>
> commit b1c127ae990bccf0187d741c1695a61e54de1943
> Author: Felipe Balbi 
> Date:   Fri Apr 22 13:17:16 2016 +0300
>
> usb: host: xhci: plat: make use of new methods in xhci_plat_priv
> 
> Now that the code has been refactored enough,
> switching over to using ->plat_start() and
> ->init_quirk() becomes a very simple patch.
> 
> After this patch, there are no further uses for
> xhci_plat_type_is() which will be removed in a
> follow-up patch.
> 
> Acked-by: Yoshihiro Shimoda 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Mathias Nyman 
> Signed-off-by: Greg Kroah-Hartman 
>
> < Overview >
> The regression is the quirks flag "XHCI_NO_64BIT_SUPPORT" will be overwritten
> by xhci_gen_setup(). Then, the driver will not work correctly.
>
> < Detail >
> Since the previous code will do the following, the quirks flag can be set:
>
> xhci_plat_setup()
>  -> xhci_gen_setup(hcd, xhci_plat_quirks);
>   -> xhci->quirks = quirks;
>-> get_quirks() [This is xhci_plat_quirks]
> -> xhci->quirks |= XHCI_NO_64BIT_SUPPORT
>
> However, after we applied the patch above, the quirks will disappear:
>
> xhci_plat_setup()
>  -> xhci_priv_init_quirk();
>   -> xhci_rcar_init_quirk();
>-> xhci->quirks |= XHCI_NO_64BIT_SUPPORT
>   -> xhci_gen_setup(hcd, xhci_plat_quirks);
>-> xhci->quirks = quirks; <- here
> -> get_quirks() [This is xhci_plat_quirks]
>
> So, I submitted incremental patches to resolve this issue like the followings:
>
> xhci_plat_setup()
>  -> xhci_priv_init_quirk();
>   -> xhci_rcar_init_quirk();
>   -> xhci_gen_setup(hcd, xhci_plat_quirks);
>-> xhci->quirks = quirks;
> -> get_quirks() [This is xhci_plat_quirks]
>  -> xhci->quirks |= priv->quirks (XHCI_NO_64BIT_SUPPORT)

isn't the following enough?

@@ -4886,7 +4886,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t 
get_quirks)
xhci->hcc_params2 = readl(>cap_regs->hcc_params2);
xhci_print_registers(xhci);
 
-   xhci->quirks = quirks;
+   xhci->quirks |= quirks;
 
get_quirks(dev, xhci);
 
-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2 2/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Yoshihiro Shimoda]

Since the commit b1c127ae990b ("usb: host: xhci: plat: make use of new
methods in xhci_plat_priv") changed the setting timing of xhci->quirks to
xhci_rcar_init_quirk(), the quirks was overwritten by xhci_gen_setup().

So, this patch fixes the issue using a "quirks" of struct xhci_plat_priv.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/host/xhci-plat.c | 12 +++-
 drivers/usb/host/xhci-plat.h |  1 +
 drivers/usb/host/xhci-rcar.c | 21 -
 3 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 676ea45..7f03608 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -57,12 +57,14 @@ static int xhci_priv_init_quirk(struct usb_hcd *hcd)
 
 static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 {
+   struct xhci_plat_priv *priv = xhci_to_priv(xhci);
+
/*
 * As of now platform drivers don't provide MSI support so we ensure
 * here that the generic code does not try to make a pci_dev from our
 * dev struct in order to setup MSI
 */
-   xhci->quirks |= XHCI_PLAT;
+   xhci->quirks |= XHCI_PLAT | priv->quirks;
 }
 
 /* called during probe() after chip reset completes */
@@ -89,16 +91,24 @@ static const struct xhci_plat_priv xhci_plat_marvell_armada 
= {
.init_quirk = xhci_mvebu_mbus_init_quirk,
 };
 
+/*
+ * On R-Car Gen2 and Gen3, the AC64 bit (bit 0) of HCCPARAMS1 is set to 1.
+ * However, these SoCs don't support 64-bit address memory pointers. So, this
+ * driver clears the AC64 bit of xhci->hcc_params to call
+ * dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().
+ */
 static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen2 = {
.firmware_name = XHCI_RCAR_FIRMWARE_NAME_V1,
.init_quirk = xhci_rcar_init_quirk,
.plat_start = xhci_rcar_start,
+   .quirks = XHCI_NO_64BIT_SUPPORT,
 };
 
 static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen3 = {
.firmware_name = XHCI_RCAR_FIRMWARE_NAME_V2,
.init_quirk = xhci_rcar_init_quirk,
.plat_start = xhci_rcar_start,
+   .quirks = XHCI_NO_64BIT_SUPPORT,
 };
 
 static const struct of_device_id usb_xhci_of_match[] = {
diff --git a/drivers/usb/host/xhci-plat.h b/drivers/usb/host/xhci-plat.h
index c652f33..15144c9 100644
--- a/drivers/usb/host/xhci-plat.h
+++ b/drivers/usb/host/xhci-plat.h
@@ -20,5 +20,6 @@ struct xhci_plat_priv {
unsigned int quirks;
 };
 
+#define xhci_to_priv(x) ((struct xhci_plat_priv *)(x)->priv)
 #define hcd_to_xhci_priv(h) ((struct xhci_plat_priv *)hcd_to_xhci(h)->priv)
 #endif /* _XHCI_PLAT_H */
diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
index 0e4535e..2617cd7 100644
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -87,14 +87,6 @@ static int xhci_rcar_is_gen2(struct device *dev)
of_device_is_compatible(node, "renensas,rcar-gen2-xhci");
 }
 
-static int xhci_rcar_is_gen3(struct device *dev)
-{
-   struct device_node *node = dev->of_node;
-
-   return of_device_is_compatible(node, "renesas,xhci-r8a7795") ||
-   of_device_is_compatible(node, "renesas,rcar-gen3-xhci");
-}
-
 void xhci_rcar_start(struct usb_hcd *hcd)
 {
u32 temp;
@@ -175,22 +167,9 @@ static int xhci_rcar_download_firmware(struct usb_hcd *hcd)
 /* This function needs to initialize a "phy" of usb before */
 int xhci_rcar_init_quirk(struct usb_hcd *hcd)
 {
-   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
-
/* If hcd->regs is NULL, we don't just call the following function */
if (!hcd->regs)
return 0;
 
-   /*
-* On R-Car Gen2 and Gen3, the AC64 bit (bit 0) of HCCPARAMS1 is set
-* to 1. However, these SoCs don't support 64-bit address memory
-* pointers. So, this driver clears the AC64 bit of xhci->hcc_params
-* to call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in
-* xhci_gen_setup().
-*/
-   if (xhci_rcar_is_gen2(hcd->self.controller) ||
-   xhci_rcar_is_gen3(hcd->self.controller))
-   xhci->quirks |= XHCI_NO_64BIT_SUPPORT;
-
return xhci_rcar_download_firmware(hcd);
 }
-- 
1.9.1

[PATCH v2 1/2] usb: host: xhci: plat: add ->quirks value for platform-specific

[Yoshihiro Shimoda]

This patch adds quirks in struct xhci_plat_priv to set xhci->quirks
for platform-specific.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/host/xhci-plat.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-plat.h b/drivers/usb/host/xhci-plat.h
index 9af0cb4..c652f33 100644
--- a/drivers/usb/host/xhci-plat.h
+++ b/drivers/usb/host/xhci-plat.h
@@ -17,6 +17,7 @@ struct xhci_plat_priv {
const char *firmware_name;
void (*plat_start)(struct usb_hcd *);
int (*init_quirk)(struct usb_hcd *);
+   unsigned int quirks;
 };
 
 #define hcd_to_xhci_priv(h) ((struct xhci_plat_priv *)hcd_to_xhci(h)->priv)
-- 
1.9.1

[PATCH v2 0/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Yoshihiro Shimoda]

I'm afraid but I found a regression of xhci-rcar in v4.7-rc1.
This regression is caused by the following commit:

commit b1c127ae990bccf0187d741c1695a61e54de1943
Author: Felipe Balbi 
Date:   Fri Apr 22 13:17:16 2016 +0300

usb: host: xhci: plat: make use of new methods in xhci_plat_priv

Now that the code has been refactored enough,
switching over to using ->plat_start() and
->init_quirk() becomes a very simple patch.

After this patch, there are no further uses for
xhci_plat_type_is() which will be removed in a
follow-up patch.

Acked-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 

< Overview >
The regression is the quirks flag "XHCI_NO_64BIT_SUPPORT" will be overwritten
by xhci_gen_setup(). Then, the driver will not work correctly.

< Detail >
Since the previous code will do the following, the quirks flag can be set:

xhci_plat_setup()
 -> xhci_gen_setup(hcd, xhci_plat_quirks);
  -> xhci->quirks = quirks;
   -> get_quirks() [This is xhci_plat_quirks]
-> xhci->quirks |= XHCI_NO_64BIT_SUPPORT

However, after we applied the patch above, the quirks will disappear:

xhci_plat_setup()
 -> xhci_priv_init_quirk();
  -> xhci_rcar_init_quirk();
   -> xhci->quirks |= XHCI_NO_64BIT_SUPPORT
  -> xhci_gen_setup(hcd, xhci_plat_quirks);
   -> xhci->quirks = quirks; <- here
-> get_quirks() [This is xhci_plat_quirks]

So, I submitted incremental patches to resolve this issue like the followings:

xhci_plat_setup()
 -> xhci_priv_init_quirk();
  -> xhci_rcar_init_quirk();
  -> xhci_gen_setup(hcd, xhci_plat_quirks);
   -> xhci->quirks = quirks;
-> get_quirks() [This is xhci_plat_quirks]
 -> xhci->quirks |= priv->quirks (XHCI_NO_64BIT_SUPPORT)

Changes from v1:
 - Revise the commit log in patch 2 because checkpatch.pl said the patch
   has ERRROR.

Yoshihiro Shimoda (2):
  usb: host: xhci: plat: add ->quirks value for platform-specific
  usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

 drivers/usb/host/xhci-plat.c | 12 +++-
 drivers/usb/host/xhci-plat.h |  2 ++
 drivers/usb/host/xhci-rcar.c | 21 -
 3 files changed, 13 insertions(+), 22 deletions(-)

-- 
1.9.1

RE: [PATCH 2/2] usb: host: xhci: rcar: fix the quirks setting of XHCI_NO_64BIT_SUPPORT

[Yoshihiro Shimoda]

> From: Yoshihiro Shimoda
> Sent: Wednesday, June 01, 2016 11:40 AM
> 
> Since the commit b1c127ae (usb: host: xhci: plat: make use of new methods
> in xhci_plat_priv) changed the setting timing of xhci->quirks to

Oops, checkpatch.pl said this message should be revised.
So, I will submit v2 patch later.

Best regards,
Yoshihiro Shimoda

> So, this patch fixes the issue using a "quirks" of struct xhci_plat_priv.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/usb/host/xhci-plat.c | 12 +++-
>  drivers/usb/host/xhci-plat.h |  1 +
>  drivers/usb/host/xhci-rcar.c | 21 -
>  3 files changed, 12 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 676ea45..7f03608 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -57,12 +57,14 @@ static int xhci_priv_init_quirk(struct usb_hcd *hcd)
> 
>  static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
>  {
> + struct xhci_plat_priv *priv = xhci_to_priv(xhci);
> +
>   /*
>* As of now platform drivers don't provide MSI support so we ensure
>* here that the generic code does not try to make a pci_dev from our
>* dev struct in order to setup MSI
>*/
> - xhci->quirks |= XHCI_PLAT;
> + xhci->quirks |= XHCI_PLAT | priv->quirks;
>  }
> 
>  /* called during probe() after chip reset completes */
> @@ -89,16 +91,24 @@ static const struct xhci_plat_priv 
> xhci_plat_marvell_armada = {
>   .init_quirk = xhci_mvebu_mbus_init_quirk,
>  };
> 
> +/*
> + * On R-Car Gen2 and Gen3, the AC64 bit (bit 0) of HCCPARAMS1 is set to 1.
> + * However, these SoCs don't support 64-bit address memory pointers. So, this
> + * driver clears the AC64 bit of xhci->hcc_params to call
> + * dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().
> + */
>  static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen2 = {
>   .firmware_name = XHCI_RCAR_FIRMWARE_NAME_V1,
>   .init_quirk = xhci_rcar_init_quirk,
>   .plat_start = xhci_rcar_start,
> + .quirks = XHCI_NO_64BIT_SUPPORT,
>  };
> 
>  static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen3 = {
>   .firmware_name = XHCI_RCAR_FIRMWARE_NAME_V2,
>   .init_quirk = xhci_rcar_init_quirk,
>   .plat_start = xhci_rcar_start,
> + .quirks = XHCI_NO_64BIT_SUPPORT,
>  };
> 
>  static const struct of_device_id usb_xhci_of_match[] = {
> diff --git a/drivers/usb/host/xhci-plat.h b/drivers/usb/host/xhci-plat.h
> index c652f33..15144c9 100644
> --- a/drivers/usb/host/xhci-plat.h
> +++ b/drivers/usb/host/xhci-plat.h
> @@ -20,5 +20,6 @@ struct xhci_plat_priv {
>   unsigned int quirks;
>  };
> 
> +#define xhci_to_priv(x) ((struct xhci_plat_priv *)(x)->priv)
>  #define hcd_to_xhci_priv(h) ((struct xhci_plat_priv *)hcd_to_xhci(h)->priv)
>  #endif   /* _XHCI_PLAT_H */
> diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> index 0e4535e..2617cd7 100644
> --- a/drivers/usb/host/xhci-rcar.c
> +++ b/drivers/usb/host/xhci-rcar.c
> @@ -87,14 +87,6 @@ static int xhci_rcar_is_gen2(struct device *dev)
>   of_device_is_compatible(node, "renensas,rcar-gen2-xhci");
>  }
> 
> -static int xhci_rcar_is_gen3(struct device *dev)
> -{
> - struct device_node *node = dev->of_node;
> -
> - return of_device_is_compatible(node, "renesas,xhci-r8a7795") ||
> - of_device_is_compatible(node, "renesas,rcar-gen3-xhci");
> -}
> -
>  void xhci_rcar_start(struct usb_hcd *hcd)
>  {
>   u32 temp;
> @@ -175,22 +167,9 @@ static int xhci_rcar_download_firmware(struct usb_hcd 
> *hcd)
>  /* This function needs to initialize a "phy" of usb before */
>  int xhci_rcar_init_quirk(struct usb_hcd *hcd)
>  {
> - struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> -
>   /* If hcd->regs is NULL, we don't just call the following function */
>   if (!hcd->regs)
>   return 0;
> 
> - /*
> -  * On R-Car Gen2 and Gen3, the AC64 bit (bit 0) of HCCPARAMS1 is set
> -  * to 1. However, these SoCs don't support 64-bit address memory
> -  * pointers. So, this driver clears the AC64 bit of xhci->hcc_params
> -  * to call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in
> -  * xhci_gen_setup().
> -  */
> - if (xhci_rcar_is_gen2(hcd->self.controller) ||
> - xhci_rcar_is_gen3(hcd->self.controller))
> - xhci->quirks |= XHCI_NO_64BIT_SUPPORT;
> -
>   return xhci_rcar_download_firmware(hcd);
>  }
> --
> 1.9.1