Re: [PATCH 0/2] arm64: dts: renesas: Mark EthernetAVB device nodes disabled

[Simon Horman]

On Wed, Jan 25, 2017 at 02:19:29PM +0100, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> This patch series marks the EthernetAVB device nodes in the R-Car H3 and
> M3-W DTSes disabled.
> Device nodes representing I/O devices should be marked disabled in the
> SoC-specific DTSes, and overridden by board-specific DTSes where needed.
> 
> Thanks for applying!

Thanks,

as these are fixes I have queued them up for v4.11.

Re: [PATCH/RFC 3/4] iommu: dma: iommu iova domain reset

[Magnus Damm]

Hi Robin, Shimoda-san, everyone,

Thanks for your feedback!

On Thu, Jan 26, 2017 at 1:38 AM, Robin Murphy  wrote:
> On 25/01/17 12:54, Yoshihiro Shimoda wrote:
>> From: Magnus Damm 
>>
>> To add a workaround code for ipmmu-vmsa driver, this patch adds
>> a new geometry "force_reset_when_empty" not to reuse iova space.
>
> The domain geometry is absolutely not the appropriate place for that. If
> anything, it could possibly be a domain attribute, but it has nothing to
> do with describing the range of input addresses the hardware is able to
> translate.

I agree, this flag was added without too much consideration about
correct location.

>> When all pfns happen to get unmapped then ask the IOMMU driver to
>> flush the state followed by starting from an empty iova space.
>
> And what happens if all the PFNs are never unmapped? Many devices (USB
> being among them) use a coherent allocation for some kind of descriptor
> buffer which exists for the lifetime of the device, then use streaming
> mappings for data transfers - the net result of that is that the number
> of PFNs mapped will always be >=1, and eventually streaming mapping will
> fail because you've exhausted the address space. And if the device *is*
> a USB controller, at that point the thread will hang because the USB
> core's response to a DMA mapping failure happens to be "keep trying
> indefinitely".

You are absolutely right. My apologies for not providing more
information in the first place.

Like you mention, the workaround can not be made into something
general purpose, however for some restricted use case it might be
helpful. For instance, we have some MMC controllers that are able to
perform on-chip bus mastering but they lack scatter gather support.
>From the hardware design point of view the scatter gather feature was
decided to be put into the IPMMU hardware. Because of that we would
like to use the IPMMU hardware for this purpose, however with some ES
specific errata we need to handle unmapping in a special way.
Fortunately the MMC controllers are grouped together using the same
IPMMU and we are able to make sure that all the buffers are unmapped
now and then from a workaround in the MMC device driver. Not pretty
but not super intrusive.

> Essentially, however long this allocation workaround postpones it, one
> or other failure mode is unavoidable with certain devices unless you can
> do something drastic like periodically suspend and resume the entire
> system to reset everything.

Yeah, suspend/resume or unbind/bind might work.

>> Signed-off-by: Magnus Damm 
>> Signed-off-by: Yoshihiro Shimoda 
>> ---
>>  drivers/iommu/dma-iommu.c | 42 +-
>>  drivers/iommu/iova.c  |  9 +
>>  include/linux/iommu.h |  2 ++
>>  include/linux/iova.h  |  1 +
>>  4 files changed, 49 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index a0b8c0f..d0fa0b1 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -42,6 +42,7 @@ struct iommu_dma_cookie {
>>   struct iova_domain  iovad;
>>   struct list_headmsi_page_list;
>>   spinlock_t  msi_lock;
>> + spinlock_t  reset_lock;
>
> So now we do get something in the cookie, but it's protecting a bunch of
> machinery that's accessible from a wider scope? That doesn't seem like a
> good design.

It's not. =)

There is room for improvement in the implementation for sure! We also
had other ideas of tracking mapped pages per device instead of per
domain. We have other requirements from the hardware to serialize some
MMC data handling, so grouping the MMC devices together into a single
IOMMU domain seemed light weight and simple for a first shot!

>>  };
>>
>>  static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
>> @@ -74,6 +75,7 @@ int iommu_get_dma_cookie(struct iommu_domain *domain)
>>
>>   spin_lock_init(>msi_lock);
>>   INIT_LIST_HEAD(>msi_page_list);
>> + spin_lock_init(>reset_lock);
>>   domain->iova_cookie = cookie;
>>   return 0;
>>  }
>> @@ -208,9 +210,11 @@ int dma_direction_to_prot(enum dma_data_direction dir, 
>> bool coherent)
>>  static struct iova *__alloc_iova(struct iommu_domain *domain, size_t size,
>>   dma_addr_t dma_limit)
>>  {
>> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
>>   struct iova_domain *iovad = cookie_iovad(domain);
>>   unsigned long shift = iova_shift(iovad);
>>   unsigned long length = iova_align(iovad, size) >> shift;
>> + unsigned long flags;
>>   struct iova *iova;
>>
>>   if (domain->geometry.force_aperture)
>> @@ -219,9 +223,19 @@ static struct iova *__alloc_iova(struct iommu_domain 
>> *domain, size_t size,
>>* Enforce size-alignment to be safe - there could perhaps be 

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

[Chris Brandt]

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



Chris

RE: [RFC 0/5] Renesas RZ series pinctrl driver

[Chris Brandt]

Hi Jacopo,

Thanks for the patches.

On Wednesday, January 25, 2017, Jacopo Mondi wrote:
> Right now, the only "SoC" module support implemented is for RZ/A1H (Genmai
> and GR-Peach boards).

I'm going to give it a try on the RZ/A1 RSK board.


> I have tested the correctness of mux settings printing out register values,
> and enabling/disabling the SCIF2 module connected to serial debug
> interface.

I can give it a try on things like Eth, I2C, SPI, SDHI, MMC.


> One note on the current DT ABI:
> right now a pin configuration is specified in DTS using utility macros
> defined in the (currently undocumented) arch/arm/boot/dts/include/dt-
> bindings/pinctrl/pinctrl-renesas-rz.h header file.
> Each pin configuration is a triplet of u32 in the form of
> 
> 
> 
> It should be fairly easy adding additional parameters to configure what
> was missing in the original group-based PFC driver for RZ devices (I'm
> thinking of IO mode control, input buffer configuration, bi-directional
> configuration etc).

SDHI is one that will need another parameter. Half the pins need Bidirection
(PBDC) enabled, and the other half need PBDC disabled.
SDHI data pins are PBDC=1, the others are PBDC=0.


> The series makes use of newly introduced pin[ctrl|mux]_generic functions,
> currently only available in Linus Walleij's linux-pinctrl.git tree.

Hmmm, I was hoping to 'easily' back port this to 4.9.
I guess if it's the best way forward, then maybe I can back port those new
generic functions for the LTSI tree.


Chris

Re: [PATCH/RFC 1/4] iommu: dma: track mapped iova

[Magnus Damm]

Hi Robin, Shimoda-san, everyone,

On Thu, Jan 26, 2017 at 1:27 AM, Robin Murphy  wrote:
> On 25/01/17 12:53, Yoshihiro Shimoda wrote:
>> From: Magnus Damm 
>>
>> To track mapped iova for a workaround code in the future.
>>
>> Signed-off-by: Magnus Damm 
>> Signed-off-by: Yoshihiro Shimoda 
>> ---
>>  drivers/iommu/dma-iommu.c | 29 +++--
>>  include/linux/iommu.h |  2 ++
>
> So what's being added here is a counter of allocations within the
> iova_domain held by an iommu_dma_cookie? Then why is it all the way down
> in the iommu_domain and not in the cookie? That's needlessly invasive -
> it would be almost understandable (but still horrible) if you needed to
> refer to it directly from the IOMMU driver, but as far as I can see you
> don't.

You are very correct about all points. =)

As you noticed, the counter is kept per-domain. History is a bit
blurry but I think the reason for my abstraction-breaking is that i
decided to implement the simplest possible code to get the reset
callback to near the iova code and the domain level seemed suitable as
a first step. Moving it to a different level is of course no problem.

My main concern for this series is however if a subsystem-level
intrusive workaround like this ever could be beaten into acceptable
form for upstream merge.The code is pretty simple - the main portion
of the workaround is this counter that used to detect when the number
of mapped pages drops back to zero together with the callback. But
unless the code can be made pluggable it introduces overhead for all
users.

In your other email you asked what happens if the counter never drops
to zero. You are right that this workaround is not a general-purpose
fix suitable for all kinds of devices. Because of that the workaround
is designed to be enabled on only some of the IPMMU instances on the
system. It is also most likely an errata workaround for a particular
ES version, so we would most likely have to enable it with
soc_device_match().

I'll reply to patch 3/4 with some more details.

Thanks!

/ magnus

[PATCH v4 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 
---
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..757bd71
--- /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)
+{
+   return container_of(ced, struct 

[PATCH v4 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

Re: [PATCH] arm64: renesas: r8a7795: tidyup audma definition order

[Kuninori Morimoto]

Hi Geert

Thank you for your feedback

> > From: Kuninori Morimoto 
> >
> > Current r8a7795.dtsi defines audma -> ipmmu -> dma order.
> > Because of this order, dma can connect to ipmmu, but
> > audma can't connect to it.
> > This patch moves audma order as ipmmu -> dma -> audma.
> 
> Does "[PATCH V7 00/11] IOMMU probe deferral support" help?
> https://www.spinics.net/lists/arm-kernel/msg557110.html

Maybe, Maybe not, i'm not sure.
But AudioDMAC is anyway located random position now.
I think AudioDMAC should be located close/next to DMAC node :)

Best regards
---
Kuninori Morimoto

Re: [PATCH] arm64: renesas: r8a7795: tidyup audma definition order

[Kuninori Morimoto]

Hi Simon

> sorry for missing this earlier.
> 
> The patch did not seem to compile so I have applied it manually
> by moving the audma0 and audma1 nodes to between the dmac2 and avb nodes.
> 
> The result is follows:

Thank you for your adjusting !!

> 
> From: Kuninori Morimoto 
> Subject: [PATCH] arm64: renesas: r8a7795: tidyup audma definition order
> 
> Current r8a7795.dtsi defines audma -> ipmmu -> dma order.
> Because of this order, dma can connect to ipmmu, but
> audma can't connect to it.
> This patch moves audma order as ipmmu -> dma -> audma.
> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 132 
> +++
>  1 file changed, 66 insertions(+), 66 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 8b030c323c10..74a4e1ad057d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -340,72 +340,6 @@
>   #power-domain-cells = <1>;
>   };
>  
> - audma0: dma-controller@ec70 {
> - compatible = "renesas,dmac-r8a7795",
> -  "renesas,rcar-dmac";
> - reg = <0 0xec70 0 0x1>;
> - interrupts =  -   GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
> - interrupt-names = "error",
> - "ch0", "ch1", "ch2", "ch3",
> - "ch4", "ch5", "ch6", "ch7",
> - "ch8", "ch9", "ch10", "ch11",
> - "ch12", "ch13", "ch14", "ch15";
> - clocks = < CPG_MOD 502>;
> - clock-names = "fck";
> - power-domains = < R8A7795_PD_ALWAYS_ON>;
> - #dma-cells = <1>;
> - dma-channels = <16>;
> - };
> -
> - audma1: dma-controller@ec72 {
> - compatible = "renesas,dmac-r8a7795",
> -  "renesas,rcar-dmac";
> - reg = <0 0xec72 0 0x1>;
> - interrupts =  -   GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 349 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 382 IRQ_TYPE_LEVEL_HIGH
> -   GIC_SPI 383 IRQ_TYPE_LEVEL_HIGH>;
> - interrupt-names = "error",
> - "ch0", "ch1", "ch2", "ch3",
> - "ch4", "ch5", "ch6", "ch7",
> - "ch8", "ch9", "ch10", "ch11",
> - "ch12", "ch13", "ch14", "ch15";
> - clocks = < CPG_MOD 501>;
> - clock-names = "fck";
> - power-domains = < 

[PATCH v3 3/3] drm: rcar-du: Add VSP1 live source support

[Sergei Shtylyov]

From: Laurent Pinchart 

Register live sources for VSPD0 and VSPD1 and configure the plane source
at plane setup time to source frames from memory or from the VSP1.

[Sergei: ported to the modern kernel.]

Signed-off-by: Laurent Pinchart 
Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- ported the patch to the modern kernel;
- reformatted rcar_du_live_fb_create_handle()/rcar_du_live_fb_create()'s
  parameter lists;
- added my signoff.

 drivers/gpu/drm/rcar-du/rcar_du_drv.c   |6 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |   77 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.h   |3 +
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   79 +++-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |3 +
 5 files changed, 164 insertions(+), 4 deletions(-)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -60,7 +60,8 @@ static const struct rcar_du_device_info
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
- | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
.quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
.num_crtcs = 3,
.routes = {
@@ -90,7 +91,8 @@ static const struct rcar_du_device_info
 static const struct rcar_du_device_info rcar_du_r8a7791_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
- | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 2,
.routes = {
/* R8A779[13] has one RGB output, one LVDS output and one
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -166,6 +166,74 @@ int rcar_du_dumb_create(struct drm_file
return drm_gem_cma_dumb_create_internal(file, dev, args);
 }
 
+struct rcar_du_live_framebuffer {
+   struct drm_framebuffer fb;
+   struct drm_live_source *src;
+};
+
+#define to_live_fb(fb) container_of(fb, struct rcar_du_live_framebuffer, fb)
+
+struct drm_live_source *rcar_du_live_fb_source(struct drm_framebuffer *fb)
+{
+   return fb->flags & DRM_MODE_FB_LIVE_SOURCE ? to_live_fb(fb)->src : NULL;
+}
+
+static void rcar_du_live_fb_destroy(struct drm_framebuffer *fb)
+{
+   struct rcar_du_live_framebuffer *live_fb = to_live_fb(fb);
+
+   drm_framebuffer_cleanup(fb);
+   kfree(live_fb);
+}
+
+static int rcar_du_live_fb_create_handle(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int *handle)
+{
+   *handle = 0;
+   return 0;
+}
+
+static struct drm_framebuffer_funcs rcar_du_live_fb_funcs = {
+   .destroy= rcar_du_live_fb_destroy,
+   .create_handle  = rcar_du_live_fb_create_handle,
+};
+
+static struct drm_framebuffer *
+rcar_du_live_fb_create(struct drm_device *dev, struct drm_file *file_priv,
+  const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   struct rcar_du_live_framebuffer *fb;
+   struct drm_mode_object *obj;
+   struct drm_live_source *src;
+   int ret;
+
+   obj = drm_mode_object_find(dev, mode_cmd->handles[0],
+  DRM_MODE_OBJECT_LIVE_SOURCE);
+   if (!obj)
+   return ERR_PTR(-EINVAL);
+
+   src = obj_to_live_source(obj);
+
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+   if (!fb)
+   return ERR_PTR(-ENOMEM);
+
+   drm_helper_mode_fill_fb_struct(dev, >fb, mode_cmd);
+
+   fb->src = src;
+
+   ret = drm_framebuffer_init(dev, >fb, _du_live_fb_funcs);
+   if (ret) {
+   dev_err(dev->dev, "Failed to initialize framebuffer: %d\n",
+   ret);
+   kfree(fb);
+   return ERR_PTR(ret);
+   }
+
+   return >fb;
+}
+
 static struct drm_framebuffer *
 rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
  const struct drm_mode_fb_cmd2 *mode_cmd)
@@ -177,6 +245,9 @@ rcar_du_fb_create(struct drm_device *dev
unsigned int bpp;
unsigned int i;
 
+   if (mode_cmd->flags & DRM_MODE_FB_LIVE_SOURCE)
+   return rcar_du_live_fb_create(dev, file_priv, mode_cmd);
+
format = rcar_du_format_info(mode_cmd->pixel_format);
if (format == NULL) {
dev_dbg(dev->dev, "unsupported pixel 

[PATCH v2] ARM: dts: r8a7791: link DU to VSPDs

[Sergei Shtylyov]

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

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

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

 arch/arm/boot/dts/r8a7791.dtsi |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -992,7 +992,7 @@
power-domains = < R8A7791_PD_ALWAYS_ON>;
};
 
-   vsp1@fe93 {
+   vspd0: vsp1@fe93 {
compatible = "renesas,vsp1";
reg = <0 0xfe93 0 0x8000>;
interrupts = ;
@@ -1000,7 +1000,7 @@
power-domains = < R8A7791_PD_ALWAYS_ON>;
};
 
-   vsp1@fe938000 {
+   vspd1: vsp1@fe938000 {
compatible = "renesas,vsp1";
reg = <0 0xfe938000 0 0x8000>;
interrupts = ;
@@ -1019,6 +1019,7 @@
 <_clks R8A7791_CLK_DU1>,
 <_clks R8A7791_CLK_LVDS0>;
clock-names = "du.0", "du.1", "lvds.0";
+   vsps = < >;
status = "disabled";
 
ports {

[PATCH v3 2/3] drm: Connect live source to framebuffers

[Sergei Shtylyov]

From: Laurent Pinchart 

Introduce a new live source flag for framebuffers. When a framebuffer is
created with that flag set, a live source is associated with the
framebuffer instead of buffer objects. The framebuffer can then be used
with a plane to connect it with the live source.

[Sergei: ported to the modern kernel.]

Signed-off-by: Laurent Pinchart 
Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- ported the patch to the modern kernel;
- added my signoff.

 drivers/gpu/drm/drm_framebuffer.c |  134 ++
 include/uapi/drm/drm_mode.h   |7 +
 2 files changed, 113 insertions(+), 28 deletions(-)

Index: linux/drivers/gpu/drm/drm_framebuffer.c
===
--- linux.orig/drivers/gpu/drm/drm_framebuffer.c
+++ linux/drivers/gpu/drm/drm_framebuffer.c
@@ -126,34 +126,18 @@ int drm_mode_addfb(struct drm_device *de
return 0;
 }
 
-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
+static int framebuffer_check_buffers(const struct drm_mode_fb_cmd2 *r,
+int hsub, int vsub)
 {
-   const struct drm_format_info *info;
-   int i;
+   int num_planes, i;
+   unsigned int cpp;
 
-   info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
-   if (!info) {
-   struct drm_format_name_buf format_name;
-   DRM_DEBUG_KMS("bad framebuffer format %s\n",
- drm_get_format_name(r->pixel_format,
- _name));
-   return -EINVAL;
-   }
-
-   if (r->width == 0 || r->width % info->hsub) {
-   DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
-   return -EINVAL;
-   }
-
-   if (r->height == 0 || r->height % info->vsub) {
-   DRM_DEBUG_KMS("bad framebuffer height %u\n", r->height);
-   return -EINVAL;
-   }
+   num_planes = drm_format_num_planes(r->pixel_format);
+   cpp = drm_format_plane_cpp(r->pixel_format, 0);
 
-   for (i = 0; i < info->num_planes; i++) {
-   unsigned int width = r->width / (i != 0 ? info->hsub : 1);
-   unsigned int height = r->height / (i != 0 ? info->vsub : 1);
-   unsigned int cpp = info->cpp[i];
+   for (i = 0; i < num_planes; i++) {
+   unsigned int width = r->width / (i != 0 ? hsub : 1);
+   unsigned int height = r->height / (i != 0 ? vsub : 1);
 
if (!r->handles[i]) {
DRM_DEBUG_KMS("no buffer object handle for plane %d\n", 
i);
@@ -203,7 +187,7 @@ static int framebuffer_check(const struc
}
}
 
-   for (i = info->num_planes; i < 4; i++) {
+   for (i = num_planes; i < 4; i++) {
if (r->modifier[i]) {
DRM_DEBUG_KMS("non-zero modifier for unused plane 
%d\n", i);
return -EINVAL;
@@ -232,6 +216,99 @@ static int framebuffer_check(const struc
return 0;
 }
 
+static int framebuffer_check_sources(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
+{
+   struct drm_mode_object *obj;
+   struct drm_live_source *src;
+   unsigned int cpp;
+   unsigned int i;
+
+   /*
+* Ensure that userspace has zeroed unused handles, pitches, offsets and
+* modifiers to allow future API extensions.
+*/
+   if (r->offsets[0] || r->modifier[0])
+   return -EINVAL;
+
+   for (i = 1; i < ARRAY_SIZE(r->handles); ++i) {
+   if (r->handles[i] || r->pitches[i] ||
+   r->offsets[i] || r->modifier[i])
+   return -EINVAL;
+   }
+
+   /* Validate width, height and pitch. */
+   cpp = drm_format_plane_cpp(r->pixel_format, 0);
+
+   if ((uint64_t) r->width * cpp > UINT_MAX)
+   return -ERANGE;
+
+   if ((uint64_t) r->height * r->pitches[0] > UINT_MAX)
+   return -ERANGE;
+
+   if (r->pitches[0] != r->width * cpp) {
+   DRM_DEBUG_KMS("bad pitch %u for plane %d\n", r->pitches[0], i);
+   return -EINVAL;
+   }
+
+   /*
+* Find the live source and check whether it supports the requested
+* pixel format.
+*/
+
+   obj = drm_mode_object_find(dev, r->handles[0],
+  DRM_MODE_OBJECT_LIVE_SOURCE);
+   if (!obj) {
+   DRM_DEBUG_KMS("bad framebuffer source ID %u\n", r->handles[0]);
+   return -EINVAL;
+   }
+
+   src = obj_to_live_source(obj);
+
+   for (i = 0; i < src->format_count; i++) {
+   if (r->pixel_format == src->format_types[i])
+   break;
+   }
+
+   if (i == 

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

[Geert Uytterhoeven]

Hi Robin,

On Wed, Jan 25, 2017 at 6:27 PM, Robin Murphy  wrote:
> On 25/01/17 16:23, Geert Uytterhoeven wrote:
>> On Mon, May 9, 2016 at 11:37 AM, Robin Murphy  wrote:
>>> On 08/05/16 11:59, Niklas Söderlund wrote:
 While using CONFIG_DMA_API_DEBUG i came across this warning which I
 think is a false positive. As shown dma_sync_single_for_device() are
 called from the dma_map_single() call path. This triggers the warning
 since the dma-debug code have not yet been made aware of the mapping.
>>>
>>> Almost right ;) The thing being mapped (the SPI device's buffer) and the
>>> thing being synced (the IOMMU's PTE) are entirely unrelated. Due to the
>>> current of_iommu_init() setup, the IOMMU is probed long before
>>> dma_debug_init() gets called, therefore DMA debug is missing entries for
>>> some of the initial page table mappings and gets confused when we update
>>> them later.
>>
>> I think I've been seeing the same as Niklas since quite a while.
>> Finally I had a deeper look, and it looks like there is a bug somewhere,
>> causing the wrong IOMMU PTE to be synced.
>>
 I try to solve this by introducing __dma_sync_single_for_device() which
 do not call into the dma-debug code. I'm no expert and this might be a
 bad way of solving the problem but it allowed me to keep working.
>>>
>>> The simple fix should be to just call dma_debug_init() from a sufficiently
>>> earlier initcall level. The best would be to sort out a proper device
>>> dependency order to avoid the whole early-IOMMU-creation thing entirely.
>>
>> And so I did. After disabling the call to dma_debug_fs_init(), you can call
>> dma_debug_init() quite early. But the warning didn't go away:
>
> Yet the underlying reason has subtly changed!
>
>> ipmmu-vmsa e67b.mmu: DMA-API: device driver tries to sync DMA memory
>> it has not allocated [device address=0x00067bab2ff8] [size=8 
>> bytes]
>> [ cut here ]
>> WARNING: CPU: 0 PID: 174 at lib/dma-debug.c:1235 check_sync+0xcc/0x568
>> ...
>> [] check_sync+0xcc/0x568
>> [] debug_dma_sync_single_for_device+0x44/0x4c
>> [] __arm_lpae_set_pte.isra.3+0x6c/0x78
>> [] __arm_lpae_map+0x318/0x384
>> [] arm_lpae_map+0xb0/0xc4
>> [] ipmmu_map+0x48/0x58
>> [] iommu_map+0x120/0x1fc
>> [] __iommu_dma_map+0xb8/0xec
>> [] iommu_dma_map_page+0x50/0x58
>> [] __iommu_map_page+0x54/0x98
>>
>> So, who allocated that memory?
>>
>> During early kernel init (before fs_initcall(dma_debug_init)):
>>
>> arm-lpae io-pgtable: arm_lpae_alloc_pgtable:652: cfg->ias = 32
>
> Note that you have a 32-bit IAS...

Ah, so that's what it means...

>> data->pg_shift = 12 va_bits = 20
>> arm-lpae io-pgtable: arm_lpae_alloc_pgtable:657: data->bits_per_level = 9
>> data->levels = 3 pgd_bits = 2
>> ipmmu-vmsa e67b.mmu: __arm_lpae_alloc_pages:224
>> dma_map_single(0xffc63bab2000, 32) returned 0x00067bab2000
>>
>> Hence 0x67bab2000 is the PGD, which has only 4 entries (32 bytes).
>> Call stack:
>>
>> [] __arm_lpae_alloc_pages.isra.11+0x144/0x1e8
>> [] arm_64_lpae_alloc_pgtable_s1+0xdc/0x118
>> [] arm_32_lpae_alloc_pgtable_s1+0x44/0x68
>> [] alloc_io_pgtable_ops+0x4c/0x80
>> [] ipmmu_attach_device+0xd0/0x3b0
>>
>> When starting DMA from the device:
>>
>> iommu: map: iova 0xfff000 pa 0x00067a555000 size 0x1000 pgsize 
>> 4096
>
> ...then count the f's carefully.

Indeed, 40-bits.

>> arm-lpae io-pgtable: __arm_lpae_map:318: iova 0xfff000
>> phys 0x00067a555000 size 4096 lvl 1 ptep 0xffc63bab2000
>> arm-lpae io-pgtable: __arm_lpae_map:320: incr. ptep to 0xffc63bab2ff8
>> ipmmu-vmsa e67b.mmu: __arm_lpae_alloc_pages:224
>> dma_map_single(0xffc63a49, 4096) returned 0x00067a49
>> ipmmu-vmsa e67b.mmu: DMA-API: device driver tries to sync DMA memory
>> it has not allocated [device address=0x00067bab2ff8] [size=8 
>> bytes]
>>
>> __arm_lpae_map() added "ARM_LPAE_LVL_IDX(iova, lvl, data)" == 0xff8 to ptep
>> (the PGD base address), but the PGD has only 32 bytes, leading to the 
>> warning.
>>
>> Does my analysis make sense?
>> Do you have a clue?
>
> The initial false positive misleads from the fact that this is actually
> DMA-debug doing its job admirably. The bug lies in however you ended up
> trying to map a 40-bit IOVA in a 32-bit pagetable.

Right, I completely forgot that I was still running with a patch to
allow the DMAC to use 40-bit addresses:

dma_set_mask_and_coherent(dmac->dev, DMA_BIT_MASK(40));

which works fine without IOMMU, but fails with, as the IPMMU-VMSA driver
doesn't support that yet.

Thanks a lot, and sorry for the noise...

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, 

[PATCH v6 3/3] ARM: dts: r7s72100: update sdhi clock bindings

[Chris Brandt]

The SDHI controller in the RZ/A1 has 2 clock sources per channel and both
need to be enabled/disabled for proper operation. This fixes the fact that
the define for R7S72100_CLK_SDHI1 was not correct to begin with (typo), and
that all 4 clock sources need to be defined an used.

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
---
v2:
* add missing clock sources instead of just fixing typo
* changed clock name from "carddetect" to "cd"
---
 arch/arm/boot/dts/r7s72100.dtsi| 17 -
 include/dt-bindings/clock/r7s72100-clock.h |  6 --
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 3dd427d..9d0b8d0 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -153,9 +153,12 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0xfcfe0444 4>;
-   clocks = <_clk>, <_clk>;
-   clock-indices = ;
-   clock-output-names = "sdhi1", "sdhi0";
+   clocks = <_clk>, <_clk>, <_clk>, <_clk>;
+   clock-indices = <
+   R7S72100_CLK_SDHI00 R7S72100_CLK_SDHI01
+   R7S72100_CLK_SDHI10 R7S72100_CLK_SDHI11
+   >;
+   clock-output-names = "sdhi00", "sdhi01", "sdhi10", 
"sdhi11";
};
};
 
@@ -478,7 +481,9 @@
  GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH
  GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
 
-   clocks = <_clks R7S72100_CLK_SDHI0>;
+   clocks = <_clks R7S72100_CLK_SDHI00>,
+<_clks R7S72100_CLK_SDHI01>;
+   clock-names = "core", "cd";
cap-sd-highspeed;
cap-sdio-irq;
status = "disabled";
@@ -491,7 +496,9 @@
  GIC_SPI 274 IRQ_TYPE_LEVEL_HIGH
  GIC_SPI 275 IRQ_TYPE_LEVEL_HIGH>;
 
-   clocks = <_clks R7S72100_CLK_SDHI1>;
+   clocks = <_clks R7S72100_CLK_SDHI10>,
+<_clks R7S72100_CLK_SDHI11>;
+   clock-names = "core", "cd";
cap-sd-highspeed;
cap-sdio-irq;
status = "disabled";
diff --git a/include/dt-bindings/clock/r7s72100-clock.h 
b/include/dt-bindings/clock/r7s72100-clock.h
index 29e01ed..f2d8428 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -45,7 +45,9 @@
 #define R7S72100_CLK_SPI4  3
 
 /* MSTP12 */
-#define R7S72100_CLK_SDHI0 3
-#define R7S72100_CLK_SDHI1 2
+#define R7S72100_CLK_SDHI003
+#define R7S72100_CLK_SDHI012
+#define R7S72100_CLK_SDHI101
+#define R7S72100_CLK_SDHI110
 
 #endif /* __DT_BINDINGS_CLOCK_R7S72100_H__ */
-- 
2.10.1

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

[Chris Brandt]

In the case of a single clock source, you don't need names. However,
if the controller has 2 clock sources, you need to name them correctly
so the driver can find the 2nd one. The 2nd clock is for the internal
card detect logic.

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
---
v5:
* add Reviewed-by: Geert Uytterhoeven
* list number of clocks for each SoC
* remove example because it already exists in mmc.txt
v4:
* just explain there might be 2 clocks, don't explain how
  we will use them in the driver
v3:
* add more clarification about why there are sometimes 2 clocks
  and what you should do with them.
* remove 'status = "disabled"' from example
v2:
* fix spelling and change wording
* changed clock name from "carddetect" to "cd"
---
 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt 
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index a1650ed..4fd8b7a 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -25,6 +25,19 @@ 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
+ logic that exists in this controller is sectioned off to be run by a
+ separate second clock source to allow the main core clock to be turned
+ off to save power.
+ If 2 clocks are specified by the hardware, you must name them as
+ "core" and "cd". If the controller only has 1 clock, naming is not
+ required.
+ Below is the number clocks for each supported SoC:
+  1: SH73A0, R8A73A4, R8A7740, R8A7778, R8A7779, R8A7790
+ R8A7791, R8A7792, R8A7793, R8A7794, R8A7795, R8A7796
+  2: R7S72100
+
 Optional properties:
 - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
 - pinctrl-names: should be "default", "state_uhs"
-- 
2.10.1

[PATCH v6 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks

[Chris Brandt]

Some controllers have 2 clock sources instead of 1. The 2nd clock
is for the internal card detect logic and must be enabled/disabled
along with the main core clock for proper operation.

Signed-off-by: Chris Brandt 
---
v5:
* call clk_disable_unprepare even if clk_cd is NULL
v4:
* add technical explanation within probe routine
v3:
* add more clarification to the commit log
v2:
* changed clk2 to clk_cd
* disable clk if clk_cd enable fails
* changed clock name from "carddetect" to "cd"
---
 drivers/mmc/host/sh_mobile_sdhi.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c 
b/drivers/mmc/host/sh_mobile_sdhi.c
index 59db14b..d964a0d 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -143,6 +143,7 @@ MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
 
 struct sh_mobile_sdhi {
struct clk *clk;
+   struct clk *clk_cd;
struct tmio_mmc_data mmc_data;
struct tmio_mmc_dma dma_priv;
struct pinctrl *pinctrl;
@@ -190,6 +191,12 @@ static int sh_mobile_sdhi_clk_enable(struct tmio_mmc_host 
*host)
if (ret < 0)
return ret;
 
+   ret = clk_prepare_enable(priv->clk_cd);
+   if (ret < 0) {
+   clk_disable_unprepare(priv->clk);
+   return ret;
+   }
+
/*
 * The clock driver may not know what maximum frequency
 * actually works, so it should be set with the max-frequency
@@ -255,6 +262,7 @@ static void sh_mobile_sdhi_clk_disable(struct tmio_mmc_host 
*host)
struct sh_mobile_sdhi *priv = host_to_priv(host);
 
clk_disable_unprepare(priv->clk);
+   clk_disable_unprepare(priv->clk_cd);
 }
 
 static int sh_mobile_sdhi_card_busy(struct mmc_host *mmc)
@@ -572,6 +580,21 @@ static int sh_mobile_sdhi_probe(struct platform_device 
*pdev)
goto eprobe;
}
 
+   /*
+* Some controllers provide a 2nd clock just to run the internal card
+* detection logic. Unfortunately, the existing driver architecture does
+* not support a separation of clocks for runtime PM usage. When
+* native hotplug is used, the tmio driver assumes that the core
+* must continue to run for card detect to stay active, so we cannot
+* disable it.
+* Additionally, it is prohibited to supply a clock to the core but not
+* to the card detect circuit. That leaves us with if separate clocks
+* are presented, we must treat them both as virtually 1 clock.
+*/
+   priv->clk_cd = devm_clk_get(>dev, "cd");
+   if (IS_ERR(priv->clk_cd))
+   priv->clk_cd = NULL;
+
priv->pinctrl = devm_pinctrl_get(>dev);
if (!IS_ERR(priv->pinctrl)) {
priv->pins_default = pinctrl_lookup_state(priv->pinctrl,
-- 
2.10.1

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

[Chris Brandt]

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

Re: [PATCH v2 0/3] net: phy: leds: Fix truncated LED trigger names and crashes

[David Miller]

From: Geert Uytterhoeven 
Date: Wed, 25 Jan 2017 11:39:47 +0100

> I started seeing crashes during s2ram and poweroff on all my ARM boards,
> like:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 
> 
> ...
> [] (__list_del_entry_valid) from [] 
> (led_trigger_unregister+0x34/0xcc)
> [] (led_trigger_unregister) from [] 
> (phy_led_triggers_unregister+0x28/0x34)
> [] (phy_led_triggers_unregister) from [] 
> (phy_detach+0x30/0x74)
> [] (phy_detach) from [] (sh_eth_close+0x64/0x9c)
> [] (sh_eth_close) from [] (dpm_run_callback+0x48/0xc8)
> 
> or:
> 
> list_del corruption. prev->next should be dede6540, but was 2e323931
> [ cut here ]
> kernel BUG at lib/list_debug.c:52!
> ...
> [] (__list_del_entry_valid) from [] 
> (led_trigger_unregister+0x34/0xcc)
> [] (led_trigger_unregister) from [] 
> (phy_led_triggers_unregister+0x28/0x34)
> [] (phy_led_triggers_unregister) from [] 
> (phy_detach+0x30/0x74)
> [] (phy_detach) from [] (sh_eth_close+0x6c/0xa4)
> [] (sh_eth_close) from [] (__dev_close_many+0xac/0xd0)
> 
> As the only clue was a kernel message like
> 
> sh-eth ee70.ethernet eth0: No phy led trigger registered for 
> speed(100)
> 
> I had to bisected this, leading to commit 4567d686f5c6d955 ("phy:
> increase size of MII_BUS_ID_SIZE and bus_id").  Reverting that commit
> fixed the issue.
> 
> More investigation revealed the crashes are due to the combination of
> two things:
>   - Truncated LED trigger names, leading to duplicate names, and
> registration failures,
>   - Bad error handling in case of registration failures.
> 
> Both are fixed by this patch series.

Thanks for tracking this down and fixing it.

Series applied, thanks.

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

[Jacopo Mondi]

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

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af..6d72e58 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -294,6 +294,7 @@ source "drivers/pinctrl/mvebu/Kconfig"
 source "drivers/pinctrl/nomadik/Kconfig"
 source "drivers/pinctrl/pxa/Kconfig"
 source "drivers/pinctrl/qcom/Kconfig"
+source "drivers/pinctrl/rz-pfc/Kconfig"
 source "drivers/pinctrl/samsung/Kconfig"
 source "drivers/pinctrl/sh-pfc/Kconfig"
 source "drivers/pinctrl/spear/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f43..96e7ece 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_PINCTRL_MVEBU)   += mvebu/
 obj-y  += nomadik/
 obj-$(CONFIG_PINCTRL_PXA)  += pxa/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_PINCTRL_RZ_PINCTRL)   += rz-pfc/
 obj-$(CONFIG_PINCTRL_SAMSUNG)  += samsung/
 obj-$(CONFIG_PINCTRL_SH_PFC)   += sh-pfc/
 obj-$(CONFIG_PINCTRL_SPEAR)+= spear/
diff --git a/drivers/pinctrl/rz-pfc/Kconfig b/drivers/pinctrl/rz-pfc/Kconfig
new file mode 100644
index 000..3714c10
--- /dev/null
+++ b/drivers/pinctrl/rz-pfc/Kconfig
@@ -0,0 +1,18 @@
+#
+# Renesas RZ pinctrl drivers
+#
+
+if ARCH_RENESAS
+
+config PINCTRL_RZ_PINCTRL
+   select PINMUX
+   select PINCONF
+   select GPIOLIB
+   select GENERIC_PINCONF
+   select GENERIC_PINMUX_FUNCTIONS
+   select GENERIC_PINCTRL_GROUPS
+   def_bool y
+   help
+ This enables pin control drivers for Renesas RZ platforms
+
+endif
diff --git a/drivers/pinctrl/rz-pfc/Makefile b/drivers/pinctrl/rz-pfc/Makefile
new file mode 100644
index 000..cba8283
--- /dev/null
+++ b/drivers/pinctrl/rz-pfc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PINCTRL_RZ_PINCTRL)   += pinctrl-rz.o
diff --git a/drivers/pinctrl/rz-pfc/pinctrl-rz.c 
b/drivers/pinctrl/rz-pfc/pinctrl-rz.c
new file mode 100644
index 000..3efbf03
--- /dev/null
+++ b/drivers/pinctrl/rz-pfc/pinctrl-rz.c
@@ -0,0 +1,447 @@
+/*
+ * Pinctrl support for Renesas RZ Series
+ *
+ * Copyright (C) 2017 Jacopo Mondi
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "../core.h"
+#include "../devicetree.h"
+#include "../pinmux.h"
+
+#include "pinctrl-rz.h"
+
+#define DRIVER_NAME"rz-pinctrl"
+#define RZ_PIN_ARGS_COUNT  3
+
+/**
+ * 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;
+   int i, npins;
+
+   info = rz_pinctrl->info;
+   npins = info->npins;
+   for (i = 0; i < npins; ++i) {
+   rz_pin = >pins[i];
+
+   /*
+* return the pin index in the array, not the pin number,
+* so that we can access it easily when muxing group's pins
+*/
+   if (rz_pin->bank == bank && rz_pin->pin == pin)
+   return i;
+   }
+
+   return -1;
+}
+
+/* 
+ * pinctrl operations
+ */
+static void rz_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
+   unsigned int pin)
+{
+   struct rz_pinctrl_dev *rz_pinctrl;
+   struct rz_pinctrl_info *info;
+
+   rz_pinctrl = pinctrl_dev_get_drvdata(pctldev);
+   info = rz_pinctrl->info;
+
+   seq_printf(s, "%s %s\n", info->pins[pin].name, DRIVER_NAME);
+}
+
+/**
+ * rz_dt_node_to_map() - Parse device tree nodes 

[RFC 3/5] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

[Jacopo Mondi]

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
+
+#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
+
+#endif
-- 
2.7.4

[RFC 0/5] Renesas RZ series pinctrl driver

[Jacopo Mondi]

Hello,
   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.

This RFC series adds a minimal driver infrastructure which supports pin
multiplexing via explicit per-pin settings performed in device tree sources.

The driver is composed by a "core" module, which aims to be generic enough to
support different RZ SoC device, and a "SoC" module, which is instead specific
to the single device.
Right now, the only "SoC" module support implemented is for RZ/A1H (Genmai
and GR-Peach boards).

Why an "SoC" module, if a single SoC is supported then?
RZ devices with a pin-based PFC hardware have different register layouts and
available pin functions, the "SoC" module is requested to enumerate its pins,
and provide function for HW interfacing (currently only set_mux() is supported).
This should make adding support for new chips fairly easy.

One note on the current DT ABI:
right now a pin configuration is specified in DTS using utility macros defined
in the (currently undocumented)
arch/arm/boot/dts/include/dt-bindings/pinctrl/pinctrl-renesas-rz.h header file.
Each pin configuration is a triplet of u32 in the form of



It should be fairly easy adding additional parameters to configure
what was missing in the original group-based PFC driver for RZ devices
(I'm thinking of IO mode control, input buffer configuration, bi-directional
configuration etc).
Once these configuration parameters have been retrieved from the DTS, they can
be passed down to the "SoC" module, and let it deal with them as it does right
now with mux settings.

Currently, there is no support for pinconfig operations, and no GPIO support.
I'm planning to work on GPIO integration as soon as I have sent this out, but
I wanted to send this first to start collecting comments as soon as I could.

I have tested the correctness of mux settings printing out register values,
and enabling/disabling the SCIF2 module connected to serial debug interface.

The series makes use of newly introduced pin[ctrl|mux]_generic functions,
currently only available in Linus Walleij's linux-pinctrl.git tree.
I have merged the devel/ branch of that tree on top of Geert's renesas-drivers
master one.
The merge is available for clone at git://jmondi.org/linux in
jmondi/renesas/pinctrl-devel branch, for the interested ones.

Sending out as RFC, as I do expect lot of comments both from Renesas people that
has a deeper knowledge of other RZ Series SoCs than me, and from gpio/pinctrl
people as this is the first pin control driver I send out (so please bear with
me on this :)

Thank you
   j

Jacopo Mondi (5):
  pinctrl: rz-pfc: Add Renesas RZ pinctrl core module
  pinctrl: rz-pfc: Add Renesas RZ/A1 pinctrl driver
  arm: dts: dt-bindings: Add Renesas RZ pinctrl header
  arm: dts: r7s1000: Add pincontroller node
  arm: dts: genmai: Add SCIF2 pin group

 arch/arm/boot/dts/r7s72100-genmai.dts|  13 +
 arch/arm/boot/dts/r7s72100.dtsi  |  12 +
 drivers/pinctrl/Kconfig  |   1 +
 drivers/pinctrl/Makefile |   1 +
 drivers/pinctrl/rz-pfc/Kconfig   |  25 ++
 drivers/pinctrl/rz-pfc/Makefile  |   2 +
 drivers/pinctrl/rz-pfc/pinctrl-rz.c  | 433 +++
 drivers/pinctrl/rz-pfc/pinctrl-rz.h  | 114 ++
 drivers/pinctrl/rz-pfc/pinctrl-rza1.c| 346 ++
 include/dt-bindings/pinctrl/pinctrl-renesas-rz.h |  19 +
 10 files changed, 966 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
 create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rza1.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-renesas-rz.h

-- 
2.7.4

[RFC 5/5] arm: dts: genmai: Add SCIF2 pin group

[Jacopo Mondi]

Add  TxD and RxD pin configuration for SCIF2 serial communication
interface on r7s72100 Genmai board.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r7s72100-genmai.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts 
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 118a8e2..ea649c7 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include "include/dt-bindings/pinctrl/pinctrl-renesas-rz.h"
 
 / {
model = "Genmai";
@@ -34,6 +35,18 @@
#address-cells = <1>;
#size-cells = <1>;
};
+
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   scif2_pins: serial2 {
+   /* P3_0 as TxD2; P3_2 as RxD2 */
+   renesas-rz,pins = ,
+ ;
+   };
 };
 
 _clk {
-- 
2.7.4

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

[Jacopo Mondi]

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 
---
 drivers/pinctrl/rz-pfc/Kconfig|   7 +
 drivers/pinctrl/rz-pfc/Makefile   |   1 +
 drivers/pinctrl/rz-pfc/pinctrl-rza1.c | 347 ++
 3 files changed, 355 insertions(+)
 create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rza1.c

diff --git a/drivers/pinctrl/rz-pfc/Kconfig b/drivers/pinctrl/rz-pfc/Kconfig
index 3714c10..2b9c111 100644
--- a/drivers/pinctrl/rz-pfc/Kconfig
+++ b/drivers/pinctrl/rz-pfc/Kconfig
@@ -15,4 +15,11 @@ config PINCTRL_RZ_PINCTRL
help
  This enables pin control drivers for Renesas RZ platforms
 
+config PINCTRL_RZA1_PINCTRL
+depends on ARCH_R7S72100
+   select PINCTRL_RZ_PINCTRL
+   def_bool y
+   help
+ This enables pin control drivers for Renesas RZ/A1 SoC
+
 endif
diff --git a/drivers/pinctrl/rz-pfc/Makefile b/drivers/pinctrl/rz-pfc/Makefile
index cba8283..e3befa5 100644
--- 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
@@ -0,0 +1,347 @@
+/*
+ * Pinctrl support for Renesas RZ/A1 SoC
+ *
+ * Copyright (C) 2017 Jacopo Mondi
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "pinctrl-rz.h"
+
+#define RZA1_REG_DBG
+
+/* memory resources indexes */
+#define MEM_RES_LOW0 /* PORTn_base */
+#define MEM_RES_HIGH   1 /* PORTn_base + 0x4000 */
+
+/* displacements from PORTn_base */
+#define PMC_REG0x400
+#define PFC_REG0x500
+#define PFCE_REG   0x600
+#define PFCEA_REG  0xA00
+
+/* displacements from PORTn_base + 0x4000 */
+#define PIBC_REG   0x000
+#define PBDC_REG   0x100
+#define PIPC_REG   0x200
+
+/* build register address using memory base, offset and bank number */
+#define RZA1_ADDR(mem_base, reg, bank) \
+   ((mem_base) + (reg) + (bank * 4))
+
+/* 
+ * pin enumeration
+ */
+enum rza1_pins {
+   /* Port 0 */
+   RZ_PIN_NAME(0, 0) = 0, RZ_PIN_NAME(0, 1), RZ_PIN_NAME(0, 2),
+   RZ_PIN_NAME(0, 3), RZ_PIN_NAME(0, 4), RZ_PIN_NAME(0, 5),
+
+   /* Port 1 */
+   RZ_PIN_NAME(1, 0), RZ_PIN_NAME(1, 1), RZ_PIN_NAME(1, 2),
+   RZ_PIN_NAME(1, 3), RZ_PIN_NAME(1, 4), RZ_PIN_NAME(1, 5),
+   RZ_PIN_NAME(1, 6), RZ_PIN_NAME(1, 7), RZ_PIN_NAME(1, 8),
+   RZ_PIN_NAME(1, 9), RZ_PIN_NAME(1, 10), RZ_PIN_NAME(1, 11),
+   RZ_PIN_NAME(1, 12), RZ_PIN_NAME(1, 13), RZ_PIN_NAME(1, 14),
+   RZ_PIN_NAME(1, 15),
+
+   /* Port 2 */
+   RZ_PIN_NAME(2, 0), RZ_PIN_NAME(2, 1), RZ_PIN_NAME(2, 2),
+   RZ_PIN_NAME(2, 3), RZ_PIN_NAME(2, 4), RZ_PIN_NAME(2, 5),
+   RZ_PIN_NAME(2, 6), RZ_PIN_NAME(2, 7), RZ_PIN_NAME(2, 8),
+   RZ_PIN_NAME(2, 9), RZ_PIN_NAME(2, 10), RZ_PIN_NAME(2, 11),
+   RZ_PIN_NAME(2, 12), RZ_PIN_NAME(2, 13), RZ_PIN_NAME(2, 14),
+   RZ_PIN_NAME(2, 15),
+
+   /* Port 3 */
+   RZ_PIN_NAME(3, 0), RZ_PIN_NAME(3, 1), RZ_PIN_NAME(3, 2),
+   RZ_PIN_NAME(3, 3), RZ_PIN_NAME(3, 4), RZ_PIN_NAME(3, 5),
+   RZ_PIN_NAME(3, 6), RZ_PIN_NAME(3, 7), RZ_PIN_NAME(3, 8),
+   RZ_PIN_NAME(3, 9), RZ_PIN_NAME(3, 10), RZ_PIN_NAME(3, 11),
+   RZ_PIN_NAME(3, 12), RZ_PIN_NAME(3, 13), RZ_PIN_NAME(3, 14),
+   RZ_PIN_NAME(3, 15),
+
+   /* Port 4 */
+   RZ_PIN_NAME(4, 0), RZ_PIN_NAME(4, 1), RZ_PIN_NAME(4, 2),
+   RZ_PIN_NAME(4, 3), RZ_PIN_NAME(4, 4), RZ_PIN_NAME(4, 5),
+   RZ_PIN_NAME(4, 6), RZ_PIN_NAME(4, 7), RZ_PIN_NAME(4, 8),
+   RZ_PIN_NAME(4, 9), RZ_PIN_NAME(4, 10), RZ_PIN_NAME(4, 11),
+   RZ_PIN_NAME(4, 12), RZ_PIN_NAME(4, 13), RZ_PIN_NAME(4, 14),
+   RZ_PIN_NAME(4, 15),
+
+   /* Port 5 */
+   RZ_PIN_NAME(5, 0), RZ_PIN_NAME(5, 1), RZ_PIN_NAME(5, 2),
+   RZ_PIN_NAME(5, 3), RZ_PIN_NAME(5, 4), RZ_PIN_NAME(5, 5),
+   RZ_PIN_NAME(5, 6), RZ_PIN_NAME(5, 7), RZ_PIN_NAME(5, 8),
+   RZ_PIN_NAME(5, 9), RZ_PIN_NAME(5, 10),
+
+   /* Port 6 */
+   RZ_PIN_NAME(6, 0), RZ_PIN_NAME(6, 1), RZ_PIN_NAME(6, 2),
+   RZ_PIN_NAME(6, 3), RZ_PIN_NAME(6, 4), RZ_PIN_NAME(6, 5),
+   RZ_PIN_NAME(6, 6), RZ_PIN_NAME(6, 7), RZ_PIN_NAME(6, 8),
+   RZ_PIN_NAME(6, 9), RZ_PIN_NAME(6, 10), RZ_PIN_NAME(6, 11),
+   

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

[Robin Murphy]

On 25/01/17 16:23, Geert Uytterhoeven wrote:
> Hi Robin,

Hi Geert,

> On Mon, May 9, 2016 at 11:37 AM, Robin Murphy  wrote:
>> On 08/05/16 11:59, Niklas Söderlund wrote:
>>> While using CONFIG_DMA_API_DEBUG i came across this warning which I
>>> think is a false positive. As shown dma_sync_single_for_device() are
>>> called from the dma_map_single() call path. This triggers the warning
>>> since the dma-debug code have not yet been made aware of the mapping.
>>
>> Almost right ;) The thing being mapped (the SPI device's buffer) and the
>> thing being synced (the IOMMU's PTE) are entirely unrelated. Due to the
>> current of_iommu_init() setup, the IOMMU is probed long before
>> dma_debug_init() gets called, therefore DMA debug is missing entries for
>> some of the initial page table mappings and gets confused when we update
>> them later.
> 
> I think I've been seeing the same as Niklas since quite a while.
> Finally I had a deeper look, and it looks like there is a bug somewhere,
> causing the wrong IOMMU PTE to be synced.
> 
>>> I try to solve this by introducing __dma_sync_single_for_device() which
>>> do not call into the dma-debug code. I'm no expert and this might be a
>>> bad way of solving the problem but it allowed me to keep working.
>>
>> The simple fix should be to just call dma_debug_init() from a sufficiently
>> earlier initcall level. The best would be to sort out a proper device
>> dependency order to avoid the whole early-IOMMU-creation thing entirely.
> 
> And so I did. After disabling the call to dma_debug_fs_init(), you can call
> dma_debug_init() quite early. But the warning didn't go away:

Yet the underlying reason has subtly changed!

> ipmmu-vmsa e67b.mmu: DMA-API: device driver tries to sync DMA memory
> it has not allocated [device address=0x00067bab2ff8] [size=8 
> bytes]
> [ cut here ]
> WARNING: CPU: 0 PID: 174 at lib/dma-debug.c:1235 check_sync+0xcc/0x568
> ...
> [] check_sync+0xcc/0x568
> [] debug_dma_sync_single_for_device+0x44/0x4c
> [] __arm_lpae_set_pte.isra.3+0x6c/0x78
> [] __arm_lpae_map+0x318/0x384
> [] arm_lpae_map+0xb0/0xc4
> [] ipmmu_map+0x48/0x58
> [] iommu_map+0x120/0x1fc
> [] __iommu_dma_map+0xb8/0xec
> [] iommu_dma_map_page+0x50/0x58
> [] __iommu_map_page+0x54/0x98
> 
> So, who allocated that memory?
> 
> During early kernel init (before fs_initcall(dma_debug_init)):
> 
> arm-lpae io-pgtable: arm_lpae_alloc_pgtable:652: cfg->ias = 32

Note that you have a 32-bit IAS...

> data->pg_shift = 12 va_bits = 20
> arm-lpae io-pgtable: arm_lpae_alloc_pgtable:657: data->bits_per_level = 9
> data->levels = 3 pgd_bits = 2
> ipmmu-vmsa e67b.mmu: __arm_lpae_alloc_pages:224
> dma_map_single(0xffc63bab2000, 32) returned 0x00067bab2000
> 
> Hence 0x67bab2000 is the PGD, which has only 4 entries (32 bytes).
> Call stack:
> 
> [] __arm_lpae_alloc_pages.isra.11+0x144/0x1e8
> [] arm_64_lpae_alloc_pgtable_s1+0xdc/0x118
> [] arm_32_lpae_alloc_pgtable_s1+0x44/0x68
> [] alloc_io_pgtable_ops+0x4c/0x80
> [] ipmmu_attach_device+0xd0/0x3b0
> 
> When starting DMA from the device:
> 
> iommu: map: iova 0xfff000 pa 0x00067a555000 size 0x1000 pgsize 
> 4096

...then count the f's carefully.

> arm-lpae io-pgtable: __arm_lpae_map:318: iova 0xfff000
> phys 0x00067a555000 size 4096 lvl 1 ptep 0xffc63bab2000
> arm-lpae io-pgtable: __arm_lpae_map:320: incr. ptep to 0xffc63bab2ff8
> ipmmu-vmsa e67b.mmu: __arm_lpae_alloc_pages:224
> dma_map_single(0xffc63a49, 4096) returned 0x00067a49
> ipmmu-vmsa e67b.mmu: DMA-API: device driver tries to sync DMA memory
> it has not allocated [device address=0x00067bab2ff8] [size=8 
> bytes]
> 
> __arm_lpae_map() added "ARM_LPAE_LVL_IDX(iova, lvl, data)" == 0xff8 to ptep
> (the PGD base address), but the PGD has only 32 bytes, leading to the warning.
> 
> Does my analysis make sense?
> Do you have a clue?

The initial false positive misleads from the fact that this is actually
DMA-debug doing its job admirably. The bug lies in however you ended up
trying to map a 40-bit IOVA in a 32-bit pagetable.

Robin.

> 
> Thanks!
> 
> 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/RFC v3 net] ravb: unmap descriptors when freeing rings

[Simon Horman]

On Wed, Jan 25, 2017 at 07:18:15PM +0300, Sergei Shtylyov wrote:
> On 01/24/2017 09:21 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.
> 
>Could you look into the sh_eth driver which seems to have the same issue?

Sure, I will check.

> >Note, ravb_tx_free() is moved but not otherwise modified by this patch.
> 
>This is not true anymore BTW.

Thanks for noticing, I'll fix that.

> >Signed-off-by: Kazuya Mizuguchi 
> >[simon: reworked]
> >Signed-off-by: Simon Horman 
> 
> MBR, Sergei
> 

Re: [PATCH/RFC v3 net] ravb: unmap descriptors when freeing rings

[Simon Horman]

On Wed, Jan 25, 2017 at 07:05:08PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 01/24/2017 09:21 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.
> >
> >Note, ravb_tx_free() is moved but not otherwise modified by this patch.
> >
> >Signed-off-by: Kazuya Mizuguchi 
> >[simon: reworked]
> >Signed-off-by: Simon Horman 
> >--
> >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 | 113 
> > ++-
> > 1 file changed, 65 insertions(+), 48 deletions(-)
> >
> >diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
> >b/drivers/net/ethernet/renesas/ravb_main.c
> >index 89ac1e3f6175..57fe1411bb9d 100644
> >--- a/drivers/net/ethernet/renesas/ravb_main.c
> >+++ b/drivers/net/ethernet/renesas/ravb_main.c
> >@@ -179,6 +179,51 @@ static struct mdiobb_ops bb_ops = {
> > .get_mdio_data = ravb_get_mdio_data,
> > };
> >
> >+enum ravb_tx_free_mode {
> >+ravb_tx_free_all,
> >+ravb_tx_free_txed_only,
> >+};
> >+
> >+/* Free TX skb function for AVB-IP */
> >+static int ravb_tx_free(struct net_device *ndev, int q,
> >+enum ravb_tx_free_mode free_mode)
> 
>Hmm... Sorry but this looks over-engineered. A *bool* parameter (named
> e.g 'all) would suffice IMHO.

Ha! The last time I used a bool for something like this I was encouraged
to use an enum, admittedly that was not kernel code but I was unsure
which way to go this time. I'll change things to bool as you sugget.

> >+{
> >+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]++) {
> >+entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
> >+ NUM_TX_DESC);
> >+desc = >tx_ring[q][entry];
> >+if (free_mode == ravb_tx_free_txed_only &&
> >+desc->die_dt != DT_FEMPTY)
> >+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++;
> >+}
> >+stats->tx_bytes += size;
> 
>Hmmm... we shouldn't count the discarded unsent packets/bytes as sent, 
> right?

Yes, I think so. Sorry for missing that.

> [...]
> >@@ -215,12 +262,19 @@ static void ravb_ring_free(struct net_device *ndev, 
> >int q)
> > }
> >
> > if (priv->tx_ring[q]) {
> >+ravb_tx_free(ndev, q, ravb_tx_free_all);
> >+
> > ring_size = sizeof(struct ravb_tx_desc) *
> > (priv->num_tx_ring[q] * NUM_TX_DESC + 1);
> > dma_free_coherent(ndev->dev.parent, ring_size, priv->tx_ring[q],
> >   priv->tx_desc_dma[q]);
> > priv->tx_ring[q] = NULL;
> > }
> >+
> >+/* Free TX skb ringbuffer.
> >+ * SKBs are freed by ravb_tx_free() call above. */
> 
>This is not a recommended comment format:
> 
> /* bla
>  * bla
>  */

Thanks, I will fix that.

Re: [PATCH] serial: sh-sci: Reformat sci_parse_dt() for git diff

[Simon Horman]

On Wed, Jan 25, 2017 at 03:55:49PM +0100, Geert Uytterhoeven wrote:
> As the function header of sci_parse_dt() 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 

Reviewed-by: Simon Horman 

> ---
>  drivers/tty/serial/sh-sci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 9bc9756a2d15d574..a589544f320661f5 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2816,8 +2816,8 @@ static int sci_remove(struct platform_device *dev)
>  };
>  MODULE_DEVICE_TABLE(of, of_sci_match);
>  
> -static struct plat_sci_port *
> -sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
> +static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
> +   unsigned int *dev_id)
>  {
>   struct device_node *np = pdev->dev.of_node;
>   const struct of_device_id *match;
> -- 
> 1.9.1
> 

Re: [PATCH 0/2] clk: renesas: r8a7795/r8a7796: Add IIC-DVFS clock

[Simon Horman]

On Wed, Jan 25, 2017 at 12:19:32PM +0100, Geert Uytterhoeven wrote:
>   Hi all,
> 
> This patch series, pulled from the rcar-3.5.1 BSP, adds the module
> clocks for IIC-DVFS on the R-Car H3 and M3-W SoCs.
> 
> As this is a dependency for Suspend-to-RAM, I plan to queue this in
> clk-renesas-for-v4.11.
> 
> Thanks for your comments!

Acked-by: Simon Horman 

Re: [PATCH/RFC 3/4] iommu: dma: iommu iova domain reset

[Robin Murphy]

On 25/01/17 12:54, Yoshihiro Shimoda wrote:
> From: Magnus Damm 
> 
> To add a workaround code for ipmmu-vmsa driver, this patch adds
> a new geometry "force_reset_when_empty" not to reuse iova space.

The domain geometry is absolutely not the appropriate place for that. If
anything, it could possibly be a domain attribute, but it has nothing to
do with describing the range of input addresses the hardware is able to
translate.

> When all pfns happen to get unmapped then ask the IOMMU driver to
> flush the state followed by starting from an empty iova space.

And what happens if all the PFNs are never unmapped? Many devices (USB
being among them) use a coherent allocation for some kind of descriptor
buffer which exists for the lifetime of the device, then use streaming
mappings for data transfers - the net result of that is that the number
of PFNs mapped will always be >=1, and eventually streaming mapping will
fail because you've exhausted the address space. And if the device *is*
a USB controller, at that point the thread will hang because the USB
core's response to a DMA mapping failure happens to be "keep trying
indefinitely".

Essentially, however long this allocation workaround postpones it, one
or other failure mode is unavoidable with certain devices unless you can
do something drastic like periodically suspend and resume the entire
system to reset everything.

> Signed-off-by: Magnus Damm 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/iommu/dma-iommu.c | 42 +-
>  drivers/iommu/iova.c  |  9 +
>  include/linux/iommu.h |  2 ++
>  include/linux/iova.h  |  1 +
>  4 files changed, 49 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index a0b8c0f..d0fa0b1 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -42,6 +42,7 @@ struct iommu_dma_cookie {
>   struct iova_domain  iovad;
>   struct list_headmsi_page_list;
>   spinlock_t  msi_lock;
> + spinlock_t  reset_lock;

So now we do get something in the cookie, but it's protecting a bunch of
machinery that's accessible from a wider scope? That doesn't seem like a
good design.

>  };
>  
>  static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
> @@ -74,6 +75,7 @@ int iommu_get_dma_cookie(struct iommu_domain *domain)
>  
>   spin_lock_init(>msi_lock);
>   INIT_LIST_HEAD(>msi_page_list);
> + spin_lock_init(>reset_lock);
>   domain->iova_cookie = cookie;
>   return 0;
>  }
> @@ -208,9 +210,11 @@ int dma_direction_to_prot(enum dma_data_direction dir, 
> bool coherent)
>  static struct iova *__alloc_iova(struct iommu_domain *domain, size_t size,
>   dma_addr_t dma_limit)
>  {
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
>   struct iova_domain *iovad = cookie_iovad(domain);
>   unsigned long shift = iova_shift(iovad);
>   unsigned long length = iova_align(iovad, size) >> shift;
> + unsigned long flags;
>   struct iova *iova;
>  
>   if (domain->geometry.force_aperture)
> @@ -219,9 +223,19 @@ static struct iova *__alloc_iova(struct iommu_domain 
> *domain, size_t size,
>* Enforce size-alignment to be safe - there could perhaps be an
>* attribute to control this per-device, or at least per-domain...
>*/
> - iova = alloc_iova(iovad, length, dma_limit >> shift, true);
> - if (iova)
> - atomic_add(iova_size(iova), >iova_pfns_mapped);
> + if (domain->geometry.force_reset_when_empty) {
> + spin_lock_irqsave(>reset_lock, flags);

Is this locking definitely safe against the potential concurrent callers
of __free_iova() on the same domain who won't touch reset_lock? (It may
well be, it's just not clear)

> +
> + iova = alloc_iova(iovad, length, dma_limit >> shift, true);
> + if (iova)
> + atomic_add(iova_size(iova), >iova_pfns_mapped);
> +
> + spin_unlock_irqrestore(>reset_lock, flags);
> + } else {
> + iova = alloc_iova(iovad, length, dma_limit >> shift, true);
> + if (iova)
> + atomic_add(iova_size(iova), >iova_pfns_mapped);

Why would we even need to keep track of this on non-broken IOMMUS?

> + }
>  
>   return iova;
>  }
> @@ -229,10 +243,28 @@ static struct iova *__alloc_iova(struct iommu_domain 
> *domain, size_t size,
>  void
>  __free_iova_domain(struct iommu_domain *domain, struct iova *iova)
>  {
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
>   struct iova_domain *iovad = cookie_iovad(domain);
> + unsigned long flags;
>  
> - atomic_sub(iova_size(iova), >iova_pfns_mapped);
> - __free_iova(iovad, iova);
> + /* In case force_reset_when_empty is set, do not reuse iova space
> +

Re: [PATCH/RFC 1/4] iommu: dma: track mapped iova

[Robin Murphy]

On 25/01/17 12:53, Yoshihiro Shimoda wrote:
> From: Magnus Damm 
> 
> To track mapped iova for a workaround code in the future.
> 
> Signed-off-by: Magnus Damm 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/iommu/dma-iommu.c | 29 +++--
>  include/linux/iommu.h |  2 ++

So what's being added here is a counter of allocations within the
iova_domain held by an iommu_dma_cookie? Then why is it all the way down
in the iommu_domain and not in the cookie? That's needlessly invasive -
it would be almost understandable (but still horrible) if you needed to
refer to it directly from the IOMMU driver, but as far as I can see you
don't.

Robin.

>  2 files changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 2db0d64..a0b8c0f 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see .
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -147,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, 
> dma_addr_t base,
>   order = __ffs(domain->pgsize_bitmap);
>   base_pfn = max_t(unsigned long, 1, base >> order);
>   end_pfn = (base + size - 1) >> order;
> + atomic_set(>iova_pfns_mapped, 0);
>  
>   /* Check the domain allows at least some access to the device... */
>   if (domain->geometry.force_aperture) {
> @@ -209,6 +211,7 @@ static struct iova *__alloc_iova(struct iommu_domain 
> *domain, size_t size,
>   struct iova_domain *iovad = cookie_iovad(domain);
>   unsigned long shift = iova_shift(iovad);
>   unsigned long length = iova_align(iovad, size) >> shift;
> + struct iova *iova;
>  
>   if (domain->geometry.force_aperture)
>   dma_limit = min(dma_limit, domain->geometry.aperture_end);
> @@ -216,9 +219,23 @@ static struct iova *__alloc_iova(struct iommu_domain 
> *domain, size_t size,
>* 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);
> + iova = alloc_iova(iovad, length, dma_limit >> shift, true);
> + if (iova)
> + atomic_add(iova_size(iova), >iova_pfns_mapped);
> +
> + return iova;
>  }
>  
> +void
> +__free_iova_domain(struct iommu_domain *domain, struct iova *iova)
> +{
> + struct iova_domain *iovad = cookie_iovad(domain);
> +
> + atomic_sub(iova_size(iova), >iova_pfns_mapped);
> + __free_iova(iovad, iova);
> +}
> +
> +
>  /* The IOVA allocator knows what we mapped, so just unmap whatever that was 
> */
>  static void __iommu_dma_unmap(struct iommu_domain *domain, dma_addr_t 
> dma_addr)
>  {
> @@ -235,7 +252,7 @@ static void __iommu_dma_unmap(struct iommu_domain 
> *domain, dma_addr_t dma_addr)
>   size -= iommu_unmap(domain, pfn << shift, size);
>   /* ...and if we can't, then something is horribly, horribly wrong */
>   WARN_ON(size > 0);
> - __free_iova(iovad, iova);
> + __free_iova_domain(domain, iova);
>  }
>  
>  static void __iommu_dma_free_pages(struct page **pages, int count)
> @@ -401,7 +418,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
> size, gfp_t gfp,
>  out_free_sg:
>   sg_free_table();
>  out_free_iova:
> - __free_iova(iovad, iova);
> + __free_iova_domain(domain, iova);
>  out_free_pages:
>   __iommu_dma_free_pages(pages, count);
>   return NULL;
> @@ -447,7 +464,7 @@ static dma_addr_t __iommu_dma_map(struct device *dev, 
> phys_addr_t phys,
>  
>   dma_addr = iova_dma_addr(iovad, iova);
>   if (iommu_map(domain, dma_addr, phys - iova_off, len, prot)) {
> - __free_iova(iovad, iova);
> + __free_iova_domain(domain, iova);
>   return DMA_ERROR_CODE;
>   }
>   return dma_addr + iova_off;
> @@ -613,7 +630,7 @@ int iommu_dma_map_sg(struct device *dev, struct 
> scatterlist *sg,
>   return __finalise_sg(dev, sg, nents, dma_addr);
>  
>  out_free_iova:
> - __free_iova(iovad, iova);
> + __free_iova_domain(domain, iova);
>  out_restore_sg:
>   __invalidate_sg(sg, nents);
>   return 0;
> @@ -689,7 +706,7 @@ static struct iommu_dma_msi_page 
> *iommu_dma_get_msi_page(struct device *dev,
>   return msi_page;
>  
>  out_free_iova:
> - __free_iova(iovad, iova);
> + __free_iova_domain(domain, iova);
>  out_free_page:
>   kfree(msi_page);
>   return NULL;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 0ff5111..91d0159 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -19,6 +19,7 @@
>  #ifndef __LINUX_IOMMU_H
>  #define __LINUX_IOMMU_H
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -84,6 +85,7 @@ struct iommu_domain {
>   

Re: [PATCH/RFC 2/4] iommu: iova: use __alloc_percpu_gfp() with GFP_NOWAIT in init_iova_rcaches()

[Robin Murphy]

On 25/01/17 12:54, Yoshihiro Shimoda wrote:
> In the future, the init_iova_rcaches will be called in atomic.

That screams "doing the wrong thing". The sole point of the rcaches is
to reuse IOVAs, whereas the main point of this series seems to involve
not reusing IOVAs. The fact that we have to affect the allocation of
something we explicitly want to avoid using, rather than, say, not
allocating it at all, is a bit of a red flag.

Also, the rcaches are rather big. Allocating all this lot in atomic
context is not necessarily going to be the best idea.

Robin.

> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/iommu/iova.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index b7268a1..866ad65 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -723,7 +723,9 @@ static void init_iova_rcaches(struct iova_domain *iovad)
>   rcache = >rcaches[i];
>   spin_lock_init(>lock);
>   rcache->depot_size = 0;
> - rcache->cpu_rcaches = __alloc_percpu(sizeof(*cpu_rcache), 
> cache_line_size());
> + rcache->cpu_rcaches = __alloc_percpu_gfp(sizeof(*cpu_rcache),
> +  cache_line_size(),
> +  GFP_NOWAIT);
>   if (WARN_ON(!rcache->cpu_rcaches))
>   continue;
>   for_each_possible_cpu(cpu) {
> 

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

[Geert Uytterhoeven]

Hi Robin,

On Mon, May 9, 2016 at 11:37 AM, Robin Murphy  wrote:
> On 08/05/16 11:59, Niklas Söderlund wrote:
>> While using CONFIG_DMA_API_DEBUG i came across this warning which I
>> think is a false positive. As shown dma_sync_single_for_device() are
>> called from the dma_map_single() call path. This triggers the warning
>> since the dma-debug code have not yet been made aware of the mapping.
>
> Almost right ;) The thing being mapped (the SPI device's buffer) and the
> thing being synced (the IOMMU's PTE) are entirely unrelated. Due to the
> current of_iommu_init() setup, the IOMMU is probed long before
> dma_debug_init() gets called, therefore DMA debug is missing entries for
> some of the initial page table mappings and gets confused when we update
> them later.

I think I've been seeing the same as Niklas since quite a while.
Finally I had a deeper look, and it looks like there is a bug somewhere,
causing the wrong IOMMU PTE to be synced.

>> I try to solve this by introducing __dma_sync_single_for_device() which
>> do not call into the dma-debug code. I'm no expert and this might be a
>> bad way of solving the problem but it allowed me to keep working.
>
> The simple fix should be to just call dma_debug_init() from a sufficiently
> earlier initcall level. The best would be to sort out a proper device
> dependency order to avoid the whole early-IOMMU-creation thing entirely.

And so I did. After disabling the call to dma_debug_fs_init(), you can call
dma_debug_init() quite early. But the warning didn't go away:

ipmmu-vmsa e67b.mmu: DMA-API: device driver tries to sync DMA memory
it has not allocated [device address=0x00067bab2ff8] [size=8 bytes]
[ cut here ]
WARNING: CPU: 0 PID: 174 at lib/dma-debug.c:1235 check_sync+0xcc/0x568
...
[] check_sync+0xcc/0x568
[] debug_dma_sync_single_for_device+0x44/0x4c
[] __arm_lpae_set_pte.isra.3+0x6c/0x78
[] __arm_lpae_map+0x318/0x384
[] arm_lpae_map+0xb0/0xc4
[] ipmmu_map+0x48/0x58
[] iommu_map+0x120/0x1fc
[] __iommu_dma_map+0xb8/0xec
[] iommu_dma_map_page+0x50/0x58
[] __iommu_map_page+0x54/0x98

So, who allocated that memory?

During early kernel init (before fs_initcall(dma_debug_init)):

arm-lpae io-pgtable: arm_lpae_alloc_pgtable:652: cfg->ias = 32
data->pg_shift = 12 va_bits = 20
arm-lpae io-pgtable: arm_lpae_alloc_pgtable:657: data->bits_per_level = 9
data->levels = 3 pgd_bits = 2
ipmmu-vmsa e67b.mmu: __arm_lpae_alloc_pages:224
dma_map_single(0xffc63bab2000, 32) returned 0x00067bab2000

Hence 0x67bab2000 is the PGD, which has only 4 entries (32 bytes).
Call stack:

[] __arm_lpae_alloc_pages.isra.11+0x144/0x1e8
[] arm_64_lpae_alloc_pgtable_s1+0xdc/0x118
[] arm_32_lpae_alloc_pgtable_s1+0x44/0x68
[] alloc_io_pgtable_ops+0x4c/0x80
[] ipmmu_attach_device+0xd0/0x3b0

When starting DMA from the device:

iommu: map: iova 0xfff000 pa 0x00067a555000 size 0x1000 pgsize 4096
arm-lpae io-pgtable: __arm_lpae_map:318: iova 0xfff000
phys 0x00067a555000 size 4096 lvl 1 ptep 0xffc63bab2000
arm-lpae io-pgtable: __arm_lpae_map:320: incr. ptep to 0xffc63bab2ff8
ipmmu-vmsa e67b.mmu: __arm_lpae_alloc_pages:224
dma_map_single(0xffc63a49, 4096) returned 0x00067a49
ipmmu-vmsa e67b.mmu: DMA-API: device driver tries to sync DMA memory
it has not allocated [device address=0x00067bab2ff8] [size=8 bytes]

__arm_lpae_map() added "ARM_LPAE_LVL_IDX(iova, lvl, data)" == 0xff8 to ptep
(the PGD base address), but the PGD has only 32 bytes, leading to the warning.

Does my analysis make sense?
Do you have a clue?

Thanks!

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

[Sergei Shtylyov]

Hello.

On 01/24/2017 09:21 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.

Note, ravb_tx_free() is moved but not otherwise modified by this patch.

Signed-off-by: Kazuya Mizuguchi 
[simon: reworked]
Signed-off-by: Simon Horman 
--
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 | 113 ++-
 1 file changed, 65 insertions(+), 48 deletions(-)

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

+enum ravb_tx_free_mode {
+   ravb_tx_free_all,
+   ravb_tx_free_txed_only,
+};
+
+/* Free TX skb function for AVB-IP */
+static int ravb_tx_free(struct net_device *ndev, int q,
+   enum ravb_tx_free_mode free_mode)


   Hmm... Sorry but this looks over-engineered. A *bool* parameter (named e.g 
'all) would suffice IMHO.



+{
+   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]++) {
+   entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+   desc = >tx_ring[q][entry];
+   if (free_mode == ravb_tx_free_txed_only &&
+   desc->die_dt != DT_FEMPTY)
+   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++;
+   }
+   stats->tx_bytes += size;


   Hmmm... we shouldn't count the discarded unsent packets/bytes as sent, right?

[...]

@@ -215,12 +262,19 @@ static void ravb_ring_free(struct net_device *ndev, int q)
}

if (priv->tx_ring[q]) {
+   ravb_tx_free(ndev, q, ravb_tx_free_all);
+
ring_size = sizeof(struct ravb_tx_desc) *
(priv->num_tx_ring[q] * NUM_TX_DESC + 1);
dma_free_coherent(ndev->dev.parent, ring_size, priv->tx_ring[q],
  priv->tx_desc_dma[q]);
priv->tx_ring[q] = NULL;
}
+
+   /* Free TX skb ringbuffer.
+* SKBs are freed by ravb_tx_free() call above. */


   This is not a recommended comment format:

/* bla
 * bla
 */

[...]

MBR, Sergei

[PATCH] serial: sh-sci: Reformat sci_parse_dt() for git diff

[Geert Uytterhoeven]

As the function header of sci_parse_dt() 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 
---
 drivers/tty/serial/sh-sci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9bc9756a2d15d574..a589544f320661f5 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2816,8 +2816,8 @@ static int sci_remove(struct platform_device *dev)
 };
 MODULE_DEVICE_TABLE(of, of_sci_match);
 
-static struct plat_sci_port *
-sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
+static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
+ unsigned int *dev_id)
 {
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *match;
-- 
1.9.1

Re: [PATCH] arm64: renesas: r8a7795: tidyup audma definition order

[Geert Uytterhoeven]

Hi Morimoto-san,

On Wed, Dec 21, 2016 at 5:56 AM, Kuninori Morimoto
 wrote:
> From: Kuninori Morimoto 
>
> Current r8a7795.dtsi defines audma -> ipmmu -> dma order.
> Because of this order, dma can connect to ipmmu, but
> audma can't connect to it.
> This patch moves audma order as ipmmu -> dma -> audma.

Does "[PATCH V7 00/11] IOMMU probe deferral support" help?
https://www.spinics.net/lists/arm-kernel/msg557110.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 Wed, Jan 25, 2017 at 3:35 PM, Chris Brandt  wrote:
> On Wednesday, January 25, 2017, Geert Uytterhoeven wrote:
>> > But won't the individual drivers still want to keep turning clocks on
>> and off manually?
>> > (unless I'm not understanding that the underlying clock routines will
>> basically just
>> > ignore everything). But even if that' the case...that just wasted CPU
>> cycles (remember,
>> > I'm only working with a 400MHz single core here running XIP_KERNEL)
>>
>> If a clock is already enabled, preparing and/or enabling it again will
>> just
>> increase the prepare resp. enable counters. Disabling/unpreparing
>> afterwards
>> will also just decrease the counters. Should be quite cheap
>
> OK, I think I see your point:
>
> If I go and double-enable a clock, then the runtime pm won't do much
> of anything because I'll always be a count higher so a true 'clock disable'
> will never really occur. Is that correct?

That's correct.

> #I'm getting side tracked from what I really started to do which was test
> out PFC for i2c and spi :(

Welcome to the world of scratching your (increasing number of) itches ;-)

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

[Chris Brandt]

Hi Geert,

On Wednesday, January 25, 2017, Geert Uytterhoeven wrote:
> > I can play around and see. I know udealy(100) works OK, but then I
> > have to have a delay that's as long as the slowest peripheral.
> > If it was just to turn a clock on once, or once in a while, that's OK.
> > But it seems like runtime pm wants to turn the clocks on/off as much
> > as possible.
> 
> That's not really true: depending on tuning and/or QoS parameters,
> pm_runtime_put() may anticipate future use, and may decide not turn off
> the clock immediately.
> It may be worth looking into that, and to see how to relax that behavior
> on RZ/A1.

Yes, if there is a way to relax things, then that would be better.


> > But won't the individual drivers still want to keep turning clocks on
> and off manually?
> > (unless I'm not understanding that the underlying clock routines will
> basically just
> > ignore everything). But even if that' the case...that just wasted CPU
> cycles (remember,
> > I'm only working with a 400MHz single core here running XIP_KERNEL)
> 
> If a clock is already enabled, preparing and/or enabling it again will
> just
> increase the prepare resp. enable counters. Disabling/unpreparing
> afterwards
> will also just decrease the counters. Should be quite cheap

OK, I think I see your point:

If I go and double-enable a clock, then the runtime pm won't do much
of anything because I'll always be a count higher so a true 'clock disable'
will never really occur. Is that correct?



#I'm getting side tracked from what I really started to do which was test
out PFC for i2c and spi :(



Chris

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

[Chris Brandt]

Hi Daniel,

On Wednesday, January 25, 2017, Daniel Lezcano wrote:
> > Then things work, but I'm back to managing the rollback code manually.
> >
> >
> > Any other ideas on how to get the corresponding platform_device for a
> > DT node?
> 
> No :/
> 
> So up to you.
>   - CLOCKSOURCE_OF_DECLARE consistent but need rollback
>   or
>   - platform_device but with another timer available at early time

As far as I can tell, the rollback functions don't mind if I pass NULL
pointers to them. So with CLOCKSOURCE_OF_DECLARE, my error rollback at
the end of ostm_init is basically:


err:
if (ret) {
clk_disable_unprepare(ostm_clk);
iounmap(ostm->base);
kfree(ostm);
return ret;
}

return 0;
}



If I go with CLOCKSOURCE_OF_DECLARE, I can at least get rid of the early boot 
message
"clocksource_probe: no matching clocksources found"

I'll go ahead and send a v4 today with all the changes you suggested.

Thank you for your help.

Regards,
Chris

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

[Chris Brandt]

Hi Geert,

On Wednesday, January 25, 2017, Geert Uytterhoeven wrote:
> > So I realized that in order to use builtin_platform, I can't have any
> > of the functions in __init because the build system has no idea that I
> > never plan on removing or probing again after boot. But, even if I
> > take out all the __init from my code, I'm still calling
> > clocksource_mmio_init which is __init so I can never escape the "Section
> mismatch".
> 
> For single-probe drivers, you can use builtin_platform_driver_probe().


Thank you for the info.


Chris

[PATCH 2/2] arm64: dts: r8a7796: Mark EthernetAVB device node disabled

[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.

Fixes: 8e8b9eaef8fb05d9 ("arm64: dts: renesas: r8a7796: Add EthernetAVB 
instance")
Signed-off-by: Geert Uytterhoeven 
---
r8a7796-salvator-x.dts already has the override.

 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 82c5ef1b60659944..f7120cdedd0d67b2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -472,6 +472,7 @@
phy-mode = "rgmii-id";
#address-cells = <1>;
#size-cells = <0>;
+   status = "disabled";
};
 
scif2: serial@e6e88000 {
-- 
1.9.1

[PATCH 1/2] arm64: dts: r8a7795: Mark EthernetAVB device node disabled

[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.

Fixes: a92843c8a6f8c039 ("arm64: dts: r8a7795: add EthernetAVB device node")
Signed-off-by: Geert Uytterhoeven 
---
r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts already have the override.

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 8b030c323c10488d..337061b8e99ec738 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -566,6 +566,7 @@
phy-mode = "rgmii-id";
#address-cells = <1>;
#size-cells = <0>;
+   status = "disabled";
};
 
can0: can@e6c3 {
-- 
1.9.1

[PATCH 0/2] arm64: dts: renesas: Mark EthernetAVB device nodes disabled

[Geert Uytterhoeven]

Hi Simon, Magnus,

This patch series marks the EthernetAVB device nodes in the R-Car H3 and
M3-W DTSes disabled.
Device nodes representing I/O devices should be marked disabled in the
SoC-specific DTSes, and overridden by board-specific DTSes where needed.

Thanks for applying!

Geert Uytterhoeven (2):
  arm64: dts: r8a7795: Mark EthernetAVB device node disabled
  arm64: dts: r8a7796: Mark EthernetAVB device node disabled

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 1 +
 2 files changed, 2 insertions(+)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

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

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

[PATCH/RFC 1/4] iommu: dma: track mapped iova

[Yoshihiro Shimoda]

From: Magnus Damm 

To track mapped iova for a workaround code in the future.

Signed-off-by: Magnus Damm 
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/dma-iommu.c | 29 +++--
 include/linux/iommu.h |  2 ++
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 2db0d64..a0b8c0f 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -147,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, 
dma_addr_t base,
order = __ffs(domain->pgsize_bitmap);
base_pfn = max_t(unsigned long, 1, base >> order);
end_pfn = (base + size - 1) >> order;
+   atomic_set(>iova_pfns_mapped, 0);
 
/* Check the domain allows at least some access to the device... */
if (domain->geometry.force_aperture) {
@@ -209,6 +211,7 @@ static struct iova *__alloc_iova(struct iommu_domain 
*domain, size_t size,
struct iova_domain *iovad = cookie_iovad(domain);
unsigned long shift = iova_shift(iovad);
unsigned long length = iova_align(iovad, size) >> shift;
+   struct iova *iova;
 
if (domain->geometry.force_aperture)
dma_limit = min(dma_limit, domain->geometry.aperture_end);
@@ -216,9 +219,23 @@ static struct iova *__alloc_iova(struct iommu_domain 
*domain, size_t size,
 * 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);
+   iova = alloc_iova(iovad, length, dma_limit >> shift, true);
+   if (iova)
+   atomic_add(iova_size(iova), >iova_pfns_mapped);
+
+   return iova;
 }
 
+void
+__free_iova_domain(struct iommu_domain *domain, struct iova *iova)
+{
+   struct iova_domain *iovad = cookie_iovad(domain);
+
+   atomic_sub(iova_size(iova), >iova_pfns_mapped);
+   __free_iova(iovad, iova);
+}
+
+
 /* The IOVA allocator knows what we mapped, so just unmap whatever that was */
 static void __iommu_dma_unmap(struct iommu_domain *domain, dma_addr_t dma_addr)
 {
@@ -235,7 +252,7 @@ static void __iommu_dma_unmap(struct iommu_domain *domain, 
dma_addr_t dma_addr)
size -= iommu_unmap(domain, pfn << shift, size);
/* ...and if we can't, then something is horribly, horribly wrong */
WARN_ON(size > 0);
-   __free_iova(iovad, iova);
+   __free_iova_domain(domain, iova);
 }
 
 static void __iommu_dma_free_pages(struct page **pages, int count)
@@ -401,7 +418,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
size, gfp_t gfp,
 out_free_sg:
sg_free_table();
 out_free_iova:
-   __free_iova(iovad, iova);
+   __free_iova_domain(domain, iova);
 out_free_pages:
__iommu_dma_free_pages(pages, count);
return NULL;
@@ -447,7 +464,7 @@ static dma_addr_t __iommu_dma_map(struct device *dev, 
phys_addr_t phys,
 
dma_addr = iova_dma_addr(iovad, iova);
if (iommu_map(domain, dma_addr, phys - iova_off, len, prot)) {
-   __free_iova(iovad, iova);
+   __free_iova_domain(domain, iova);
return DMA_ERROR_CODE;
}
return dma_addr + iova_off;
@@ -613,7 +630,7 @@ int iommu_dma_map_sg(struct device *dev, struct scatterlist 
*sg,
return __finalise_sg(dev, sg, nents, dma_addr);
 
 out_free_iova:
-   __free_iova(iovad, iova);
+   __free_iova_domain(domain, iova);
 out_restore_sg:
__invalidate_sg(sg, nents);
return 0;
@@ -689,7 +706,7 @@ static struct iommu_dma_msi_page 
*iommu_dma_get_msi_page(struct device *dev,
return msi_page;
 
 out_free_iova:
-   __free_iova(iovad, iova);
+   __free_iova_domain(domain, iova);
 out_free_page:
kfree(msi_page);
return NULL;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 0ff5111..91d0159 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -19,6 +19,7 @@
 #ifndef __LINUX_IOMMU_H
 #define __LINUX_IOMMU_H
 
+#include 
 #include 
 #include 
 #include 
@@ -84,6 +85,7 @@ struct iommu_domain {
void *handler_token;
struct iommu_domain_geometry geometry;
void *iova_cookie;
+   atomic_t iova_pfns_mapped;
 };
 
 enum iommu_cap {
-- 
1.9.1

[PATCH/RFC 4/4] iommu: ipmmu-vmsa: enable force_reset_when_empty

[Yoshihiro Shimoda]

The IPMMU of R-Car Gen3 will mistake an address translation if
IMCTR.FLUSH is set while some related devices that on the same doamin
are running. To avoid this, this patch uses the force_reset_when_empty
feature.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 11550ac..4b62969 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -302,7 +302,8 @@ static void ipmmu_tlb_flush_all(void *cookie)
 {
struct ipmmu_vmsa_domain *domain = cookie;
 
-   ipmmu_tlb_invalidate(domain);
+   if (!domain->io_domain.geometry.force_reset_when_empty)
+   ipmmu_tlb_invalidate(domain);
 }
 
 static void ipmmu_tlb_add_flush(unsigned long iova, size_t size,
@@ -555,6 +556,13 @@ static void ipmmu_domain_free(struct iommu_domain 
*io_domain)
kfree(domain);
 }
 
+static void ipmmu_domain_reset(struct iommu_domain *io_domain)
+{
+   struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain);
+
+   ipmmu_tlb_invalidate(domain);
+}
+
 static int ipmmu_attach_device(struct iommu_domain *io_domain,
   struct device *dev)
 {
@@ -832,6 +840,7 @@ static struct iommu_domain *ipmmu_domain_alloc(unsigned 
type)
 static const struct iommu_ops ipmmu_ops = {
.domain_alloc = ipmmu_domain_alloc,
.domain_free = ipmmu_domain_free,
+   .domain_reset = ipmmu_domain_reset,
.attach_dev = ipmmu_attach_device,
.detach_dev = ipmmu_detach_device,
.map = ipmmu_map,
@@ -858,8 +867,10 @@ static struct iommu_domain 
*ipmmu_domain_alloc_dma(unsigned type)
 
case IOMMU_DOMAIN_DMA:
io_domain = __ipmmu_domain_alloc(type);
-   if (io_domain)
+   if (io_domain) {
iommu_get_dma_cookie(io_domain);
+   io_domain->geometry.force_reset_when_empty = true;
+   }
break;
}
 
@@ -927,6 +938,7 @@ static int ipmmu_of_xlate_dma(struct device *dev,
 static const struct iommu_ops ipmmu_ops = {
.domain_alloc = ipmmu_domain_alloc_dma,
.domain_free = ipmmu_domain_free_dma,
+   .domain_reset = ipmmu_domain_reset,
.attach_dev = ipmmu_attach_device,
.detach_dev = ipmmu_detach_device,
.map = ipmmu_map,
-- 
1.9.1

[PATCH/RFC 0/4] iommu: add workaround for R-Car Gen3 IPMMU

[Yoshihiro Shimoda]

This patch set is based on:
 iommu.git / next branch and the following patch that Magnus-san sent:
 [patch v6 00/07] iommu/ipmmu-vmsa: ipmmu multi-arch update v6

R-Car Gen3 IPMMU has an issue that will mistake an address translation
if IMCTR.FLUSH is set while some related devices that on the same domain
are running.

To avoid this, we have some choices but any ideas are not perfect...
 1) IMUCTR.FLUSH of the connected device is set after the device stopped.
  - For now, IPMMU driver cannot know the dev pointer in map/unmap timing.
So, we cannot implement such a code.
 2) IMCTR.FLUSH is set after all devices are unmapped on the domain.

 - In any cases, before DMA API's "unmap" calling, the device should be stopped.
   However, some device drivers (e.g. USB EHCI) don't do so.
 - If we have a special API to set the register and call the API on each
   device drivers, maybe we can avoid the issue. But, I think it is not
   acceptable in upstream...

Anyway, this patch set has the idea 2) above to avoid the issue.
But, I'm not sure, this is good or not. So, I marked this patch set as "RFC".

Magnus Damm (2):
  iommu: dma: track mapped iova
  iommu: dma: iommu iova domain reset

Yoshihiro Shimoda (2):
  iommu: iova: use __alloc_percpu_gfp() with GFP_NOWAIT in
init_iova_rcaches()
  iommu: ipmmu-vmsa: enable force_reset_when_empty

 drivers/iommu/dma-iommu.c  | 61 +-
 drivers/iommu/iova.c   | 13 +-
 drivers/iommu/ipmmu-vmsa.c | 16 ++--
 include/linux/iommu.h  |  4 +++
 include/linux/iova.h   |  1 +
 5 files changed, 86 insertions(+), 9 deletions(-)

-- 
1.9.1

[PATCH/RFC 2/4] iommu: iova: use __alloc_percpu_gfp() with GFP_NOWAIT in init_iova_rcaches()

[Yoshihiro Shimoda]

In the future, the init_iova_rcaches will be called in atomic.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/iova.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index b7268a1..866ad65 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -723,7 +723,9 @@ static void init_iova_rcaches(struct iova_domain *iovad)
rcache = >rcaches[i];
spin_lock_init(>lock);
rcache->depot_size = 0;
-   rcache->cpu_rcaches = __alloc_percpu(sizeof(*cpu_rcache), 
cache_line_size());
+   rcache->cpu_rcaches = __alloc_percpu_gfp(sizeof(*cpu_rcache),
+cache_line_size(),
+GFP_NOWAIT);
if (WARN_ON(!rcache->cpu_rcaches))
continue;
for_each_possible_cpu(cpu) {
-- 
1.9.1

Re: [PATCH v2 2/3] net: phy: leds: Break dependency of phy.h on phy_led_triggers.h

[Andrew Lunn]

On Wed, Jan 25, 2017 at 11:39:49AM +0100, Geert Uytterhoeven wrote:
>  includes , which is not really
> needed.  Drop the include from , and add it to all users
> that didn't include it explicitly.
> 
> Suggested-by: Andrew Lunn 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH v2 3/3] net: phy: leds: Fix truncated LED trigger names

[Andrew Lunn]

On Wed, Jan 25, 2017 at 11:39:50AM +0100, Geert Uytterhoeven wrote:
> Commit 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and
> bus_id") increased the size of MII bus IDs, but forgot to update the
> private definition in .
> This may cause:
>   1. Truncation of LED trigger names,
>   2. Duplicate LED trigger names,
>   3. Failures registering LED triggers,
>   4. Crashes due to bad error handling in the LED trigger failure path.
> 
> To fix this, and prevent the definitions going out of sync again in the
> future, let the PHY LED trigger code use the existing MII_BUS_ID_SIZE
> definition.
> 
> Example:
>   - Before I had triggers "ee70.etherne:01:100Mbps" and
> "ee70.etherne:01:10Mbps",
>   - After the increase of MII_BUS_ID_SIZE, both became
> "ee70.ethernet-:01:" => FAIL,
>   - Now, the triggers are "ee70.ethernet-:01:100Mbps" and
> "ee70.ethernet-:01:10Mbps", which are unique again.
> 
> Fixes: 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and bus_id")
> Fixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy 
> link state change")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Andrew Lunn 

Andrew

[PATCH 1/2] clk: renesas: r8a7795: Add IIC-DVFS clock

[Geert Uytterhoeven]

From: Keita Kobayashi 

This patch adds DVFS clock 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: Geert Uytterhoeven 
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c 
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 50698a7d90745447..bfffdb00df972547 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -221,6 +221,7 @@ enum clk_ids {
DEF_MOD("can-if0",   916,   R8A7795_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A7795_CLK_S3D2),
DEF_MOD("i2c5",  919,   R8A7795_CLK_S3D2),
+   DEF_MOD("i2c-dvfs",  926,   R8A7795_CLK_CP),
DEF_MOD("i2c4",  927,   R8A7795_CLK_S3D2),
DEF_MOD("i2c3",  928,   R8A7795_CLK_S3D2),
DEF_MOD("i2c2",  929,   R8A7795_CLK_S3D2),
-- 
1.9.1

[PATCH 2/2] clk: renesas: r8a7796: Add IIC-DVFS clock

[Geert Uytterhoeven]

From: Khiem Nguyen 

This patch adds DVFS clock for R8A7796 SoC.

Signed-off-by: Khiem Nguyen 
Signed-off-by: Dien Pham 
Signed-off-by: Takeshi Kihara 
Signed-off-by: Geert Uytterhoeven 
---
Khiem: I've updated your email address, and added your missing SoB.
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 3bc36ef3aebf4108..11e084a56b0d9005 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -192,6 +192,7 @@ enum clk_ids {
DEF_MOD("can-if0",   916,   R8A7796_CLK_S3D4),
DEF_MOD("i2c6",  918,   R8A7796_CLK_S0D6),
DEF_MOD("i2c5",  919,   R8A7796_CLK_S0D6),
+   DEF_MOD("i2c-dvfs",  926,   R8A7796_CLK_CP),
DEF_MOD("i2c4",  927,   R8A7796_CLK_S0D6),
DEF_MOD("i2c3",  928,   R8A7796_CLK_S0D6),
DEF_MOD("i2c2",  929,   R8A7796_CLK_S3D2),
-- 
1.9.1

[PATCH 0/2] clk: renesas: r8a7795/r8a7796: Add IIC-DVFS clock

[Geert Uytterhoeven]

Hi all,

This patch series, pulled from the rcar-3.5.1 BSP, adds the module
clocks for IIC-DVFS on the R-Car H3 and M3-W SoCs.

As this is a dependency for Suspend-to-RAM, I plan to queue this in
clk-renesas-for-v4.11.

Thanks for your comments!

Keita Kobayashi (1):
  clk: renesas: r8a7795: Add IIC-DVFS clock

Khiem Nguyen (1):
  clk: renesas: r8a7796: Add IIC-DVFS clock

 drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 +
 2 files changed, 2 insertions(+)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

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

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

[PATCH v2 3/3] net: phy: leds: Fix truncated LED trigger names

[Geert Uytterhoeven]

Commit 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and
bus_id") increased the size of MII bus IDs, but forgot to update the
private definition in .
This may cause:
  1. Truncation of LED trigger names,
  2. Duplicate LED trigger names,
  3. Failures registering LED triggers,
  4. Crashes due to bad error handling in the LED trigger failure path.

To fix this, and prevent the definitions going out of sync again in the
future, let the PHY LED trigger code use the existing MII_BUS_ID_SIZE
definition.

Example:
  - Before I had triggers "ee70.etherne:01:100Mbps" and
"ee70.etherne:01:10Mbps",
  - After the increase of MII_BUS_ID_SIZE, both became
"ee70.ethernet-:01:" => FAIL,
  - Now, the triggers are "ee70.ethernet-:01:100Mbps" and
"ee70.ethernet-:01:10Mbps", which are unique again.

Fixes: 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and bus_id")
Fixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy 
link state change")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Drop moving the include of , as
 no longer includes it,
  - #include  from .
---
 include/linux/phy_led_triggers.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/phy_led_triggers.h b/include/linux/phy_led_triggers.h
index a2daea0a37d2ae14..b37b05bfd1a6dd8a 100644
--- a/include/linux/phy_led_triggers.h
+++ b/include/linux/phy_led_triggers.h
@@ -18,11 +18,11 @@
 #ifdef CONFIG_LED_TRIGGER_PHY
 
 #include 
+#include 
 
 #define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE  10
-#define PHY_MII_BUS_ID_SIZE(20 - 3)
 
-#define PHY_LINK_LED_TRIGGER_NAME_SIZE (PHY_MII_BUS_ID_SIZE + \
+#define PHY_LINK_LED_TRIGGER_NAME_SIZE (MII_BUS_ID_SIZE + \
   FIELD_SIZEOF(struct mdio_device, addr)+\
   PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE)
 
-- 
1.9.1

[ANNOUNCE] Renesas tree closed for v4.11

[Simon Horman]

Hi,

I would like to stop accepting non-bug-fix patches for v4.11 and get
the last pull requests posted by the end of this week. This is in order
for them to be sent before the release of v4.10-rc6, the deadline set by the
ARM SoC maintainers.  As patches should ideally progress from the renesas
tree into linux-next before sending pull requests there is a few days lead
time involved.

I intend to begin queueing up patches for v4.12 as new patches are ready.

[PATCH v2 2/3] net: phy: leds: Break dependency of phy.h on phy_led_triggers.h

[Geert Uytterhoeven]

 includes , which is not really
needed.  Drop the include from , and add it to all users
that didn't include it explicitly.

Suggested-by: Andrew Lunn 
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - New.
---
 drivers/net/phy/phy.c  | 1 +
 drivers/net/phy/phy_led_triggers.c | 1 +
 include/linux/phy.h| 1 -
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 48da6e93c3f783e0..807abd6e331f8aa2 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/phy/phy_led_triggers.c 
b/drivers/net/phy/phy_led_triggers.c
index 3f619e7371e97d8a..94ca42e630bbead0 100644
--- a/drivers/net/phy/phy_led_triggers.c
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -12,6 +12,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 
 static struct phy_led_trigger *phy_speed_to_led_trigger(struct phy_device *phy,
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5c9d2529685fe215..43474f39ef6523c5 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
-- 
1.9.1

[PATCH v2 0/3] net: phy: leds: Fix truncated LED trigger names and crashes

[Geert Uytterhoeven]

Hi David,

I started seeing crashes during s2ram and poweroff on all my ARM boards,
like:

Unable to handle kernel NULL pointer dereference at virtual address 
...
[] (__list_del_entry_valid) from [] 
(led_trigger_unregister+0x34/0xcc)
[] (led_trigger_unregister) from [] 
(phy_led_triggers_unregister+0x28/0x34)
[] (phy_led_triggers_unregister) from [] 
(phy_detach+0x30/0x74)
[] (phy_detach) from [] (sh_eth_close+0x64/0x9c)
[] (sh_eth_close) from [] (dpm_run_callback+0x48/0xc8)

or:

list_del corruption. prev->next should be dede6540, but was 2e323931
[ cut here ]
kernel BUG at lib/list_debug.c:52!
...
[] (__list_del_entry_valid) from [] 
(led_trigger_unregister+0x34/0xcc)
[] (led_trigger_unregister) from [] 
(phy_led_triggers_unregister+0x28/0x34)
[] (phy_led_triggers_unregister) from [] 
(phy_detach+0x30/0x74)
[] (phy_detach) from [] (sh_eth_close+0x6c/0xa4)
[] (sh_eth_close) from [] (__dev_close_many+0xac/0xd0)

As the only clue was a kernel message like

sh-eth ee70.ethernet eth0: No phy led trigger registered for speed(100)

I had to bisected this, leading to commit 4567d686f5c6d955 ("phy:
increase size of MII_BUS_ID_SIZE and bus_id").  Reverting that commit
fixed the issue.

More investigation revealed the crashes are due to the combination of
two things:
  - Truncated LED trigger names, leading to duplicate names, and
registration failures,
  - Bad error handling in case of registration failures.

Both are fixed by this patch series.

Changes compared to v1:
  - Add Reviewed-by,
  - New patch "net: phy: leds: Break dependency of phy.h on
phy_led_triggers.h",
  - Drop moving the include of , as
 no longer includes it,
  - #include  from .

Thanks!

Geert Uytterhoeven (3):
  net: phy: leds: Clear phy_num_led_triggers on failure to avoid crash
  net: phy: leds: Break dependency of phy.h on phy_led_triggers.h
  net: phy: leds: Fix truncated LED trigger names

 drivers/net/phy/phy.c  | 1 +
 drivers/net/phy/phy_led_triggers.c | 9 +++--
 include/linux/phy.h| 1 -
 include/linux/phy_led_triggers.h   | 4 ++--
 4 files changed, 10 insertions(+), 5 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

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

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

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

[Simon Horman]

On Tue, Jan 24, 2017 at 04:32:30PM +, Chris Brandt wrote:
> On Tuesday, January 24, 2017, Simon Horman wrote:
> > On Mon, Jan 23, 2017 at 04:12:16PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Jan 23, 2017 at 3:13 PM, Chris Brandt 
> > wrote:
> > > > Signed-off-by: Chris Brandt 
> > >
> > > Reported-by: Geert Uytterhoeven 
> > > Acked-by: Geert Uytterhoeven 
> > 
> > Should this be queued up as a fix for v4.10 with the following tag?
> > 
> > Fixes: 887862227ba3 ("ARM: dts: r7s72100: add mmcif to device tree")
> 
> I assume it can. I'm not sure how it effect the driver one way good or bad
> (that's a question for Geert I think).
> SDHI for r7s72100 needs it too, I just didn't send that yet because my other
> fix will cause a merge conflict because it is modifying the same line. But, 
> that patch is taking longer than I expected.
> 
> My guess is that power-domains is for runtime power management...which seems
> to be a sore subject for r7s72100 at this point.

Geert tells me that this should not have a runtime effect.
Accordingly, I will queued it up for v4.11.

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

[Simon Horman]

On Wed, Jan 25, 2017 at 10:02:13AM +0100, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - Remove unneeded parentheses in phys_to_sbar().

Thanks, I have queued this up for v4.11.

Re: [PATCH] arm64: renesas: r8a7795: tidyup audma definition order

[Simon Horman]

Hi Morimoto-san,

sorry for missing this earlier.

The patch did not seem to compile so I have applied it manually
by moving the audma0 and audma1 nodes to between the dmac2 and avb nodes.

The result is follows:

From: Kuninori Morimoto 
Subject: [PATCH] arm64: renesas: r8a7795: tidyup audma definition order

Current r8a7795.dtsi defines audma -> ipmmu -> dma order.
Because of this order, dma can connect to ipmmu, but
audma can't connect to it.
This patch moves audma order as ipmmu -> dma -> audma.

Signed-off-by: Kuninori Morimoto 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 132 +++
 1 file changed, 66 insertions(+), 66 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 8b030c323c10..74a4e1ad057d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -340,72 +340,6 @@
#power-domain-cells = <1>;
};
 
-   audma0: dma-controller@ec70 {
-   compatible = "renesas,dmac-r8a7795",
-"renesas,rcar-dmac";
-   reg = <0 0xec70 0 0x1>;
-   interrupts = ;
-   interrupt-names = "error",
-   "ch0", "ch1", "ch2", "ch3",
-   "ch4", "ch5", "ch6", "ch7",
-   "ch8", "ch9", "ch10", "ch11",
-   "ch12", "ch13", "ch14", "ch15";
-   clocks = < CPG_MOD 502>;
-   clock-names = "fck";
-   power-domains = < R8A7795_PD_ALWAYS_ON>;
-   #dma-cells = <1>;
-   dma-channels = <16>;
-   };
-
-   audma1: dma-controller@ec72 {
-   compatible = "renesas,dmac-r8a7795",
-"renesas,rcar-dmac";
-   reg = <0 0xec72 0 0x1>;
-   interrupts = ;
-   interrupt-names = "error",
-   "ch0", "ch1", "ch2", "ch3",
-   "ch4", "ch5", "ch6", "ch7",
-   "ch8", "ch9", "ch10", "ch11",
-   "ch12", "ch13", "ch14", "ch15";
-   clocks = < CPG_MOD 501>;
-   clock-names = "fck";
-   power-domains = < R8A7795_PD_ALWAYS_ON>;
-   #dma-cells = <1>;
-   dma-channels = <16>;
-   };
-
pfc: pfc@e606 {
compatible = "renesas,pfc-r8a7795";
reg = <0 0xe606 0 0x50c>;
@@ -525,6 +459,72 @@
dma-channels = <16>;
};
 
+   audma0: dma-controller@ec70 {
+   compatible = "renesas,dmac-r8a7795",
+"renesas,rcar-dmac";
+   reg = <0 0xec70 0 0x1>;
+   interrupts = ;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7",
+   "ch8", "ch9", "ch10", "ch11",
+   "ch12", "ch13", "ch14", "ch15";
+   clocks = < CPG_MOD 502>;
+   clock-names = "fck";
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #dma-cells = <1>;
+   dma-channels = <16>;
+   };
+
+   audma1: dma-controller@ec72 {
+   compatible = "renesas,dmac-r8a7795",
+"renesas,rcar-dmac";
+   reg = <0 0xec72 0 0x1>;
+   interrupts = ;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7",
+   "ch8", "ch9", "ch10", "ch11",
+   "ch12", "ch13", "ch14", "ch15";
+   clocks = < CPG_MOD 501>;
+   clock-names = "fck";
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #dma-cells = <1>;
+   dma-channels = <16>;
+   };
+
avb: ethernet@e680 {
compatible = "renesas,etheravb-r8a7795",
 "renesas,etheravb-rcar-gen3";
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH v2 4/7] serial: sh-sci: increase RX FIFO trigger defaults for (H)SCIF

[Greg KH]

On Mon, Jan 23, 2017 at 05:04:15PM +0100, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/tty/serial/sh-sci.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)

I will not take a patch without any changelog text, sorry...

Re: [PATCH/RFC 1/2] arm64: mm: Silently allow devices lacking IOMMU group

[Magnus Damm]

Hi Robin,

On Mon, Jan 23, 2017 at 9:34 PM, Robin Murphy  wrote:
> Hi Magnus,
>
> On 23/01/17 12:12, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Consider failure of iommu_get_domain_for_dev() as non-critical and
>> get rid of the warning printout. This allows IOMMU properties to be
>> included in the DTB even though the kernel is configured with
>> CONFIG_IOMMU_API=n or in case a particular IOMMU driver refuses to
>> enable IOMMU support for a certain slave device and returns error
>> from the ->add_device() callback.
>>
>> This is only a cosmetic change that removes console warning printouts.
>
> The warning is there for a reason - at this point, we *expected* the
> device to be using an IOMMU for DMA, so a failure is significant. Rather
> than masking genuine failures in other cases because your case
> deliberately breaks that expectation, simply change the expectation -
> i.e. rather than letting of_xlate() succeed then failing add_device()
> later, reject the of_xlate() call up-front such that the DMA layer never
> gets told about the IOMMU in the first place.

Thanks for pointing me in the right direction! I will try to handle
this in xlate() instead.

Cheers,

/ magnus

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

[Daniel Lezcano]

On Tue, Jan 24, 2017 at 08:19:50PM +, Chris Brandt wrote:
> Hi Daniel,
> 
> On Tuesday, January 24, 2017, Daniel Lezcano wrote:
> > > > > +early_platform_init("earlytimer", _timer);
> > > > > +subsys_initcall(ostm_init); module_exit(ostm_exit);
> > > > > +
> > > > > +MODULE_AUTHOR("Chris Brandt");
> > > > > +MODULE_DESCRIPTION("Renesas OSTM Timer Driver");
> > > > > +MODULE_LICENSE("GPL v2");
> > > >
> > > > Maybe you can try with builtin_platform ?
> > >
> > > Good idea. But, now I get a "Section mismatch" during link time so
> > > I'll have to figure out why that is.
> > 
> > Mmh, I think it would be more consistent to convert this to:
> > 
> > CLOCKSOURCE_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
> > 
> > The only problem is to get the struct device associated to the of_node
> > passed as parameter to ostm_init in order to use the devm_* API.
> > 
> > I think of_find_device_by_node should return the platform_device, then
> > pdev->dev. If that works the other drivers will benefit from that to
> > pdev->remove all
> > the rollback code everywhere.
> 
> 
> It was a good ideabut it will not work.
> 
> While CLOCKSOURCE_OF_DECLARE is good at putting the driver at the
> front of the line for loading, it's too early in boot to detect
> a platform_device.
> 
> of_find_device_by_node calls bus_find_device. But the first thing that
> bus_find_device does is:
> 
>   if (!bus || !bus->p)
>   return NULL;
> 
> But bus->p=0 so it returns immediately.
> 
> 
> Of course changing the code over to:
> devm_kzalloc -> devm_kzalloc
> devm_ioremap_nocache -> of_io_request_and_map
> platform_get_irq -> irq_of_parse_and_map
>  dev_err -> pr_err
> 
> 
> Then things work, but I'm back to managing the rollback code manually.
> 
> 
> Any other ideas on how to get the corresponding platform_device for
> a DT node?

No :/

So up to you.
- CLOCKSOURCE_OF_DECLARE consistent but need rollback
or
- platform_device but with another timer available at early time

-- 

  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 2/2] net: phy: leds: Fix truncated LED trigger names

[Geert Uytterhoeven]

Hi Andrew,

On Tue, Jan 24, 2017 at 9:03 PM, Andrew Lunn  wrote:
>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index 5c9d2529685fe215..f6ab919528ab3627 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -25,7 +25,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>
>>  #include 
>>
>> @@ -339,6 +338,8 @@ struct phy_c45_device_ids {
>>   u32 device_ids[8];
>>  };
>>
>> +#include 
>> +
>>  /* phy_device: An instance of a PHY
>>   *
>>   * drv: Pointer to the driver for this PHY instance
>> diff --git a/include/linux/phy_led_triggers.h 
>> b/include/linux/phy_led_triggers.h
>> index a2daea0a37d2ae14..69dffb4fc5a294e9 100644
>> --- a/include/linux/phy_led_triggers.h
>> +++ b/include/linux/phy_led_triggers.h
>> @@ -20,9 +20,8 @@
>>  #include 
>>
>>  #define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE10
>> -#define PHY_MII_BUS_ID_SIZE  (20 - 3)
>>
>> -#define PHY_LINK_LED_TRIGGER_NAME_SIZE (PHY_MII_BUS_ID_SIZE + \
>> +#define PHY_LINK_LED_TRIGGER_NAME_SIZE (MII_BUS_ID_SIZE + \
>>  FIELD_SIZEOF(struct mdio_device, addr)+\
>>  PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE)
>
> Hi Geert
>
> Using the macro is great, but it does seem a bit ugly having the
> include in the middle of the file.
>
> As far as i can see, phy.h only uses a pointer to a struct
> phy_led_trigger, not struct phy_led_trigger itself. Could you try
> removing the header file all together and just have a forward
> declaration of phy_led_trigger?

Thanks for the suggestion!
Yes, the include can be removed. A forward declaration isn't even needed.

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 7/7] arm64: dts: r8a7796: salvator-x: add SCIF1 (DEBUG1)

[Ulrich Hecht]

On Tue, Jan 24, 2017 at 9:08 AM, Geert Uytterhoeven
 wrote:
> While the patch is acceptable as-is, my question is still valid:
> Is there any specific reason you chose scif1 over hscif1?

Conservatism. :)

CU
Uli

[PATCH v2 4/4] clk: renesas: cpg-mssr: Add support for reset control

[Geert Uytterhoeven]

Add optional support for the Reset Control feature of the Renesas Clock
Pulse Generator / Module Standby and Software Reset module on R-Car
Gen2, R-Car Gen3, and RZ/G1 SoCs.

This allows to reset SoC devices using the Reset Controller API.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Philipp Zabel 
Acked-by: Stephen Boyd 
Reviewed-by: Niklas Söderlund 
---
v2:
  - Add Acked-by, Reviewed-by,
  - Use variable bitmask in all reset operations, to make them more
similar.
---
 drivers/clk/renesas/renesas-cpg-mssr.c | 126 +
 1 file changed, 126 insertions(+)

diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c 
b/drivers/clk/renesas/renesas-cpg-mssr.c
index f1161a585c57e433..eadcbd43ff88319b 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -96,6 +98,7 @@
 /**
  * Clock Pulse Generator / Module Standby and Software Reset Private Data
  *
+ * @rcdev: Optional reset controller entity
  * @dev: CPG/MSSR device
  * @base: CPG/MSSR register block base address
  * @rmw_lock: protects RMW register accesses
@@ -105,6 +108,9 @@
  * @last_dt_core_clk: ID of the last Core Clock exported to DT
  */
 struct cpg_mssr_priv {
+#ifdef CONFIG_RESET_CONTROLLER
+   struct reset_controller_dev rcdev;
+#endif
struct device *dev;
void __iomem *base;
spinlock_t rmw_lock;
@@ -494,6 +500,122 @@ static int __init cpg_mssr_add_clk_domain(struct device 
*dev,
return 0;
 }
 
+#ifdef CONFIG_RESET_CONTROLLER
+
+#define rcdev_to_priv(x)   container_of(x, struct cpg_mssr_priv, rcdev)
+
+static int cpg_mssr_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+   struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
+   unsigned int reg = id / 32;
+   unsigned int bit = id % 32;
+   u32 bitmask = BIT(bit);
+   unsigned long flags;
+   u32 value;
+
+   dev_dbg(priv->dev, "reset %u%02u\n", reg, bit);
+
+   /* Reset module */
+   spin_lock_irqsave(>rmw_lock, flags);
+   value = readl(priv->base + SRCR(reg));
+   value |= bitmask;
+   writel(value, priv->base + SRCR(reg));
+   spin_unlock_irqrestore(>rmw_lock, flags);
+
+   /* Wait for at least one cycle of the RCLK clock (@ ca. 32 kHz) */
+   udelay(35);
+
+   /* Release module from reset state */
+   writel(bitmask, priv->base + SRSTCLR(reg));
+
+   return 0;
+}
+
+static int cpg_mssr_assert(struct reset_controller_dev *rcdev, unsigned long 
id)
+{
+   struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
+   unsigned int reg = id / 32;
+   unsigned int bit = id % 32;
+   u32 bitmask = BIT(bit);
+   unsigned long flags;
+   u32 value;
+
+   dev_dbg(priv->dev, "assert %u%02u\n", reg, bit);
+
+   spin_lock_irqsave(>rmw_lock, flags);
+   value = readl(priv->base + SRCR(reg));
+   value |= bitmask;
+   writel(value, priv->base + SRCR(reg));
+   spin_unlock_irqrestore(>rmw_lock, flags);
+   return 0;
+}
+
+static int cpg_mssr_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
+   unsigned int reg = id / 32;
+   unsigned int bit = id % 32;
+   u32 bitmask = BIT(bit);
+
+   dev_dbg(priv->dev, "deassert %u%02u\n", reg, bit);
+
+   writel(bitmask, priv->base + SRSTCLR(reg));
+   return 0;
+}
+
+static int cpg_mssr_status(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
+   unsigned int reg = id / 32;
+   unsigned int bit = id % 32;
+   u32 bitmask = BIT(bit);
+
+   return !!(readl(priv->base + SRCR(reg)) & bitmask);
+}
+
+static const struct reset_control_ops cpg_mssr_reset_ops = {
+   .reset = cpg_mssr_reset,
+   .assert = cpg_mssr_assert,
+   .deassert = cpg_mssr_deassert,
+   .status = cpg_mssr_status,
+};
+
+static int cpg_mssr_reset_xlate(struct reset_controller_dev *rcdev,
+   const struct of_phandle_args *reset_spec)
+{
+   struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
+   unsigned int unpacked = reset_spec->args[0];
+   unsigned int idx = MOD_CLK_PACK(unpacked);
+
+   if (unpacked % 100 > 31 || idx >= rcdev->nr_resets) {
+   dev_err(priv->dev, "Invalid reset index %u\n", unpacked);
+   return -EINVAL;
+   }
+
+   return idx;
+}
+
+static int cpg_mssr_reset_controller_register(struct cpg_mssr_priv *priv)
+{
+   priv->rcdev.ops = _mssr_reset_ops;
+   priv->rcdev.of_node = priv->dev->of_node;
+   

[PATCH v2 1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset control support

[Geert Uytterhoeven]

Document properties needed to use the Reset Control feature of the
Renesas Clock Pulse Generator / Module Standby and Software Reset
module.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Change oneline summary to refer to dt-bindings.
---
 Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt 
b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
index c469194129536332..f4f944d813081857 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -42,6 +42,10 @@ Required Properties:
Domain bindings in
Documentation/devicetree/bindings/power/power_domain.txt.
 
+  - #reset-cells: Must be 1
+  - The single reset specifier cell must be the module number, as defined
+   in the datasheet.
+
 
 Examples
 
@@ -55,6 +59,7 @@ Examples
clock-names = "extal", "extalr";
#clock-cells = <2>;
#power-domain-cells = <0>;
+   #reset-cells = <1>;
};
 
 
@@ -69,5 +74,6 @@ Examples
dmas = < 0x13>, < 0x12>;
dma-names = "tx", "rx";
power-domains = <>;
+   resets = < 310>;
status = "disabled";
};
-- 
1.9.1

[PATCH v2 0/4] Renesas CPG/MSSR Reset Control Support

[Geert Uytterhoeven]

Hi all,

This patch series adds reset control support to the Renesas Clock Pulse
Generator / Module Standby and Software Reset module, on the R-Car H3
and M3-W, RZ/G1M, and RZ/G1E SoCs.

  - Patch 1 amends the Renesas CPG/MSSR DT bindings for reset control,
  - Patches 2-4 add reset control to the Renesas CPG/MSSR driver.

Note that this patch series implements reset functionality only.
Actual reset policy is to be defined and implemented separately.

This is an optional feature, to be enabled explicitly using
CONFIG_RESET_CONTROLLER=y.  When enabled, an on-SoC device can be reset
easily using device_reset(), or by using the reset_control_*() API when
more fine-grained control is desired.

Possible use cases are (not exhaustive):
  - Reset a device before use, to make sure it's in a predefined state, and
doesn't depend on earlier configuration by e.g. the boot loader,
  - Reset a device after detecting an anomaly,
  - Reset a device to verify suspend/resume is handled correctly by the
driver in case the device would be part of a power domain on a
different/future SoC.

Changes compared to v1:
  - Change oneline summary for binding update to refer to dt-bindings.
  - Add Acked-by, Reviewed-by,
  - Use variable bitmask in all reset operations, to make them more
similar,
  - Dropped the DTS changes:
  - If CONFIG_RESET_CONTROLLER=y, they have a hard dependency on the
driver patches (at least for USB on R-Car Gen3), so they can
only go upstream in a later cycle,
  - The DTS changes will have to be respun anyway, to accommodate
for changes in the DTS files between now and final upstreaming.

For your convenience, the driver and DTS changes (incl. dependencies)
are available in the topic/renesas-cpg-mssr-reset-driver-v2 resp.
topic/renesas-cpg-mssr-reset-dts-v1 branches of my topic/rcar-rst-v4
branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git

This has been tested on the R-Car Gen3 Salvator-X (H3 and M3-W) and the
R-Car M2-W (using out-of-tree driver modifications) Koelsch development
boards, by inspecting device register contents before and after reset,
and by comparing them with their documented reset values.

As this modifies a Renesas clock driver, I'll queue this up in my
clk-renesas-for-v4.11 branch, and will send a pull request later this
week.  

Thanks!

Geert Uytterhoeven (4):
  dt-bindings: clock: renesas: cpg-mssr: Document reset control support
  clk: renesas: cpg-mssr: Document suitability for RZ/G1
  clk: renesas: cpg-mssr: Rename cpg_mssr_priv.mstp_lock
  clk: renesas: cpg-mssr: Add support for reset control

 .../devicetree/bindings/clock/renesas,cpg-mssr.txt |   6 +
 drivers/clk/renesas/renesas-cpg-mssr.c | 138 -
 2 files changed, 138 insertions(+), 6 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

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

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

[PATCH v2 3/4] clk: renesas: cpg-mssr: Rename cpg_mssr_priv.mstp_lock

[Geert Uytterhoeven]

The spinlock is used to protect Read-Modify-Write register accesses,
which won't be limited to SMSTPCR register accesses.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Stephen Boyd 
---
v2:
  - Add Acked-by.
---
 drivers/clk/renesas/renesas-cpg-mssr.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c 
b/drivers/clk/renesas/renesas-cpg-mssr.c
index eb8534e5ebf3007d..f1161a585c57e433 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -98,7 +98,7 @@
  *
  * @dev: CPG/MSSR device
  * @base: CPG/MSSR register block base address
- * @mstp_lock: protects writes to SMSTPCR
+ * @rmw_lock: protects RMW register accesses
  * @clks: Array containing all Core and Module Clocks
  * @num_core_clks: Number of Core Clocks in clks[]
  * @num_mod_clks: Number of Module Clocks in clks[]
@@ -107,7 +107,7 @@
 struct cpg_mssr_priv {
struct device *dev;
void __iomem *base;
-   spinlock_t mstp_lock;
+   spinlock_t rmw_lock;
 
struct clk **clks;
unsigned int num_core_clks;
@@ -144,7 +144,7 @@ static int cpg_mstp_clock_endisable(struct clk_hw *hw, bool 
enable)
 
dev_dbg(dev, "MSTP %u%02u/%pC %s\n", reg, bit, hw->clk,
enable ? "ON" : "OFF");
-   spin_lock_irqsave(>mstp_lock, flags);
+   spin_lock_irqsave(>rmw_lock, flags);
 
value = readl(priv->base + SMSTPCR(reg));
if (enable)
@@ -153,7 +153,7 @@ static int cpg_mstp_clock_endisable(struct clk_hw *hw, bool 
enable)
value |= bitmask;
writel(value, priv->base + SMSTPCR(reg));
 
-   spin_unlock_irqrestore(>mstp_lock, flags);
+   spin_unlock_irqrestore(>rmw_lock, flags);
 
if (!enable)
return 0;
@@ -550,7 +550,7 @@ static int __init cpg_mssr_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
priv->dev = dev;
-   spin_lock_init(>mstp_lock);
+   spin_lock_init(>rmw_lock);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(dev, res);
-- 
1.9.1

[PATCH v2 2/4] clk: renesas: cpg-mssr: Document suitability for RZ/G1

[Geert Uytterhoeven]

The Renesas CPG/MSSR driver is already in active use for RZ/G1 since
commits c0b2d75d2a4bf6a3 ("clk: renesas: cpg-mssr: Add R8A7743 support")
and 9127d54bb8947159 ("clk: renesas: cpg-mssr: Add R8A7745 support").

Signed-off-by: Geert Uytterhoeven 
Acked-by: Stephen Boyd 
---
v2:
  - Add Acked-by.
---
 drivers/clk/renesas/renesas-cpg-mssr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c 
b/drivers/clk/renesas/renesas-cpg-mssr.c
index 6947482d48a55094..eb8534e5ebf3007d 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -43,7 +43,7 @@
  * Module Standby and Software Reset register offets.
  *
  * If the registers exist, these are valid for SH-Mobile, R-Mobile,
- * R-Car Gen 2, and R-Car Gen 3.
+ * R-Car Gen2, R-Car Gen3, and RZ/G1.
  * These are NOT valid for R-Car Gen1 and RZ/A1!
  */
 
-- 
1.9.1

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

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Remove unneeded parentheses in phys_to_sbar().
---
 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 dd9ac366868f4336..0178da7ace82dcbd 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);
 
-- 
1.9.1

Re: [PATCH] arm64: Use __pa_symbol for empty_zero_page

[Laura Abbott]

On 01/24/2017 12:43 PM, Geert Uytterhoeven wrote:

If CONFIG_DEBUG_VIRTUAL=y and CONFIG_ARM64_SW_TTBR0_PAN=y:

virt_to_phys used for non-linear address: ff8008cc 
(empty_zero_page+0x0/0x1000)
WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:14 
__virt_to_phys+0x28/0x60
...
[] __virt_to_phys+0x28/0x60
[] setup_arch+0x46c/0x4d4

Fixes: 2077be6783b5936c ("arm64: Use __pa_symbol for kernel symbols")
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 669fc9ff728b227f..b5222094ab52db6f 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -298,7 +298,7 @@ void __init setup_arch(char **cmdline_p)
 * faults in case uaccess_enable() is inadvertently called by the init
 * thread.
 */
-   init_task.thread_info.ttbr0 = virt_to_phys(empty_zero_page);
+   init_task.thread_info.ttbr0 = __pa_symbol(empty_zero_page);
 #endif

 #ifdef CONFIG_VT



(thought I sent this yesterday but SMTP was not set correctly)

Acked-by: Laura Abbott 

Re: [PATCH] drivers: firmware: psci: Use __pa_symbol for cpu_resume

[Laura Abbott]

On 01/24/2017 04:30 PM, Geert Uytterhoeven wrote:

If CONFIG_DEBUG_VIRTUAL=y, during s2ram:

virt_to_phys used for non-linear address: ff80085db280 
(cpu_resume+0x0/0x20)
[ cut here ]
WARNING: CPU: 0 PID: 1628 at arch/arm64/mm/physaddr.c:14 
__virt_to_phys+0x28/0x60
...
[] __virt_to_phys+0x28/0x60
[] psci_system_suspend+0x20/0x44
[] cpu_suspend+0x3c/0x68
[] psci_system_suspend_enter+0x18/0x20
[] suspend_devices_and_enter+0x3f8/0x7e8
[] pm_suspend+0x544/0x5f4

Fixes: 1a08e3d9e0ac4577 ("drivers: firmware: psci: Use __pa_symbol for kernel 
symbol")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/firmware/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 66a8793f3b3793ff..493a56a4cfc4a836 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -419,7 +419,7 @@ int psci_cpu_suspend_enter(unsigned long index)
 static int psci_system_suspend(unsigned long unused)
 {
return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
- virt_to_phys(cpu_resume), 0, 0);
+ __pa_symbol(cpu_resume), 0, 0);
 }

 static int psci_system_suspend_enter(suspend_state_t state)



(thought I sent this yesterday but SMTP was not set correctly)

Acked-by: Laura Abbott 

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

[Geert Uytterhoeven]

Hi Chris,

On Tue, Jan 24, 2017 at 5:22 PM, Chris Brandt  wrote:
> On Tuesday, January 24, 2017, Geert Uytterhoeven wrote:
>> > From what I can tell, that makes the register space readable...but the
>> > IP block is not fully functional unless you delay a little.
>>
>> If you know the minimum delay needed, and it's not too long, it can be
>> added to the enable path.
>
> I can play around and see. I know udealy(100) works OK, but then I have
> to have a delay that's as long as the slowest peripheral.
> If it was just to turn a clock on once, or once in a while, that's OK. But
> it seems like runtime pm wants to turn the clocks on/off as much as
> possible.

That's not really true: depending on tuning and/or QoS parameters,
pm_runtime_put() may anticipate future use, and may decide not turn off the
clock immediately.
It may be worth looking into that, and to see how to relax that behavior
on RZ/A1.

>> > But, I think I'd like to disable runtime pm for RZ/A1 in the drivers
>> > for now Because 'functional' is better than 'lower-power-but-broken'
>>
>> I prefer not doing that in the individual drivers, as they're shared with
>> other SoCs.
>
> What I meant was looking at the compatible string and only doing
> it for RZ/A1.
>
> For example, in rspi_probe():
>
> if (of_device_is_compatible(np, " renesas,rspi-r7s72100"))
> master->auto_runtime_pm = false;
> else
> master->auto_runtime_pm = true;
>
>
> I would do the same kind of thing for riic.

That needs to be done in individual drivers, ugh...

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

> But won't the individual drivers still want to keep turning clocks on and off 
> manually?
> (unless I'm not understanding that the underlying clock routines will 
> basically just
> ignore everything). But even if that' the case...that just wasted CPU cycles 
> (remember,
> I'm only working with a 400MHz single core here running XIP_KERNEL)

If a clock is already enabled, preparing and/or enabling it again will just
increase the prepare resp. enable counters. Disabling/unpreparing afterwards
will also just decrease the counters. Should be quite cheap.

> I think I should at least put the dummy read in cpg_mstp_clock_endisable() 
> first,
> then maybe I can see what drivers work. Something like this:
>
>
> spin_lock_irqsave(>lock, flags);
>
> value = cpg_mstp_read(group, group->smstpcr);
> if (enable)
> value &= ~bitmask;
> else
> value |= bitmask;
> cpg_mstp_write(group, value, group->smstpcr);
>
> +   if (!group->mstpsr) {
> +   /* dummy read to ensure write has completed */
> +   clk_readl(group->smstpcr);
> +   barrier_data(group->smstpcr);
> +   }
>
> spin_unlock_irqrestore(>lock, flags);

Yes, that's a good first step.

The only other supported SoCs without[*] status registers are R-Car M1A
and H1. I believe they should handle the additional reads fine.

[*] On R-Car Gen1, some MSTP blocks have status registers, some don't.

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

[Geert Uytterhoeven]

Hi Chris,

On Tue, Jan 24, 2017 at 3:43 PM, Chris Brandt  wrote:
> On Tuesday, January 24, 2017, Daniel Lezcano wrote:
>> > > > +early_platform_init("earlytimer", _timer);
>> > > > +subsys_initcall(ostm_init); module_exit(ostm_exit);
>> > > > +
>> > > > +MODULE_AUTHOR("Chris Brandt");
>> > > > +MODULE_DESCRIPTION("Renesas OSTM Timer Driver");
>> > > > +MODULE_LICENSE("GPL v2");
>> > >
>> > > Maybe you can try with builtin_platform ?
>> >
>> > Good idea. But, now I get a "Section mismatch" during link time so
>> > I'll have to figure out why that is.
>>
>> Mmh, I think it would be more consistent to convert this to:
>>
>> CLOCKSOURCE_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
>>
>> The only problem is to get the struct device associated to the of_node
>> passed as parameter to ostm_init in order to use the devm_* API.
>>
>> I think of_find_device_by_node should return the platform_device, then
>> pdev->dev. If that works the other drivers will benefit from that to
>> pdev->remove all
>> the rollback code everywhere.
>
> So I realized that in order to use builtin_platform, I can't have any of the
> functions in __init because the build system has no idea that I never plan
> on removing or probing again after boot. But, even if I take out all the
> __init from my code, I'm still calling clocksource_mmio_init which is __init
> so I can never escape the "Section mismatch".

For single-probe drivers, you can use builtin_platform_driver_probe().

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

[Geert Uytterhoeven]

On Tue, Jan 24, 2017 at 9:19 PM, Chris Brandt  wrote:
> On Tuesday, January 24, 2017, Daniel Lezcano wrote:
>> > > > +early_platform_init("earlytimer", _timer);
>> > > > +subsys_initcall(ostm_init); module_exit(ostm_exit);
>> > > > +
>> > > > +MODULE_AUTHOR("Chris Brandt");
>> > > > +MODULE_DESCRIPTION("Renesas OSTM Timer Driver");
>> > > > +MODULE_LICENSE("GPL v2");
>> > >
>> > > Maybe you can try with builtin_platform ?
>> >
>> > Good idea. But, now I get a "Section mismatch" during link time so
>> > I'll have to figure out why that is.
>>
>> Mmh, I think it would be more consistent to convert this to:
>>
>> CLOCKSOURCE_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
>>
>> The only problem is to get the struct device associated to the of_node
>> passed as parameter to ostm_init in order to use the devm_* API.
>>
>> I think of_find_device_by_node should return the platform_device, then
>> pdev->dev. If that works the other drivers will benefit from that to
>> pdev->remove all
>> the rollback code everywhere.
>
> It was a good ideabut it will not work.
>
> While CLOCKSOURCE_OF_DECLARE is good at putting the driver at the
> front of the line for loading, it's too early in boot to detect
> a platform_device.

That's correct. All those *_OF_DECLARE() style initializations start
to break as soon as power and/or clock domains are involved.
That's one reason why some subsystems (e.g. clock) are moving away from it.

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