Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

[Peter Rosin]

On 2018-05-09 17:53, Peter Rosin wrote:
> On 2018-05-09 17:08, Andrzej Hajda wrote:
>> On 04.05.2018 15:51, Peter Rosin wrote:
>>> Bridge drivers can now (temporarily, in a transition phase) select if
>>> they want to provide a full owner device or keep just providing an
>>> of_node.
>>>
>>> By providing a full owner device, the bridge drivers no longer need
>>> to provide an of_node since that node is available via the owner
>>> device.
>>>
>>> When all bridge drivers provide an owner device, that will become
>>> mandatory and the .of_node member will be removed.
>>>
>>> Signed-off-by: Peter Rosin 
>>> ---
>>>  drivers/gpu/drm/drm_bridge.c | 3 ++-
>>>  drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
>>
>> What is the reason to put rockchip here? Shouldn't be in separate patch?
> 
> Because the rockchip driver peeks into the bridge struct and all the
> changes in this patch relate to making the new .odev member optional in
> the transition phase, when the bridge can have either a new-style odev
> or an old style of_node.
> 
> I guess this rockchip change could be patch 2, but it has to come first
> after this patch and it makes no sense on its own. Hence, one patch.
> 
> This rockchip_lvds interaction is also present in patch 24/26
> drm/bridge: remove the .of_node member
> 
> I can split them if you want, but I personally don't see the point.

I had a second look, and maybe the series should start with a patch like
this instead, so that the rockchip_lvds.c hunks can be removed from
patch 1/26 and 24/26. That would perhaps be slightly cleaner?

On the other hand, it's orthogonal and this series can be left as is
(with the benefit of me not having to do another iteration and you all
not having another bunch of messages to sift through). The below
patch could easily be (adjusted and) applied later instead. Or not,
since the right fix is to do this with the newfangled static image
format mechanism from Jacopo Mondi, and it might be easier to just do
it right.

State your preference.

Cheers,
Peter

>From dee27b36a36acd271459d1489336b56132097425 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Wed, 9 May 2018 23:58:24 +0200
Subject: [PATCH] drm/rockchip: lvds: do not dig into the DT of remote bridges

The driver is trying to find the needed "data-mapping" for
interacting with the following bridge in the graphics chain.
But, doing so is bad since it is done w/o regard of the
compatible of the remote bridge, so the value of "data-mapping"
might not mean what this driver assumes. It is also pointless
since no bridge has any documented "data-mapping" DT property
and no dts file show any undocumented use.

Just remove the inappropriate code.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..fa3f4bf9712f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
-   else
-   remote = lvds->bridge->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", ))
/* default set it as output rgb */
lvds->output = DISPLAY_OUTPUT_RGB;
-- 
2.11.0

Re: [PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node

[Simon Horman]

On Wed, May 09, 2018 at 10:18:47PM +0300, Sergei Shtylyov wrote:
> On 5/9/2018 10:14 PM, Simon Horman wrote:
> 
> > > > Add resets property to CAN-FD node to describe it in the reset topology 
> > > > of
> > > > on-SoC devices.  This allows to reset the CAN-FD device using the Reset
> > > > Controller API.
> > > > 
> > > > Signed-off-by: Simon Horman 
> > > 
> > > Reviewed-by: Geert Uytterhoeven 
> > 
> > Thanks, applied.
> 
>You're too quick (and I'm on holiday today). Need "to| before "CAN-FD" in
> the subject. ;-)

Thanks, fixed.

Re: [PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node

[Sergei Shtylyov]

On 5/9/2018 10:14 PM, Simon Horman wrote:


Add resets property to CAN-FD node to describe it in the reset topology of
on-SoC devices.  This allows to reset the CAN-FD device using the Reset
Controller API.

Signed-off-by: Simon Horman 


Reviewed-by: Geert Uytterhoeven 


Thanks, applied.


   You're too quick (and I'm on holiday today). Need "to| before "CAN-FD" in 
the subject. ;-)


MBR, Sergei

Re: [PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node

[Simon Horman]

On Wed, May 09, 2018 at 08:29:19PM +0200, Geert Uytterhoeven wrote:
> On Wed, May 9, 2018 at 7:54 PM, Simon Horman  
> wrote:
> > Add resets property to CAN-FD node to describe it in the reset topology of
> > on-SoC devices.  This allows to reset the CAN-FD device using the Reset
> > Controller API.
> >
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 0/8] ARM: dts: renesas: Add PMU device nodes

[Simon Horman]

On Mon, May 07, 2018 at 03:56:59PM +0200, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> This patch series enables support for the ARM Performance Monitor Units
> in Cortex-A7, Cortex-A9, and Cortex-A15 CPU cores on Renesas RZ/A1,
> R-Car Gen2, and RZ/G1 SoCs.  This allows for better performance analysis
> using the "perf" tool.
> 
> Sample output of "perf stat echo" on r8a7791/koelsch:
> 
>   - Before:
> 
>  Performance counter stats for 'echo':
> 
> 2,636300  task-clock (msec) #0,265 CPUs utilized
>8  context-switches  #0,003 M/sec
>0  cpu-migrations#0,000 K/sec
>   43  page-faults   #0,016 M/sec
>  cycles
>  stalled-cycles-frontend
>  stalled-cycles-backend
>  instructions
>  branches
>  branch-misses
> 
>  0,009960300 seconds time elapsed
> 
>   - After:
> 
>  Performance counter stats for 'echo':
> 
> 2,455400  task-clock (msec) #0,273 CPUs utilized
>3  context-switches  #0,001 M/sec
>0  cpu-migrations#0,000 K/sec
>   45  page-faults   #0,018 M/sec
>3.556.784  cycles#1,449 GHz
>  stalled-cycles-frontend
>  stalled-cycles-backend
>1.350.480  instructions  #0,38  insns per cycle
>  335.542  branches  #  136,655 M/sec
>   18.075  branch-misses #5,39% of all branches
> 
>  0,008987900 seconds time elapsed
> 
> Still missing:
>   - R-Mobile APE6 (no PMU interrupt documented),
>   - R-Car M1A and H1 (the PMU interrupt seems to be routed to the legacy
> SH INTC only?),
>   - RZ/G1C (SMP support not yet upstream).
> 
> This has been tested on r8a7791/koelsch, and boot-tested on
> r7s72100/genmai, r8a7790/lager, r8a7792/blanche, and r8a7794/silk.

Thanks, applied.

Re: [PATCH v2 0/2] arm64: dts: renesas: r8a77970: Add SMP Support

[Simon Horman]

On Wed, May 09, 2018 at 05:23:21PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
> 
> This patch series enables SMP support on the R-Car V3M SoC, by adding
> the second Cortex-A53 CPU core.  It also adds the performance monitor
> unit, and links it to both CPU cores.
> 
> Changes compared to v1:
>   - Adjust GIC_CPU_MASK_SIMPLE(),
>   - Use symbolic core clock and power domain indices,
>   - Move the pmu node from the soc subnode to the root node, as it
> doesn't have registers.
> 
> Note that the PSCI implementation on Eagle may be a preliminary version
> with some familiar quirks:
>   - SMP bringup works, and both CPUs can be used,
>   - Offlining CPU0 crashes the system,
>   - CPU1 can be offlined, but trying to bring it online again crashes
> the system, too.
> 
> I'm confident these will be fixed in future firmware versions, just like
> on H3/Salvator-X.  Note that
> g...@github.com:renesas-rcar/arm-trusted-firmware.git does not have
> support for R-Car V3M, V3H, and D3.
> 
> Thanks!
> 
> Geert Uytterhoeven (2):
>   arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
>   arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node

Thanks, applied.

Re: [PATCH] arm64: dts: renesas: r8a77970: add SMP support

[Simon Horman]

On Tue, May 08, 2018 at 09:47:10PM +0300, Sergei Shtylyov wrote:
> On 05/08/2018 09:40 PM, Geert Uytterhoeven wrote:
> 
> >> Add the device node for the second Cortex-A53 CPU core.
> >>
> >> Based on the original (and large) patch by Daisuke Matsushita
> >> .
> >>
> >> Signed-off-by: Vladimir Barinov 
> >> Signed-off-by: Sergei Shtylyov 
> > 
> > Dupe of https://patchwork.kernel.org/patch/10032875/
> 
>Sorry!
>Not an exact dupe, though -- mine has clock/power #define's used,
> yours -- only bare #s. :-)
> 
> > From series "[PATCH 0/2] arm64: dts: renesas: r8a77970: Add SMP Support"
> > (https://www.spinics.net/lists/linux-renesas-soc/msg19681.html)
> 
>Hmm... what's the fate of this series?

There is now a v2 of Geert's series which incorporates your enhancements.
I will apply that.

Re: [PATCH 0/2] ARM: dts: r7s72100: Correct interrupt types

[Simon Horman]

On Mon, May 07, 2018 at 02:39:13PM +, Chris Brandt wrote:
> Hi Geert,
> 
> On Monday, May 07, 2018, Geert Uytterhoeven wrote:
> > 
> > Hi Simon, Magnus,
> > 
> > RZ/A1H peripherals use a mix of level and edge interrupts.
> > 
> > This patch series corrects the interrupt types for watchdog and RTC from
> > edge to level, to match the datasheet.
> > 
> > Is there any easy way to test this?
> > The watchdog interrupt is not used by the Linux driver.
> > The RTC interrupts are used, but how to trigger them?
> 
> Honestly, I can't remember if I did that for a reason, or it was just an
> oversight.
> 
> Like you mentioned, the watchdog driver does not use interrupts, it 
> simply resets system on overflow.
> 
> As for RTC, I thought I remember setting an 'alarm' and testing the code
> did work. But, I can't seem to find any leftover test scripts (so did I
> really do that)
> 
> I would say make the changes anyway as they should match what is in the 
> hardware manual.

Thanks, applied.

Re: [PATCH 00/10] ARM, arm64: dts: renesas: update register properties

[Simon Horman]

On Wed, May 02, 2018 at 03:10:18PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Apr 26, 2018 at 12:29 PM, Simon Horman
>  wrote:
> > this series:
> >
> > 1. Drops unnecessary address properties from VIN port nodes
> >on Renesas R-Car Gen2 SoC board DTSes. These are unnecessary
> >as the nodes to not have bus addresses.
> 
> I guess the example in Documentation/devicetree/bindings/media/rcar_vin.txt
> should be updated, too?

I have sent a patch for this.

> > 2. And adds address properties to R-Car Sound port nodes on
> >Renesas R-Car Gen2 SoC DTSes. These are necessary as the nodes
> >have unit names.
> 
> Documentation/devicetree/bindings/sound/renesas,rsnd.txt doesn't say
> anything about the presence of ports?

[PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port

[Simon Horman]

The example vin port node does not have an address and thus does not
need address-cells or address size-properties.

Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index a19517e1c669..2a0c59e97f40 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -107,9 +107,6 @@ Board setup example for Gen2 platforms (vin1 composite 
video input)
 status = "okay";
 
 port {
-#address-cells = <1>;
-#size-cells = <0>;
-
 vin1ep0: endpoint {
 remote-endpoint = <>;
 bus-width = <8>;
-- 
2.11.0

Re: [PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node

[Geert Uytterhoeven]

On Wed, May 9, 2018 at 7:54 PM, Simon Horman  wrote:
> Add resets property to CAN-FD node to describe it in the reset topology of
> on-SoC devices.  This allows to reset the CAN-FD device using the Reset
> Controller API.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH/RFT v3 1/3] thermal: rcar_thermal: add r8a77995 support

[Simon Horman]

On Tue, Apr 03, 2018 at 09:43:03PM +0900, Yoshihiro Kaneko wrote:
> Add support for R-Car D3 (r8a77995) thermal sensor.
> 
> Signed-off-by: Yoshihiro Kaneko 
> ---
>  drivers/thermal/rcar_thermal.c | 154 
> -
>  1 file changed, 122 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> index 73e5fee..5ec47a9 100644
> --- a/drivers/thermal/rcar_thermal.c
> +++ b/drivers/thermal/rcar_thermal.c
> @@ -58,10 +58,43 @@ struct rcar_thermal_common {
>   spinlock_t lock;
>  };
>  
> +struct rcar_thermal_chip {
> + unsigned int use_of_thermal : 1;
> + unsigned int has_filonoff : 1;
> + unsigned int irq_per_ch : 1;
> + unsigned int needs_suspend_resume : 1;
> + unsigned int nirqs;
> +};
> +
> +static const struct rcar_thermal_chip rcar_thermal = {
> + .use_of_thermal = 0,
> + .has_filonoff = 1,
> + .irq_per_ch = 0,
> + .needs_suspend_resume = 0,
> + .nirqs = 1,
> +};
> +
> +static const struct rcar_thermal_chip rcar_gen2_thermal = {
> + .use_of_thermal = 1,
> + .has_filonoff = 1,
> + .irq_per_ch = 0,
> + .needs_suspend_resume = 0,
> + .nirqs = 1,
> +};
> +
> +static const struct rcar_thermal_chip rcar_gen3_thermal = {
> + .use_of_thermal = 1,
> + .has_filonoff = 0,
> + .irq_per_ch = 1,
> + .needs_suspend_resume = 1,
> + .nirqs = 2,
> +};

The binding and dts patches in this series describe 3 interrupts
for R-Car D3. But the above specifies two. Am I missing something obvious?

Re: [PATCH/RFT v3 2/3] dt-bindings: thermal: rcar-thermal: add R8A77995 support

[Simon Horman]

On Mon, Apr 09, 2018 at 04:21:29PM -0500, Rob Herring wrote:
> On Tue, Apr 03, 2018 at 09:43:04PM +0900, Yoshihiro Kaneko wrote:
> > Signed-off-by: Yoshihiro Kaneko 
> > Reviewed-by: Geert Uytterhoeven 
> > ---
> >  Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
> > b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > index 349e635..5ab5fcd 100644
> > --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > @@ -3,7 +3,8 @@
> >  Required properties:
> >  - compatible   : "renesas,thermal-",
> >"renesas,rcar-gen2-thermal" (with thermal-zone) or
> > -  "renesas,rcar-thermal" (without thermal-zone) as 
> > fallback.
> > +  "renesas,rcar-thermal" (without thermal-zone) as
> > +   fallback except R-Car D3.
> >   Examples with soctypes are:
> > - "renesas,thermal-r8a73a4" (R-Mobile APE6)
> > - "renesas,thermal-r8a7743" (RZ/G1M)
> > @@ -12,13 +13,15 @@ Required properties:
> > - "renesas,thermal-r8a7791" (R-Car M2-W)
> > - "renesas,thermal-r8a7792" (R-Car V2H)
> > - "renesas,thermal-r8a7793" (R-Car M2-N)
> > +   - "renesas,thermal-r8a77995" (R-Car D3)
> >  - reg  : Address range of the thermal registers.
> >   The 1st reg will be recognized as common register
> >   if it has "interrupts".
> >  
> >  Option properties:
> >  
> > -- interrupts   : use interrupt
> > +- interrupts   : use interrupt.
> > +  Should contain 3 interrupts for R-Car D3.
> 
> And how many for other chips?

How about this?

If present should contain 3 interrupts for
R-Car D3 or 1 interrupt otherwise.

> >  
> >  Example (non interrupt support):
> >  
> > -- 
> > 1.9.1
> > 
> 

Re: [PATCH/RFT v2 1/3] thermal: rcar_thermal: add r8a77995 support

[Simon Horman]

On Wed, May 09, 2018 at 10:35:16PM +0900, Yoshihiro Kaneko wrote:
> Hi Simon-san,
> 
> 2018-05-07 21:43 GMT+09:00 Simon Horman :
> > Hi Kaneko-san,
> >
> > could you re-spin this series with Geerts concerns (below) addressed.
> >
> > When you repost I think you can add the tested tags and drop the RFT from
> > the prefix. I think its likely it can then be merged.
> 
> I had posted V3 that was updated with Geert-san's suggestions.
> Should I repost V4 with the tested tags and without the RFT prefix?

Sorry, I missed that when I wrote the above.
I will respond to v3.

Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add CAN-FD support

[Simon Horman]

On Fri, May 04, 2018 at 09:52:38AM +0200, Geert Uytterhoeven wrote:
> Hi Sergei,
> 
> On Fri, Apr 27, 2018 at 9:12 PM, Sergei Shtylyov
>  wrote:
> > Define the generic R8A77980 part of the CAN-FD device node.
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov 
> > Signed-off-by: Sergei Shtylyov 
> 
> Thanks for your patch!
> 
> > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> =
> > @@ -170,6 +177,30 @@
> > status = "disabled";
> > };
> >
> > +   canfd: can@e66c {
> > +   compatible = "renesas,r8a77980-canfd",
> > +"renesas,rcar-gen3-canfd";
> > +   reg = <0 0xe66c 0 0x8000>;
> > +   interrupts = ,
> > +;
> > +   clocks = < CPG_MOD 914>,
> > +< CPG_CORE R8A77980_CLK_CANFD>,
> > +<_clk>;
> > +   clock-names = "fck", "canfd", "can_clk";
> > +   assigned-clocks = < CPG_CORE 
> > R8A77980_CLK_CANFD>;
> > +   assigned-clock-rates = <4000>;
> > +   power-domains = < R8A77980_PD_ALWAYS_ON>;
> 
> You forgot the resets property.

Thanks, I have sent a follow-up patch.

[PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node

[Simon Horman]

Add resets property to CAN-FD node to describe it in the reset topology of
on-SoC devices.  This allows to reset the CAN-FD device using the Reset
Controller API.

Signed-off-by: Simon Horman 
---
Based on renesas-devel-20180508-v4.17-rc4
---
 arch/arm64/boot/dts/renesas/r8a77980.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77980.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
index 3a127643d1dc..32db26f2c8b5 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -190,6 +190,7 @@
assigned-clocks = < CPG_CORE R8A77980_CLK_CANFD>;
assigned-clock-rates = <4000>;
power-domains = < R8A77980_PD_ALWAYS_ON>;
+   resets = < 914>;
status = "disabled";
 
channel0 {
-- 
2.11.0

Re: [PATCH v2] arm64: dts: r8a77965: Add SDHI device nodes

[Simon Horman]

On Wed, May 09, 2018 at 03:39:45PM +0200, Geert Uytterhoeven wrote:
> Hi Kaneko-san,
> 
> On Wed, May 9, 2018 at 2:38 PM, Yoshihiro Kaneko  
> wrote:
> > From: Takeshi Kihara 
> >
> > Add SDHI nodes to the DT of the r8a77965 SoC.
> >
> > Based on several similar patches of the R8A7796 device tree
> > by Simon Horman .
> >
> > Signed-off-by: Takeshi Kihara 
> > Signed-off-by: Yoshihiro Kaneko 
> > ---
> >
> > This patch is based on the devel branch of Simon Horman's renesas tree.
> >
> > v2 [Yoshihiro Kaneko]
> > * As suggested by Simon Horman
> > Rebased on top of the devel branch of the renesas tree.
> 
> Thanks for the update!
> 
> >  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 36 
> > +++
> >  1 file changed, 32 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
> > b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > index ba0edda..510815e 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > @@ -978,23 +978,51 @@
> > };
> >
> > sdhi0: sd@ee10 {
> > +   compatible = "renesas,sdhi-r8a77965",
> > +"renesas,rcar-gen3-sdhi";
> > reg = <0 0xee10 0 0x2000>;
> > -   /* placeholder */
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 314>;
> > +   max-frequency = <2>;
> > +   power-domains = < 32>;
> 
> In the mean time,  has landed
> upstream, so please use R8A77965_PD_ALWAYS_ON.
> 
> With the above fixed:
> Reviewed-by: Geert Uytterhoeven 

Thanks, I have applied the patch with that fix.
The result is as follows:

From: Takeshi Kihara 
Subject: [PATCH] arm64: dts: r8a77965: Add SDHI device nodes

Add SDHI nodes to the DT of the r8a77965 SoC.

Based on several similar patches of the R8A7796 device tree
by Simon Horman .

Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Kaneko 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 36 +++
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index ba0edda431a5..f51c1b2cbae4 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -978,23 +978,51 @@
};
 
sdhi0: sd@ee10 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee10 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 314>;
+   max-frequency = <2>;
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 314>;
+   status = "disabled";
};
 
sdhi1: sd@ee12 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee12 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 313>;
+   max-frequency = <2>;
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 313>;
+   status = "disabled";
};
 
sdhi2: sd@ee14 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee14 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 312>;
+   max-frequency = <2>;
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 312>;
+   status = "disabled";
};
 
sdhi3: sd@ee16 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee16 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 311>;
+   max-frequency = <2>;
+   

[git pull] pinctrl: sh-pfc: Updates for v4.18

[Geert Uytterhoeven]

Hi Linus,

(this time with the right subject line)

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/sh-pfc-for-v4.18-tag1

for you to fetch changes up to f18fab4bcb4f85db806048b2ee44c885b46b5a0f:

  pinctrl: sh-pfc: Add r8a77470 PFC support (2018-05-04 11:42:54 +0200)


pinctrl: sh-pfc: Updates for v4.18

  - Add DU, MSIOF, PWM, and SDHI pin groups on R-Car M3-N,
  - Add support for the new RZ/G1C SoC,
  - Add support for I/O voltage control on R-Car V3M and V3H,
  - Small fixes and cleanups.

Thanks for pulling!


Biju Das (2):
  dt-bindings: pinctrl: sh-pfc: Document r8a77470 PFC support
  pinctrl: sh-pfc: Add r8a77470 PFC support

Geert Uytterhoeven (2):
  pinctrl: sh-pfc: r8a7795: Fix comment for MSIOF3 SS2_E pin
  pinctrl: sh-pfc: r8a7796: Fix comment for MSIOF3 SS2_E pin

Kieran Bingham (1):
  pinctrl: sh-pfc: r8a77965: Add DU RGB output pins, groups and functions

Sergei Shtylyov (2):
  pinctrl: sh-pfc: r8a77980: Add pin I/O voltage control support
  pinctrl: sh-pfc: r8a77970: Fix pin I/O voltage control support

Takeshi Kihara (3):
  pinctrl: sh-pfc: r8a77965: Add MSIOF pins, groups and functions
  pinctrl: sh-pfc: r8a77965: Add PWM pins, groups and functions
  pinctrl: sh-pfc: r8a77965: Add SDHI pins, groups and functions

Thomas Gleixner (1):
  pinctrl: sh-pfc: r8a77965: Fixup incorrect SPDX identifier

 .../bindings/pinctrl/renesas,pfc-pinctrl.txt   |1 +
 drivers/pinctrl/sh-pfc/Kconfig |5 +
 drivers/pinctrl/sh-pfc/Makefile|1 +
 drivers/pinctrl/sh-pfc/core.c  |6 +
 drivers/pinctrl/sh-pfc/pfc-r8a77470.c  | 2343 
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c   |2 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7796.c   |2 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77965.c  | 1509 -
 drivers/pinctrl/sh-pfc/pfc-r8a77970.c  |   32 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77980.c  |   52 +-
 drivers/pinctrl/sh-pfc/sh_pfc.h|1 +
 11 files changed, 3940 insertions(+), 14 deletions(-)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77470.c

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 2/2] clk: renesas: cpg-mssr: Add support for R-Car E3

[Geert Uytterhoeven]

Hi Shimoda-san,

On Fri, Apr 20, 2018 at 2:27 PM, Yoshihiro Shimoda
 wrote:
> --- /dev/null
> +++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
> @@ -0,0 +1,289 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

For the record: SPDX lines in C source files should use C++-style comments,
as recent checkpatch complains about.

Fixed for the pull request.

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

[git pull] clk: renesas: Updates for v4.18

[Geert Uytterhoeven]

Hi Mike, Stephen,

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/clk-renesas-for-v4.18-tag1

for you to fetch changes up to 3570a2af473789c5d5f5b9e04f72295102967824:

  clk: renesas: cpg-mssr: Add support for R-Car E3 (2018-05-09 18:43:57 +0200)


clk: renesas: Updates for v4.18

  - Add support for the MSIOF module clocks on R-Car M3-N,
  - Add support for the new RZ/G1C and R-Car E3 SoCs,
  - Small fixes and cleanups.

Thanks for pulling!


Biju Das (2):
  clk: renesas: Add r8a77470 CPG Core Clock Definitions
  clk: renesas: cpg-mssr: Add r8a77470 support

Geert Uytterhoeven (7):
  clk: renesas: r8a7743: Fix LB clock divider
  clk: renesas: r8a7745: Fix LB clock divider
  clk: renesas: r8a7791/r8a7793: Fix LB clock divider
  clk: renesas: r8a7792: Fix LB clock divider
  clk: renesas: r8a7794: Fix LB clock divider
  clk: renesas: r8a77980: Correct parent clock of PCIEC0
  clk: renesas: rcar-gen2: Centralize quirks handling

Takeshi Kihara (2):
  clk: renesas: r8a77965: Add MSIOF controller clocks
  clk: renesas: Add r8a77990 CPG Core Clock Definitions

Yoshihiro Shimoda (1):
  clk: renesas: cpg-mssr: Add support for R-Car E3

 .../devicetree/bindings/clock/renesas,cpg-mssr.txt |  10 +-
 drivers/clk/renesas/Kconfig|  10 +
 drivers/clk/renesas/Makefile   |   2 +
 drivers/clk/renesas/r8a7743-cpg-mssr.c |   2 +-
 drivers/clk/renesas/r8a7745-cpg-mssr.c |   2 +-
 drivers/clk/renesas/r8a77470-cpg-mssr.c| 229 
 drivers/clk/renesas/r8a7791-cpg-mssr.c |   2 +-
 drivers/clk/renesas/r8a7792-cpg-mssr.c |   2 +-
 drivers/clk/renesas/r8a7794-cpg-mssr.c |   2 +-
 drivers/clk/renesas/r8a77965-cpg-mssr.c|   4 +
 drivers/clk/renesas/r8a77980-cpg-mssr.c|   2 +-
 drivers/clk/renesas/r8a77990-cpg-mssr.c| 289 +
 drivers/clk/renesas/rcar-gen2-cpg.c|  24 ++
 drivers/clk/renesas/renesas-cpg-mssr.c |  12 +
 drivers/clk/renesas/renesas-cpg-mssr.h |   2 +
 include/dt-bindings/clock/r8a77470-cpg-mssr.h  |  36 +++
 include/dt-bindings/clock/r8a77990-cpg-mssr.h  |  62 +
 17 files changed, 683 insertions(+), 9 deletions(-)
 create mode 100644 drivers/clk/renesas/r8a77470-cpg-mssr.c
 create mode 100644 drivers/clk/renesas/r8a77990-cpg-mssr.c
 create mode 100644 include/dt-bindings/clock/r8a77470-cpg-mssr.h
 create mode 100644 include/dt-bindings/clock/r8a77990-cpg-mssr.h

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

[git pull] pinctrl: sh-pfc: Updates for v4.17 (take two)

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/sh-pfc-for-v4.18-tag1

for you to fetch changes up to f18fab4bcb4f85db806048b2ee44c885b46b5a0f:

  pinctrl: sh-pfc: Add r8a77470 PFC support (2018-05-04 11:42:54 +0200)


pinctrl: sh-pfc: Updates for v4.18

  - Add DU, MSIOF, PWM, and SDHI pin groups on R-Car M3-N,
  - Add support for the new RZ/G1C SoC,
  - Add support for I/O voltage control on R-Car V3M and V3H,
  - Small fixes and cleanups.

Thanks for pulling!


Biju Das (2):
  dt-bindings: pinctrl: sh-pfc: Document r8a77470 PFC support
  pinctrl: sh-pfc: Add r8a77470 PFC support

Geert Uytterhoeven (2):
  pinctrl: sh-pfc: r8a7795: Fix comment for MSIOF3 SS2_E pin
  pinctrl: sh-pfc: r8a7796: Fix comment for MSIOF3 SS2_E pin

Kieran Bingham (1):
  pinctrl: sh-pfc: r8a77965: Add DU RGB output pins, groups and functions

Sergei Shtylyov (2):
  pinctrl: sh-pfc: r8a77980: Add pin I/O voltage control support
  pinctrl: sh-pfc: r8a77970: Fix pin I/O voltage control support

Takeshi Kihara (3):
  pinctrl: sh-pfc: r8a77965: Add MSIOF pins, groups and functions
  pinctrl: sh-pfc: r8a77965: Add PWM pins, groups and functions
  pinctrl: sh-pfc: r8a77965: Add SDHI pins, groups and functions

Thomas Gleixner (1):
  pinctrl: sh-pfc: r8a77965: Fixup incorrect SPDX identifier

 .../bindings/pinctrl/renesas,pfc-pinctrl.txt   |1 +
 drivers/pinctrl/sh-pfc/Kconfig |5 +
 drivers/pinctrl/sh-pfc/Makefile|1 +
 drivers/pinctrl/sh-pfc/core.c  |6 +
 drivers/pinctrl/sh-pfc/pfc-r8a77470.c  | 2343 
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c   |2 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7796.c   |2 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77965.c  | 1509 -
 drivers/pinctrl/sh-pfc/pfc-r8a77970.c  |   32 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77980.c  |   52 +-
 drivers/pinctrl/sh-pfc/sh_pfc.h|1 +
 11 files changed, 3940 insertions(+), 14 deletions(-)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77470.c

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 01/26] drm/bridge: allow optionally specifying an owner .odev device

[Peter Rosin]

On 2018-05-09 17:08, Andrzej Hajda wrote:
> On 04.05.2018 15:51, Peter Rosin wrote:
>> Bridge drivers can now (temporarily, in a transition phase) select if
>> they want to provide a full owner device or keep just providing an
>> of_node.
>>
>> By providing a full owner device, the bridge drivers no longer need
>> to provide an of_node since that node is available via the owner
>> device.
>>
>> When all bridge drivers provide an owner device, that will become
>> mandatory and the .of_node member will be removed.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/drm_bridge.c | 3 ++-
>>  drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
> 
> What is the reason to put rockchip here? Shouldn't be in separate patch?

Because the rockchip driver peeks into the bridge struct and all the
changes in this patch relate to making the new .odev member optional in
the transition phase, when the bridge can have either a new-style odev
or an old style of_node.

I guess this rockchip change could be patch 2, but it has to come first
after this patch and it makes no sense on its own. Hence, one patch.

This rockchip_lvds interaction is also present in patch 24/26
drm/bridge: remove the .of_node member

I can split them if you want, but I personally don't see the point.

>>  include/drm/drm_bridge.h | 2 ++
>>  3 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 1638bfe9627c..3872f5379998 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
>> *np)
>>  mutex_lock(_lock);
>>  
>>  list_for_each_entry(bridge, _list, list) {
>> -if (bridge->of_node == np) {
>> +if ((bridge->odev && bridge->odev->of_node == np) ||
>> +bridge->of_node == np) {
>>  mutex_unlock(_lock);
>>  return bridge;
>>  }
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
>> b/drivers/gpu/drm/rockchip/rockchip_lvds.c
>> index 4bd94b167d2c..557e0079c98d 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
>> @@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, 
>> struct device *master,
>>  }
>>  if (lvds->panel)
>>  remote = lvds->panel->dev->of_node;
>> -else
>> +else if (lvds->bridge->of_node)
>>  remote = lvds->bridge->of_node;
>> +else
>> +remote = lvds->bridge->odev->of_node;
> 
> I guess odev should be NULL here, or have I missed something.

s/should/could/ ???

Assuming that was what you meant and answering accordingly...

No, .odev cannot be NULL in that else branch. drm_of_find_panel_or_bridge
either found a panel or a bridge (or it failed). If it found a bridge
(which is the relevant branch for this question) that bridge would have
to have either an of_node (in the transition phase) or a valid .odev.
Otherwise the bridge could not have been found by
drm_of_find_panel_or_bridge.

*time passes*

Ahh, yes, .odev is always NULL here so you probably did mean "should".
But after patches 2-23 when bridges start populating .odev *instead*
of .of_node, .odev will not remain NULL. But as I said above, while
.odev is NULL, .of_node will never be NULL and vice versa (or
drm_of_find_panel_or_bridge could not have found the bridge) so there
is no risk of a NULL dereference.

Cheers,
Peter

> 
> Regards
> Andrzej
> 
>>  if (of_property_read_string(dev->of_node, "rockchip,output", ))
>>  /* default set it as output rgb */
>>  lvds->output = DISPLAY_OUTPUT_RGB;
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 3270fec46979..7c17977c3537 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -254,6 +254,7 @@ struct drm_bridge_timings {
>>  
>>  /**
>>   * struct drm_bridge - central DRM bridge control structure
>> + * @odev: device that owns the bridge
>>   * @dev: DRM device this bridge belongs to
>>   * @encoder: encoder to which this bridge is connected
>>   * @next: the next bridge in the encoder chain
>> @@ -265,6 +266,7 @@ struct drm_bridge_timings {
>>   * @driver_private: pointer to the bridge driver's internal context
>>   */
>>  struct drm_bridge {
>> +struct device *odev;
>>  struct drm_device *dev;
>>  struct drm_encoder *encoder;
>>  struct drm_bridge *next;
> 
> 

[PATCH v2 1/2] arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core

[Geert Uytterhoeven]

Add a device node for the second Cortex-A53 CPU core on the Renesas
R-Car V3M (r8a77970) SoC, and adjust the interrupt delivery masks for
ARM Generic Interrupt Controller and Architectured Timer.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Adjust GIC_CPU_MASK_SIMPLE(),
  - Use symbolic core clock and power domain indices.
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 6ed2e95eb53dbb15..ccc955e89cea4d32 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -41,6 +41,16 @@
enable-method = "psci";
};
 
+   a53_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <1>;
+   clocks = < CPG_CORE R8A77970_CLK_Z2>;
+   power-domains = < R8A77970_PD_CA53_CPU1>;
+   next-level-cache = <_CA53>;
+   enable-method = "psci";
+   };
+
L2_CA53: cache-controller {
compatible = "cache";
power-domains = < R8A77970_PD_CA53_SCU>;
@@ -603,7 +613,7 @@
  <0 0xf102 0 0x2>,
  <0 0xf104 0 0x2>,
  <0 0xf106 0 0x2>;
-   interrupts = ;
clocks = < CPG_MOD 408>;
clock-names = "clk";
@@ -694,9 +704,9 @@
 
timer {
compatible = "arm,armv8-timer";
-   interrupts-extended = < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) 
| IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) 
| IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) 
| IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) 
| IRQ_TYPE_LEVEL_LOW)>;
+   interrupts-extended = < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) 
| IRQ_TYPE_LEVEL_LOW)>,
+ < GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) 
| IRQ_TYPE_LEVEL_LOW)>,
+ < GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) 
| IRQ_TYPE_LEVEL_LOW)>,
+ < GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) 
| IRQ_TYPE_LEVEL_LOW)>;
};
 };
-- 
2.7.4

[PATCH v2 0/2] arm64: dts: renesas: r8a77970: Add SMP Support

[Geert Uytterhoeven]

Hi Simon, Magnus,

This patch series enables SMP support on the R-Car V3M SoC, by adding
the second Cortex-A53 CPU core.  It also adds the performance monitor
unit, and links it to both CPU cores.

Changes compared to v1:
  - Adjust GIC_CPU_MASK_SIMPLE(),
  - Use symbolic core clock and power domain indices,
  - Move the pmu node from the soc subnode to the root node, as it
doesn't have registers.

Note that the PSCI implementation on Eagle may be a preliminary version
with some familiar quirks:
  - SMP bringup works, and both CPUs can be used,
  - Offlining CPU0 crashes the system,
  - CPU1 can be offlined, but trying to bring it online again crashes
the system, too.

I'm confident these will be fixed in future firmware versions, just like
on H3/Salvator-X.  Note that
g...@github.com:renesas-rcar/arm-trusted-firmware.git does not have
support for R-Car V3M, V3H, and D3.

Thanks!

Geert Uytterhoeven (2):
  arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
  arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node

 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

-- 
2.7.4

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 2/2] arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node

[Geert Uytterhoeven]

Enable the performance monitor unit for the Cortex-A53 cores on the
R-Car V3M (r8a77970) SoC.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Move the pmu node from the soc subnode to the root node, as it
doesn't have registers.
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index ccc955e89cea4d32..71157ad893910a97 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -73,6 +73,13 @@
clock-frequency = <0>;
};
 
+   pmu_a53 {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-affinity = <_0>, <_1>;
+   };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
-- 
2.7.4

Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

[Andrzej Hajda]

On 04.05.2018 15:51, Peter Rosin wrote:
> Bridge drivers can now (temporarily, in a transition phase) select if
> they want to provide a full owner device or keep just providing an
> of_node.
>
> By providing a full owner device, the bridge drivers no longer need
> to provide an of_node since that node is available via the owner
> device.
>
> When all bridge drivers provide an owner device, that will become
> mandatory and the .of_node member will be removed.
>
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_bridge.c | 3 ++-
>  drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-

What is the reason to put rockchip here? Shouldn't be in separate patch?

>  include/drm/drm_bridge.h | 2 ++
>  3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 1638bfe9627c..3872f5379998 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
> *np)
>   mutex_lock(_lock);
>  
>   list_for_each_entry(bridge, _list, list) {
> - if (bridge->of_node == np) {
> + if ((bridge->odev && bridge->odev->of_node == np) ||
> + bridge->of_node == np) {
>   mutex_unlock(_lock);
>   return bridge;
>   }
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
> b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 4bd94b167d2c..557e0079c98d 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct 
> device *master,
>   }
>   if (lvds->panel)
>   remote = lvds->panel->dev->of_node;
> - else
> + else if (lvds->bridge->of_node)
>   remote = lvds->bridge->of_node;
> + else
> + remote = lvds->bridge->odev->of_node;

I guess odev should be NULL here, or have I missed something.

Regards
Andrzej

>   if (of_property_read_string(dev->of_node, "rockchip,output", ))
>   /* default set it as output rgb */
>   lvds->output = DISPLAY_OUTPUT_RGB;
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 3270fec46979..7c17977c3537 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -254,6 +254,7 @@ struct drm_bridge_timings {
>  
>  /**
>   * struct drm_bridge - central DRM bridge control structure
> + * @odev: device that owns the bridge
>   * @dev: DRM device this bridge belongs to
>   * @encoder: encoder to which this bridge is connected
>   * @next: the next bridge in the encoder chain
> @@ -265,6 +266,7 @@ struct drm_bridge_timings {
>   * @driver_private: pointer to the bridge driver's internal context
>   */
>  struct drm_bridge {
> + struct device *odev;
>   struct drm_device *dev;
>   struct drm_encoder *encoder;
>   struct drm_bridge *next;

Re: [PATCH 0/8] ARM: dts: renesas: Add PMU device nodes

[Geert Uytterhoeven]

On Mon, May 7, 2018 at 3:56 PM, Geert Uytterhoeven
 wrote:
> This patch series enables support for the ARM Performance Monitor Units
> in Cortex-A7, Cortex-A9, and Cortex-A15 CPU cores on Renesas RZ/A1,
> R-Car Gen2, and RZ/G1 SoCs.  This allows for better performance analysis
> using the "perf" tool.

[...]

> This has been tested on r8a7791/koelsch, and boot-tested on
> r7s72100/genmai, r8a7790/lager, r8a7792/blanche, and r8a7794/silk.

... and r8a7793/gose and r8a7794/alt.

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] arm64: dts: r8a77965: Add SDHI device nodes

[Geert Uytterhoeven]

Hi Kaneko-san,

On Wed, May 9, 2018 at 2:38 PM, Yoshihiro Kaneko  wrote:
> From: Takeshi Kihara 
>
> Add SDHI nodes to the DT of the r8a77965 SoC.
>
> Based on several similar patches of the R8A7796 device tree
> by Simon Horman .
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Kaneko 
> ---
>
> This patch is based on the devel branch of Simon Horman's renesas tree.
>
> v2 [Yoshihiro Kaneko]
> * As suggested by Simon Horman
> Rebased on top of the devel branch of the renesas tree.

Thanks for the update!

>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 36 
> +++
>  1 file changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> index ba0edda..510815e 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -978,23 +978,51 @@
> };
>
> sdhi0: sd@ee10 {
> +   compatible = "renesas,sdhi-r8a77965",
> +"renesas,rcar-gen3-sdhi";
> reg = <0 0xee10 0 0x2000>;
> -   /* placeholder */
> +   interrupts = ;
> +   clocks = < CPG_MOD 314>;
> +   max-frequency = <2>;
> +   power-domains = < 32>;

In the mean time,  has landed
upstream, so please use R8A77965_PD_ALWAYS_ON.

With the above fixed:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH/RFT v2 1/3] thermal: rcar_thermal: add r8a77995 support

[Yoshihiro Kaneko]

Hi Simon-san,

2018-05-07 21:43 GMT+09:00 Simon Horman :
> Hi Kaneko-san,
>
> could you re-spin this series with Geerts concerns (below) addressed.
>
> When you repost I think you can add the tested tags and drop the RFT from
> the prefix. I think its likely it can then be merged.

I had posted V3 that was updated with Geert-san's suggestions.
Should I repost V4 with the tested tags and without the RFT prefix?

>
> On Tue, Apr 03, 2018 at 08:17:01PM +0900, Yoshihiro Kaneko wrote:
>> Hi Geert-san,
>>
>> 2018-03-30 18:25 GMT+09:00 Geert Uytterhoeven :
>> > Hi Kaneko-san,
>> >
>> > On Fri, Mar 30, 2018 at 5:13 AM, Yoshihiro Kaneko  
>> > wrote:
>> >> Add support for R-Car D3 (r8a77995) thermal sensor.
>> >>
>> >> Signed-off-by: Yoshihiro Kaneko 
>> >
>> > Thanks for your patch!
>> >
>> >> --- a/drivers/thermal/rcar_thermal.c
>> >> +++ b/drivers/thermal/rcar_thermal.c
>> >> @@ -58,10 +58,35 @@ struct rcar_thermal_common {
>> >> spinlock_t lock;
>> >>  };
>> >>
>> >> +enum rcar_thermal_type {
>> >> +   RCAR_THERMAL,
>> >> +   RCAR_GEN2_THERMAL,
>> >> +   RCAR_GEN3_THERMAL,
>> >> +};
>> >> +
>> >> +struct rcar_thermal_chip {
>> >> +   int use_of_thermal;
>> >
>> > This can be a single bit:
>> >
>> > unsigned int use_of_thermal : 1;
>> >
>> >> +   enum rcar_thermal_type type;
>> >
>> > If you would add feature bits, you can get rid of rcar_thermal_type:
>> >
>> > unsigned int has_filonoff : 1;
>> > unsigned int has_enr : 1;
>> > unsigned int needs_suspend_resume : 1;
>> >
>> > The number of interrupts can be stored here, too.
>>
>> It's nice!
>>
>> >
>> >> +};
>> >> +
>> >> +static const struct rcar_thermal_chip rcar_thermal = {
>> >> +   .use_of_thermal = 0,
>> >> +   .type = RCAR_THERMAL,
>> >
>> > .has_filonoff = 1,
>> > .has_enr = 0,
>> > ...
>> > .nirqs = 1,
>> >
>> >> @@ -190,7 +222,8 @@ static int rcar_thermal_update_temp(struct 
>> >> rcar_thermal_priv *priv)
>> >>  * enable IRQ
>> >>  */
>> >> if (rcar_has_irq_support(priv)) {
>> >> -   rcar_thermal_write(priv, FILONOFF, 0);
>> >> +   if (priv->chip->type != RCAR_GEN3_THERMAL)
>> >
>> > if (priv->chip->has_filonoff)
>> >
>> >> @@ -438,6 +471,9 @@ static int rcar_thermal_probe(struct platform_device 
>> >> *pdev)
>> >> struct rcar_thermal_priv *priv;
>> >> struct device *dev = >dev;
>> >> struct resource *res, *irq;
>> >> +   struct rcar_thermal_chip *chip = ((struct rcar_thermal_chip *)
>> >
>> > I don't think the cast is needed.
>>
>> I will make 'chip' a const variable.
>>
>> >
>> >> @@ -457,19 +493,35 @@ static int rcar_thermal_probe(struct 
>> >> platform_device *pdev)
>> >> pm_runtime_enable(dev);
>> >> pm_runtime_get_sync(dev);
>> >>
>> >> -   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> >> -   if (irq) {
>> >> -   /*
>> >> -* platform has IRQ support.
>> >> -* Then, driver uses common registers
>> >> -* rcar_has_irq_support() will be enabled
>> >> -*/
>> >> -   res = platform_get_resource(pdev, IORESOURCE_MEM, mres++);
>> >> -   common->base = devm_ioremap_resource(dev, res);
>> >> -   if (IS_ERR(common->base))
>> >> -   return PTR_ERR(common->base);
>> >> +   for (i = 0; i < nirq; i++) {
>> >
>> > for (i = 0; i < priv->nirqs; i++) {
>>
>>
>> Best regards,
>> Kaneko
>>
>> >
>> > 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] mmc: renesas_sdhi: Add r8a77965 support

[Wolfram Sang]

On Wed, May 09, 2018 at 09:38:48PM +0900, Yoshihiro Kaneko wrote:
> From: Masaharu Hayakawa 
> 
> This patch adds r8a77965 support in SDHI.
> 
> Signed-off-by: Masaharu Hayakawa 
> Signed-off-by: Yoshihiro Kaneko 
> Tested-by: Simon Horman 
> Tested-by: Wolfram Sang 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

[PATCH v2] mmc: renesas_sdhi: Add r8a77965 support

[Yoshihiro Kaneko]

From: Masaharu Hayakawa 

This patch adds r8a77965 support in SDHI.

Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Yoshihiro Kaneko 
Tested-by: Simon Horman 
Tested-by: Wolfram Sang 
---

This patch is based on the next branch of Ulf Hansson's mmc tree.

v2 [Yoshihiro Kaneko]
renesas_sdhi_internal_dmac.c
* As suggested by Simon Horman
  Dropped .revision for r8a77965 in gen3_soc_whitelist.
* As suggested by Wolfram Sang
  Dropped "renesas,rcar-gen3-sdhi" line in renesas_sdhi_internal_dmac_of_match.

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
 drivers/mmc/host/renesas_sdhi_internal_dmac.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt 
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index ba38252..ee978c9 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -26,6 +26,7 @@ Required properties:
"renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
"renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
"renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC
+   "renesas,sdhi-r8a77965" - SDHI IP on R8A77965 SoC
"renesas,sdhi-r8a77980" - SDHI IP on R8A77980 SoC
"renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC
"renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index a6bf123..b6edb7a 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -276,6 +276,7 @@ static void 
renesas_sdhi_internal_dmac_complete_tasklet_fn(unsigned long arg)
/* generic ones */
{ .soc_id = "r8a7795" },
{ .soc_id = "r8a7796" },
+   { .soc_id = "r8a77965" },
{ .soc_id = "r8a77980" },
{ .soc_id = "r8a77995" },
{ /* sentinel */ }
-- 
1.9.1

[PATCH v2] arm64: dts: r8a77965: Add SDHI device nodes

[Yoshihiro Kaneko]

From: Takeshi Kihara 

Add SDHI nodes to the DT of the r8a77965 SoC.

Based on several similar patches of the R8A7796 device tree
by Simon Horman .

Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is based on the devel branch of Simon Horman's renesas tree.

v2 [Yoshihiro Kaneko]
* As suggested by Simon Horman
Rebased on top of the devel branch of the renesas tree.

 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 36 +++
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index ba0edda..510815e 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -978,23 +978,51 @@
};
 
sdhi0: sd@ee10 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee10 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 314>;
+   max-frequency = <2>;
+   power-domains = < 32>;
+   resets = < 314>;
+   status = "disabled";
};
 
sdhi1: sd@ee12 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee12 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 313>;
+   max-frequency = <2>;
+   power-domains = < 32>;
+   resets = < 313>;
+   status = "disabled";
};
 
sdhi2: sd@ee14 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee14 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 312>;
+   max-frequency = <2>;
+   power-domains = < 32>;
+   resets = < 312>;
+   status = "disabled";
};
 
sdhi3: sd@ee16 {
+   compatible = "renesas,sdhi-r8a77965",
+"renesas,rcar-gen3-sdhi";
reg = <0 0xee16 0 0x2000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 311>;
+   max-frequency = <2>;
+   power-domains = < 32>;
+   resets = < 311>;
+   status = "disabled";
};
 
gic: interrupt-controller@f101 {
-- 
1.9.1

RE: [PATCH v5] gpio: dwapb: Add support for 1 interrupt per port A GPIO

[Phil Edworthy]

Hi Andy,

On 05 May 2018 11:49 Andy Shevchenko wrote:
> On Thu, Apr 26, 2018 at 7:19 PM, Phil Edworthy wrote:
> 
> Sotty fo a late response. Consider follow up fixes for below.
> 
> > if (!pp->irq_shared) {
> > +   int i;
> > +
> > +   for (i = 0; i < pp->ngpio; i++) {
> > +   if (pp->irq[i])
> > +   irq_set_chained_handler_and_data(pp->irq[i],
> > +   dwapb_irq_handler, gpio);
> > +   }
> > } else {
> > /*
> >  * Request a shared IRQ since where MFD would have devices
> >  * using the same irq pin
> >  */
> > +   err = devm_request_irq(gpio->dev, pp->irq[0],
> >dwapb_irq_handler_mfd,
> >IRQF_SHARED, "gpio-dwapb-mfd",
> > gpio);
> 
> > +   if (pp->has_irq)
> > dwapb_configure_irqs(gpio, port, pp);
> 
> I would rather make irq array a type of signed int and move conditional into
> the function to test per IRQ based.
Ok, though since the driver can be used without interrupts, it has to check
if any are used before the driver does all the other interrupt related things.
 
> > /* Add GPIO-signaled ACPI event support */
> > +   if (pp->has_irq)
> > acpi_gpiochip_request_interrupts(>gc);
> 
> Perhaps something similar.
> 
> > if (dev->of_node && pp->idx == 0 &&
> > fwnode_property_read_bool(fwnode,
> >
> > "interrupt-controller")) {
> 
> > +   struct device_node *np = to_of_node(fwnode);
> > +   unsigned int j;
> > +
> > +   /*
> > +* The IP has configuration options to allow a 
> > single
> > +* combined interrupt or one per gpio. If one per 
> > gpio,
> > +* some might not be used.
> > +*/
> > +   for (j = 0; j < pp->ngpio; j++) {
> > +   int irq = of_irq_get(np, j);
> > +   if (irq < 0)
> > +   continue;
> > +
> > +   pp->irq[j] = irq;
> > +   pp->has_irq = true;
> > +   }
> 
> for (...)
>  pp->irq = of_irq_get();
> 
> > }
> 
> > +   if (has_acpi_companion(dev) && pp->idx == 0) {
> > +   unsigned int j;
> > +
> > +   for (j = 0; j < pp->ngpio; j++) {
> > +   pp->irq[j] = 
> > platform_get_irq(to_platform_device(dev), j);
> > +   if (pp->irq[j])
> > +   pp->has_irq = true;
> > +   }
> 
> Ditto.
> Moreover you have a bug here. See my proposal at the top of this message.
I guess you mean that it doesn’t check for errors returned?

> And now even better to ask, why platform_get_irq() wouldn't work for DT
> case?
The problem is that the interrupts are defined in the port sub-node in DT,
not in the gpio controller node, causing platform_get_irq() to fail. The
port sub-node doesn’t have an associated platform device. I don’t think
there is a way around this...

> > +
> > +   if (!pp->has_irq)
> > dev_warn(dev, "no irq for port%d\n",
> > pp->idx);
> 
> This could be issued in the actual function which will try to allocate IRQs
> (perhaps on debug level)
> 
> 
> P.S. Just think about it, perhaps you find even better solutions.
There's certainly some duplication between DT and ACPI that can be removed.

Thanks
Phil

Re: [PATCH v9 00/12] Sunxi: Add SMP support on A83T

[Maxime Ripard]

Hi!

On Tue, May 08, 2018 at 10:11:07AM -0700, Florian Fainelli wrote:
> On 05/08/2018 06:19 AM, Maxime Ripard wrote:
> > Hi,
> > 
> > On Fri, May 04, 2018 at 09:05:33PM +0200, Mylène Josserand wrote:
> >> Hello everyone,
> >>
> >> This is a V9 of my series that adds SMP support for Allwinner sun8i-a83t.
> >> Based on sunxi's tree, sunxi/for-next branch.
> >> Depends on a patch from Doug Berger that allows to include the "cpu-type"
> >> header on assembly files that I included in my series (patch 01).
> > 
> > I applied the patches, with the remarks done by Russell on v8 fixed,
> > and the function sun8i_a83t_cntvoff_init made static.
> 
> Did you push those patches to sunxi/linux.git yet? I would like to make
> sure I have the same copy of patch 1 since that is necessary for some of
> our Broadcom ARM SoCs for 4.18.

I forgot, I just did. I tested to merge the latest next tag though,
and it went fine without any conflicts, so I guess we're fine?

Maxime


-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature