RE: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Chris Brandt]

Hi Jacopo,

On Thursday, January 26, 2017, jacopo mondi wrote:
> > I think we should try to avoid the rz naming as much as possible since
> > this driver will hopefully be useful for other future Renesas devices
> > if they move to a similar pin-control type method. Maybe future "R-car"
> SoCs?
> > Or, maybe Renesas Marketing decides to come up with a new name for SoCs.
> >
> > Otherwise, you could end up with a directly like "mach-shmobile"
> > filled with a bunch of...well...not SH-Mobile parts.
> >
> > Maybe just
> >   drivers/pinctrl/renesas/pinctrl-renesas.c
> >
> 
> Wouldn't this be confusing, as most of renesas SoC are supported through
> drivers/pinctrl/sh-pfc instead?

It's already confusing that a bunch of ARM parts use a "sh" pin controller.

In reality, any Renesas device could be a peripheral mix of ex-Mitsubishi,
ex-Hitachi, ex-NEC or Renesas original. Or, some IP was licensed from a 3rd
party (ie, the SDHI/TMIO controller).
The only thing consistent is "Renesas".

> I agree on dropping the rz name, if more SoC will come and join the pin-
> based PFC realm...

I will suggest it for the next generation of SoCs, so we'll see what happens...

Thanks,
Chris

RE: [PATCH v5 2/3] mmc: sh_mobile_sdhi: explain clock bindings

[Chris Brandt]

On Thursday, January 26, 2017, Rob Herring wrote:
> >> > +
> >> > +Example showing 2 clocks:
> >> > +   sdhi0: sd@e804e000 {
> >>
> >> mmc@...
> >
> > I'm confused. I see that for all SDHI controllers, it either "sd@" or
> "sdhci@".
> >
> > $ grep sdhi $(find arch/arm/boot/dts -name "*.dtsi")
> >
> > $ grep sdhci $(find arch/arm/boot/dts -name "*.dtsi")
> 
> Yes, there's lots of variation. Node names are supposed to be generic for
> their class of device (e.g. ethernet, pci, usb, interrupt-controller,
> etc.). I'd be fine with "sd", but think "mmc" is more common. Either way,
> we should pick one moving forward. "sdhci"
> should not be used as that's a specific implementation.
> 
> Rob

For now, I took the example back out of tmio_mmc.txt since I figured
people can refer back to mmc.txt for what the naming should be (since
the directory name is mmc, you would think the golden rules were in
mmc.txt)


> I'd be fine with "sd", but think "mmc" is more common.

NOTE: mmc.txt currently has 2 examples:

sdhci@ab00 {

mmc3: mmc@01c12000 {

Chris

[PATCHv5 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Niklas Söderlund]

A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
hardware blocks are connected between the video sources and the video
grabbers (VIN).

Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/Kconfig |  11 +
 drivers/media/platform/rcar-vin/Makefile|   1 +
 drivers/media/platform/rcar-vin/rcar-csi2.c | 616 
 3 files changed, 628 insertions(+)
 create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c

diff --git a/drivers/media/platform/rcar-vin/Kconfig 
b/drivers/media/platform/rcar-vin/Kconfig
index 111d2a151f6a4d44..f1df85d526e96a74 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -1,3 +1,14 @@
+config VIDEO_RCAR_CSI2
+   tristate "R-Car MIPI CSI-2 Receiver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+   depends on ARCH_RENESAS || COMPILE_TEST
+   ---help---
+ Support for Renesas R-Car MIPI CSI-2 receiver.
+ Supports R-Car Gen3 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-csi2.
+
 config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) Driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
MEDIA_CONTROLLER
diff --git a/drivers/media/platform/rcar-vin/Makefile 
b/drivers/media/platform/rcar-vin/Makefile
index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
--- a/drivers/media/platform/rcar-vin/Makefile
+++ b/drivers/media/platform/rcar-vin/Makefile
@@ -1,3 +1,4 @@
 rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
 
+obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
 obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
b/drivers/media/platform/rcar-vin/rcar-csi2.c
new file mode 100644
index ..2d18bf32eb4e7fdb
--- /dev/null
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -0,0 +1,616 @@
+/*
+ * Driver for Renesas R-Car MIPI CSI-2 Receiver
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Register offsets and bits */
+
+/* Control Timing Select */
+#define TREF_REG   0x00
+#define TREF_TREF  (1 << 0)
+
+/* Software Reset */
+#define SRST_REG   0x04
+#define SRST_SRST  (1 << 0)
+
+/* PHY Operation Control */
+#define PHYCNT_REG 0x08
+#define PHYCNT_SHUTDOWNZ   (1 << 17)
+#define PHYCNT_RSTZ(1 << 16)
+#define PHYCNT_ENABLECLK   (1 << 4)
+#define PHYCNT_ENABLE_3(1 << 3)
+#define PHYCNT_ENABLE_2(1 << 2)
+#define PHYCNT_ENABLE_1(1 << 1)
+#define PHYCNT_ENABLE_0(1 << 0)
+
+/* Checksum Control */
+#define CHKSUM_REG 0x0c
+#define CHKSUM_ECC_EN  (1 << 1)
+#define CHKSUM_CRC_EN  (1 << 0)
+
+/*
+ * Channel Data Type Select
+ * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
+ * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
+ */
+#define VCDT_REG   0x10
+#define VCDT2_REG  0x14
+#define VCDT_VCDTN_EN  (1 << 15)
+#define VCDT_SEL_VC(n) (((n) & 0x3) << 8)
+#define VCDT_SEL_DTN_ON(1 << 6)
+#define VCDT_SEL_DT(n) (((n) & 0x1f) << 0)
+
+/* Frame Data Type Select */
+#define FRDT_REG   0x18
+
+/* Field Detection Control */
+#define FLD_REG0x1c
+#define FLD_FLD_NUM(n) (((n) & 0xff) << 16)
+#define FLD_FLD_EN4(1 << 3)
+#define FLD_FLD_EN3(1 << 2)
+#define FLD_FLD_EN2(1 << 1)
+#define FLD_FLD_EN (1 << 0)
+
+/* Automatic Standby Control */
+#define ASTBY_REG  0x20
+
+/* Long Data Type Setting 0 */
+#define LNGDT0_REG 0x28
+
+/* Long Data Type Setting 1 */
+#define LNGDT1_REG 0x2c
+
+/* Interrupt Enable */
+#define INTEN_REG  0x30
+
+/* Interrupt Source Mask */
+#define INTCLOSE_REG   0x34
+
+/* Interrupt Status Monitor */
+#define INTSTATE_REG   0x38
+
+/* Interrupt Error Status Monitor */
+#define INTERRSTATE_REG0x3c
+
+/* Short Packet Data */
+#define SHPDAT_REG 

[PATCHv5 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support

[Niklas Söderlund]

Hi,

This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's 
based on top of v4.10-rc1 and are tested on Renesas Salvator-X together 
with the out of tree patches for rcar-vin to add support for Gen3 VIN 
and a prototype driver for ADV7482. If anyone is interested to test 
video grabbing using these out of tree patches please see [1].

Changes since v4:
- Match SoC part numbers and drop trailing space in documentation, 
  thanks Geert for pointing this out.
- Clarify that the driver is a CSI-2 receiver by supervised 
  s/interface/receiver/, thanks Laurent.
- Add entries in Kconfig and Makefile alphabetically instead of append.
- Rename struct rcar_csi2 member swap to lane_swap.
- Remove macros to wrap calls to dev_{dbg,info,warn,err}.
- Add wrappers for ioread32 and iowrite32.
- Remove unused interrupt handler, but keep checking in probe that there 
  are a interrupt define in DT.
- Rework how to wait for LP-11 state, thanks Laurent for the great idea!
- Remove unneeded delay in rcar_csi2_reset()
- Remove check for duplicated lane id:s from DT parsing. Broken out to a 
  separate patch adding this check directly to v4l2_of_parse_endpoint().
- Fixed rcar_csi2_start() to ask it's source subdevice for information 
  about pixel rate and frame format. With this change having 
  {set,get}_fmt operations became redundant, it was only used for 
  figuring out this out so dropped them.
- Tabulated frequency settings map.
- Dropped V4L2_SUBDEV_FL_HAS_DEVNODE it should never have been set.
- Switched from MEDIA_ENT_F_ATV_DECODER to 
  MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER as entity function. I can't 
  find a more suitable function, and what the hardware do is to fetch 
  video from an external chip and passes it on to a another SoC internal 
  IP it's sort of a formatter.
- Break out DT documentation and code in two patches.

Changes since v3:
- Update DT binding documentation with input from Geert Uytterhoeven,
  thanks!

Changes since v2:
- Added media control pads as this is needed by the new rcar-vin driver.
- Update DT bindings after review comments and to add r8a7796 support.
- Add get_fmt handler.
- Fix media bus format error s/YUYV8/UYVY8/

Changes since v1:
- Drop dependency on a pad aware s_stream operation.
- Use the DT bindings format "renesas,-", thanks Geert
  for pointing this out.

1. http://elinux.org/R-Car/Tests:rcar-vin

Niklas Söderlund (2):
  media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
  media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

 .../devicetree/bindings/media/rcar-csi2.txt| 116 
 drivers/media/platform/rcar-vin/Kconfig|  11 +
 drivers/media/platform/rcar-vin/Makefile   |   1 +
 drivers/media/platform/rcar-vin/rcar-csi2.c| 616 +
 4 files changed, 744 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
 create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c

-- 
2.11.0

[PATCHv5 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Niklas Söderlund]

Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
are located between the video sources (CSI-2 transmitters) and the video
grabbers (VIN) on Gen3 of Renesas R-Car SoC.

Each CSI-2 device is connected to more then one VIN device which
simultaneously can receive video from the same CSI-2 device. Each VIN
device can also be connected to more then one CSI-2 device. The routing
of which link are used are controlled by the VIN devices. There are only
a few possible routes which are set by hardware limitations, which are
different for each SoC in the Gen3 family.

To work with the limitations of routing possibilities it is necessary
for the DT bindings to describe which VIN device is connected to which
CSI-2 device. This is why port 1 needs to to assign reg numbers for each
VIN device that be connected to it. To setup and to know which links are
valid for each SoC is the responsibility of the VIN driver since the
register to configure it belongs to the VIN hardware.

Signed-off-by: Niklas Söderlund 
---
 .../devicetree/bindings/media/rcar-csi2.txt| 116 +
 1 file changed, 116 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt

diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt 
b/Documentation/devicetree/bindings/media/rcar-csi2.txt
new file mode 100644
index ..f6e2027ee92b171a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt
@@ -0,0 +1,116 @@
+Renesas R-Car MIPI CSI-2
+
+
+The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
+family of devices. It is to be used in conjunction with the R-Car VIN module,
+which provides the video capture capabilities.
+
+ - compatible: Must be one or more of the following
+   - "renesas,r8a7795-csi2" for the R8A7795 device.
+   - "renesas,r8a7796-csi2" for the R8A7796 device.
+   - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device.
+
+   When compatible with a generic version nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+The device node should contain two 'port' child nodes according to the
+bindings defined in Documentation/devicetree/bindings/media/
+video-interfaces.txt. Port 0 should connect the node that is the video
+source for to the CSI-2. Port 1 should connect all the R-Car VIN
+modules, which can make use of the CSI-2 module.
+
+- Port 0 - Video source
+   - Reg 0 - sub-node describing the endpoint that is the video source
+
+- Port 1 - VIN instances
+   - Reg 0 - sub-node describing the endpoint that is VIN0
+   - Reg 1 - sub-node describing the endpoint that is VIN1
+   - Reg 2 - sub-node describing the endpoint that is VIN2
+   - Reg 3 - sub-node describing the endpoint that is VIN3
+   - Reg 4 - sub-node describing the endpoint that is VIN4
+   - Reg 5 - sub-node describing the endpoint that is VIN5
+   - Reg 6 - sub-node describing the endpoint that is VIN6
+   - Reg 7 - sub-node describing the endpoint that is VIN7
+
+Example:
+
+/* SoC properties */
+
+csi20: csi2@fea8 {
+compatible = "renesas,r8a7796-csi2";
+reg = <0 0xfea8 0 0x1>;
+interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < CPG_MOD 714>;
+power-domains = < R8A7796_PD_ALWAYS_ON>;
+status = "disabled";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+reg = <1>;
+
+csi20vin0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <>;
+};
+csi20vin1: endpoint@1 {
+reg = <1>;
+remote-endpoint = <>;
+};
+csi20vin2: endpoint@2 {
+reg = <2>;
+remote-endpoint = <>;
+};
+csi20vin3: endpoint@3 {
+reg = <3>;
+remote-endpoint = <>;
+};
+csi20vin4: endpoint@4 {
+reg = <4>;
+remote-endpoint = <>;

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Simon Horman]

On Thu, Jan 26, 2017 at 03:16:57PM +0100, Wolfram Sang wrote:
> 
> > I have tested with "the new mmc/next" and things seem better.
> 
> Good. The issue you saw is expected when you have not the enablement
> patches in place.
> 
> > I am still of a mind to drop the M3-W patch of this series because unless
> > we can control the order that things are merged into Linus's tree
> > there will be a temporary regression there. Moreover I'm not very excited
> > about renesas-next having regressed.
> 
> I have not heard of a regression. Geert, did you report that? Did I miss
> that? As you can see, I did test the patches with M3 as well:
> 
> http://elinux.org/Tests:eMMC-HS
> 
> and Jinso test team (Duc-san) confirmed it works for them with H3 and
> M3-W. In private communication, though.

The problem I see is the following logged to the console
(which makes the console semi-unusable).

sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13)

I'm on IRC if you'd like to chat there.

[PATCH 2/4] arm64: dts: m3ulcb: Update memory node to 2 GiB map

[Vladimir Barinov]

From: Vladimir Barinov 

This patch updates memory region:

  - After changes, the new map of the m3ulcb board on R8A7796 SoC
Bank0: 1GiB RAM : 0x4800 -> 0x0007fff
Bank1: 1GiB RAM : 0x0006 -> 0x0063fff

  - Before changes, the old map looked like this:
Bank0: 1GiB RAM : 0x4800 -> 0x0007fff

Signed-off-by: Vladimir Barinov 
---
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index f35e96c..38bde9d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -32,6 +32,11 @@
reg = <0x0 0x4800 0x0 0x3800>;
};
 
+   memory@6 {
+   device_type = "memory";
+   reg = <0x6 0x 0x0 0x4000>;
+   };
+
leds {
compatible = "gpio-leds";
 
-- 
1.9.1

[PATCH 1/4] arm64: dts: m3ulcb: enable I2C

[Vladimir Barinov]

From: Vladimir Barinov 

This supports I2C2 bus on M3ULCB board

Signed-off-by: Vladimir Barinov 
---
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index a9c296b..f35e96c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -120,6 +120,11 @@
function = "scif_clk";
};
 
+   i2c2_pins: i2c2 {
+   groups = "i2c2_a";
+   function = "i2c2";
+   };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -183,6 +198,13 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};
+
  {
timeout-sec = <60>;
status = "okay";
-- 
1.9.1

[PATCH 1/2] arm64: dts: h3ulcb: Update memory node to 4 GiB map

[Vladimir Barinov]

From: Vladimir Barinov 

This patch adds memory region:

  - After changes, the H3ULCB board has the following map:
Bank0: 1GiB RAM : 0x4800 -> 0x0007fff
Bank1: 1GiB RAM : 0x0005 -> 0x0053fff
Bank2: 1GiB RAM : 0x0006 -> 0x0063fff
Bank3: 1GiB RAM : 0x0007 -> 0x0073fff

  - Before changes, the old map looked like this:
Bank0: 1GiB RAM : 0x4800 -> 0x0007fff

Signed-off-by: Vladimir Barinov 
---
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index b36c300..3edf966 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -33,6 +33,21 @@
reg = <0x0 0x4800 0x0 0x3800>;
};
 
+   memory@5 {
+   device_type = "memory";
+   reg = <0x5 0x 0x0 0x4000>;
+   };
+
+   memory@6 {
+   device_type = "memory";
+   reg = <0x6 0x 0x0 0x4000>;
+   };
+
+   memory@7 {
+   device_type = "memory";
+   reg = <0x7 0x 0x0 0x4000>;
+   };
+
leds {
compatible = "gpio-leds";
 
-- 
1.9.1

[PATCH 2/2] arm64: dts: h3ulcb: enable HS200 for eMMC

[Vladimir Barinov]

From: Vladimir Barinov 

This supports HS200 mode for eMMC on H3ULCB board

Signed-off-by: Vladimir Barinov 
---
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 7a8986e..51ef8bb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -329,6 +329,7 @@
vmmc-supply = <_3p3v>;
vqmmc-supply = <_1p8v>;
bus-width = <8>;
+   mmc-hs200-1_8v;
non-removable;
status = "okay";
 };
-- 
1.9.1

[PATCH 0/2] arm64: renesas: enable H3ULCB board peripherals

[Vladimir Barinov]

Hello,

This adds the folowing:
- R8A7795 SoC based H3ULCB board peripherals

Vladimir Barinov (2):
[1/2] arm64: dts: h3ulcb: Update memory node to 4 GiB map
[2/2] arm64: dts: h3ulcb: enable HS200 for eMMC

---
This patchset is against the 'kernel/git/horms/renesas.git' repo.

 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 16 
+
 1 file changed, 16 insertions(+)

[PATCH 0/4] arm64: renesas: enable M3ULCB board peripherals

[Vladimir Barinov]

Hello,

This adds the folowing:
- R8A7796 SoC based M3ULCB board peripherals

Vladimir Barinov (4):
[1/4] arm64: dts: m3ulcb: enable I2C
[2/4] arm64: dts: m3ulcb: Update memory node to 2 GiB map
[3/4] arm64: dts: m3ulcb: enable EthernetAVB
[4/4] arm64: dts: m3ulcb: enable HS200 for eMMC

---
This patchset is against the 'kernel/git/horms/renesas.git' repo.

 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 50 
+
 1 file changed, 50 insertions(+)

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Wolfram Sang]

> The issue happened with renesas-devel, i.e. without those patches.
> It was mentioned during last core meeting, so have a look at that log.

No need to. As I said, the behaviour is expected without the patches.
Thanks for the update!



signature.asc
Description: PGP signature

[PATCH 3/4] arm64: dts: m3ulcb: enable EthernetAVB

[Vladimir Barinov]

From: Vladimir Barinov 

This supports Ethernet AVB on M3ULCB board

Signed-off-by: Vladimir Barinov 
---
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 32 ++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 38bde9d..c7f40f8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -20,6 +20,7 @@
 
aliases {
serial0 = 
+   ethernet0 = 
};
 
chosen {
@@ -115,6 +116,11 @@
pinctrl-0 = <_clk_pins>;
pinctrl-names = "default";
 
+   avb_pins: avb {
+   groups = "avb_mdc";
+   function = "avb";
+   };
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
@@ -155,6 +161,32 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   renesas,no-ether-link;
+   phy-handle = <>;
+   status = "okay";
+
+   phy0: ethernet-phy@0 {
+   rxc-skew-ps = <900>;
+   rxdv-skew-ps = <0>;
+   rxd0-skew-ps = <0>;
+   rxd1-skew-ps = <0>;
+   rxd2-skew-ps = <0>;
+   rxd3-skew-ps = <0>;
+   txc-skew-ps = <900>;
+   txen-skew-ps = <0>;
+   txd0-skew-ps = <0>;
+   txd1-skew-ps = <0>;
+   txd2-skew-ps = <0>;
+   txd3-skew-ps = <0>;
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-1 = <_pins_uhs>;
-- 
1.9.1

[PATCH 4/4] arm64: dts: m3ulcb: enable HS200 for eMMC

[Vladimir Barinov]

From: Vladimir Barinov 

This supports HS200 mode for eMMC on M3ULCB board

Signed-off-by: Vladimir Barinov 
---
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index c7f40f8..c3e0b9e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -209,6 +209,7 @@
vmmc-supply = <_3p3v>;
vqmmc-supply = <_1p8v>;
bus-width = <8>;
+   mmc-hs200-1_8v;
non-removable;
status = "okay";
 };
-- 
1.9.1

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Geert Uytterhoeven]

Hi Wolfram,

On Thu, Jan 26, 2017 at 11:03 AM, Wolfram Sang  wrote:
> On Thu, Jan 26, 2017 at 11:01:17AM +0100, Simon Horman wrote:
>> On Fri, Jan 13, 2017 at 09:39:28AM +0100, Wolfram Sang wrote:
>> > > Sorry for missing these.
>> > > I have queued them up for v4.11.
>> >
>> > Thank you!
>>
>> On my r8a7796/salvator-x I see the following with this series applied:
>>
>> sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13)
>
> Do you have the HS200 enablement patches in that branch? They are
> currently in -next.

I saw the same thing with renesas-devel last week, only on M3-W.
The same kernel on H3 didn't spew such messages.
According to Shimoda-san, it was due to different eMMCs on H3 and M3-W.

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 v5 net] ravb: unmap descriptors when freeing rings

[Simon Horman]

From: Kazuya Mizuguchi 

"swiotlb buffer is full" errors occur after repeated initialisation of a
device - f.e. suspend/resume or ip link set up/down. This is because memory
mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
is not released.  Resolve this problem by unmapping descriptors when
freeing rings.

Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi 
[simon: reworked]
Signed-off-by: Simon Horman 
--

On inspection it appears that a similar problem is also present in
the SH-Ethernet driver.

v5 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Correct bogus fixes tag
  - Count neither bytes nor packets if skb is not transmitted

v4 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Use bool as type for new parameter to ravb_tx_free()
  - Clean up comment style
  - Only increment tx_bytes for transmitted skbs

v3 [Simon Horman]
* As suggested by Sergei Shtylyov
  - consistently use le32_to_cpu(desc->dptr)
  - Do not clear desc->ds_cc as it is not used
* Paramatise ravb_tx_free() to allow it to free non-transmitted buffers

v2 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
this is consistent with the way that they are mapped
  - Use ravb_tx_free() to clear TX descriptors
* Reduce scope of new local variable

v1 [Kazuya Mizuguchi]
---
 drivers/net/ethernet/renesas/ravb_main.c | 112 ++-
 1 file changed, 64 insertions(+), 48 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 89ac1e3f6175..301f48755093 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -179,6 +179,49 @@ static struct mdiobb_ops bb_ops = {
.get_mdio_data = ravb_get_mdio_data,
 };
 
+/* Free TX skb function for AVB-IP */
+static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
+{
+   struct ravb_private *priv = netdev_priv(ndev);
+   struct net_device_stats *stats = >stats[q];
+   struct ravb_tx_desc *desc;
+   int free_num = 0;
+   int entry;
+   u32 size;
+
+   for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
+   bool txed;
+
+   entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+   desc = >tx_ring[q][entry];
+   txed = desc->die_dt == DT_FEMPTY;
+   if (free_txed_only && !txed)
+   break;
+   /* Descriptor type must be checked before all other reads */
+   dma_rmb();
+   size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+   /* Free the original skb. */
+   if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+   dma_unmap_single(ndev->dev.parent, 
le32_to_cpu(desc->dptr),
+size, DMA_TO_DEVICE);
+   /* Last packet descriptor? */
+   if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
+   entry /= NUM_TX_DESC;
+   dev_kfree_skb_any(priv->tx_skb[q][entry]);
+   priv->tx_skb[q][entry] = NULL;
+   if (txed)
+   stats->tx_packets++;
+   }
+   free_num++;
+   }
+   if (txed)
+   stats->tx_bytes += size;
+   desc->die_dt = DT_EEMPTY;
+   }
+   return free_num;
+}
+
 /* Free skb's and DMA buffers for Ethernet AVB */
 static void ravb_ring_free(struct net_device *ndev, int q)
 {
@@ -194,19 +237,21 @@ static void ravb_ring_free(struct net_device *ndev, int q)
kfree(priv->rx_skb[q]);
priv->rx_skb[q] = NULL;
 
-   /* Free TX skb ringbuffer */
-   if (priv->tx_skb[q]) {
-   for (i = 0; i < priv->num_tx_ring[q]; i++)
-   dev_kfree_skb(priv->tx_skb[q][i]);
-   }
-   kfree(priv->tx_skb[q]);
-   priv->tx_skb[q] = NULL;
-
/* Free aligned TX buffers */
kfree(priv->tx_align[q]);
priv->tx_align[q] = NULL;
 
if (priv->rx_ring[q]) {
+   for (i = 0; i < priv->num_rx_ring[q]; i++) {
+   struct ravb_ex_rx_desc *desc = >rx_ring[q][i];
+
+   if (!dma_mapping_error(ndev->dev.parent,
+  le32_to_cpu(desc->dptr)))
+   dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(desc->dptr),
+PKT_BUF_SZ,
+DMA_FROM_DEVICE);
+ 

Re: [PATCH/RFC] iommu/ipmmu-vmsa: Restrict IOMMU Domain Geometry to 32-bit address space

[Geert Uytterhoeven]

Hi Robin,

On Thu, Jan 26, 2017 at 12:23 PM, Robin Murphy  wrote:
> On 26/01/17 09:53, Geert Uytterhoeven wrote:
>> Currently, the IPMMU/VMSA driver supports 32-bit I/O Virtual Addresses
>> only, and thus sets io_pgtable_cfg.ias = 32.  However, it doesn't force
>> a 32-bit IOVA space through the IOMMU Domain Geometry.
>>
>> Hence if a device (e.g. SYS-DMAC) rightfully configures a 40-bit DMA
>> mask, it will still be handed out a 40-bit IOVA, outside the 32-bit IOVA
>> space, leading to out-of-bounds accesses of the PGD when mapping the
>> IOVA.
>>
>> Force a 32-bit IOMMU Domain Geometry to fix this.
>
> Reviewed-by: Robin Murphy 

Thanks!

>> Signed-off-by: Geert Uytterhoeven 
>> ---
>> Should the generic code restrict the geometry based on IAS instead?
>
> Which generic code? IAS is specific to the io-pgtable library (well,
> really it's an ARM-SMMU-ism, but "input address size" is a fairly
> portable concept), but io-pgtable is just factored-out driver helper
> code and doesn't know anything about iommu_domains and the IOMMU API.
> Conversely, the IOMMU API core and kernel code beyond also know nothing
> about io-pgtable internals - in fact the domain geometry *is* how the
> IOMMU driver communicates its configured address space size to the
> outside world.

OK, so the IPMMU/VMSA does have to take care of it itself.

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 RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Wolfram Sang]

> > Do you already fetch from Ulf's kernel.org tree? He switched away from
> > the Linaro tree for MMC for a while. I only realized when he complained

"since a while" not "for a while", of course.

> Thanks, I had not realised that. I've pulled the kernel.org tree.

So, there is hope for the patches to be in v4.11? :)



signature.asc
Description: PGP signature

Re: [PATCH v4 net] ravb: unmap descriptors when freeing rings

[Simon Horman]

On Thu, Jan 26, 2017 at 03:58:45PM +0300, Sergei Shtylyov wrote:
> On 01/26/2017 02:04 PM, Simon Horman wrote:
> 
> >From: Kazuya Mizuguchi 
> >
> >"swiotlb buffer is full" errors occur after repeated initialisation of a
> >device - f.e. suspend/resume or ip link set up/down. This is because memory
> >mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
> >is not released.  Resolve this problem by unmapping descriptors when
> >freeing rings.
> >
> >Fixes: a780893c89f6 ("ravb: unmap descriptors when freeing rings")
> 
>No such SHA1 hash known and the summary is from this patch.

Sorry, it took the HEAD commit rather than a hash I should have provided
as an argument to git fixes:


[alias]
fixes = log -1 --pretty=fixes
[core]
abbrev = 12
[pretty]
fixes = Fixes: %h (\"%s\")

What I wanted to say was:

Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")

> >Signed-off-by: Kazuya Mizuguchi 
> >[simon: reworked]
> >Signed-off-by: Simon Horman 
> >--
> >
> >On inspection it appears that a similar problem is also present in
> >the SH-Ethernet driver.
> >
> >v4 [Simon Horman]
> >* As suggested by Sergei Shtylyov
> >  - Use bool as type for new parameter to ravb_tx_free()
> >  - Clean up comment style
> >  - Only increment tx_bytes for transmitted skbs
> >
> >v3 [Simon Horman]
> >* As suggested by Sergei Shtylyov
> >  - consistently use le32_to_cpu(desc->dptr)
> >  - Do not clear desc->ds_cc as it is not used
> >* Paramatise ravb_tx_free() to allow it to free non-transmitted buffers
> >
> >v2 [Simon Horman]
> >* As suggested by Sergei Shtylyov
> >  - Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
> >this is consistent with the way that they are mapped
> >  - Use ravb_tx_free() to clear TX descriptors
> >* Reduce scope of new local variable
> >
> >v1 [Kazuya Mizuguchi]
> >---
> > drivers/net/ethernet/renesas/ravb_main.c | 111 
> > ++-
> > 1 file changed, 63 insertions(+), 48 deletions(-)
> >
> >diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
> >b/drivers/net/ethernet/renesas/ravb_main.c
> >index 89ac1e3f6175..5d66ac721335 100644
> >--- a/drivers/net/ethernet/renesas/ravb_main.c
> >+++ b/drivers/net/ethernet/renesas/ravb_main.c
> >@@ -179,6 +179,48 @@ static struct mdiobb_ops bb_ops = {
> > .get_mdio_data = ravb_get_mdio_data,
> > };
> >
> >+/* Free TX skb function for AVB-IP */
> >+static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
> >+{
> >+struct ravb_private *priv = netdev_priv(ndev);
> >+struct net_device_stats *stats = >stats[q];
> >+struct ravb_tx_desc *desc;
> >+int free_num = 0;
> >+int entry;
> >+u32 size;
> >+
> >+for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
> >+bool txed;
> >+
> >+entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
> >+ NUM_TX_DESC);
> >+desc = >tx_ring[q][entry];
> >+txed = desc->die_dt == DT_FEMPTY;
> >+if (free_txed_only && !txed)
> >+break;
> >+/* Descriptor type must be checked before all other reads */
> >+dma_rmb();
> >+size = le16_to_cpu(desc->ds_tagl) & TX_DS;
> >+/* Free the original skb. */
> >+if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
> >+dma_unmap_single(ndev->dev.parent, 
> >le32_to_cpu(desc->dptr),
> >+ size, DMA_TO_DEVICE);
> >+/* Last packet descriptor? */
> >+if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
> >+entry /= NUM_TX_DESC;
> >+dev_kfree_skb_any(priv->tx_skb[q][entry]);
> >+priv->tx_skb[q][entry] = NULL;
> >+stats->tx_packets++;
> 
>We're still incrementing the packet # even when the packet hasn't been 
> sent...

Thanks, sorry for missing that.

> >+}
> >+free_num++;
> >+}
> >+if (!txed)
> 
>Your logic is reversed! :-(

Oops.

> >+stats->tx_bytes += size;
> >+desc->die_dt = DT_EEMPTY;
> >+}
> >+return free_num;
> >+}
> >+
> > /* Free skb's and DMA buffers for Ethernet AVB */
> > static void ravb_ring_free(struct net_device *ndev, int q)
> > {
> >@@ -194,19 +236,21 @@ static void ravb_ring_free(struct net_device *ndev, 
> >int q)
> [...]
> >
> > if (priv->rx_ring[q]) {
> >+for (i = 0; i < priv->num_rx_ring[q]; i++) {
> >+struct ravb_ex_rx_desc *desc = >rx_ring[q][i];
> >+
> >+if (!dma_mapping_error(ndev->dev.parent,
> >+   le32_to_cpu(desc->dptr)))
> 
>I'd check for zero buffer 

RE: [PATCH v6 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100 clocks

[Chris Brandt]

On Thursday, January 26, 2017, Wolfram Sang wrote:
> Subject: Re: [PATCH v6 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100
> clocks
> 
> 
> > Thanks, applied patch1 and patch2 for next. Patch3 is for Simon, I
> > guess!? (And I can add Rob's ack afterwards).
> 
> Can you add my tags as well. They got dropped somehow:
> 
> Reviewed-by: Wolfram Sang 

Sorry, that was my fault. It looks like you added that back on patch set
v3, but I forgot to add that when sending v4+.


Chris

RE: [PATCH v6 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100 clocks

[Chris Brandt]

Hi Simon,

On Thursday, January 26, 2017, Simon Horman wrote:
> > Thanks, applied patch1 and patch2 for next. Patch3 is for Simon, I
> > guess!? (And I can add Rob's ack afterwards).
> 
> Thanks, I will take care of the 3rd patch.
> 
> Chris, is it safe to apply the 3rd patch without the first 2 patches
> present?

Yes, it is safe.

Chris

RE: [PATCH v4 2/2] clocksource: Add renesas-ostm timer driver

[Chris Brandt]

Hi Daniel,

On Thursday, January 26, 2017, Daniel Lezcano wrote:
> > ---
> > v3:
> > * Added more details to commit log
> > * Kconfig: SYS_SUPPORTS_RENESAS_OSTM to just RENESAS_OSTM
> > * removed all MODULE code (this driver is builtin only)
> > * removed items from 'struct ostm_device'
> > * changed ioread8 to readb
> 
> The iowrite* conversion is missing.
> 
> s/iowrite8/writeb/
> s/iowrite32/writel/
> 
> Other than that the driver looks good to me.

Ugh. I missed that.

Thanks!

Chris

Re: [PATCH] v4l: of: check for unique lanes in data-lanes and clock-lanes

[Geert Uytterhoeven]

Hi Niklas,

On Thu, Jan 26, 2017 at 2:12 PM, Niklas Söderlund
 wrote:
> diff --git a/drivers/media/v4l2-core/v4l2-of.c 
> b/drivers/media/v4l2-core/v4l2-of.c
> index 93b33681776c..1042db6bb996 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -32,12 +32,19 @@ static int v4l2_of_parse_csi_bus(const struct device_node 
> *node,
> prop = of_find_property(node, "data-lanes", NULL);
> if (prop) {
> const __be32 *lane = NULL;
> -   unsigned int i;
> +   unsigned int i, n;

Not "j"?

> for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
> lane = of_prop_next_u32(prop, lane, );
> if (!lane)
> break;
> +   for (n = 0; n < i; n++) {

I'm not used seeing for loops with an index named "n", and limit named "i" ;-)

> +   if (bus->data_lanes[n] == v) {
> +   pr_warn("%s: duplicated lane %u in 
> data-lanes\n",
> +   node->full_name, v);
> +   return -EINVAL;
> +   }
> +   }
> bus->data_lanes[i] = v;
> }
> bus->num_data_lanes = i;
> @@ -63,6 +70,15 @@ static int v4l2_of_parse_csi_bus(const struct device_node 
> *node,
> }
>
> if (!of_property_read_u32(node, "clock-lanes", )) {
> +   unsigned int n;

Likewise.

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 RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Wolfram Sang]

> > Do you have the HS200 enablement patches in that branch? They are
> > currently in -next.
> 
> I tried mmc/next (but didn't notice anything special there).
> Which patches should I be looking for?

The series starting with 59c21074b582aa ("mmc: sh_mobile_sdhi: simplify
accessing DT data") up to 8c81459fa8adec ("mmc: sh_mobile_sdhi: enable
HS200").

Do you already fetch from Ulf's kernel.org tree? He switched away from
the Linaro tree for MMC for a while. I only realized when he complained
that he can't apply my patches.



signature.asc
Description: PGP signature

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Geert Uytterhoeven]

Hi Wolfram,

On Thu, Jan 26, 2017 at 3:16 PM, Wolfram Sang  wrote:
>> I have tested with "the new mmc/next" and things seem better.
>
> Good. The issue you saw is expected when you have not the enablement
> patches in place.
>
>> I am still of a mind to drop the M3-W patch of this series because unless
>> we can control the order that things are merged into Linus's tree
>> there will be a temporary regression there. Moreover I'm not very excited
>> about renesas-next having regressed.
>
> I have not heard of a regression. Geert, did you report that? Did I miss
> that? As you can see, I did test the patches with M3 as well:
>
> http://elinux.org/Tests:eMMC-HS
>
> and Jinso test team (Duc-san) confirmed it works for them with H3 and
> M3-W. In private communication, though.

The issue happened with renesas-devel, i.e. without those patches.
It was mentioned during last core meeting, so have a look at that log.

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 v5 2/3] mmc: sh_mobile_sdhi: explain clock bindings

[Rob Herring]

On Mon, Jan 23, 2017 at 11:56 AM, Chris Brandt  wrote:
> Hello Rob,
>
>
> On Monday, January 23, 2017, Rob Herring wrote:
>> > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
>> > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
>> > @@ -25,8 +25,32 @@ Required properties:
>> > "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
>> > "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC
>> >
>> > +- clocks: Most controllers only have 1 clock source per channel.
>> However, on
>> > + some variations of this controller, the internal card detection
>>
>> This should be explicit as to which compatible strings have 2 clocks and
>> which have 1 clock.
>
> OK. I'll make a list like I did for sh_mmcif:
>
> https://patchwork.kernel.org/patch/9512091/
>
>
>
>> > +
>> > +Example showing 2 clocks:
>> > +   sdhi0: sd@e804e000 {
>>
>> mmc@...
>
> I'm confused. I see that for all SDHI controllers, it either "sd@" or 
> "sdhci@".
>
> $ grep sdhi $(find arch/arm/boot/dts -name "*.dtsi")
>
> $ grep sdhci $(find arch/arm/boot/dts -name "*.dtsi")

Yes, there's lots of variation. Node names are supposed to be generic
for their class of device (e.g. ethernet, pci, usb,
interrupt-controller, etc.). I'd be fine with "sd", but think "mmc" is
more common. Either way, we should pick one moving forward. "sdhci"
should not be used as that's a specific implementation.

Rob

[PATCH v4 net] ravb: unmap descriptors when freeing rings

[Simon Horman]

From: Kazuya Mizuguchi 

"swiotlb buffer is full" errors occur after repeated initialisation of a
device - f.e. suspend/resume or ip link set up/down. This is because memory
mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
is not released.  Resolve this problem by unmapping descriptors when
freeing rings.

Fixes: a780893c89f6 ("ravb: unmap descriptors when freeing rings")
Signed-off-by: Kazuya Mizuguchi 
[simon: reworked]
Signed-off-by: Simon Horman 
--

On inspection it appears that a similar problem is also present in
the SH-Ethernet driver.

v4 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Use bool as type for new parameter to ravb_tx_free()
  - Clean up comment style
  - Only increment tx_bytes for transmitted skbs

v3 [Simon Horman]
* As suggested by Sergei Shtylyov
  - consistently use le32_to_cpu(desc->dptr)
  - Do not clear desc->ds_cc as it is not used
* Paramatise ravb_tx_free() to allow it to free non-transmitted buffers

v2 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
this is consistent with the way that they are mapped
  - Use ravb_tx_free() to clear TX descriptors
* Reduce scope of new local variable

v1 [Kazuya Mizuguchi]
---
 drivers/net/ethernet/renesas/ravb_main.c | 111 ++-
 1 file changed, 63 insertions(+), 48 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 89ac1e3f6175..5d66ac721335 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -179,6 +179,48 @@ static struct mdiobb_ops bb_ops = {
.get_mdio_data = ravb_get_mdio_data,
 };
 
+/* Free TX skb function for AVB-IP */
+static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
+{
+   struct ravb_private *priv = netdev_priv(ndev);
+   struct net_device_stats *stats = >stats[q];
+   struct ravb_tx_desc *desc;
+   int free_num = 0;
+   int entry;
+   u32 size;
+
+   for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
+   bool txed;
+
+   entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+   desc = >tx_ring[q][entry];
+   txed = desc->die_dt == DT_FEMPTY;
+   if (free_txed_only && !txed)
+   break;
+   /* Descriptor type must be checked before all other reads */
+   dma_rmb();
+   size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+   /* Free the original skb. */
+   if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+   dma_unmap_single(ndev->dev.parent, 
le32_to_cpu(desc->dptr),
+size, DMA_TO_DEVICE);
+   /* Last packet descriptor? */
+   if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
+   entry /= NUM_TX_DESC;
+   dev_kfree_skb_any(priv->tx_skb[q][entry]);
+   priv->tx_skb[q][entry] = NULL;
+   stats->tx_packets++;
+   }
+   free_num++;
+   }
+   if (!txed)
+   stats->tx_bytes += size;
+   desc->die_dt = DT_EEMPTY;
+   }
+   return free_num;
+}
+
 /* Free skb's and DMA buffers for Ethernet AVB */
 static void ravb_ring_free(struct net_device *ndev, int q)
 {
@@ -194,19 +236,21 @@ static void ravb_ring_free(struct net_device *ndev, int q)
kfree(priv->rx_skb[q]);
priv->rx_skb[q] = NULL;
 
-   /* Free TX skb ringbuffer */
-   if (priv->tx_skb[q]) {
-   for (i = 0; i < priv->num_tx_ring[q]; i++)
-   dev_kfree_skb(priv->tx_skb[q][i]);
-   }
-   kfree(priv->tx_skb[q]);
-   priv->tx_skb[q] = NULL;
-
/* Free aligned TX buffers */
kfree(priv->tx_align[q]);
priv->tx_align[q] = NULL;
 
if (priv->rx_ring[q]) {
+   for (i = 0; i < priv->num_rx_ring[q]; i++) {
+   struct ravb_ex_rx_desc *desc = >rx_ring[q][i];
+
+   if (!dma_mapping_error(ndev->dev.parent,
+  le32_to_cpu(desc->dptr)))
+   dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(desc->dptr),
+PKT_BUF_SZ,
+DMA_FROM_DEVICE);
+   }
ring_size = sizeof(struct ravb_ex_rx_desc) *
(priv->num_rx_ring[q] + 1);
dma_free_coherent(ndev->dev.parent, ring_size, 

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Wolfram Sang]

> I have tested with "the new mmc/next" and things seem better.

Good. The issue you saw is expected when you have not the enablement
patches in place.

> I am still of a mind to drop the M3-W patch of this series because unless
> we can control the order that things are merged into Linus's tree
> there will be a temporary regression there. Moreover I'm not very excited
> about renesas-next having regressed.

I have not heard of a regression. Geert, did you report that? Did I miss
that? As you can see, I did test the patches with M3 as well:

http://elinux.org/Tests:eMMC-HS

and Jinso test team (Duc-san) confirmed it works for them with H3 and
M3-W. In private communication, though.

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH/RFC] iommu/ipmmu-vmsa: Restrict IOMMU Domain Geometry to 32-bit address space

[Robin Murphy]

On 26/01/17 09:53, Geert Uytterhoeven wrote:
> Currently, the IPMMU/VMSA driver supports 32-bit I/O Virtual Addresses
> only, and thus sets io_pgtable_cfg.ias = 32.  However, it doesn't force
> a 32-bit IOVA space through the IOMMU Domain Geometry.
> 
> Hence if a device (e.g. SYS-DMAC) rightfully configures a 40-bit DMA
> mask, it will still be handed out a 40-bit IOVA, outside the 32-bit IOVA
> space, leading to out-of-bounds accesses of the PGD when mapping the
> IOVA.
> 
> Force a 32-bit IOMMU Domain Geometry to fix this.

Reviewed-by: Robin Murphy 

> Signed-off-by: Geert Uytterhoeven 
> ---
> Should the generic code restrict the geometry based on IAS instead?

Which generic code? IAS is specific to the io-pgtable library (well,
really it's an ARM-SMMU-ism, but "input address size" is a fairly
portable concept), but io-pgtable is just factored-out driver helper
code and doesn't know anything about iommu_domains and the IOMMU API.
Conversely, the IOMMU API core and kernel code beyond also know nothing
about io-pgtable internals - in fact the domain geometry *is* how the
IOMMU driver communicates its configured address space size to the
outside world.

Robin.

> ---
>  drivers/iommu/ipmmu-vmsa.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 798578f1676480c6..eb8b3df8733b15fb 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -424,6 +424,8 @@ static int ipmmu_domain_init_context(struct 
> ipmmu_vmsa_domain *domain)
>   domain->cfg.ias = 32;
>   domain->cfg.oas = 40;
>   domain->cfg.tlb = _gather_ops;
> + domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(32);
> + domain->io_domain.geometry.force_aperture = true;
>   /*
>* TODO: Add support for coherent walk through CCI with DVM and remove
>* cache handling. For now, delegate it to the io-pgtable code.
> 

Re: [PATCH v4 net] ravb: unmap descriptors when freeing rings

[Sergei Shtylyov]

On 01/26/2017 02:04 PM, Simon Horman wrote:


From: Kazuya Mizuguchi 

"swiotlb buffer is full" errors occur after repeated initialisation of a
device - f.e. suspend/resume or ip link set up/down. This is because memory
mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
is not released.  Resolve this problem by unmapping descriptors when
freeing rings.

Fixes: a780893c89f6 ("ravb: unmap descriptors when freeing rings")


   No such SHA1 hash known and the summary is from this patch.


Signed-off-by: Kazuya Mizuguchi 
[simon: reworked]
Signed-off-by: Simon Horman 
--

On inspection it appears that a similar problem is also present in
the SH-Ethernet driver.

v4 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Use bool as type for new parameter to ravb_tx_free()
  - Clean up comment style
  - Only increment tx_bytes for transmitted skbs

v3 [Simon Horman]
* As suggested by Sergei Shtylyov
  - consistently use le32_to_cpu(desc->dptr)
  - Do not clear desc->ds_cc as it is not used
* Paramatise ravb_tx_free() to allow it to free non-transmitted buffers

v2 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
this is consistent with the way that they are mapped
  - Use ravb_tx_free() to clear TX descriptors
* Reduce scope of new local variable

v1 [Kazuya Mizuguchi]
---
 drivers/net/ethernet/renesas/ravb_main.c | 111 ++-
 1 file changed, 63 insertions(+), 48 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 89ac1e3f6175..5d66ac721335 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -179,6 +179,48 @@ static struct mdiobb_ops bb_ops = {
.get_mdio_data = ravb_get_mdio_data,
 };

+/* Free TX skb function for AVB-IP */
+static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)
+{
+   struct ravb_private *priv = netdev_priv(ndev);
+   struct net_device_stats *stats = >stats[q];
+   struct ravb_tx_desc *desc;
+   int free_num = 0;
+   int entry;
+   u32 size;
+
+   for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
+   bool txed;
+
+   entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+   desc = >tx_ring[q][entry];
+   txed = desc->die_dt == DT_FEMPTY;
+   if (free_txed_only && !txed)
+   break;
+   /* Descriptor type must be checked before all other reads */
+   dma_rmb();
+   size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+   /* Free the original skb. */
+   if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+   dma_unmap_single(ndev->dev.parent, 
le32_to_cpu(desc->dptr),
+size, DMA_TO_DEVICE);
+   /* Last packet descriptor? */
+   if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
+   entry /= NUM_TX_DESC;
+   dev_kfree_skb_any(priv->tx_skb[q][entry]);
+   priv->tx_skb[q][entry] = NULL;
+   stats->tx_packets++;


   We're still incrementing the packet # even when the packet hasn't been 
sent...


+   }
+   free_num++;
+   }
+   if (!txed)


   Your logic is reversed! :-(


+   stats->tx_bytes += size;
+   desc->die_dt = DT_EEMPTY;
+   }
+   return free_num;
+}
+
 /* Free skb's and DMA buffers for Ethernet AVB */
 static void ravb_ring_free(struct net_device *ndev, int q)
 {
@@ -194,19 +236,21 @@ static void ravb_ring_free(struct net_device *ndev, int q)

[...]


if (priv->rx_ring[q]) {
+   for (i = 0; i < priv->num_rx_ring[q]; i++) {
+   struct ravb_ex_rx_desc *desc = >rx_ring[q][i];
+
+   if (!dma_mapping_error(ndev->dev.parent,
+  le32_to_cpu(desc->dptr)))


   I'd check for zero buffer length (that marks unmapped RX buffers) but this 
should be good too... it's just that the length check is shorter. :-)



+   dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(desc->dptr),
+PKT_BUF_SZ,
+DMA_FROM_DEVICE);
+   }
ring_size = sizeof(struct ravb_ex_rx_desc) *
(priv->num_rx_ring[q] + 1);
dma_free_coherent(ndev->dev.parent, ring_size, priv->rx_ring[q],

[...]

MBR, Sergei

[PATCH] v4l: of: check for unique lanes in data-lanes and clock-lanes

[Niklas Söderlund]

All lines in data-lanes and clock-lanes properties must be unique.
Instead of drivers checking for this add it to the generic parser.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-of.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
index 93b33681776c..1042db6bb996 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -32,12 +32,19 @@ static int v4l2_of_parse_csi_bus(const struct device_node 
*node,
prop = of_find_property(node, "data-lanes", NULL);
if (prop) {
const __be32 *lane = NULL;
-   unsigned int i;
+   unsigned int i, n;
 
for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
lane = of_prop_next_u32(prop, lane, );
if (!lane)
break;
+   for (n = 0; n < i; n++) {
+   if (bus->data_lanes[n] == v) {
+   pr_warn("%s: duplicated lane %u in 
data-lanes\n",
+   node->full_name, v);
+   return -EINVAL;
+   }
+   }
bus->data_lanes[i] = v;
}
bus->num_data_lanes = i;
@@ -63,6 +70,15 @@ static int v4l2_of_parse_csi_bus(const struct device_node 
*node,
}
 
if (!of_property_read_u32(node, "clock-lanes", )) {
+   unsigned int n;
+
+   for (n = 0; n < bus->num_data_lanes; n++) {
+   if (bus->data_lanes[n] == v) {
+   pr_warn("%s: duplicated lane %u in 
clock-lanes\n",
+   node->full_name, v);
+   return -EINVAL;
+   }
+   }
bus->clock_lane = v;
have_clk_lane = true;
}
-- 
2.11.0

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Simon Horman]

On Thu, Jan 26, 2017 at 12:36:57PM +0100, Wolfram Sang wrote:
> 
> > > Do you have the HS200 enablement patches in that branch? They are
> > > currently in -next.
> > 
> > I tried mmc/next (but didn't notice anything special there).
> > Which patches should I be looking for?
> 
> The series starting with 59c21074b582aa ("mmc: sh_mobile_sdhi: simplify
> accessing DT data") up to 8c81459fa8adec ("mmc: sh_mobile_sdhi: enable
> HS200").
> 
> Do you already fetch from Ulf's kernel.org tree? He switched away from
> the Linaro tree for MMC for a while. I only realized when he complained
> that he can't apply my patches.

Thanks, I had not realised that. I've pulled the kernel.org tree.

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Simon Horman]

On Thu, Jan 26, 2017 at 02:54:53PM +0100, Wolfram Sang wrote:
> 
> > > Do you already fetch from Ulf's kernel.org tree? He switched away from
> > > the Linaro tree for MMC for a while. I only realized when he complained
> 
> "since a while" not "for a while", of course.
> 
> > Thanks, I had not realised that. I've pulled the kernel.org tree.

I have tested with "the new mmc/next" and things seem better.
The problem does not appear to manifest in light testing.

> So, there is hope for the patches to be in v4.11? :)

On Thu, Jan 26, 2017 at 02:58:58PM +0100, Geert Uytterhoeven wrote:
> Hi Wolfram,
> 
> On Thu, Jan 26, 2017 at 11:03 AM, Wolfram Sang  wrote:
> > On Thu, Jan 26, 2017 at 11:01:17AM +0100, Simon Horman wrote:
> >> On Fri, Jan 13, 2017 at 09:39:28AM +0100, Wolfram Sang wrote:
> >> > > Sorry for missing these.
> >> > > I have queued them up for v4.11.
> >> >
> >> > Thank you!
> >>
> >> On my r8a7796/salvator-x I see the following with this series applied:
> >>
> >> sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13)
> >
> > Do you have the HS200 enablement patches in that branch? They are
> > currently in -next.
> 
> I saw the same thing with renesas-devel last week, only on M3-W.
> The same kernel on H3 didn't spew such messages.
> According to Shimoda-san, it was due to different eMMCs on H3 and M3-W.

Thanks, my interpretation of that is that the H3 patch of this series is fine.

I am still of a mind to drop the M3-W patch of this series because unless
we can control the order that things are merged into Linus's tree
there will be a temporary regression there. Moreover I'm not very excited
about renesas-next having regressed.

Re: [PATCH v5 net] ravb: unmap descriptors when freeing rings

[Sergei Shtylyov]

On 01/26/2017 04:29 PM, Simon Horman wrote:


From: Kazuya Mizuguchi 


   Well, Kazuya's patch is so far from your now, you could have said it was 
reported by him or that your patch is loosely based on his one. :-)



"swiotlb buffer is full" errors occur after repeated initialisation of a
device - f.e. suspend/resume or ip link set up/down. This is because memory
mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
is not released.  Resolve this problem by unmapping descriptors when
freeing rings.

Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi 
[simon: reworked]
Signed-off-by: Simon Horman 


Acked-by: Sergei Shtylyov 


--


   --- is needed here...


---


   ... unlike this place. :-)


 drivers/net/ethernet/renesas/ravb_main.c | 112 ++-
 1 file changed, 64 insertions(+), 48 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 89ac1e3f6175..301f48755093 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -179,6 +179,49 @@ static struct mdiobb_ops bb_ops = {
.get_mdio_data = ravb_get_mdio_data,
 };

+/* Free TX skb function for AVB-IP */
+static int ravb_tx_free(struct net_device *ndev, int q, bool free_txed_only)


   I'd have called the last parameter just 'all' or at least would have 
avoided such verbs as 'txed'... :-)



+{
+   struct ravb_private *priv = netdev_priv(ndev);
+   struct net_device_stats *stats = >stats[q];
+   struct ravb_tx_desc *desc;
+   int free_num = 0;
+   int entry;
+   u32 size;
+
+   for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
+   bool txed;


I'd have declared this in the function scope like all other local vars.
And would have chosen somewhat clearer name, like 'sent'. :-)

[...]

MBR, Sergei

Re: [PATCH v3 1/8] pinctrl: sh-pfc: Add r7s72100 PFC driver

[Wolfram Sang]

Just some very minor nits... Probably not worth the resend.

On Mon, Jan 16, 2017 at 01:12:45PM +0100, Jacopo Mondi wrote:
> From: Magnus Damm 
> 
> Squash commits in Geert's renesas-driver/genmai-gpio-and-pfc branch that
> add support for r7s72100 PFC.
> This squash combines commits for Magnus' original driver, several
> "groups" definitions and minor fixes on top to forward-port it to a more
> recent kernel (v4.10)
> 
> Signed-off-by: Magnus Damm 
> Signed-off-by: Wolfram Sang 

I'd prefer the "wsa+renesas@..." address here, too.

> Signed-off-by: Simon Horman 
> Signed-off-by: Geert Uytterhoeven 
> Signed-off-by: Jacopo Mondi 

...

> diff --git a/drivers/pinctrl/sh-pfc/pfc-r7s72100.c 
> b/drivers/pinctrl/sh-pfc/pfc-r7s72100.c
> new file mode 100644
> index 000..72e1dff
> --- /dev/null
> +++ b/drivers/pinctrl/sh-pfc/pfc-r7s72100.c
> @@ -0,0 +1,529 @@
> +/*
> + * R7S72100 processor support
> + *
> + * Copyright (C) 2013  Renesas Electronics Corporation

2013-2017?



signature.asc
Description: PGP signature

[PATCH v5 2/2] clocksource: Add renesas-ostm timer driver

[Chris Brandt]

This patch adds a OSTM driver for the Renesas architecture.
The OS Timer (OSTM) has independent channels that can be
used as a freerun or interval times.
This driver uses the first probed device as a clocksource
and then any additional devices as clock events.

Signed-off-by: Chris Brandt 
---
v4:
* changed iowrite8/32 to writeb/l
v3:
* Added more details to commit log
* Kconfig: SYS_SUPPORTS_RENESAS_OSTM to just RENESAS_OSTM
* removed all MODULE code (this driver is builtin only)
* removed items from 'struct ostm_device'
* changed ioread8 to readb
* explain endless while loop
* removed un-needed vars like 'ret'
* removed WARN_ON(!clockevent_state_oneshot(ced));
* removed "failed to allocate memory" message
* remove pm_runtime calls
* remove "earlytimer" register (only for sh, not arm)
* convert from platform driver to CLOCKSOURCE_OF_DECLARE
* ostm_probe code is now in ostm_init
v2:
* changed implementation to be independent channel nodes
---
 arch/arm/mach-shmobile/Kconfig |   1 +
 drivers/clocksource/Kconfig|   7 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/renesas-ostm.c | 262 +
 4 files changed, 271 insertions(+)
 create mode 100644 drivers/clocksource/renesas-ostm.c

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 2bb4b09..ad7d604 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -57,6 +57,7 @@ config ARCH_R7S72100
select PM
select PM_GENERIC_DOMAINS
select SYS_SUPPORTS_SH_MTU2
+   select RENESAS_OSTM
 
 config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4866f7a..a0786a6 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -467,6 +467,13 @@ config SH_TIMER_MTU2
  Timer Pulse Unit 2 (MTU2) hardware available on SoCs from Renesas.
  This hardware comes with 16 bit-timer registers.
 
+config RENESAS_OSTM
+   bool "Renesas OSTM timer driver" if COMPILE_TEST
+   depends on GENERIC_CLOCKEVENTS
+   select CLKSRC_MMIO
+   help
+ Enables the support for the Renesas OSTM.
+
 config SH_TIMER_TMU
bool "Renesas TMU timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index a14111e..bbd163b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)+= cs5535-clockevt.o
 obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
+obj-$(CONFIG_RENESAS_OSTM) += renesas-ostm.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
 obj-$(CONFIG_EM_TIMER_STI) += em_sti.o
 obj-$(CONFIG_CLKBLD_I8253) += i8253.o
diff --git a/drivers/clocksource/renesas-ostm.c 
b/drivers/clocksource/renesas-ostm.c
new file mode 100644
index 000..2570e3f
--- /dev/null
+++ b/drivers/clocksource/renesas-ostm.c
@@ -0,0 +1,262 @@
+/*
+ * Renesas Timer Support - OSTM
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The OSTM contains independent channels.
+ * The first OSTM channel probed will be set up as a free running
+ * clocksource. Additionally we will use this clocksource for the system
+ * schedule timer sched_clock().
+ *
+ * The second (or more) channel probed will be set up as an interrupt
+ * driven clock event.
+ */
+
+struct ostm_device {
+   void __iomem *base;
+   unsigned long ticks_per_jiffy;
+   struct clock_event_device ced;
+};
+
+static void __iomem *system_clock; /* For sched_clock() */
+
+/* OSTM REGISTERS */
+#defineOSTM_CMP0x000   /* RW,32 */
+#defineOSTM_CNT0x004   /* R,32 */
+#defineOSTM_TE 0x010   /* R,8 */
+#defineOSTM_TS 0x014   /* W,8 */
+#defineOSTM_TT 0x018   /* W,8 */
+#defineOSTM_CTL0x020   /* RW,8 */
+
+#defineTE  0x01
+#defineTS  0x01
+#defineTT  0x01
+#defineCTL_PERIODIC0x00
+#defineCTL_ONESHOT 0x02
+#defineCTL_FREERUN 0x02
+
+static struct ostm_device *ced_to_ostm(struct clock_event_device *ced)
+{
+   

[PATCH v5 1/2] dt-bindings: document renesas-ostm timer

[Chris Brandt]

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
---
v3:
* changed ostm@fcfec000 to timer@fcfec000 in example
* added power-domains in example
v2:
* remove sw implementation specific portions
---
 .../devicetree/bindings/timer/renesas,ostm.txt | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt

diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt 
b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
new file mode 100644
index 000..be3ae0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
@@ -0,0 +1,30 @@
+* Renesas OS Timer (OSTM)
+
+The OSTM is a multi-channel 32-bit timer/counter with fixed clock
+source that can operate in either interval count down timer or free-running
+compare match mode.
+
+Channels are independent from each other.
+
+Required Properties:
+
+  - compatible: must be one or more of the following:
+- "renesas,r7s72100-ostm" for the r7s72100 OSTM
+- "renesas,ostm" for any OSTM
+   This is a fallback for the above renesas,*-ostm entries
+
+  - reg: base address and length of the register block for a timer channel.
+
+  - interrupts: interrupt specifier for the timer channel.
+
+  - clocks: clock specifier for the timer channel.
+
+Example: R7S72100 (RZ/A1H) OSTM node
+
+   ostm0: timer@fcfec000 {
+   compatible = "renesas,r7s72100-ostm", "renesas,ostm";
+   reg = <0xfcfec000 0x30>;
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_OSTM0>;
+   power-domains = <_clocks>;
+   };
-- 
2.10.1

[PATCH v5 0/2] clocksource: Add renesas-ostm timer driver

[Chris Brandt]

This patch set adds a new clocksource driver that uses the OS Timer
(OSTM) that exists in the R7S72100 (RZ/A1) SoC.

The operation of the driver was tested with a simple user application
that does multiple calls to nanosleep() and gettimeofday().

The purpose of adding this driver is to get better time keeping
accuracy over the default MTU2 clocksource timer.

v5:
* changed iowrite8/32 to writeb/l

v4:
* Added more details to commit log
* Kconfig: SYS_SUPPORTS_RENESAS_OSTM to just RENESAS_OSTM
* removed all MODULE code (this driver is builtin only)
* removed items from 'struct ostm_device'
* changed ioread8 to readb
* explain endless while loop
* removed un-needed vars like 'ret'
* removed WARN_ON(!clockevent_state_oneshot(ced));
* removed "failed to allocate memory" message
* remove pm_runtime calls
* remove "earlytimer" register (only for sh, not arm)
* convert from platform driver to CLOCKSOURCE_OF_DECLARE
* ostm_probe code is now in ostm_init

v3:
* Changed ostm@fcfec000 to timer@fcfec000
* Added power-domains to nodes

v2:
* The biggest change was now the channels are independent of each
  other and have separate nodes in the DT. The first probed will
  be set up as a clock source, and any additional channels probed
  will become a clock event.


Chris Brandt (2):
  dt-bindings: document renesas-ostm timer
  clocksource: Add renesas-ostm timer driver

 .../devicetree/bindings/timer/renesas,ostm.txt |  30 +++
 arch/arm/mach-shmobile/Kconfig |   1 +
 drivers/clocksource/Kconfig|   7 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/renesas-ostm.c | 262 +
 5 files changed, 301 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
 create mode 100644 drivers/clocksource/renesas-ostm.c

-- 
2.10.1

[Lager(H2)-V4.10-rc2]: DISPLAY-UNIT: Does not support 640x480 resolution & Does not support 16-bit for color numbers.

[DongCV]

Dear Stefan,
Cc: Geert,

I've tested the linux v4.10-rc2 for Gen2 Lager and found two issues 
about DISPLAY-UNIT:  Does not support 640x480 resolution & Does not 
support 16-bit for color numbers.


"root@linaro-naro:~# fbset -xres 640 -yres 480 -laced 0
 ioctl FBIOPUT_VSCREENINFO: Invalid argument"

"root@linaro-naro:~# fbset -depth 16 -rgba 5,6,5,0
 ioctl FBIOPUT_VSCREENINFO: Invalid argument"


And I found the patch which I think it is the cause of this issues.
The commit name is '865afb1 drm/fb-helper: reject any changes to the fbdev'
If I reverted this patch and retested it on H2 board, the issue will be 
gone!


Please have a look at the attached testlog file for detail.


Regards,
Dong

LAGER SPI_LOADER V0.27 2014.06.20
DEVICE S25FL512


U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)

CPU: Renesas Electronics R8A7790 rev 2.0
Board: Lager
I2C:   ready
DRAM:  512 MiB
MMC:   sh_mmcif: 0, sh-sdhi: 1, sh-sdhi: 2
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB
In:serial_sh
Out:   serial_sh
Err:   serial_sh
Net:   sh_eth
Hit any key to stop autoboot:  0 
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Half
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
DHCP client bound to address 192.168.1.235 (5781 ms)
Using sh_eth device
TFTP from server 192.168.1.225; our IP address is 192.168.1.235
Filename 'lager/uImage.dtb'.
Load address: 0x40007fc0
Loading: #
 #
 #
 #
 7.5 MiB/s
done
Bytes transferred = 3750536 (393a88 hex)
## Booting kernel from Legacy Image at 40007fc0 ...
   Image Name:   Linux-v4.10-rc2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3750472 Bytes = 3.6 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.10.0-rc2-dirty (dong@dong-Jinso) (gcc version 
4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #275 SMP Thu Jan 19 13:29:13 JST 
2017
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt:Machine model: Lager
[0.00] OF: fdt:Ignoring memory block 0x14000 - 0x2
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0a32840, node_mem_map 
ef7f9000
[0.00]   Normal zone: 1536 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] percpu: Embedded 12 pages/cpu @ef775000 s25152 r0 d24000 u49152
[0.00] pcpu-alloc: s25152 r0 d24000 u49152 alloc=12*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260608
[0.00] Kernel command line: console=ttySC0,38400 ignore_loglevel rw 
root=/dev/nfs ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1029252K/1048576K available (6144K kernel code, 207K 
rwdata, 1488K rodata, 1024K init, 300K bss, 19324K reserved, 0K cma-reserved, 
262144K high)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00]   .text : 0xc0008000 - 0xc070   (7136 kB)
[0.00]   .init : 0xc090 - 0xc0a0   (1024 kB)
[0.00]   .data : 0xc0a0 - 0xc0a33c60   ( 208 kB)
[0.00].bss : 0xc0a35000 - 0xc0a8020c   ( 301 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] arm_arch_timer: Architected cp15 timer(s) running at 10.00MHz 
(virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[0.04] sched_clock: 56 

[PATCH/RFC v2 2/4] iommu/ipmmu-vmsa: Get rid of disabled device check

[Magnus Damm]

From: Magnus Damm 

Since of_iommu_configure() now skips over disabled devices
we can simply drop this check in the IPMMU driver.

Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |7 ---
 1 file changed, 7 deletions(-)

--- 0001/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-01-27 13:09:36.840607110 +0900
@@ -1051,13 +1051,6 @@ static struct iommu_group *ipmmu_device_
 static int ipmmu_of_xlate_dma(struct device *dev,
  struct of_phandle_args *spec)
 {
-   /* If the IPMMU device is disabled in DT then return error
-* to make sure the of_iommu code does not install ops
-* even though the iommu device is disabled
-*/
-   if (!of_device_is_available(spec->np))
-   return -ENODEV;
-
return 0;
 }
 

[PATCH/RFC v2 0/4] iommu/ipmmu-vmsa: IPMMU slave device whitelist V2

[Magnus Damm]

iommu/ipmmu-vmsa: IPMMU slave device whitelist V2

[PATCH/RFC v2 1/4] iommu/of: Skip IOMMU devices disabled in DT
[PATCH/RFC v2 2/4] iommu/ipmmu-vmsa: Get rid of disabled device check
[PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Check devices in xlate()
[PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Opt-in slave devices based on ES version

Here's an updated prototype that shows how DT integration of IPMMU details
may be integrated and merged upstream based on SoC data sheet ahead of
time followed by enablement in the IPMMU driver code once the appropriate
SoC ES version has been released and the hardware has been tested.

Changes since V1:
 - Broke out patch 1 from the IPMMU driver
 - Moved slave device check from ->add_device() to ->xlate() (Thanks Robin!)
 - Updated white list patch to hook into ->xlate()

Patch 1 may be suitable for upstream merge, however other patches should
in the future if agreed on be rolled into the IPMMU driver series.

Signed-off-by: Magnus Damm 
---

 Developed on top of renesas-drivers-2017-01-24-v4.10-rc5

 drivers/iommu/ipmmu-vmsa.c |   59 +++-
 drivers/iommu/of_iommu.c   |2 -
 2 files changed, 33 insertions(+), 28 deletions(-)

[PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Opt-in slave devices based on ES version

[Magnus Damm]

From: Magnus Damm 

Match on r8a7795 ES2 and enable a certain DMA controller.
In other cases the IPMMU driver remains disabled.

Signed-off-by: Magnus Damm 
---

 Changes since V1:
 - Perform white list check in ->xlate() instead of ->add_device()

 drivers/iommu/ipmmu-vmsa.c |   25 +
 1 file changed, 25 insertions(+)

--- 0009/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-01-27 13:14:47.470607110 +0900
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
 #include 
@@ -1032,9 +1033,33 @@ static void ipmmu_remove_device_dma(stru
iommu_group_remove_device(dev);
 }
 
+static const struct soc_device_attribute r8a7795es2[] = {
+   { .soc_id = "r8a7795", .revision = "ES2.*" },
+   { /* sentinel */ }
+};
+
+static int ipmmu_slave_whitelist(struct device *dev)
+{
+   /* Opt-in slave devices based on SoC and ES version */
+   if (soc_device_match(r8a7795es2)) {
+   if (!strcmp(dev_name(dev), "e731.dma-controller"))
+   return 0;
+   }
+
+   /* By default, do not allow use of IPMMU */
+   return -ENODEV;
+}
+
 static int ipmmu_of_xlate_dma(struct device *dev,
  struct of_phandle_args *spec)
 {
+   int ret;
+
+   /* Opt-in devices based on SoC and ES version */
+   ret = ipmmu_slave_whitelist(dev);
+   if (ret)
+   return ret;
+
/* For now only tested on R-Car Gen3 with ARM64 arch init order
 * TODO: Test R-Car Gen2 with ARM32 arch init order
 */

[PATCH/RFC v2 1/4] iommu/of: Skip IOMMU devices disabled in DT

[Magnus Damm]

From: Magnus Damm 

Extend the shared IOMMU code to skip over ->xlate() in case the
IOMMU device pointed to by a slave device has been disabled in DT.

Difficult to trigger in case a single IOMMU device is used, however
when multiple IOMMUs are used and some of them are disabled in DT
then this patch makes sure that ->xlate() only gets invoked for the
enabled ones.

Signed-off-by: Magnus Damm 
---

 I used to keep this as a local check in the xlate() callback
 for the not-yet-merged-upstream R-Car Gen3 IPMMU driver stack.

 Since honoring DT disabled devices probably makes sense for most users
 it seems like a good plan to try to push it into the common subsystem level.

 Thanks to Geert for suggesting this ages ago.

 Developed on top of renesas-drivers-2017-01-24-v4.10-rc5 which
 includes a recent version of iommu/next.

 drivers/iommu/of_iommu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0001/drivers/iommu/of_iommu.c
+++ work/drivers/iommu/of_iommu.c   2017-01-27 13:19:22.540607110 +0900
@@ -159,7 +159,7 @@ const struct iommu_ops *of_iommu_configu
np = iommu_spec.np;
ops = of_iommu_get_ops(np);
 
-   if (!ops || !ops->of_xlate ||
+   if (!ops || !ops->of_xlate || !of_device_is_available(np) ||
iommu_fwspec_init(dev, >fwnode, ops) ||
ops->of_xlate(dev, _spec))
goto err_put_node;

[PATCH/RFC] iommu/dma: Per-domain flag to control size-alignment

[Magnus Damm]

From: Magnus Damm 

Introduce the flag "no_size_align" to allow disabling size-alignment
on a per-domain basis. This follows the suggestion by the comment
in the code, however a per-device control may be preferred?

Needed to make virtual space contiguous for certain devices.

Signed-off-by: Magnus Damm 
---

 drivers/iommu/dma-iommu.c |6 +-
 include/linux/iommu.h |1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

--- 0001/drivers/iommu/dma-iommu.c
+++ work/drivers/iommu/dma-iommu.c  2017-01-27 15:17:50.280607110 +0900
@@ -209,14 +209,18 @@ static struct iova *__alloc_iova(struct
struct iova_domain *iovad = cookie_iovad(domain);
unsigned long shift = iova_shift(iovad);
unsigned long length = iova_align(iovad, size) >> shift;
+   bool size_aligned = true;
 
if (domain->geometry.force_aperture)
dma_limit = min(dma_limit, domain->geometry.aperture_end);
+
+   if (domain->no_size_align)
+   size_aligned = false;
/*
 * Enforce size-alignment to be safe - there could perhaps be an
 * attribute to control this per-device, or at least per-domain...
 */
-   return alloc_iova(iovad, length, dma_limit >> shift, true);
+   return alloc_iova(iovad, length, dma_limit >> shift, size_aligned);
 }
 
 /* The IOVA allocator knows what we mapped, so just unmap whatever that was */
--- 0001/include/linux/iommu.h
+++ work/include/linux/iommu.h  2017-01-27 15:16:37.630607110 +0900
@@ -83,6 +83,7 @@ struct iommu_domain {
iommu_fault_handler_t handler;
void *handler_token;
struct iommu_domain_geometry geometry;
+   bool no_size_align;
void *iova_cookie;
 };
 

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Simon Horman]

On Thu, Jan 26, 2017 at 09:17:02PM +0100, Wolfram Sang wrote:
> 
> > The problem I see is the following logged to the console
> > (which makes the console semi-unusable).
> > 
> > sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13)
> 
> Just to make sure: with the HS200 enablement patches present?

Using renesas-next without mmc-next I see the problem above on the M3-W.
Using renesas-next with mmc-next I do not see the problem above.
Using v4.10-rc2 I also do not see the problem above.

So I believe we should delay the integration change, which is currently in
renesas-next, until the driver change in mmc-next hits Linus's tree.

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Wolfram Sang]

> Using renesas-next without mmc-next I see the problem above on the M3-W.
> Using renesas-next with mmc-next I do not see the problem above.
> Using v4.10-rc2 I also do not see the problem above.

OK. So there is no problem with the code, at least.

> So I believe we should delay the integration change, which is currently in
> renesas-next, until the driver change in mmc-next hits Linus's tree.

Whatever you do, H3 and M3-W should be treated equally IMO.



signature.asc
Description: PGP signature

Re: [Lager(H2)-V4.10-rc2]: DISPLAY-UNIT: Does not support 640x480 resolution & Does not support 16-bit for color numbers.

[Geert Uytterhoeven]

Hi Dong,

On Fri, Jan 27, 2017 at 6:38 AM, DongCV  wrote:
> I've tested the linux v4.10-rc2 for Gen2 Lager and found two issues about
> DISPLAY-UNIT:  Does not support 640x480 resolution & Does not support 16-bit
> for color numbers.
>
> "root@linaro-naro:~# fbset -xres 640 -yres 480 -laced 0
>  ioctl FBIOPUT_VSCREENINFO: Invalid argument"
>
> "root@linaro-naro:~# fbset -depth 16 -rgba 5,6,5,0
>  ioctl FBIOPUT_VSCREENINFO: Invalid argument"
>
>
> And I found the patch which I think it is the cause of this issues.
> The commit name is '865afb1 drm/fb-helper: reject any changes to the fbdev'
> If I reverted this patch and retested it on H2 board, the issue will be
> gone!
>
> Please have a look at the attached testlog file for detail.

Do you get the correct output on the display after reverting that patch?

Cfr. Laurent Pinchart's answer in the thread "Re: The failure summary
report of GEN2 for linux stable v4.10-rc2":

| I confirm your analysis. However, I think this isn't a new issue. Before
| the aforementioned patch, running
|
| # fbset -xres 640 -yres 480 -laced 0
| # fbset -depth 16 -rgba 5,6,5,0
|
| didn't produce any error, but didn't either resize the display to
| 640x480 or changed the pixel format. With the patch applied, the
| commands are rejected as they should be, as they wouldn't produce the
| expected results. The new behaviour is thus in my opinion correct.

http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg10879.html

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] Runtime PM on the RZ/A series is never going to work right

[Geert Uytterhoeven]

Hi Chris,

On Fri, Jan 27, 2017 at 4:05 AM, Chris Brandt  wrote:
> On Wednesday, January 25, 2017, Geert Uytterhoeven wrote:
>> >> I think you can handle that in drivers/clk/renesas/clk-mstp.c:
>> >>   - in cpg_mstp_attach_dev(), add a call to pm_clk_resume(dev) after
>> the
>> >> call to pm_clk_add_clk(),
>> >>   - in cpg_mstp_detach_dev(), add a call to pm_clk_suspend(dev) before
>> the
>> >> call to pm_clk_destroy().
>> >> Yes, that means the module clocks are enabled all the time.
>> >> Of course when running on RZ/A1H ;-)
>> >
>> > That might be OK.
>>
>> Forgot to mention: you should also no longer set GENPD_FLAG_PM_CLK in
>> cpg_mstp_add_clk_domain(). The flag won't hurt, it will just cause extra
>> code to be executed.
>
> So to be clear before I start hacking away, your suggestion here is
> to do this ONLY for RZ/A1 so I don't screw up any other SoCs, right?

Correct.

> For example:
>
> int cpg_mstp_attach_dev()
> {
> ...
>
> error = pm_clk_add_clk(dev, clk);
> if (error) {
> dev_err(dev, "pm_clk_add_clk %pC failed %d\n", clk, error);
> goto fail_destroy;
> }
>
> +   if (of_device_is_compatible(np, "renesas,r7s72100-mstp-clocks"))
> +   pm_clk_suspend(dev);

That should be pm_clk_resume(dev), as is this the attach function ;-)

And please drop GENPD_FLAG_PM_CLK on RZ/A1, too.

> ...
> }
>
> Then, this would be OK to submit until I find some other way to do stable
> runtime pm for RZ/A1? (which might not be possible...unless I put in the
> silly delay)
>
> A that point, any peripheral I use (status="okay") will stay on, but the
> ones I don't use will stay off, correct?

Correct.

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] ARM: dts: r8a7791: link DU to VSPDs

[Sergei Shtylyov]

On 01/26/2017 12:42 AM, Sergei Shtylyov wrote:


Add the "vsps" property to the DU device node in order to link this node to
the VSPD nodes.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 2:
- rebased the patch.

This patch is against the 'renesas-devel-20170125-v4.10-rc5' of Simon Horman's
'renesas.git' repo.  It's  only meaningful if the DRM driver patches I've just
posted are applied.


   Forgot to note that without this patch the DU driver fails to link to VSPD 
and probe correctly, so there's no video signal. So it makes sense to apply 
before the DU driver patch (once it's ACKed for merge)...


MBR, Sergei

Re: [RFC 2/5] pinctrl: rz-pfc: Add Renesas RZ/A1 pinctrl driver

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:
> Add pin controller driver for Renesas RZ/A1 SoC.
> The SoC driver registers to rz-pfc core module and provides pin
> description array and SoC specific pin mux operation.
>
> Signed-off-by: Jacopo Mondi 

> --- a/drivers/pinctrl/rz-pfc/Makefile
> +++ b/drivers/pinctrl/rz-pfc/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_PINCTRL_RZ_PINCTRL)   += pinctrl-rz.o
> +obj-$(CONFIG_PINCTRL_RZA1_PINCTRL) += pinctrl-rza1.o
> diff --git a/drivers/pinctrl/rz-pfc/pinctrl-rza1.c 
> b/drivers/pinctrl/rz-pfc/pinctrl-rza1.c
> new file mode 100644
> index 000..221f048
> --- /dev/null
> +++ b/drivers/pinctrl/rz-pfc/pinctrl-rza1.c

> +
> +/* 
> 
> + * SoC operations
> + */
> +
> +static inline void rza1_set_bit(struct rz_pinctrl_res *res, int reg,
> +   int bank, int pin, int set)
> +{
> +   void __iomem *mem = RZA1_ADDR(res->base, reg, bank);
> +   u16 val = set ? ioread16(mem) | 1 << pin :
> +   ioread16(mem) & ~(1 << pin);
> +#ifdef RZA1_REG_DBG
> +   u16 temp = ioread16(mem);
> +
> +   pr_err("%p %p %p - %4x %4x\n",
> +  (void *)res->start, res->base, mem, temp, val);

Please drop the cast, take the address, and use %pa to format a
resource_size_t, cfr. Documentation/printk-formats.txt.

> + static struct rz_pinctrl_ops rza1_pinctrl_ops = {

const

> +   .set_mux = rza1_set_mux,
> +};
> +
> +static struct rz_pinctrl_info rza1_info = {

const

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/5] Renesas RZ series pinctrl driver

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:
>after having discussed in great detail the RZ series per-pin PFC hardware
> peculiarities, this is a proposal for a possible pin-based pin controller
> driver for SoC devices of Renesas RZ family.

"RZ" is a bad name, as there are (currently) 3 RZ subfamilies, and they
differ a lot. So it's better to use "RZ/A".
Or perhaps even "RZ/A1", as you never know what's going to happen with "2"...

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 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:
> Add core module for per-pin Renesas RZ series pin controller.
> The core module allows SoC driver to register their pins and SoC
> specific operations and interfaces with pinctrl and pinmux core on their
> behalf.
>
> Signed-off-by: Jacopo Mondi 

I believe nothing besides the DT property "renesas-rz,pins" and the value
of the RZ_PIN_ARGS_COUNT macro is really specific to Renesas or RZ(A)?
So this could become something really generic, and part of core pinctrl?

> --- /dev/null
> +++ b/drivers/pinctrl/rz-pfc/pinctrl-rz.c
> @@ -0,0 +1,447 @@

> +#define RZ_PIN_ARGS_COUNT  3

This should be a parameter in the SoC-specific subdriver.

> +/**
> + * rz_pinctrl_pos_to_index() - Retrieve the index of pin at position 
> [bank:pin]
> + *
> + * This can be improved, as it walks all the pins reported by the SoC driver
> + *
> + * @return: pin number between [0 - npins]; -1 if not found
> + */
> +static int rz_pinctrl_pos_to_index(struct rz_pinctrl_dev *rz_pinctrl,
> +  unsigned int bank, unsigned int pin)
> +{
> +   struct rz_pinctrl_info *info;
> +   struct rz_pin_desc *rz_pin;

const

> +   int i, npins;

unsigned int

> +/* 
> 
> + * pinctrl operations
> + */
> +static void rz_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,

const ... pctldev

> +   unsigned int pin)
> +{
> +   struct rz_pinctrl_dev *rz_pinctrl;
> +   struct rz_pinctrl_info *info;

const

> +static int rz_dt_node_to_map(struct pinctrl_dev *pctldev,
> +struct device_node *np_config,
> +struct pinctrl_map **map, unsigned int *num_maps)
> +{

> +   fngrps = devm_kzalloc(rz_pinctrl->dev, sizeof(*fngrps), GFP_KERNEL);
> +   if (unlikely(!fngrps)) {

Please don't use unlikely.

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 3/5] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:
> Add dt-bindings header for Renesas RZ pincontroller.
> The header defines macros for pin description and alternate function
> numbers.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  include/dt-bindings/pinctrl/pinctrl-renesas-rz.h | 19 +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 include/dt-bindings/pinctrl/pinctrl-renesas-rz.h
>
> diff --git a/include/dt-bindings/pinctrl/pinctrl-renesas-rz.h 
> b/include/dt-bindings/pinctrl/pinctrl-renesas-rz.h
> new file mode 100644
> index 000..92816d4
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/pinctrl-renesas-rz.h
> @@ -0,0 +1,19 @@
> +/*
> + * Defines macros and constants for Renesas RZ pin controller and muxer
> + */
> +
> +#ifndef __DT_BINDINGS_PINCTRL_RENESAS_RZ_H
> +#define __DT_BINDINGS_PINCTRL_RENESAS_RZ_H
> +
> +#define RZ_PIN(b, p) b p

And the advantage of this macro is?

> +#define ALTERNATE_FUNC_1   0
> +#define ALTERNATE_FUNC_2   1
> +#define ALTERNATE_FUNC_3   2
> +#define ALTERNATE_FUNC_4   3
> +#define ALTERNATE_FUNC_5   4
> +#define ALTERNATE_FUNC_6   5
> +#define ALTERNATE_FUNC_7   6
> +#define ALTERNATE_FUNC_8   7

I have mixed feelings about these macros:
  1. They're long to type,
  2. They just map from n to n-1.

Why not use plain numbers 1..8 (the alternate function numbering in the
datasheet is 1-based), and subtract 1 in the C code?

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 v6 2/2] clocksource: Add renesas-ostm timer driver

[Chris Brandt]

This patch adds a OSTM driver for the Renesas architecture.
The OS Timer (OSTM) has independent channels that can be
used as a freerun or interval times.
This driver uses the first probed device as a clocksource
and then any additional devices as clock events.

Signed-off-by: Chris Brandt 
---
v5:
* add Copyright
v4:
* changed iowrite8/32 to writeb/l
v3:
* Added more details to commit log
* Kconfig: SYS_SUPPORTS_RENESAS_OSTM to just RENESAS_OSTM
* removed all MODULE code (this driver is builtin only)
* removed items from 'struct ostm_device'
* changed ioread8 to readb
* explain endless while loop
* removed un-needed vars like 'ret'
* removed WARN_ON(!clockevent_state_oneshot(ced));
* removed "failed to allocate memory" message
* remove pm_runtime calls
* remove "earlytimer" register (only for sh, not arm)
* convert from platform driver to CLOCKSOURCE_OF_DECLARE
* ostm_probe code is now in ostm_init
v2:
* changed implementation to be independent channel nodes
---
 arch/arm/mach-shmobile/Kconfig |   1 +
 drivers/clocksource/Kconfig|   7 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/renesas-ostm.c | 265 +
 4 files changed, 274 insertions(+)
 create mode 100644 drivers/clocksource/renesas-ostm.c

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 2bb4b09..ad7d604 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -57,6 +57,7 @@ config ARCH_R7S72100
select PM
select PM_GENERIC_DOMAINS
select SYS_SUPPORTS_SH_MTU2
+   select RENESAS_OSTM
 
 config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4866f7a..a0786a6 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -467,6 +467,13 @@ config SH_TIMER_MTU2
  Timer Pulse Unit 2 (MTU2) hardware available on SoCs from Renesas.
  This hardware comes with 16 bit-timer registers.
 
+config RENESAS_OSTM
+   bool "Renesas OSTM timer driver" if COMPILE_TEST
+   depends on GENERIC_CLOCKEVENTS
+   select CLKSRC_MMIO
+   help
+ Enables the support for the Renesas OSTM.
+
 config SH_TIMER_TMU
bool "Renesas TMU timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index a14111e..bbd163b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)+= cs5535-clockevt.o
 obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
+obj-$(CONFIG_RENESAS_OSTM) += renesas-ostm.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
 obj-$(CONFIG_EM_TIMER_STI) += em_sti.o
 obj-$(CONFIG_CLKBLD_I8253) += i8253.o
diff --git a/drivers/clocksource/renesas-ostm.c 
b/drivers/clocksource/renesas-ostm.c
new file mode 100644
index 000..9369dd4
--- /dev/null
+++ b/drivers/clocksource/renesas-ostm.c
@@ -0,0 +1,265 @@
+/*
+ * Renesas Timer Support - OSTM
+ *
+ * Copyright (C) 2017 Renesas Electronics America, Inc.
+ * Copyright (C) 2017 Chris Brandt
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The OSTM contains independent channels.
+ * The first OSTM channel probed will be set up as a free running
+ * clocksource. Additionally we will use this clocksource for the system
+ * schedule timer sched_clock().
+ *
+ * The second (or more) channel probed will be set up as an interrupt
+ * driven clock event.
+ */
+
+struct ostm_device {
+   void __iomem *base;
+   unsigned long ticks_per_jiffy;
+   struct clock_event_device ced;
+};
+
+static void __iomem *system_clock; /* For sched_clock() */
+
+/* OSTM REGISTERS */
+#defineOSTM_CMP0x000   /* RW,32 */
+#defineOSTM_CNT0x004   /* R,32 */
+#defineOSTM_TE 0x010   /* R,8 */
+#defineOSTM_TS 0x014   /* W,8 */
+#defineOSTM_TT 0x018   /* W,8 */
+#defineOSTM_CTL0x020   /* RW,8 */
+
+#defineTE  0x01
+#defineTS  0x01
+#defineTT  0x01
+#defineCTL_PERIODIC0x00
+#defineCTL_ONESHOT 0x02
+#define   

[PATCH v6 1/2] dt-bindings: document renesas-ostm timer

[Chris Brandt]

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
---
v3:
* changed ostm@fcfec000 to timer@fcfec000 in example
* added power-domains in example
v2:
* remove sw implementation specific portions
---
 .../devicetree/bindings/timer/renesas,ostm.txt | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt

diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt 
b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
new file mode 100644
index 000..be3ae0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
@@ -0,0 +1,30 @@
+* Renesas OS Timer (OSTM)
+
+The OSTM is a multi-channel 32-bit timer/counter with fixed clock
+source that can operate in either interval count down timer or free-running
+compare match mode.
+
+Channels are independent from each other.
+
+Required Properties:
+
+  - compatible: must be one or more of the following:
+- "renesas,r7s72100-ostm" for the r7s72100 OSTM
+- "renesas,ostm" for any OSTM
+   This is a fallback for the above renesas,*-ostm entries
+
+  - reg: base address and length of the register block for a timer channel.
+
+  - interrupts: interrupt specifier for the timer channel.
+
+  - clocks: clock specifier for the timer channel.
+
+Example: R7S72100 (RZ/A1H) OSTM node
+
+   ostm0: timer@fcfec000 {
+   compatible = "renesas,r7s72100-ostm", "renesas,ostm";
+   reg = <0xfcfec000 0x30>;
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_OSTM0>;
+   power-domains = <_clocks>;
+   };
-- 
2.10.1

[PATCH v6 0/2] clocksource: Add renesas-ostm timer driver

[Chris Brandt]

This patch set adds a new clocksource driver that uses the OS Timer
(OSTM) that exists in the R7S72100 (RZ/A1) SoC.

The operation of the driver was tested with a simple user application
that does multiple calls to nanosleep() and gettimeofday().

The purpose of adding this driver is to get better time keeping
accuracy over the default MTU2 clocksource timer.

v6:
* add Copyright

v5:
* changed iowrite8/32 to writeb/l

v4:
* Added more details to commit log
* Kconfig: SYS_SUPPORTS_RENESAS_OSTM to just RENESAS_OSTM
* removed all MODULE code (this driver is builtin only)
* removed items from 'struct ostm_device'
* changed ioread8 to readb
* explain endless while loop
* removed un-needed vars like 'ret'
* removed WARN_ON(!clockevent_state_oneshot(ced));
* removed "failed to allocate memory" message
* remove pm_runtime calls
* remove "earlytimer" register (only for sh, not arm)
* convert from platform driver to CLOCKSOURCE_OF_DECLARE
* ostm_probe code is now in ostm_init

v3:
* Changed ostm@fcfec000 to timer@fcfec000
* Added power-domains to nodes

v2:
* The biggest change was now the channels are independent of each
  other and have separate nodes in the DT. The first probed will
  be set up as a clock source, and any additional channels probed
  will become a clock event.


Chris Brandt (2):
  dt-bindings: document renesas-ostm timer
  clocksource: Add renesas-ostm timer driver

 .../devicetree/bindings/timer/renesas,ostm.txt |  30 +++
 arch/arm/mach-shmobile/Kconfig |   1 +
 drivers/clocksource/Kconfig|   7 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/renesas-ostm.c | 265 +
 5 files changed, 304 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
 create mode 100644 drivers/clocksource/renesas-ostm.c

-- 
2.10.1

RE: [RFC] Runtime PM on the RZ/A series is never going to work right

[Chris Brandt]

Hi Geert,

On Wednesday, January 25, 2017, Geert Uytterhoeven wrote:
> >> I think you can handle that in drivers/clk/renesas/clk-mstp.c:
> >>   - in cpg_mstp_attach_dev(), add a call to pm_clk_resume(dev) after
> the
> >> call to pm_clk_add_clk(),
> >>   - in cpg_mstp_detach_dev(), add a call to pm_clk_suspend(dev) before
> the
> >> call to pm_clk_destroy().
> >> Yes, that means the module clocks are enabled all the time.
> >> Of course when running on RZ/A1H ;-)
> >
> > That might be OK.
> 
> Forgot to mention: you should also no longer set GENPD_FLAG_PM_CLK in
> cpg_mstp_add_clk_domain(). The flag won't hurt, it will just cause extra
> code to be executed.

So to be clear before I start hacking away, your suggestion here is
to do this ONLY for RZ/A1 so I don't screw up any other SoCs, right?

For example:

int cpg_mstp_attach_dev()
{
...

error = pm_clk_add_clk(dev, clk);
if (error) {
dev_err(dev, "pm_clk_add_clk %pC failed %d\n", clk, error);
goto fail_destroy;
}

+   if (of_device_is_compatible(np, "renesas,r7s72100-mstp-clocks"))
+   pm_clk_suspend(dev);

...
}

Then, this would be OK to submit until I find some other way to do stable
runtime pm for RZ/A1? (which might not be possible...unless I put in the
silly delay)

A that point, any peripheral I use (status="okay") will stay on, but the
ones I don't use will stay off, correct?


Thank you,
Chris

[PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)

[Simon Horman]

Explicitly list per-SoC binding for r8a7796. No driver change
is required as the initialisation sequence is currently the same
as for the R-Car Gen3 fallback binding.

Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt 
b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
index 7716acc55dec..ae9c2a735f39 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -10,6 +10,7 @@ Required properties:
- "renesas,iic-r8a7793" (R-Car M2-N)
- "renesas,iic-r8a7794" (R-Car E2)
- "renesas,iic-r8a7795" (R-Car H3)
+   - "renesas,iic-r8a7796" (R-Car M3-W)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
- "renesas,rcar-gen2-iic" (generic R-Car Gen2 
compatible device)
- "renesas,rcar-gen3-iic" (generic R-Car Gen3 
compatible device)
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 1/5] arm64: defconfig: Enable SH Mobile I2C controller

[Simon Horman]

Enable SH Mobile I2C controller for use on R-Car Gen3 SoCs.

Signed-off-by: Simon Horman 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 869dded0f09f..92a3ee26c6fd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -245,6 +245,7 @@ CONFIG_I2C_MESON=y
 CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_QUP=y
 CONFIG_I2C_RK3X=y
+CONFIG_I2C_SH_MOBILE=y
 CONFIG_I2C_TEGRA=y
 CONFIG_I2C_UNIPHIER_F=y
 CONFIG_I2C_RCAR=y
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 3/5] arm64: dts: r8a7796: salvator-x: Add I2C for DVFS device support

[Simon Horman]

From: Dien Pham 

This patch adds support of I2C for DVFS device for Salvator-X board on
R8A7796 SoC.

Signed-off-by: Dien Pham 
Signed-off-by: Takeshi Kihara 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index c3e0b9e54a74..d7289613e21e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -262,3 +262,7 @@
timeout-sec = <60>;
status = "okay";
 };
+
+_dvfs {
+   status = "okay";
+};
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 0/5] arm64: dts: r8a779[56]: salvator-x: Add I2C for DVFS device support

[Simon Horman]

Hi,

this series enables I2C for DVFS  on the salvator-x board for the
r8a7795 and r8a7796 SoCs.

Base:
* This series is based on renesas-next-20170126-v4.10-rc2

Dependencies:
* This series has a run-time dependency on
  "[PATCH 0/2] clk: renesas: r8a7795/r8a7796: Add IIC-DVFS clock"
* This series has a check patch dependency on
  "[PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car 
M3-W)"
* This series should be safe to apply independently of the above dependencies


Dien Pham (2):
  arm64: dts: r8a7796: Add I2C for DVFS device node
  arm64: dts: r8a7796: salvator-x: Add I2C for DVFS device support

Keita Kobayashi (2):
  arm64: dts: r8a7795: Add I2C for DVFS core to dtsi
  arm64: dts: r8a7795-salvator-x: Enable I2C for DVFS device

Simon Horman (1):
  arm64: defconfig: Enable SH Mobile I2C controller

 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  4 
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 14 ++
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |  4 
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 14 ++
 arch/arm64/configs/defconfig   |  1 +
 5 files changed, 37 insertions(+)

-- 
2.7.0.rc3.207.g0ac5344

[PATCH 5/5] arm64: dts: r8a7795-salvator-x: Enable I2C for DVFS device

[Simon Horman]

From: Keita Kobayashi 

This patch enables I2C for DVFS device for for Salvator-X board on
R8A7795 SoC.

Signed-off-by: Keita Kobayashi 
Signed-off-by: Takeshi Kihara 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 51ef8bbaa33e..ff8bb5bd675f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -486,6 +486,10 @@
clock-frequency = <22579200>;
 };
 
+_dvfs {
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 2/5] arm64: dts: r8a7796: Add I2C for DVFS device node

[Simon Horman]

From: Dien Pham 

This patch adds I2C for DVFS device node for R8A7796 SoC.

Signed-off-by: Dien Pham 
Signed-off-by: Takeshi Kihara 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f7120cdedd0d..c95ad177b097 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -25,6 +25,7 @@
i2c4 = 
i2c5 = 
i2c6 = 
+   i2c7 = _dvfs;
};
 
psci {
@@ -269,6 +270,19 @@
#power-domain-cells = <1>;
};
 
+   i2c_dvfs: i2c@e60b {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7796",
+"renesas,rcar-gen3-iic",
+"renesas,rmobile-iic";
+   reg = <0 0xe60b 0 0x425>;
+   interrupts = ;
+   clocks = < CPG_MOD 926>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
i2c0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 4/5] arm64: dts: r8a7795: Add I2C for DVFS core to dtsi

[Simon Horman]

From: Keita Kobayashi 

This patch adds I2C for DVFS device support for R8A7795 SoC.

Signed-off-by: Keita Kobayashi 
Signed-off-by: Gaku Inami 
Signed-off-by: Dien Pham 
Signed-off-by: Takeshi Kihara 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index eac4f29aa5cd..fe266bb3d913 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -25,6 +25,7 @@
i2c4 = 
i2c5 = 
i2c6 = 
+   i2c7 = _dvfs;
};
 
psci {
@@ -793,6 +794,19 @@
status = "disabled";
};
 
+   i2c_dvfs: i2c@e60b {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7795",
+"renesas,rcar-gen3-iic",
+"renesas,rmobile-iic";
+   reg = <0 0xe60b 0 0x425>;
+   interrupts = ;
+   clocks = < CPG_MOD 926>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
i2c0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)

[Geert Uytterhoeven]

On Thu, Jan 26, 2017 at 9:47 AM, Simon Horman
 wrote:
> Explicitly list per-SoC binding for r8a7796. No driver change
> is required as the initialisation sequence is currently the same
> as for the R-Car Gen3 fallback binding.
>
> Signed-off-by: Simon Horman 

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

[PATCH/RFC] iommu/ipmmu-vmsa: Restrict IOMMU Domain Geometry to 32-bit address space

[Geert Uytterhoeven]

Currently, the IPMMU/VMSA driver supports 32-bit I/O Virtual Addresses
only, and thus sets io_pgtable_cfg.ias = 32.  However, it doesn't force
a 32-bit IOVA space through the IOMMU Domain Geometry.

Hence if a device (e.g. SYS-DMAC) rightfully configures a 40-bit DMA
mask, it will still be handed out a 40-bit IOVA, outside the 32-bit IOVA
space, leading to out-of-bounds accesses of the PGD when mapping the
IOVA.

Force a 32-bit IOMMU Domain Geometry to fix this.

Signed-off-by: Geert Uytterhoeven 
---
Should the generic code restrict the geometry based on IAS instead?
---
 drivers/iommu/ipmmu-vmsa.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 798578f1676480c6..eb8b3df8733b15fb 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -424,6 +424,8 @@ static int ipmmu_domain_init_context(struct 
ipmmu_vmsa_domain *domain)
domain->cfg.ias = 32;
domain->cfg.oas = 40;
domain->cfg.tlb = _gather_ops;
+   domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(32);
+   domain->io_domain.geometry.force_aperture = true;
/*
 * TODO: Add support for coherent walk through CCI with DVM and remove
 * cache handling. For now, delegate it to the io-pgtable code.
-- 
1.9.1

Re: [PATCH 1/5] arm64: defconfig: Enable SH Mobile I2C controller

[Geert Uytterhoeven]

On Thu, Jan 26, 2017 at 9:52 AM, Simon Horman
 wrote:
> Enable SH Mobile I2C controller for use on R-Car Gen3 SoCs.
>
> Signed-off-by: Simon Horman 

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 RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Wolfram Sang]

On Thu, Jan 26, 2017 at 11:01:17AM +0100, Simon Horman wrote:
> On Fri, Jan 13, 2017 at 09:39:28AM +0100, Wolfram Sang wrote:
> > > Sorry for missing these.
> > > I have queued them up for v4.11.
> > 
> > Thank you!
> 
> On my r8a7796/salvator-x I see the following with this series applied:
> 
> sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13)

Do you have the HS200 enablement patches in that branch? They are
currently in -next.



signature.asc
Description: PGP signature

Re: [PATCH/RFC] iommu/ipmmu-vmsa: Restrict IOMMU Domain Geometry to 32-bit address space

[Magnus Damm]

Hi Geert,

On Thu, Jan 26, 2017 at 6:53 PM, Geert Uytterhoeven
 wrote:
> Currently, the IPMMU/VMSA driver supports 32-bit I/O Virtual Addresses
> only, and thus sets io_pgtable_cfg.ias = 32.  However, it doesn't force
> a 32-bit IOVA space through the IOMMU Domain Geometry.
>
> Hence if a device (e.g. SYS-DMAC) rightfully configures a 40-bit DMA
> mask, it will still be handed out a 40-bit IOVA, outside the 32-bit IOVA
> space, leading to out-of-bounds accesses of the PGD when mapping the
> IOVA.
>
> Force a 32-bit IOMMU Domain Geometry to fix this.

Nice, thanks!

> Signed-off-by: Geert Uytterhoeven 
> ---
> Should the generic code restrict the geometry based on IAS instead?

Might make sense. Since this is a software policy limited by hardware
it might be good to use as small IOVA space as possible to improve
performance. So selecting IOVA space based on slave device or domain
policy or something similar might be a good thing to do. Not sure how
to tie that into the IOMMU subsystem though...

Thanks!

/ magnus

Re: [PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)

[Wolfram Sang]

On Thu, Jan 26, 2017 at 09:47:31AM +0100, Simon Horman wrote:
> Explicitly list per-SoC binding for r8a7796. No driver change
> is required as the initialisation sequence is currently the same
> as for the R-Car Gen3 fallback binding.
> 
> Signed-off-by: Simon Horman 

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH 4/5] arm64: dts: r8a7795: Add I2C for DVFS core to dtsi

[Geert Uytterhoeven]

On Thu, Jan 26, 2017 at 9:52 AM, Simon Horman
 wrote:
> From: Keita Kobayashi 
>
> This patch adds I2C for DVFS device support for R8A7795 SoC.
>
> Signed-off-by: Keita Kobayashi 
> Signed-off-by: Gaku Inami 
> Signed-off-by: Dien Pham 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi

> @@ -793,6 +794,19 @@
> status = "disabled";
> };
>
> +   i2c_dvfs: i2c@e60b {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "renesas,iic-r8a7795",
> +"renesas,rcar-gen3-iic",
> +"renesas,rmobile-iic";
> +   reg = <0 0xe60b 0 0x425>;
> +   interrupts = ;
> +   clocks = < CPG_MOD 926>;

Same comment about dmas/dma-names.

> +   power-domains = < R8A7795_PD_ALWAYS_ON>;
> +   status = "disabled";
> +   };

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 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[jacopo mondi]

Hi Chris,

On 26/01/2017 03:58, Chris Brandt wrote:

Hi Jacopo,

On Wednesday, January 25, 2017, Jacopo Mondi wrote:

 drivers/pinctrl/Kconfig |   1 +
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/rz-pfc/Kconfig  |  18 ++
 drivers/pinctrl/rz-pfc/Makefile |   1 +
 drivers/pinctrl/rz-pfc/pinctrl-rz.c | 447

 drivers/pinctrl/rz-pfc/pinctrl-rz.h | 114 +
 6 files changed, 582 insertions(+)
 create mode 100644 drivers/pinctrl/rz-pfc/Kconfig  create mode 100644
drivers/pinctrl/rz-pfc/Makefile  create mode 100644 drivers/pinctrl/rz-
pfc/pinctrl-rz.c
 create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rz.h




I think we should try to avoid the rz naming as much as possible since
this driver will hopefully be useful for other future Renesas devices if
they move to a similar pin-control type method. Maybe future "R-car" SoCs?
Or, maybe Renesas Marketing decides to come up with a new name for SoCs.

Otherwise, you could end up with a directly like "mach-shmobile" filled
with a bunch of...well...not SH-Mobile parts.

Maybe just
  drivers/pinctrl/renesas/pinctrl-renesas.c



Wouldn't this be confusing, as most of renesas SoC are supported through 
drivers/pinctrl/sh-pfc instead?


I agree on dropping the rz name, if more SoC will come and join the 
pin-based PFC realm...


Thanks
   j






Chris

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Simon Horman]

On Tue, Jan 10, 2017 at 10:08:48PM +0100, Niklas Söderlund wrote:
> Hi Simon,
> 
> I started to se errors when I was testing DMAC+IPMMU patches on top of 
> v4.10-rc1 on Koelsch.

There has been some discussion in this thread already. I would like to
provide some more information in case it is useful.

The 3.5.0 BSP appears to contain several that may be relevant to this
discussion:

383c4437846d mmc: sh_mobile_sdhi: Add detecting a change point of data to SCC 
tuning
1823812e0937 mmc: tmio: Add detecting a change point of data to SCC tunin
03935e9182d9 mmc: tmio: Fix tuning flow
c711db03349c mmc: sh_mobile_sdhi: Fix sampling clock position selecting
2838a2ff8ca7 mmc: tmio: fix soft lockup on CMD12 for R-Car SDHI


Of these, so far I have looked into "mmc: tmio: Fix tuning flow".
It seems to do several things:

- Ensure tuning initialisation is called for each tuning procedure:
  this seems a correct fix for a bug added by me
- Do not terminate tuning on error:
  this is not my reading of the documentation but may well be correct
- Reset more:
  I am least sure about this as it does not seem to have any explanation
  in the changelog

Re: [PATCH 2/5] arm64: dts: r8a7796: Add I2C for DVFS device node

[Geert Uytterhoeven]

On Thu, Jan 26, 2017 at 9:52 AM, Simon Horman
 wrote:
> From: Dien Pham 
>
> This patch adds I2C for DVFS device node for R8A7796 SoC.
>
> Signed-off-by: Dien Pham 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi

> @@ -269,6 +270,19 @@
> #power-domain-cells = <1>;
> };
>
> +   i2c_dvfs: i2c@e60b {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "renesas,iic-r8a7796",
> +"renesas,rcar-gen3-iic",
> +"renesas,rmobile-iic";
> +   reg = <0 0xe60b 0 0x425>;
> +   interrupts = ;
> +   clocks = < CPG_MOD 926>;

You may want to add dmas/dma-names.
That can be done later, though.

> +   power-domains = < R8A7796_PD_ALWAYS_ON>;
> +   status = "disabled";
> +   };
> +

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 1/7] ARM: dts: r8a7779, marzen: Fix sata device status

[Simon Horman]

From: Geert Uytterhoeven 

Device nodes representing I/O devices should be marked disabled in the
SoC-specific DTS, and overridden by board-specific DTSes where needed.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7779-marzen.dts | 4 
 arch/arm/boot/dts/r8a7779.dtsi   | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts 
b/arch/arm/boot/dts/r8a7779-marzen.dts
index 676151b70185..89c5b24a3d03 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -216,6 +216,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index f47a0edc26d4..ae2d9a9c65af 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -347,6 +347,7 @@
interrupts = ;
clocks = <_clks R8A7779_CLK_SATA>;
power-domains = < R8A7779_PD_ALWAYS_ON>;
+   status = "disabled";
};
 
sdhi0: sd@ffe4c000 {
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 5/7] ARM: dts: r7s72100: add ostm to device tree

[Simon Horman]

From: Chris Brandt 

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r7s72100.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index d5946df29222..74e684f3c1c7 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -505,4 +505,22 @@
cap-sdio-irq;
status = "disabled";
};
+
+   ostm0: timer@fcfec000 {
+   compatible = "renesas,r7s72100-ostm", "renesas,ostm";
+   reg = <0xfcfec000 0x30>;
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_OSTM0>;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
+
+   ostm1: timer@fcfec400 {
+   compatible = "renesas,r7s72100-ostm", "renesas,ostm";
+   reg = <0xfcfec400 0x30>;
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_OSTM1>;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
 };
-- 
2.7.0.rc3.207.g0ac5344

[PATCH] ARM: shmobile: rcar-gen2: Add more register documentation

[Simon Horman]

From: Geert Uytterhoeven 

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/mach-shmobile/pm-rcar-gen2.c | 40 +--
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c 
b/arch/arm/mach-shmobile/pm-rcar-gen2.c
index dd9ac366868f..0178da7ace82 100644
--- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
@@ -20,14 +20,30 @@
 
 /* RST */
 #define RST0xe616
-#define CA15BAR0x0020
-#define CA7BAR 0x0030
-#define CA15RESCNT 0x0040
-#define CA7RESCNT  0x0044
+
+#define CA15BAR0x0020  /* CA15 Boot Address Register */
+#define CA7BAR 0x0030  /* CA7 Boot Address Register */
+#define CA15RESCNT 0x0040  /* CA15 Reset Control Register */
+#define CA7RESCNT  0x0044  /* CA7 Reset Control Register */
+
+/* SYS Boot Address Register */
+#define SBAR_BAREN BIT(4)  /* SBAR is valid */
+
+/* Reset Control Registers */
+#define CA15RESCNT_CODE0xa5a5
+#define CA15RESCNT_CPUS0xf /* CPU0-3 */
+#define CA7RESCNT_CODE 0x5a5a
+#define CA7RESCNT_CPUS 0xf /* CPU0-3 */
+
 
 /* On-chip RAM */
 #define ICRAM1 0xe63c  /* Inter Connect RAM1 (4 KiB) */
 
+static inline u32 phys_to_sbar(phys_addr_t addr)
+{
+   return (addr >> 8) & 0xfc00;
+}
+
 /* SYSC */
 #define SYSCIER 0x0c
 #define SYSCIMR 0x10
@@ -82,22 +98,24 @@ void __init rcar_gen2_pm_init(void)
 
/* setup reset vectors */
p = ioremap_nocache(RST, 0x63);
-   bar = (boot_vector_addr >> 8) & 0xfc00;
+   bar = phys_to_sbar(boot_vector_addr);
if (has_a15) {
writel_relaxed(bar, p + CA15BAR);
-   writel_relaxed(bar | 0x10, p + CA15BAR);
+   writel_relaxed(bar | SBAR_BAREN, p + CA15BAR);
 
/* de-assert reset for CA15 CPUs */
-   writel_relaxed((readl_relaxed(p + CA15RESCNT) & ~0x0f) |
-   0xa5a5, p + CA15RESCNT);
+   writel_relaxed((readl_relaxed(p + CA15RESCNT) &
+   ~CA15RESCNT_CPUS) | CA15RESCNT_CODE,
+  p + CA15RESCNT);
}
if (has_a7) {
writel_relaxed(bar, p + CA7BAR);
-   writel_relaxed(bar | 0x10, p + CA7BAR);
+   writel_relaxed(bar | SBAR_BAREN, p + CA7BAR);
 
/* de-assert reset for CA7 CPUs */
-   writel_relaxed((readl_relaxed(p + CA7RESCNT) & ~0x0f) |
-   0x5a5a, p + CA7RESCNT);
+   writel_relaxed((readl_relaxed(p + CA7RESCNT) &
+   ~CA7RESCNT_CPUS) | CA7RESCNT_CODE,
+  p + CA7RESCNT);
}
iounmap(p);
 
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 7/7] ARM: dts: r7s72100: add power-domains to mmcif

[Simon Horman]

From: Chris Brandt 

Signed-off-by: Chris Brandt 
Reported-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r7s72100.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 74e684f3c1c7..b8aa256bd515 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -475,6 +475,7 @@
  GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH
  GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R7S72100_CLK_MMCIF>;
+   power-domains = <_clocks>;
reg-io-width = <4>;
bus-width = <8>;
status = "disabled";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 2/7] ARM: dts: r8a7743: Link ARM GIC to clock and clock domain

[Simon Horman]

From: Geert Uytterhoeven 

Link the ARM GIC to the INTC-SYS module clock, and add it to the SYSC
"always-on" PM Domain, so it can be power managed using that clock.

Note that currently the GIC-400 driver doesn't support module clocks nor
Runtime PM, so this must be handled as a critical clock.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7743.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 0956125597fd..40d2cdede702 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -60,6 +60,9 @@
  <0 0xf1006000 0 0x2000>;
interrupts = ;
+   clocks = < CPG_MOD 408>;
+   clock-names = "clk";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
};
 
irqc: interrupt-controller@e61c {
-- 
2.7.0.rc3.207.g0ac5344

[GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.11

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM based SoC updates for v4.11.

This pull request is based on the previous round of
such requests, tagged as renesas-soc-for-v4.11,
which you have already pulled.


The following changes since commit 70def3e53694a65c5583fb5f411491a5074bab18:

  ARM: shmobile: rcar-gen2: Remove unused rcar_gen2_read_mode_pins() 
(2017-01-03 10:50:45 +0100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-soc2-for-v4.11

for you to fetch changes up to aa7f39d51e33555fc45645c08bc74a74e22b166f:

  ARM: shmobile: rcar-gen2: Add more register documentation (2017-01-25 
11:28:28 +0100)


Second Round of Renesas ARM Based SoC Updates for v4.11

* Add more register documentation to R-Car Gen2 PM


Geert Uytterhoeven (1):
  ARM: shmobile: rcar-gen2: Add more register documentation

 arch/arm/mach-shmobile/pm-rcar-gen2.c | 40 +--
 1 file changed, 29 insertions(+), 11 deletions(-)

[GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.11

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM based SoC DT updates for 
v4.11.

This pull request is based on the previous round of
such requests, tagged as renesas-dt-for-v4.11,
which you have already pulled.


The following changes since commit 654450baf2afba86cf328e1849ccac61ec4630af:

  ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes 
(2017-01-03 10:47:05 +0100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-dt2-for-v4.11

for you to fetch changes up to 5786ac14239a0809ca13e6a6f77147e6bb04aa29:

  ARM: dts: r7s72100: add power-domains to mmcif (2017-01-25 11:32:02 +0100)


Second Round of Renesas ARM Based SoC DT Updates for v4.11

Enhancements:
* Add power-domains to mmcif on r7s72100 SoC
* Add OSTM to rskrza1/r7s72100
* Link ARM GIC to clock and clock domain on r8a774[35] SoCs

Clean-up:
* Correct SATA device status on r8a7779/marzen


Chris Brandt (4):
  ARM: dts: r7s72100: add ostm clock to device tree
  ARM: dts: r7s72100: add ostm to device tree
  ARM: dts: rskrza1: add ostm DT support
  ARM: dts: r7s72100: add power-domains to mmcif

Geert Uytterhoeven (3):
  ARM: dts: r8a7779, marzen: Fix sata device status
  ARM: dts: r8a7743: Link ARM GIC to clock and clock domain
  ARM: dts: r8a7745: Link ARM GIC to clock and clock domain

 arch/arm/boot/dts/r7s72100-rskrza1.dts |  8 
 arch/arm/boot/dts/r7s72100.dtsi| 28 
 arch/arm/boot/dts/r8a7743.dtsi |  3 +++
 arch/arm/boot/dts/r8a7745.dtsi |  3 +++
 arch/arm/boot/dts/r8a7779-marzen.dts   |  4 
 arch/arm/boot/dts/r8a7779.dtsi |  1 +
 include/dt-bindings/clock/r7s72100-clock.h |  4 
 7 files changed, 51 insertions(+)

[PATCH 6/7] ARM: dts: rskrza1: add ostm DT support

[Simon Horman]

From: Chris Brandt 

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r7s72100-rskrza1.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts 
b/arch/arm/boot/dts/r7s72100-rskrza1.dts
index dd4418195ca6..02b59c5b3c53 100644
--- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
+++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
@@ -61,6 +61,14 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 4/7] ARM: dts: r7s72100: add ostm clock to device tree

[Simon Horman]

From: Chris Brandt 

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r7s72100.dtsi| 9 +
 include/dt-bindings/clock/r7s72100-clock.h | 4 
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 3dd427d68c83..d5946df29222 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -108,6 +108,15 @@
clock-output-names = "scif0", "scif1", "scif2", 
"scif3", "scif4", "scif5", "scif6", "scif7";
};
 
+   mstp5_clks: mstp5_clks@fcfe0428 {
+   #clock-cells = <1>;
+   compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
+   reg = <0xfcfe0428 4>;
+   clocks = <_clk>, <_clk>;
+   clock-indices = ;
+   clock-output-names = "ostm0", "ostm1";
+   };
+
mstp7_clks: mstp7_clks@fcfe0430 {
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
diff --git a/include/dt-bindings/clock/r7s72100-clock.h 
b/include/dt-bindings/clock/r7s72100-clock.h
index 29e01ed10e74..ce09915c298f 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -25,6 +25,10 @@
 #define R7S72100_CLK_SCIF6 1
 #define R7S72100_CLK_SCIF7 0
 
+/* MSTP5 */
+#define R7S72100_CLK_OSTM0 1
+#define R7S72100_CLK_OSTM1 0
+
 /* MSTP7 */
 #define R7S72100_CLK_ETHER 4
 
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH v6 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100 clocks

[Wolfram Sang]

> Thanks, applied patch1 and patch2 for next. Patch3 is for Simon, I
> guess!? (And I can add Rob's ack afterwards).

Can you add my tags as well. They got dropped somehow:

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

[PATCH 3/7] ARM: dts: r8a7745: Link ARM GIC to clock and clock domain

[Simon Horman]

From: Geert Uytterhoeven 

Link the ARM GIC to the INTC-SYS module clock, and add it to the SYSC
"always-on" PM Domain, so it can be power managed using that clock.

Note that currently the GIC-400 driver doesn't support module clocks nor
Runtime PM, so this must be handled as a critical clock.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7745.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 2f60c3cb9117..a81dcc82e2ea 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -60,6 +60,9 @@
  <0 0xf1006000 0 0x2000>;
interrupts = ;
+   clocks = < CPG_MOD 408>;
+   clock-names = "clk";
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
};
 
irqc: interrupt-controller@e61c {
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH 3/5] arm64: dts: r8a7796: salvator-x: Add I2C for DVFS device support

[Geert Uytterhoeven]

On Thu, Jan 26, 2017 at 9:52 AM, Simon Horman
 wrote:
> From: Dien Pham 
>
> This patch adds support of I2C for DVFS device for Salvator-X board on
> R8A7796 SoC.
>
> Signed-off-by: Dien Pham 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

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 5/5] arm64: dts: r8a7795-salvator-x: Enable I2C for DVFS device

[Geert Uytterhoeven]

On Thu, Jan 26, 2017 at 9:52 AM, Simon Horman
 wrote:
> From: Keita Kobayashi 
>
> This patch enables I2C for DVFS device for for Salvator-X board on
> R8A7795 SoC.
>
> Signed-off-by: Keita Kobayashi 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

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: [RFC 4/5] arm: dts: r7s1000: Add pincontroller node

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:
> Add pincontroller node compatible with the new Renesas RZ/A1
> pincontroller driver.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/arm/boot/dts/r7s72100.dtsi | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
> index 3dd427d..764006d 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -171,6 +171,18 @@
> };
> };
>
> +   pinctrl: pinctrl@fcfe3000 {
> +   compatible = "renesas,rza1-pinctrl";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   #pinctrl-cells = <2>;

Souldn't that be <3>?
E.g.  expands to <3 0 5>, i.e. 3 numbers.

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 RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Simon Horman]

On Thu, Jan 26, 2017 at 11:03:56AM +0100, Wolfram Sang wrote:
> On Thu, Jan 26, 2017 at 11:01:17AM +0100, Simon Horman wrote:
> > On Fri, Jan 13, 2017 at 09:39:28AM +0100, Wolfram Sang wrote:
> > > > Sorry for missing these.
> > > > I have queued them up for v4.11.
> > > 
> > > Thank you!
> > 
> > On my r8a7796/salvator-x I see the following with this series applied:
> > 
> > sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13)
> 
> Do you have the HS200 enablement patches in that branch? They are
> currently in -next.

I tried mmc/next (but didn't notice anything special there).
Which patches should I be looking for?

Re: [PATCH v6 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100 clocks

[Simon Horman]

On Thu, Jan 26, 2017 at 09:07:45AM +0100, Ulf Hansson wrote:
> On 25 January 2017 at 21:28, Chris Brandt  wrote:
> > At first this started out as a simple typo fix, until I realized
> > that the SDHI in the RZ/A1 has 2 clocks per channel and both need
> > to be turned on/off.
> >
> > This patch series adds the ability to specify 2 clocks instead of
> > just 1, and does so for the RZ/A1 r7s72100.
> >
> > This patch has been tested on an RZ/A1 RSK board. Card detect works
> > fine as well as bind/unbind.
> >
> > v6:
> > * more detailed descritpion in tmio_mmc.txt
> >
> > v5:
> > * Take implementation details out of DT documentation and put into
> >   the driver code.
> >
> > v4:
> > * No code changes, only text udpates to explain why there are 2 clocks
> >   and why we need to treat them as 1 clock.
> >
> > Chris Brandt (3):
> >   mmc: sh_mobile_sdhi: add support for 2 clocks
> >   mmc: sh_mobile_sdhi: explain clock bindings
> >   ARM: dts: r7s72100: update sdhi clock bindings
> >
> >  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 13 
> >  arch/arm/boot/dts/r7s72100.dtsi| 17 +++-
> >  drivers/mmc/host/sh_mobile_sdhi.c  | 23 
> > ++
> >  include/dt-bindings/clock/r7s72100-clock.h |  6 --
> >  4 files changed, 52 insertions(+), 7 deletions(-)
> >
> > --
> > 2.10.1
> >
> >
> 
> Thanks, applied patch1 and patch2 for next. Patch3 is for Simon, I
> guess!? (And I can add Rob's ack afterwards).

Thanks, I will take care of the 3rd patch.

Chris, is it safe to apply the 3rd patch without the first 2 patches
present?

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

[Wolfram Sang]

> The problem I see is the following logged to the console
> (which makes the console semi-unusable).
> 
> sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13)

Just to make sure: with the HS200 enablement patches present?



signature.asc
Description: PGP signature

Re: [PATCH] clk: renesas: mstp: Reformat cpg_mstp_clock_register() for git diff

[Stephen Boyd]

On 01/23, Geert Uytterhoeven wrote:
> As the function header of cpg_mstp_clock_register() is split in an
> unusual way, "git diff" gets confused when changes to the body of
> the function are made, and attributes them to the wrong function.
> 
> Reformat the function header to fix this.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

I'm not sure it's really necessary, but ok.

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 net] ravb: unmap descriptors when freeing rings

[David Miller]

From: Simon Horman 
Date: Thu, 26 Jan 2017 14:29:27 +0100

> From: Kazuya Mizuguchi 
> 
> "swiotlb buffer is full" errors occur after repeated initialisation of a
> device - f.e. suspend/resume or ip link set up/down. This is because memory
> mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
> is not released.  Resolve this problem by unmapping descriptors when
> freeing rings.
> 
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
> Signed-off-by: Kazuya Mizuguchi 
> [simon: reworked]
> Signed-off-by: Simon Horman 

Applied, thanks Simon.