Re: [PATCH 0/2] clk: renesas: cpg-mssr: Always use readl()/writel()

2016-09-23 Thread Stephen Boyd 
On 09/23, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The Renesas CPG/MSSR clock drivers use a mix of clk_readl()/clk_writel()
> and readl()/writel() to access the clock registers. Settle on the
> generic readl()/writel().
> 
> I plan to queue this up in clk-renesas-for-v4.10.
> 
> Geert Uytterhoeven (2):
>   clk: renesas: cpg-mssr: Always use readl()/writel()
>   clk: renesas: rcar-gen3-cpg: Always use readl()/writel()
> 
>  drivers/clk/renesas/rcar-gen3-cpg.c| 14 +++---
>  drivers/clk/renesas/renesas-cpg-mssr.c |  9 -
>  2 files changed, 11 insertions(+), 12 deletions(-)
> 

Acked-by: Stephen Boyd 

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

Re: [PATCH v2 1/2] media: adv7604: fix bindings inconsistency for default-input

2016-09-23 Thread Rob Herring 
On Thu, Sep 22, 2016 at 03:18:59PM +0200, Ulrich Hecht wrote:
> The text states that default-input is an endpoint property, but in the
> example it is a device property.
> 
> The default input is a property of the chip, not of a particular port, so
> the example makes more sense.
> 
> Signed-off-by: Ulrich Hecht 
> Reviewed-by: Laurent Pinchart 
> ---
>  Documentation/devicetree/bindings/media/i2c/adv7604.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Acked-by: Rob Herring

Re: [PATCH v2 2/3] mmc: sh_mmcif: Document r7s72100 DT bindings

2016-09-23 Thread Rob Herring 
On Tue, Sep 20, 2016 at 11:46:19AM -0400, Chris Brandt wrote:
> Signed-off-by: Chris Brandt 
> ---
> v2:
> * added interrupt description
> ---
>  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt 
> b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> index ff611fa..1443edb 100644
> --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> @@ -8,12 +8,16 @@ Required properties:
>  
>  - compatible: should be "renesas,mmcif-", "renesas,sh-mmcif" as a
>fallback. Examples with  are:
> + - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs
>   - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
>   - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
>   - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
>   - "renesas,mmcif-r8a7793" for the MMCIF found in r8a7793 SoCs
>   - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs
>  
> +- interrupts: either 1 shared interrupt, 2 separate interrupts (error and 
> int),
> +  or 3 separate interrupts (error, int, card detect)

This should be based on the compatible strings. Surely, 1, 2, or 3 is 
not valid for all compatibles.

Rob

RE: [PATCH 3/3] ARM: dts: rskrza1: add sdhi1 DT support

2016-09-23 Thread Chris Brandt 
> > On Thu, Sep 22, 2016 at 11:32 PM, Chris Brandt
>  wrote:
> > > Signed-off-by: Chris Brandt 
> > > ---
> > >  arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts
> > > b/arch/arm/boot/dts/r7s72100-rskrza1.dts
> > > index e5dea5b..548b51f 100644
> > > --- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
> > > +++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
> > > @@ -56,6 +56,10 @@
> > > };
> > >  };
> > >
> > > + {
> > > +   status = "okay";
> >
> > On all other boards, we have the bus-width property in the
> > board-specific .dts instead of in the SoC-specific .dtsi.

I did see that.
But, in my opinion, using 4-bit SDHI is way more common that 1-bit SDHI.
So I figured I'd make 4-bit the 'default' by putting it in the dtsi, and if for 
some reason someone needed 1-bit, they could override it in the board .dts.


> I'd like us to be consistent as much as possible.
> But I do wonder why it has been added as a board property.

It doesn't really matter to me. If you want me to move it to the board dts it 
to keep it consistent, just let me know and I'll change it.

Chris

Re: [PATCH 2/3] ARM: dts: r7s72100: add sdhi to device tree

2016-09-23 Thread Geert Uytterhoeven 
Hi Chris,

On Fri, Sep 23, 2016 at 4:20 PM, Chris Brandt  wrote:
>> (due to lack of documentation about SDHI, for the interrupt numbers only)
>>
>> > --- a/arch/arm/boot/dts/r7s72100.dtsi
>> > +++ b/arch/arm/boot/dts/r7s72100.dtsi
>> > @@ -458,4 +458,32 @@
>> > #size-cells = <0>;
>> > status = "disabled";
>> > };
>> > +
>> > +   sdhi0: sd@e804e000 {
>> > +   compatible = "renesas,sdhi-r7s72100";
>> > +   reg = <0xe804e000 0x100>;
>> > +   interrupts = > > + GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH
>> > + GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>> > +
>>
>> Cannot chcck the required order, but the interrupts are called SDHI0_3,
>> SDHI0_0, and SDHI0_1 in the datasheet.
>
> From the hardware manual, "Table 7.3 List of Interrupt IDs":
>
> SD host Interface, Channel 0:
> -
>   SDHI0_3 = ID 302   (302 - 32 = 270)
>   SDHI0_0 = ID 303   (303 - 32 = 271)
>   SDHI0_1 = ID 304   (304 - 32 = 272)
>
>
> #NOTE: The new 3.0 version of the hardware manual that will be coming out 
> will now have the SDHI chapter included.
>
> So, in reference to that 3.0 manual:
>
>  "50.3.3 Interrupt Request and DMA Transfer Request"
>  "Table 50.4 Interrupt Request"
>  -
>   Card detect interrupt = SDHI3
>   Card access interrupt = SDHI0
>   SDIO access interrupt = SDHI1

Thanks for checking!

However, this is another driver that doesn't document anything about the
interrupts in the DT bindings :-(

> Regardless, in sh_mobile_sdhi.c, they all get mapped to the same ISR function 
> anyway:
>
> i = 0;
> while (1) {
> irq = platform_get_irq(pdev, i);
> if (irq < 0)
> break;
> i++;
> ret = devm_request_irq(>dev, irq, tmio_mmc_irq, 0,
>   dev_name(>dev), host);
> if (ret)
> goto eirq;
> }

Uuh, then it doesn't matter much ;-)

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 PATCH 2/3] PM / Domains: Add support for devices with multiple domains

2016-09-23 Thread Geert Uytterhoeven 
Hi Jon,

On Fri, Sep 23, 2016 at 2:57 PM, Jon Hunter  wrote:
> On 21/09/16 15:57, Geert Uytterhoeven wrote:
>> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter  wrote:
>>> On 21/09/16 09:53, Geert Uytterhoeven wrote:
 On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter  wrote:
> Some devices may require more than one PM domain to operate and this is
> not currently by the PM domain framework. Furthermore, the current Linux
> 'device' structure only allows devices to be associated with a single PM
> domain and so cannot easily be associated with more than one. To allow
> devices to be associated with more than one PM domain, if multiple
> domains are defined for a given device (eg. via device-tree), then:
> 1. Create a new PM domain for this device. The name of the new PM domain
>created matches the device name for which it was created for.
> 2. Register the new PM domain as a sub-domain for all PM domains
>required by the device.
> 3. Attach the device to the new PM domain.

 This looks a suboptimal to me: if you have n devices sharing the same PM
 domains, you would add n new subdomains?
>>>
>>> BTW, would this be the case today for some renesas devices or are you
>>> just pointing this out as something that could be optimised/improved?
>>
>> This is the case for all Renesas SoCs that have power areas: devices belong
>> to both the PM domain for the power area, and to the PM domain for the clock
>> domain.
>
> To quantify this a bit, for the Renesas case, how many of these
> duplicated domains would there be if you were to use this approach as-is?

for i in $(git grep -l renesas, -- "*dts*") ; do echo --- $i ---; git
grep -w power-domains $i | sort | uniq -c | sort -n;done

tells you how many (supported) devices are (currently) present in each
PM domain.
Most of these (all but devices in CPU/SCU power areas) are also part of a
clock domain.
The synthetic R8A779*_PD_ALWAYS_ON domains could be dropped again,
as we could just refer to the CPG/MSSR node for the clock domain instead.

For older SH/R-Mobile SoCs with lots of hierarchical domains, that gives us,
after removing the above:

  1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a4mp>;
  1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_d4>;
  2 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_c5>;
  3 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a4r>;
  6 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a4s>;
 15 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a3sp>;

R-Car Gen1/Gen2 have all devices in the "always on" PM domain, so they're
not affected.

R-Car Gen3 again has devices in power areas, mostly for graphics related
purposes:

 16 arch/arm64/boot/dts/renesas/r8a7795.dtsi:
 power-domains = < R8A7795_PD_A3VP>;

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 2/3] ARM: dts: r7s72100: add sdhi to device tree

2016-09-23 Thread Chris Brandt 
Hi Geert,

> (due to lack of documentation about SDHI, for the interrupt numbers only)
> 
> > --- a/arch/arm/boot/dts/r7s72100.dtsi
> > +++ b/arch/arm/boot/dts/r7s72100.dtsi
> > @@ -458,4 +458,32 @@
> > #size-cells = <0>;
> > status = "disabled";
> > };
> > +
> > +   sdhi0: sd@e804e000 {
> > +   compatible = "renesas,sdhi-r7s72100";
> > +   reg = <0xe804e000 0x100>;
> > +   interrupts =  > + GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH
> > + GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
> > +
> 
> Cannot chcck the required order, but the interrupts are called SDHI0_3,
> SDHI0_0, and SDHI0_1 in the datasheet.


From the hardware manual, "Table 7.3 List of Interrupt IDs":

SD host Interface, Channel 0:
-
  SDHI0_3 = ID 302   (302 - 32 = 270)
  SDHI0_0 = ID 303   (303 - 32 = 271)
  SDHI0_1 = ID 304   (304 - 32 = 272)


#NOTE: The new 3.0 version of the hardware manual that will be coming out will 
now have the SDHI chapter included.

So, in reference to that 3.0 manual:

 "50.3.3 Interrupt Request and DMA Transfer Request"
 "Table 50.4 Interrupt Request"
 -
  Card detect interrupt = SDHI3
  Card access interrupt = SDHI0
  SDIO access interrupt = SDHI1


Regardless, in sh_mobile_sdhi.c, they all get mapped to the same ISR function 
anyway:

i = 0;
while (1) {
irq = platform_get_irq(pdev, i);
if (irq < 0)
break;
i++;
ret = devm_request_irq(>dev, irq, tmio_mmc_irq, 0,
  dev_name(>dev), host);
if (ret)
goto eirq;
}


Chris

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

2016-09-23 Thread Jon Hunter 
Hi Geert,

On 21/09/16 15:57, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter  wrote:
>> On 21/09/16 09:53, Geert Uytterhoeven wrote:
>>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter  wrote:
 Some devices may require more than one PM domain to operate and this is
 not currently by the PM domain framework. Furthermore, the current Linux
 'device' structure only allows devices to be associated with a single PM
 domain and so cannot easily be associated with more than one. To allow
 devices to be associated with more than one PM domain, if multiple
 domains are defined for a given device (eg. via device-tree), then:
 1. Create a new PM domain for this device. The name of the new PM domain
created matches the device name for which it was created for.
 2. Register the new PM domain as a sub-domain for all PM domains
required by the device.
 3. Attach the device to the new PM domain.
>>>
>>> This looks a suboptimal to me: if you have n devices sharing the same PM
>>> domains, you would add n new subdomains?
>>
>> BTW, would this be the case today for some renesas devices or are you
>> just pointing this out as something that could be optimised/improved?
> 
> This is the case for all Renesas SoCs that have power areas: devices belong
> to both the PM domain for the power area, and to the PM domain for the clock
> domain.

To quantify this a bit, for the Renesas case, how many of these
duplicated domains would there be if you were to use this approach as-is?

I would like to see some agreement about whether we would allow the
'power-domains' property to have more than one power-domain. We could
always improve the implementation in the future. I am quite happy to
re-work this RFC to avoid duplicated domains for devices like Renesas if
people are on board with the overall proposal.

Cheers
Jon

-- 
nvpublic

Re: [PATCH] clocksource: sh_cmt: Document r8a779[34] SoC specific bindings

2016-09-23 Thread Simon Horman 
On Fri, Sep 23, 2016 at 10:35:06AM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
> 
> On Fri, Sep 23, 2016 at 10:20 AM, Simon Horman
>  wrote:
> > This documents the SoC specific binding for the r8a779[34] SoCs.
> > This is in keeping with the documentation of other R-Car Gen2 SoCs.
> >
> > Signed-off-by: Simon Horman 
> > ---
> >  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
> > b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > index 1a05c1b243c1..566fb599ea39 100644
> > --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > @@ -48,10 +48,15 @@ Required Properties:
> > (CMT[01])
> >  - "renesas,cmt-48-r8a7791" for the r8a7791 48-bit CMT
> > (CMT[01])
> > +- "renesas,cmt-48-r8a7793" for the r8a7793 48-bit CMT
> > +   (CMT[01])
> > +- "renesas,cmt-48-r8a7794" for the r8a7793 48-bit CMT
> > +   (CMT[01])
> >  - "renesas,cmt-48-gen2" for all second generation 48-bit CMT
> > -   (CMT[01] on r8a73a4, r8a7790 and r8a7791)
> > +   (CMT[01] on r8a73a4, r8a7790, r8a7791, r8a7793, r8a7794)
> > This is a fallback for the renesas,cmt-48-r8a73a4,
> > -   renesas,cmt-48-r8a7790 and renesas,cmt-48-r8a7791 entries.
> > +   renesas,cmt-48-r8a7790, renesas,cmt-48-r8a7791,
> > +   renesas,cmt-48-r8a7793 and renesas,cmt-48-r8a7794 entries.
> >
> >- reg: base address and length of the registers block for the timer 
> > module.
> >- interrupts: interrupt-specifier for the timer, one per channel.
> 
> And these are planned to be removed again with Magnus'
> "devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings"
> (https://patchwork.kernel.org/patch/8579481/)?

Sorry, that slipped my mind.

Magnus, what is the status of that work?

Re: [PATCH] clocksource: sh_cmt: Document r8a779[34] SoC specific bindings

2016-09-23 Thread Geert Uytterhoeven 
Hi Simon, Magnus,

On Fri, Sep 23, 2016 at 10:20 AM, Simon Horman
 wrote:
> This documents the SoC specific binding for the r8a779[34] SoCs.
> This is in keeping with the documentation of other R-Car Gen2 SoCs.
>
> Signed-off-by: Simon Horman 
> ---
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
> b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> index 1a05c1b243c1..566fb599ea39 100644
> --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> @@ -48,10 +48,15 @@ Required Properties:
> (CMT[01])
>  - "renesas,cmt-48-r8a7791" for the r8a7791 48-bit CMT
> (CMT[01])
> +- "renesas,cmt-48-r8a7793" for the r8a7793 48-bit CMT
> +   (CMT[01])
> +- "renesas,cmt-48-r8a7794" for the r8a7793 48-bit CMT
> +   (CMT[01])
>  - "renesas,cmt-48-gen2" for all second generation 48-bit CMT
> -   (CMT[01] on r8a73a4, r8a7790 and r8a7791)
> +   (CMT[01] on r8a73a4, r8a7790, r8a7791, r8a7793, r8a7794)
> This is a fallback for the renesas,cmt-48-r8a73a4,
> -   renesas,cmt-48-r8a7790 and renesas,cmt-48-r8a7791 entries.
> +   renesas,cmt-48-r8a7790, renesas,cmt-48-r8a7791,
> +   renesas,cmt-48-r8a7793 and renesas,cmt-48-r8a7794 entries.
>
>- reg: base address and length of the registers block for the timer module.
>- interrupts: interrupt-specifier for the timer, one per channel.

And these are planned to be removed again with Magnus'
"devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings"
(https://patchwork.kernel.org/patch/8579481/)?

Gr{oetje,eeting}s,

Geert

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

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

Re: [RFC 1/4] clk: renesas: rcar-gen3-cpg: Add Z clock

2016-09-23 Thread Geert Uytterhoeven 
Hi Khiem,

On Tue, May 10, 2016 at 6:42 AM, Khiem Nguyen
 wrote:
> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> @@ -28,6 +28,146 @@

> +   val = (clk_readl(zclk->reg) & CPG_FRQCRC_ZFC_MASK)

Please use readl()/writel() instead of clk_readl/()/clk_writel().

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 1/2] clk: renesas: cpg-mssr: Always use readl()/writel()

2016-09-23 Thread Geert Uytterhoeven 
The Renesas CPG/MSSR driver core uses a mix of clk_readl()/clk_writel()
and readl()/writel() to access the clock registers. Settle on the
generic readl()/writel().

Signed-off-by: Geert Uytterhoeven 
---
 drivers/clk/renesas/renesas-cpg-mssr.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c 
b/drivers/clk/renesas/renesas-cpg-mssr.c
index e1365e7491ae02a0..a1d5b7431ec479b5 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -146,12 +146,12 @@ static int cpg_mstp_clock_endisable(struct clk_hw *hw, 
bool enable)
enable ? "ON" : "OFF");
spin_lock_irqsave(>mstp_lock, flags);
 
-   value = clk_readl(priv->base + SMSTPCR(reg));
+   value = readl(priv->base + SMSTPCR(reg));
if (enable)
value &= ~bitmask;
else
value |= bitmask;
-   clk_writel(value, priv->base + SMSTPCR(reg));
+   writel(value, priv->base + SMSTPCR(reg));
 
spin_unlock_irqrestore(>mstp_lock, flags);
 
@@ -159,8 +159,7 @@ static int cpg_mstp_clock_endisable(struct clk_hw *hw, bool 
enable)
return 0;
 
for (i = 1000; i > 0; --i) {
-   if (!(clk_readl(priv->base + MSTPSR(reg)) &
- bitmask))
+   if (!(readl(priv->base + MSTPSR(reg)) & bitmask))
break;
cpu_relax();
}
@@ -190,7 +189,7 @@ static int cpg_mstp_clock_is_enabled(struct clk_hw *hw)
struct cpg_mssr_priv *priv = clock->priv;
u32 value;
 
-   value = clk_readl(priv->base + MSTPSR(clock->index / 32));
+   value = readl(priv->base + MSTPSR(clock->index / 32));
 
return !(value & BIT(clock->index % 32));
 }
-- 
1.9.1

[PATCH 2/2] clk: renesas: rcar-gen3-cpg: Always use readl()/writel()

2016-09-23 Thread Geert Uytterhoeven 
The R-Car Gen3 CPG/MSSR driver uses a mix of clk_readl()/clk_writel()
and readl()/writel() to access the clock registers. Settle on the
generic readl()/writel().

Signed-off-by: Geert Uytterhoeven 
---
 drivers/clk/renesas/rcar-gen3-cpg.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c 
b/drivers/clk/renesas/rcar-gen3-cpg.c
index 9d76076da4948fc4..742f6dc7c15653ef 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -98,7 +98,7 @@ static int cpg_sd_clock_enable(struct clk_hw *hw)
u32 val, sd_fc;
unsigned int i;
 
-   val = clk_readl(clock->reg);
+   val = readl(clock->reg);
 
sd_fc = val & CPG_SD_FC_MASK;
for (i = 0; i < clock->div_num; i++)
@@ -111,7 +111,7 @@ static int cpg_sd_clock_enable(struct clk_hw *hw)
val &= ~(CPG_SD_STP_MASK);
val |= clock->div_table[i].val & CPG_SD_STP_MASK;
 
-   clk_writel(val, clock->reg);
+   writel(val, clock->reg);
 
return 0;
 }
@@ -120,14 +120,14 @@ static void cpg_sd_clock_disable(struct clk_hw *hw)
 {
struct sd_clock *clock = to_sd_clock(hw);
 
-   clk_writel(clk_readl(clock->reg) | CPG_SD_STP_MASK, clock->reg);
+   writel(readl(clock->reg) | CPG_SD_STP_MASK, clock->reg);
 }
 
 static int cpg_sd_clock_is_enabled(struct clk_hw *hw)
 {
struct sd_clock *clock = to_sd_clock(hw);
 
-   return !(clk_readl(clock->reg) & CPG_SD_STP_MASK);
+   return !(readl(clock->reg) & CPG_SD_STP_MASK);
 }
 
 static unsigned long cpg_sd_clock_recalc_rate(struct clk_hw *hw,
@@ -138,7 +138,7 @@ static unsigned long cpg_sd_clock_recalc_rate(struct clk_hw 
*hw,
u32 val, sd_fc;
unsigned int i;
 
-   val = clk_readl(clock->reg);
+   val = readl(clock->reg);
 
sd_fc = val & CPG_SD_FC_MASK;
for (i = 0; i < clock->div_num; i++)
@@ -189,10 +189,10 @@ static int cpg_sd_clock_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (i >= clock->div_num)
return -EINVAL;
 
-   val = clk_readl(clock->reg);
+   val = readl(clock->reg);
val &= ~(CPG_SD_STP_MASK | CPG_SD_FC_MASK);
val |= clock->div_table[i].val & (CPG_SD_STP_MASK | CPG_SD_FC_MASK);
-   clk_writel(val, clock->reg);
+   writel(val, clock->reg);
 
return 0;
 }
-- 
1.9.1

[PATCH 0/2] clk: renesas: cpg-mssr: Always use readl()/writel()

2016-09-23 Thread Geert Uytterhoeven 
Hi Mike, Stephen,

The Renesas CPG/MSSR clock drivers use a mix of clk_readl()/clk_writel()
and readl()/writel() to access the clock registers. Settle on the
generic readl()/writel().

I plan to queue this up in clk-renesas-for-v4.10.

Geert Uytterhoeven (2):
  clk: renesas: cpg-mssr: Always use readl()/writel()
  clk: renesas: rcar-gen3-cpg: Always use readl()/writel()

 drivers/clk/renesas/rcar-gen3-cpg.c| 14 +++---
 drivers/clk/renesas/renesas-cpg-mssr.c |  9 -
 2 files changed, 11 insertions(+), 12 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] ARM: shmobile: Sort Kconfig selections

2016-09-23 Thread Geert Uytterhoeven 
Sort alphabetically all symbols selected by ARCH_RENESAS

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/mach-shmobile/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 4a48c9f5f72537cd..b5a3cbe81dd1d1f0 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -33,15 +33,15 @@ config ARCH_RMOBILE
 menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
+   select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select ARCH_SHMOBILE
select ARCH_SHMOBILE_MULTI
+   select ARM_GIC
+   select GPIOLIB
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
-   select ARM_GIC
-   select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select NO_IOPORT_MAP
select PINCTRL
-   select GPIOLIB
select ZONE_DMA if ARM_LPAE
 
 if ARCH_RENESAS
-- 
1.9.1

[PATCH] clocksource: sh_cmt: Document r8a779[34] SoC specific bindings

2016-09-23 Thread Simon Horman 
This documents the SoC specific binding for the r8a779[34] SoCs.
This is in keeping with the documentation of other R-Car Gen2 SoCs.

Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/timer/renesas,cmt.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
index 1a05c1b243c1..566fb599ea39 100644
--- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
@@ -48,10 +48,15 @@ Required Properties:
(CMT[01])
 - "renesas,cmt-48-r8a7791" for the r8a7791 48-bit CMT
(CMT[01])
+- "renesas,cmt-48-r8a7793" for the r8a7793 48-bit CMT
+   (CMT[01])
+- "renesas,cmt-48-r8a7794" for the r8a7793 48-bit CMT
+   (CMT[01])
 - "renesas,cmt-48-gen2" for all second generation 48-bit CMT
-   (CMT[01] on r8a73a4, r8a7790 and r8a7791)
+   (CMT[01] on r8a73a4, r8a7790, r8a7791, r8a7793, r8a7794)
This is a fallback for the renesas,cmt-48-r8a73a4,
-   renesas,cmt-48-r8a7790 and renesas,cmt-48-r8a7791 entries.
+   renesas,cmt-48-r8a7790, renesas,cmt-48-r8a7791,
+   renesas,cmt-48-r8a7793 and renesas,cmt-48-r8a7794 entries.
 
   - reg: base address and length of the registers block for the timer module.
   - interrupts: interrupt-specifier for the timer, one per channel.
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH 3/3] ARM: dts: rskrza1: add sdhi1 DT support

2016-09-23 Thread Simon Horman 
On Fri, Sep 23, 2016 at 09:09:07AM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 22, 2016 at 11:32 PM, Chris Brandt  
> wrote:
> > Signed-off-by: Chris Brandt 
> > ---
> >  arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts 
> > b/arch/arm/boot/dts/r7s72100-rskrza1.dts
> > index e5dea5b..548b51f 100644
> > --- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
> > +++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
> > @@ -56,6 +56,10 @@
> > };
> >  };
> >
> > + {
> > +   status = "okay";
> 
> On all other boards, we have the bus-width property in the board-specific
> .dts instead of in the SoC-specific .dtsi.

I'd like us to be consistent as much as possible.
But I do wonder why it has been added as a board property.

> > +};
> > +
> >   {
> > status = "okay";
> >  };

Re: [PATCH 0/2] Add R8A7792 MSIOF support

2016-09-23 Thread Simon Horman 
On Fri, Sep 23, 2016 at 12:18:52AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 09/05/2016 11:54 PM, Sergei Shtylyov wrote:
> 
> >   Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
> >'renesas-devel-20160905-v4.8-rc5' tag. We're adding the R8A7792 MSIOF clocks
> >and device nodes. I'm not posting the board patches because the MSIOF driver
> >seems erratic ATM...
> >
> >[1/2] ARM: dts: r8a7792: add MSIOF clock
> >[2/2] ARM: dts: r8a7792: add MSIOF support
> 
>These seem stuck for no apparent reason. Simon?

Thanks, I have queued these up.

Re: [PATCH v2] ARM: dts: wheat: add DU support

2016-09-23 Thread Simon Horman 
On Fri, Sep 23, 2016 at 12:06:43AM +0300, Sergei Shtylyov wrote:
> Define  the  Wheat board dependent  part of the DU device node.
> Add the device nodes for the Analog Devices ADV7513 HDMI transmitters
> connected to DU0/1.  Add the necessary subnodes to interconnect DU with
> HDMI transmitters/connectors.
> 
> Signed-off-by: Sergei Shtylyov 

Thanks, I have queued this up.

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

2016-09-23 Thread Niklas Söderlund 
Hi Vinod,

On 2016-09-15 21:56:51 +0530, Vinod Koul wrote:
> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> > On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> > > Hi,
> > > 
> > > This series tries to solve the problem with DMA with device registers
> > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > > recent patch '9575632 (dmaengine: make slave address physical)'
> > > clarifies that DMA slave address provided by clients is the physical
> > > address. This puts the task of mapping the DMA slave address from a
> > > phys_addr_t to a dma_addr_t on the DMA engine.
> > > 
> > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > > the same and no special care is needed. However if you have a IOMMU you
> > > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > > like this.
> > > 
> > > This series is based on top of v4.8-rc1. And I'm hoping to be able to 
> > > collect a
> > > Ack from Russell King on patch 4/6 that adds the ARM specific part and 
> > > then be
> > > able to take the whole series through the dmaengine tree. If this is not 
> > > the
> > > best route I'm more then happy to do it another way.
> > > 
> > > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> > > /dev/mmcblk1, i2c and the serial console which are devices behind the
> > > iommu.
> > 
> > As I said in last one, the dmaengine parts look fine to me. But to go thru
> > dmaengine tree I would need ACK on non dmaengine patches.
> 
> I havent heard back from this one and I am inclined to merge this one now.
> If anyone has any objects, please speak up now...

I'm just curios, do you plan to merge this series with Arnds Ack? If not 
is there anything I can do to help move the series in the right 
direction?

> 
> Also ACKs welcome...
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 3/3] ARM: dts: rskrza1: add sdhi1 DT support

2016-09-23 Thread Geert Uytterhoeven 
On Thu, Sep 22, 2016 at 11:32 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 
> ---
>  arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts 
> b/arch/arm/boot/dts/r7s72100-rskrza1.dts
> index e5dea5b..548b51f 100644
> --- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
> +++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
> @@ -56,6 +56,10 @@
> };
>  };
>
> + {
> +   status = "okay";

On all other boards, we have the bus-width property in the board-specific
.dts instead of in the SoC-specific .dtsi.

> +};
> +
>   {
> status = "okay";
>  };

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 2/3] ARM: dts: r7s72100: add sdhi to device tree

2016-09-23 Thread Geert Uytterhoeven 
Hi Chris,

On Thu, Sep 22, 2016 at 11:32 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 

Reviewed-by: Geert Uytterhoeven 

(due to lack of documentation about SDHI, for the interrupt numbers only)

> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -458,4 +458,32 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> +   sdhi0: sd@e804e000 {
> +   compatible = "renesas,sdhi-r7s72100";
> +   reg = <0xe804e000 0x100>;
> +   interrupts =  + GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH
> + GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
> +

Cannot chcck the required order, but the interrupts are called SDHI0_3,
SDHI0_0, and SDHI0_1 in the datasheet.

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 1/3] ARM: dts: r7s72100: add sdhi clock to device tree

2016-09-23 Thread Geert Uytterhoeven 
On Thu, Sep 22, 2016 at 11:32 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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