RE: [PATCH 1/2] clk: renesas: Add r8a77990 CPG Core Clock Definitions

[Yoshihiro Shimoda]

Hi Geert-san,

Thank you for the review!

> From: Geert Uytterhoeven, Sent: Thursday, April 12, 2018 9:23 PM
> 
> Hi Shimoda-san,
> 
> On Wed, Apr 11, 2018 at 11:37 AM, Yoshihiro Shimoda
>  wrote:

> > --- /dev/null
> > +++ b/include/dt-bindings/clock/r8a77990-cpg-mssr.h
> > @@ -0,0 +1,63 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2018 Renesas Electronics Corp.
> > + */
> > +#ifndef __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
> > +#define __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
> > +
> > +#include 
> > +
> > +/* r8a77990 CPG Core Clocks */
> 
> [...]
> 
> > +#define R8A77990_CLK_CSI0  47
> 
> Note that CSI0 is not listed in Table 8.2g ("R-Car E3").
> Probably it does exist, given:
>   - Table 8.11 ("Register Configuration") says CSI0CKCR exists on R-Car E3,
>   - Figure 25.6 ("CSI2 Block Diagram (R-Car E3)") shows CSI0.

I think so. I'm asking HW team about missing CSI0 in Table 8.2g now.

> > +#define R8A77990_CLK_POST3 48
> 
> I noticed these POSTx clocks have been added to all R-Car Gen3 clock tables.
> It doesn't look like we will ever need to refer them from DT, so I think we
> can treat them as internal clocks, and omit them from the DT bindings.
> 
> What do you think?

I agree with you. So, I will omit POSTx clocks from the DT bindings in v2 patch.

Best regards,
Yoshihiro Shimoda

Re: [PATCH] extcon: int3496: use proper GPIO include

[Chanwoo Choi]

On 2018년 04월 13일 10:09, Chanwoo Choi wrote:
> Hi,
> 
> On 2018년 04월 10일 21:43, Wolfram Sang wrote:
>> Since commit eca0f13c836a ("extcon: int3496: Ignore incorrect
>> IoRestriction for ID pin"), the driver doesn't use GPIOF_* flags
>> anymore. We can thus now drop the deprecated include file for GPIO and
>> use the new one.
> 
> Looks good to me. But, you need to send stable mailing list
> and add 'Fixes' tag on v2.

You don't need to send stable mailing list. It is my mistake.
Just I'll pick this patch on extcon-fixes branch.

> 
>>
>> Signed-off-by: Wolfram Sang 
>> ---
>>
>> Compile tested only.
>>
>> @linusw: one more gone
>>
>>  drivers/extcon/extcon-intel-int3496.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/extcon/extcon-intel-int3496.c 
>> b/drivers/extcon/extcon-intel-int3496.c
>> index acaccb128fc4..fd24debe58a3 100644
>> --- a/drivers/extcon/extcon-intel-int3496.c
>> +++ b/drivers/extcon/extcon-intel-int3496.c
>> @@ -20,7 +20,7 @@
>>  
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] extcon: int3496: use proper GPIO include

[Chanwoo Choi]

Hi,

On 2018년 04월 10일 21:43, Wolfram Sang wrote:
> Since commit eca0f13c836a ("extcon: int3496: Ignore incorrect
> IoRestriction for ID pin"), the driver doesn't use GPIOF_* flags
> anymore. We can thus now drop the deprecated include file for GPIO and
> use the new one.

Looks good to me. But, you need to send stable mailing list
and add 'Fixes' tag on v2.

> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Compile tested only.
> 
> @linusw: one more gone
> 
>  drivers/extcon/extcon-intel-int3496.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon-intel-int3496.c 
> b/drivers/extcon/extcon-intel-int3496.c
> index acaccb128fc4..fd24debe58a3 100644
> --- a/drivers/extcon/extcon-intel-int3496.c
> +++ b/drivers/extcon/extcon-intel-int3496.c
> @@ -20,7 +20,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

[Niklas Söderlund]

Hi Vincent,

Thanks for helping trying to figure this out.

On 2018-04-12 15:30:31 +0200, Vincent Guittot wrote:

[snip]

> 
> I'd like to narrow the problem a bit more with the 2 patchies aboves. Can you 
> try
> them separatly on top of c18bb396d3d261eb ("Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"))
> and check if one of them fixes the problem ?i

I tried your suggested changes based on top of c18bb396d3d261eb.

> 
> (They should apply on linux-next as well)
> 
> First patch always kick ilb instead of doing ilb on local cpu before entering 
> idle
> 
> ---
>  kernel/sched/fair.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 0951d1c..b21925b 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -9739,8 +9739,7 @@ static void nohz_newidle_balance(struct rq *this_rq)
>* candidate for ilb instead of waking up another idle CPU.
>* Kick an normal ilb if we failed to do the update.
>*/
> - if (!_nohz_idle_balance(this_rq, NOHZ_STATS_KICK, CPU_NEWLY_IDLE))
> - kick_ilb(NOHZ_STATS_KICK);
> + kick_ilb(NOHZ_STATS_KICK);
>   raw_spin_lock(_rq->lock);
>  }

This change don't seem to effect the issue. I can still get the single 
ssh session and the system to lockup by hitting the return key. And 
opening a second ssh session immediately unblocks both the first ssh 
session and the serial console. And I can still trigger the console 
warning by just letting the system be once it locks-up. I do have 
just as before reset the system a few times to trigger the issue.

[  245.351693] INFO: rcu_sched detected stalls on CPUs/tasks:
[  245.357199]  0-...!: (1 GPs behind) idle=93c/0/0 softirq=2224/2225 fqs=0 
[  245.363988]  (detected by 1, t=3025 jiffies, g=337, c=336, q=10)
[  245.370003] Sending NMI from CPU 1 to CPUs 0:
[  245.374368] NMI backtrace for cpu 0
[  245.374377] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.16.0-10930-ged741fb4567c816f #42
[  245.374379] Hardware name: Generic R8A7791 (Flattened Device Tree)
[  245.374393] PC is at arch_cpu_idle+0x24/0x40
[  245.374397] LR is at arch_cpu_idle+0x34/0x40
[  245.374400] pc : []lr : []psr: 60050013
[  245.374403] sp : c0b01f40  ip : c0b01f50  fp : c0b01f4c
[  245.374405] r10: c0a56a38  r9 : e7fffbc0  r8 : c0b04c00
[  245.374407] r7 : c0b04c78  r6 : c0b04c2c  r5 : e000  r4 : 0001
[  245.374410] r3 : c0119100  r2 : e77813a8  r1 : 0002d93c  r0 : 
[  245.374414] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  245.374417] Control: 10c5387d  Table: 6662006a  DAC: 0051
[  245.374421] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.16.0-10930-ged741fb4567c816f #42
[  245.374423] Hardware name: Generic R8A7791 (Flattened Device Tree)
[  245.374425] Backtrace: 
[  245.374435] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[  245.374440]  r7:c0b47278 r6:60050193 r5: r4:c0b73d80
[  245.374450] [] (show_stack) from [] 
(dump_stack+0x84/0xa4)
[  245.374456] [] (dump_stack) from [] (show_regs+0x14/0x18)
[  245.374460]  r7:c0b47278 r6:c0b01ef0 r5: r4:c0bc62c8
[  245.374468] [] (show_regs) from [] 
(nmi_cpu_backtrace+0xfc/0x118)
[  245.374475] [] (nmi_cpu_backtrace) from [] 
(handle_IPI+0x22c/0x294)
[  245.374479]  r7:c0b47278 r6:c0b01ef0 r5:0007 r4:c0a775fc
[  245.374488] [] (handle_IPI) from [] 
(gic_handle_irq+0x8c/0x98)
[  245.374492]  r10:c0a56a38 r9:c0b0 r8:f0803000 r7:c0b47278 r6:c0b01ef0 
r5:c0b05244
[  245.374495]  r4:f0802000 r3:0407
[  245.374501] [] (gic_handle_irq) from [] 
(__irq_svc+0x6c/0x90)
[  245.374504] Exception stack(0xc0b01ef0 to 0xc0b01f38)
[  245.374507] 1ee0:  0002d93c 
e77813a8 c0119100
[  245.374512] 1f00: 0001 e000 c0b04c2c c0b04c78 c0b04c00 e7fffbc0 
c0a56a38 c0b01f4c
[  245.374516] 1f20: c0b01f50 c0b01f40 c0108564 c0108554 60050013 
[  245.374521]  r9:c0b0 r8:c0b04c00 r7:c0b01f24 r6: r5:60050013 
r4:c0108554
[  245.374528] [] (arch_cpu_idle) from [] 
(default_idle_call+0x30/0x34)
[  245.374535] [] (default_idle_call) from [] 
(do_idle+0xd8/0x128)
[  245.374540] [] (do_idle) from [] 
(cpu_startup_entry+0x20/0x24)
[  245.374543]  r7:c0b04c08 r6: r5:c0b80380 r4:00c2
[  245.374549] [] (cpu_startup_entry) from [] 
(rest_init+0x9c/0xbc)
[  245.374555] [] (rest_init) from [] 
(start_kernel+0x368/0x3ec)
[  245.374558]  r5:c0b80380 r4:c0b803c0
[  245.374563] [] (start_kernel) from [<>] (  (null))
[  245.375369] rcu_sched kthread starved for 3028 jiffies! g337 c336 f0x0 
RCU_GP_WAIT_FQS(3) ->state=0x402 ->cpu=1
[  245.641242] RCU grace-period kthread stack dump:
[  245.645859] rcu_sched   I0 9  2 0x
[  245.651350] Backtrace: 
[  245.653804] [] (__schedule) from [] (schedule+0x94/0xb8)
[  245.660857]  r10:e77903c0 r9:e77903c0 r8: r7:e709bed4 r6:ded7 
r5:
[  245.668689]  r4:e000
[  

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

[Niklas Söderlund]

Hi Vincent,

On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote:
[snip[

> 
> Can you send me your config ?
> 
> I'm going to prepare a debug patch to spy what's happening when entering idle

I'm sorry i missed this request when first reading your reply, I'm using
arch/arm/configs/shmobile_defconfig for my tests.

-- 
Regards,
Niklas Söderlund

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

[Heiner Kallweit]

Am 12.04.2018 um 15:30 schrieb Vincent Guittot:
> Heiner, Niklas,
> 
> Le Thursday 12 Apr 2018 à 13:15:19 (+0200), Niklas Söderlund a écrit :
>> Hi Vincent,
>>
>> Thanks for your feedback.
>>
>> On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote:
>>> Hi Niklas,
>>>
>>> On 12 April 2018 at 11:18, Niklas Söderlund
>>>  wrote:
 Hi Vincent,

 I have observed issues running on linus/master from a few days back [1].
 I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue
 by X forwarding the v4l2 test application qv4l2 over ssh and moving the
 courser around in the GUI (best test case description award...). I'm
 sorry about the really bad way I trigger this but I can't do it in any
 other way, I'm happy to try other methods if you got some ideas. The
 symptom of the issue is a complete hang of the system for more then 30
 seconds and then this information is printed in the console:
>>>
>>> Heiner (edded cc) also reported similar problem with his platform: a
>>> dual core celeron
>>>
>>> Do you confirm that your platform is a dual cortex-A15 ? At least that
>>> what I have seen on web
>>> This would confirm that dual system is a key point.
>>
>> I can confirm that my platform is a dual core.
>>
>>>
>>> The ssh connection is also common with Heiner's setup
>>
>> Interesting, I found Heiner's mail and I can confirm that I too 
>> experience ssh sessions lockups. I ssh into the system and by repeatedly 
>> hitting the return key I can lockup the board, while locked up starting 
>> another ssh session unblocks the first. If I don't start another ssh 
>> session but keep hitting return key sporadically in the first one I can 
>> get the trace I reported in my first mail to be printed on the serial 
>> console.
>>
>> When locked up the symptoms are that both the single ssh session is dead 
>> and the serial console. But attempting another ssh connection 
>> immediately unblocks both ssh and serial console. And if I allow enough 
>> time before starting the second ssh connection I can trigger a trace to 
>> be printed on the serial console, it's similar but different from the 
>> first I reported.
>>
>> [  207.548610]   1-...!: (0 ticks this GP) idle=79a/1/1073741824 
>> softirq=2146/2146 fqs=0 
>> [  207.556442]   (detected by 0, t=12645 jiffies, g=333, c=332, q=20)
>> [  207.562546] rcu_sched kthread starved for 12645 jiffies! g333 c332 f0x2 
>> RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
>> [  207.572548] RCU grace-period kthread stack dump:
>>
>> [  207.577166] rcu_sched   R  running task0 9  2 
>> 0x
>> [  207.584389] Backtrace: 
>> [  207.586849] [] (__schedule) from [] 
>> (schedule+0x94/0xb8)
>> [  207.593901]  r10:e77813c0 r9:e77813c0 r8: r7:e709bed4 r6:aa80 
>> r5:
>> [  207.601732]  r4:e000
>> [  207.604269] [] (schedule) from [] 
>> (schedule_timeout+0x380/0x3dc)
>> [  207.612013]  r5: r4:
>> [  207.615596] [] (schedule_timeout) from [] 
>> (rcu_gp_kthread+0x668/0xe2c)
>> [  207.623863]  r10:c0b79018 r9:014d r8:014c r7:0001 r6: 
>> r5:c0b10ad0
>> [  207.631693]  r4:c0b10980
>> [  207.634230] [] (rcu_gp_kthread) from [] 
>> (kthread+0x148/0x160)
>> [  207.641712]  r7:c0b10980
>> [  207.644249] [] (kthread) from [] 
>> (ret_from_fork+0x14/0x2c)
>> [  207.651472] Exception stack(0xe709bfb0 to 0xe709bff8)
>> [  207.656527] bfa0:   
>>  
>> [  207.664709] bfc0:       
>>  
>> [  207.672890] bfe0:     0013 
>> [  207.679508]  r10: r9: r8: r7: r6: 
>> r5:c013dc90
>> [  207.687340]  r4:e7026f4
>>
>> Continuing the anecdotal testing, I can't seem to be able to trigger the 
>> lockup if i have ever had two ssh sessions open to the systems. And 
>> about half the time I can't trigger it at all but after a reset of the 
>> system it triggers with just hitting the return key 2-5 times of opening 
>> a ssh session and just hitting the return key. But please take this part 
>> with a grain of salt as it's done by the monkey testing method :-)
>>
>> All tests above have been run base on c18bb396d3d261eb ("Merge 
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net").
>>
>>>

> 
> [snip]
> 

 I'm a bit lost on how to progress with this issue and would appreciate
 any help you can provide to help me figure this out.
>>>
>>> Can you send me your config ?
>>>
>>> I'm going to prepare a debug patch to spy what's happening when entering 
>>> idle
> 
> I'd like to narrow the problem a bit more with the 2 patchies aboves. Can you 
> try
> them separatly on top of c18bb396d3d261eb ("Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"))
> and check if one of them fixes the problem ?i
> 
> (They should apply 

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Geert Uytterhoeven]

Hi Philipp,

On Thu, Apr 12, 2018 at 4:10 PM, Philipp Zabel  wrote:
> On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
>> On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya  wrote:
>> > On 4/12/2018 7:49 AM, Auger Eric wrote:
>> > > On 12/04/18 13:32, Geert Uytterhoeven wrote:
>> > > > On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  
>> > > > wrote:
>> > > > > On 11/04/18 11:15, Geert Uytterhoeven wrote:
>> > > > > > Vfio-platform requires reset support, provided either by ACPI, or, 
>> > > > > > on DT
>> > > > > > platforms, by a device-specific reset driver matching against the
>> > > > > > device's compatible value.
>> > > > > >
>> > > > > > On many SoCs, devices are connected to an SoC-internal reset 
>> > > > > > controller.
>> > > > > > If the reset hierarchy is described in DT using "resets" 
>> > > > > > properties,
>> > > > > > such devices can be reset in a generic way through the reset 
>> > > > > > controller
>> > > > > > subsystem.  Hence add support for this, avoiding the need to write
>> > > > > > device-specific reset drivers for each single device on affected 
>> > > > > > SoCs.
>> > > > > >
>> > > > > > Devices that do require a more complex reset procedure can still 
>> > > > > > provide
>> > > > > > a device-specific reset driver, as that takes precedence.
>> > > > > >
>> > > > > > Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, 
>> > > > > > and
>> > > > > > becomes a no-op (as in: "No reset function found for device") if 
>> > > > > > reset
>> > > > > > controller support is disabled.
>> > > > > >
>> > > > > > Signed-off-by: Geert Uytterhoeven 
>> > > > > > Reviewed-by: Philipp Zabel 
>> > > > > > --- a/drivers/vfio/platform/vfio_platform_common.c
>> > > > > > +++ b/drivers/vfio/platform/vfio_platform_common.c
>> > > > > > @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
>> > > > > > vfio_platform_device *vdev)
>> > > > > >   vdev->of_reset = 
>> > > > > > vfio_platform_lookup_reset(vdev->compat,
>> > > > > >   
>> > > > > > >reset_module);
>> > > > > >   }
>> > > > > > + if (vdev->of_reset)
>> > > > > > + return 0;
>> > > > > > +
>> > > > > > + rstc = of_reset_control_get_exclusive(vdev->device->of_node, 
>> > > > > > NULL);
>> > > > >
>> > > > > Shouldn't we prefer the top level reset_control_get_exclusive()?
>> > > >
>> > > > I guess that should work, too.
>> > > >
>> > > > > To make sure about the exclusive/shared terminology, does
>> > > > > get_reset_control_get_exclusive() check we have an exclusive wire
>> > > > > between this device and the reset controller?
>> > > >
>> > > > AFAIU, the "exclusive" means that only a single user can obtain access 
>> > > > to
>> > > > the reset, and it does not guarantee that we have an exclusive wire 
>> > > > between
>> > > > the device and the reset controller.
>> > > >
>> > > > The latter depends on the SoC's reset topology. If a reset wire is 
>> > > > shared
>> > > > by multiple devices (e.g. resets shared by PWM or Display Unit devices 
>> > > > on
>> > > > R-Car SoCs), exporting a subset of these devices to a guest is a bad 
>> > > > idea,
>> > > > indeed.
>> > >
>> > > So who's going to check this assigned device will not trigger a reset of
>> > > other non assigned devices sharing the same reset controller?
>
> If the reset control is requested as exclusive, any other driver
> requesting the same reset control will fail (or this reset_control_get
> will fail, whichever comes last).
>
>> > I like the direction in general. I was hoping that you'd call it 
>> > of_reset_control
>> > rather than reset_control.
>>
>> You mean vfio_platform_device.of_reset_control?
>> If we switch to reset_control_get_exclusive(), that doesn't make much 
>> sense...
>>
>> > Is there anything in the OF spec about what to expect from DT's reset?
>>
>> Documentation/devicetree/bindings/reset/reset.txt says:
>>
>> "A word on where to place reset signal consumers in device tree: It is 
>> possible
>>  in hardware for a reset signal to affect multiple logically separate HW 
>> blocks
>>  at once. In this case, it would be unwise to represent this reset signal in
>>  the DT node of each affected HW block, since if activated, an unrelated 
>> block
>>  may be reset. Instead, reset signals should be represented in the DT node
>>  where it makes most sense to control it; this may be a bus node if all
>>  children of the bus are affected by the reset signal, or an individual HW
>>  block node for dedicated reset signals. The intent of this binding is to 
>> give
>>  appropriate software access to the reset signals in order to manage the HW,
>>  rather than to slavishly enumerate the reset signal that affects each HW
>>  block."
>
> This was written in 2012, and unfortunately the DT binding documentation
> does not inform 

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Philipp Zabel]

On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
> Hi Sinan,
> 
> On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya  wrote:
> > On 4/12/2018 7:49 AM, Auger Eric wrote:
> > > On 12/04/18 13:32, Geert Uytterhoeven wrote:
> > > > On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  
> > > > wrote:
> > > > > On 11/04/18 11:15, Geert Uytterhoeven wrote:
> > > > > > Vfio-platform requires reset support, provided either by ACPI, or, 
> > > > > > on DT
> > > > > > platforms, by a device-specific reset driver matching against the
> > > > > > device's compatible value.
> > > > > > 
> > > > > > On many SoCs, devices are connected to an SoC-internal reset 
> > > > > > controller.
> > > > > > If the reset hierarchy is described in DT using "resets" properties,
> > > > > > such devices can be reset in a generic way through the reset 
> > > > > > controller
> > > > > > subsystem.  Hence add support for this, avoiding the need to write
> > > > > > device-specific reset drivers for each single device on affected 
> > > > > > SoCs.
> > > > > > 
> > > > > > Devices that do require a more complex reset procedure can still 
> > > > > > provide
> > > > > > a device-specific reset driver, as that takes precedence.
> > > > > > 
> > > > > > Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, 
> > > > > > and
> > > > > > becomes a no-op (as in: "No reset function found for device") if 
> > > > > > reset
> > > > > > controller support is disabled.
> > > > > > 
> > > > > > Signed-off-by: Geert Uytterhoeven 
> > > > > > Reviewed-by: Philipp Zabel 
> > > > > > --- a/drivers/vfio/platform/vfio_platform_common.c
> > > > > > +++ b/drivers/vfio/platform/vfio_platform_common.c
> > > > > > @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
> > > > > > vfio_platform_device *vdev)
> > > > > >   vdev->of_reset = 
> > > > > > vfio_platform_lookup_reset(vdev->compat,
> > > > > >   
> > > > > > >reset_module);
> > > > > >   }
> > > > > > + if (vdev->of_reset)
> > > > > > + return 0;
> > > > > > +
> > > > > > + rstc = of_reset_control_get_exclusive(vdev->device->of_node, 
> > > > > > NULL);
> > > > > 
> > > > > Shouldn't we prefer the top level reset_control_get_exclusive()?
> > > > 
> > > > I guess that should work, too.
> > > > 
> > > > > To make sure about the exclusive/shared terminology, does
> > > > > get_reset_control_get_exclusive() check we have an exclusive wire
> > > > > between this device and the reset controller?
> > > > 
> > > > AFAIU, the "exclusive" means that only a single user can obtain access 
> > > > to
> > > > the reset, and it does not guarantee that we have an exclusive wire 
> > > > between
> > > > the device and the reset controller.
> > > > 
> > > > The latter depends on the SoC's reset topology. If a reset wire is 
> > > > shared
> > > > by multiple devices (e.g. resets shared by PWM or Display Unit devices 
> > > > on
> > > > R-Car SoCs), exporting a subset of these devices to a guest is a bad 
> > > > idea,
> > > > indeed.
> > > 
> > > So who's going to check this assigned device will not trigger a reset of
> > > other non assigned devices sharing the same reset controller?

If the reset control is requested as exclusive, any other driver
requesting the same reset control will fail (or this reset_control_get
will fail, whichever comes last).

> > I like the direction in general. I was hoping that you'd call it 
> > of_reset_control
> > rather than reset_control.
> 
> You mean vfio_platform_device.of_reset_control?
> If we switch to reset_control_get_exclusive(), that doesn't make much sense...
> 
> > Is there anything in the OF spec about what to expect from DT's reset?
> 
> Documentation/devicetree/bindings/reset/reset.txt says:
> 
> "A word on where to place reset signal consumers in device tree: It is 
> possible
>  in hardware for a reset signal to affect multiple logically separate HW 
> blocks
>  at once. In this case, it would be unwise to represent this reset signal in
>  the DT node of each affected HW block, since if activated, an unrelated block
>  may be reset. Instead, reset signals should be represented in the DT node
>  where it makes most sense to control it; this may be a bus node if all
>  children of the bus are affected by the reset signal, or an individual HW
>  block node for dedicated reset signals. The intent of this binding is to give
>  appropriate software access to the reset signals in order to manage the HW,
>  rather than to slavishly enumerate the reset signal that affects each HW
>  block."

This was written in 2012, and unfortunately the DT binding documentation
does not inform hardware development, and has not been updated since.

There's generally two kinds of reset uses:
- either to bring a device into a known state at a given point in time,
  which is often done using a timed 

[PATCH qemu v3] device_tree: Increase FDT_MAX_SIZE to 1 MiB

[Geert Uytterhoeven]

It is not uncommon for a contemporary FDT to be larger than 64 KiB,
leading to failures loading the device tree from sysfs:

qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE

Hence increase the limit to 1 MiB, like on PPC.

For reference, the largest arm64 DTB created from the Linux sources is
ca. 75 KiB large (100 KiB when built with symbols/fixup support).

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Update example size figures,

v2:
  - Enlarge from 128 KiB to 1 MiB, as suggested by Peter Maydell.
---
 device_tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/device_tree.c b/device_tree.c
index 19458b32bf81e55e..52c3358a55838d33 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -29,7 +29,7 @@
 
 #include 
 
-#define FDT_MAX_SIZE  0x1
+#define FDT_MAX_SIZE  0x10
 
 void *create_device_tree(int *sizep)
 {
-- 
2.7.4

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Geert Uytterhoeven]

Hi Sinan,

On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya  wrote:
> On 4/12/2018 7:49 AM, Auger Eric wrote:
>> On 12/04/18 13:32, Geert Uytterhoeven wrote:
>>> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  wrote:
 On 11/04/18 11:15, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
>
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem.  Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
>
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
>
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
>
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Philipp Zabel 
>>>
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
>>>
> @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
> vfio_platform_device *vdev)
>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>   
> >reset_module);
>   }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);

 Shouldn't we prefer the top level reset_control_get_exclusive()?
>>>
>>> I guess that should work, too.
>>>
 To make sure about the exclusive/shared terminology, does
 get_reset_control_get_exclusive() check we have an exclusive wire
 between this device and the reset controller?
>>>
>>> AFAIU, the "exclusive" means that only a single user can obtain access to
>>> the reset, and it does not guarantee that we have an exclusive wire between
>>> the device and the reset controller.
>>>
>>> The latter depends on the SoC's reset topology. If a reset wire is shared
>>> by multiple devices (e.g. resets shared by PWM or Display Unit devices on
>>> R-Car SoCs), exporting a subset of these devices to a guest is a bad idea,
>>> indeed.
>>
>> So who's going to check this assigned device will not trigger a reset of
>> other non assigned devices sharing the same reset controller?
>
> I like the direction in general. I was hoping that you'd call it 
> of_reset_control
> rather than reset_control.

You mean vfio_platform_device.of_reset_control?
If we switch to reset_control_get_exclusive(), that doesn't make much sense...

> Is there anything in the OF spec about what to expect from DT's reset?

Documentation/devicetree/bindings/reset/reset.txt says:

"A word on where to place reset signal consumers in device tree: It is possible
 in hardware for a reset signal to affect multiple logically separate HW blocks
 at once. In this case, it would be unwise to represent this reset signal in
 the DT node of each affected HW block, since if activated, an unrelated block
 may be reset. Instead, reset signals should be represented in the DT node
 where it makes most sense to control it; this may be a bus node if all
 children of the bus are affected by the reset signal, or an individual HW
 block node for dedicated reset signals. The intent of this binding is to give
 appropriate software access to the reset signals in order to manage the HW,
 rather than to slavishly enumerate the reset signal that affects each HW
 block."

So according to the bindings, a specific reset should apply to a single
device only.

A quick check shows there are several violators:

$ for i in $(git grep -lw resets -- "*dts*"); do grep -w resets $i |
sort | uniq -c | sed -e "s@^@$i:@g"; done | grep -v ":  1 "
arch/arm/boot/dts/aspeed-g4.dtsi: 14 resets = < ASPEED_RESET_I2C>;
arch/arm/boot/dts/aspeed-g5.dtsi: 14 resets = < ASPEED_RESET_I2C>;
arch/arm/boot/dts/atlas7.dtsi:  2 resets = < 29>;
arch/arm/boot/dts/gemini.dtsi:  2 resets = < GEMINI_RESET_IDE>;
arch/arm/boot/dts/meson8.dtsi:  2 resets = < RESET_USB_OTG>;
arch/arm/boot/dts/meson8b.dtsi:  2 resets = < RESET_USB_OTG>;
arch/arm/boot/dts/r8a7743.dtsi:  7 resets = < 523>;
arch/arm/boot/dts/r8a7743.dtsi:  2 resets = < 703>;
arch/arm/boot/dts/r8a7743.dtsi:  2 resets = < 704>;
arch/arm/boot/dts/r8a7745.dtsi:  7 resets = < 523>;
arch/arm/boot/dts/r8a7745.dtsi:  2 resets = < 703>;
arch/arm/boot/dts/r8a7745.dtsi:  2 resets = < 704>;
arch/arm/boot/dts/r8a7790.dtsi:  

Re: [PATCH/RFC 3/5] hw/arm/virt: Allow dynamic sysbus devices again

[Geert Uytterhoeven]

Hi Eric,

On Wed, Feb 14, 2018 at 11:37 AM, Auger Eric  wrote:
> On 09/02/18 16:17, Geert Uytterhoeven wrote:
>> Allow the instantation of generic dynamic sysbus devices again, without
>> the need to create a new device-specific vfio type.
>>
>> This is a partial revert of commit  6f2062b9758ebc64 ("hw/arm/virt:
>> Allow only supported dynamic sysbus devices").
>>
>> Not-Yet-Signed-off-by: Geert Uytterhoeven 
>> ---
>>  hw/arm/virt.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index b334c82edae9fb1f..fa83784fc08ed076 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -1596,6 +1596,7 @@ static void virt_machine_class_init(ObjectClass *oc, 
>> void *data)
>>  mc->max_cpus = 255;
>>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
>>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
>> +machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
> Couldn't you limit that to TYPE_VFIO_PLATFORM instead?

Yep, that works. 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 v3 2/2] vfio: platform: Add generic DT reset support

[Sinan Kaya]

On 4/12/2018 7:49 AM, Auger Eric wrote:
> Hi Geert,
> On 12/04/18 13:32, Geert Uytterhoeven wrote:
>> Hi Eric,
>>
>> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  wrote:
>>> On 11/04/18 11:15, Geert Uytterhoeven wrote:
 Vfio-platform requires reset support, provided either by ACPI, or, on DT
 platforms, by a device-specific reset driver matching against the
 device's compatible value.

 On many SoCs, devices are connected to an SoC-internal reset controller.
 If the reset hierarchy is described in DT using "resets" properties,
 such devices can be reset in a generic way through the reset controller
 subsystem.  Hence add support for this, avoiding the need to write
 device-specific reset drivers for each single device on affected SoCs.

 Devices that do require a more complex reset procedure can still provide
 a device-specific reset driver, as that takes precedence.

 Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
 becomes a no-op (as in: "No reset function found for device") if reset
 controller support is disabled.

 Signed-off-by: Geert Uytterhoeven 
 Reviewed-by: Philipp Zabel 
>>
 --- a/drivers/vfio/platform/vfio_platform_common.c
 +++ b/drivers/vfio/platform/vfio_platform_common.c
>>
 @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
 vfio_platform_device *vdev)
   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
   >reset_module);
   }
 + if (vdev->of_reset)
 + return 0;
 +
 + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
>>>
>>> Shouldn't we prefer the top level reset_control_get_exclusive()?
>>
>> I guess that should work, too.
>>
>>> To make sure about the exclusive/shared terminology, does
>>> get_reset_control_get_exclusive() check we have an exclusive wire
>>> between this device and the reset controller?
>>
>> AFAIU, the "exclusive" means that only a single user can obtain access to
>> the reset, and it does not guarantee that we have an exclusive wire between
>> the device and the reset controller.
>>
>> The latter depends on the SoC's reset topology. If a reset wire is shared
>> by multiple devices (e.g. resets shared by PWM or Display Unit devices on
>> R-Car SoCs), exporting a subset of these devices to a guest is a bad idea,
>> indeed.
> 
> So who's going to check this assigned device will not trigger a reset of
> other non assigned devices sharing the same reset controller?

I like the direction in general. I was hoping that you'd call it 
of_reset_control
rather than reset_control.

Is there anything in the OF spec about what to expect from DT's reset?

> 
>>
>> I guess the same thing can happen with the ACPI "_RST" method?
> 
> ACPI spec _RST chapter says about _RST object:
> 
> "This object executes a reset on the associated device
>  or devices. If included in a device context, the
> reset must not affect any other ACPI-described de
> vices; if included in a power resource for reset
> (_PRR, Section 7.3.26) the reset must affect all ACPI-described devices
> that reference it. When this object is described in
> a device context, it executes a function level reset that only affects
> the device it is associated with; neither parent nor children should be
> affected by the execution of this reset. Executing this must only result
> in this device resetting without the device appearing as if it
> has been removed from the bus altogether, to prevent OSPM re-enumeration
> of devices on hot-pluggable buses (e.g. USB)."

ACPI spec is clear. We are doing a device specific reset aka function level
reset here. It does not impact other devices in the system. 

In fact, ACPI does not have a clock controller concept. All clock/reset details
are hidden from the OS.

> 
> Adding Sinan in copy for clarification.
> 
> Thanks
> 
> Eric
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH 1/2] clk: renesas: Add r8a77990 CPG Core Clock Definitions

[Geert Uytterhoeven]

Hi Shimoda-san,

On Wed, Apr 11, 2018 at 11:37 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds all R-Car E3 Clock Pulse Generator Core Clock Outputs.
>
> Note that internal CPG clocks (S0, S1, S2, S3, SDSRC) are not included,
> as they are used as internal clock sources only, and never referenced
> from DT.
>
> Signed-off-by: Takeshi Kihara 
> [shimoda: add SPDX-License-Identifier]
> Signed-off-by: Yoshihiro Shimoda 

Thanks for your patch!

> --- /dev/null
> +++ b/include/dt-bindings/clock/r8a77990-cpg-mssr.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + */
> +#ifndef __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
> +#define __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
> +
> +#include 
> +
> +/* r8a77990 CPG Core Clocks */

[...]

> +#define R8A77990_CLK_CSI0  47

Note that CSI0 is not listed in Table 8.2g ("R-Car E3").
Probably it does exist, given:
  - Table 8.11 ("Register Configuration") says CSI0CKCR exists on R-Car E3,
  - Figure 25.6 ("CSI2 Block Diagram (R-Car E3)") shows CSI0.

> +#define R8A77990_CLK_POST3 48

I noticed these POSTx clocks have been added to all R-Car Gen3 clock tables.
It doesn't look like we will ever need to refer them from DT, so I think we
can treat them as internal clocks, and omit them from the DT bindings.

What do you think?
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 v3 2/2] vfio: platform: Add generic DT reset support

[Auger Eric]

Hi Geert,
On 12/04/18 13:32, Geert Uytterhoeven wrote:
> Hi Eric,
> 
> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  wrote:
>> On 11/04/18 11:15, Geert Uytterhoeven wrote:
>>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>>> platforms, by a device-specific reset driver matching against the
>>> device's compatible value.
>>>
>>> On many SoCs, devices are connected to an SoC-internal reset controller.
>>> If the reset hierarchy is described in DT using "resets" properties,
>>> such devices can be reset in a generic way through the reset controller
>>> subsystem.  Hence add support for this, avoiding the need to write
>>> device-specific reset drivers for each single device on affected SoCs.
>>>
>>> Devices that do require a more complex reset procedure can still provide
>>> a device-specific reset driver, as that takes precedence.
>>>
>>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>>> becomes a no-op (as in: "No reset function found for device") if reset
>>> controller support is disabled.
>>>
>>> Signed-off-by: Geert Uytterhoeven 
>>> Reviewed-by: Philipp Zabel 
> 
>>> --- a/drivers/vfio/platform/vfio_platform_common.c
>>> +++ b/drivers/vfio/platform/vfio_platform_common.c
> 
>>> @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
>>> vfio_platform_device *vdev)
>>>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>>>   >reset_module);
>>>   }
>>> + if (vdev->of_reset)
>>> + return 0;
>>> +
>>> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
>>
>> Shouldn't we prefer the top level reset_control_get_exclusive()?
> 
> I guess that should work, too.
> 
>> To make sure about the exclusive/shared terminology, does
>> get_reset_control_get_exclusive() check we have an exclusive wire
>> between this device and the reset controller?
> 
> AFAIU, the "exclusive" means that only a single user can obtain access to
> the reset, and it does not guarantee that we have an exclusive wire between
> the device and the reset controller.
> 
> The latter depends on the SoC's reset topology. If a reset wire is shared
> by multiple devices (e.g. resets shared by PWM or Display Unit devices on
> R-Car SoCs), exporting a subset of these devices to a guest is a bad idea,
> indeed.

So who's going to check this assigned device will not trigger a reset of
other non assigned devices sharing the same reset controller?

> 
> I guess the same thing can happen with the ACPI "_RST" method?

ACPI spec _RST chapter says about _RST object:

"This object executes a reset on the associated device
 or devices. If included in a device context, the
reset must not affect any other ACPI-described de
vices; if included in a power resource for reset
(_PRR, Section 7.3.26) the reset must affect all ACPI-described devices
that reference it. When this object is described in
a device context, it executes a function level reset that only affects
the device it is associated with; neither parent nor children should be
affected by the execution of this reset. Executing this must only result
in this device resetting without the device appearing as if it
has been removed from the bus altogether, to prevent OSPM re-enumeration
of devices on hot-pluggable buses (e.g. USB)."

Adding Sinan in copy for clarification.

Thanks

Eric
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

[Wolfram Sang]

On Thu, Apr 12, 2018 at 01:34:41PM +0200, Geert Uytterhoeven wrote:
> Hi Wolfram,
> 
> On Thu, Apr 12, 2018 at 1:31 PM, Wolfram Sang  wrote:
> >> That should have been caught by the !soc check above, and have already
> >> returned with -ENODEV.
> >
> > Now I get it: You mean non-0 check, not non-NULL check...
> 
> soc->data _is_ a pointer. You only cast it to an integer on the next line.

Yes. I usually worked with it as an integer, so I got confused. Will
fix.



signature.asc
Description: PGP signature

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Geert Uytterhoeven]

Hi Eric,

On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  wrote:
> On 11/04/18 11:15, Geert Uytterhoeven wrote:
>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>> platforms, by a device-specific reset driver matching against the
>> device's compatible value.
>>
>> On many SoCs, devices are connected to an SoC-internal reset controller.
>> If the reset hierarchy is described in DT using "resets" properties,
>> such devices can be reset in a generic way through the reset controller
>> subsystem.  Hence add support for this, avoiding the need to write
>> device-specific reset drivers for each single device on affected SoCs.
>>
>> Devices that do require a more complex reset procedure can still provide
>> a device-specific reset driver, as that takes precedence.
>>
>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>> becomes a no-op (as in: "No reset function found for device") if reset
>> controller support is disabled.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> Reviewed-by: Philipp Zabel 

>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c

>> @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
>> vfio_platform_device *vdev)
>>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>>   >reset_module);
>>   }
>> + if (vdev->of_reset)
>> + return 0;
>> +
>> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
>
> Shouldn't we prefer the top level reset_control_get_exclusive()?

I guess that should work, too.

> To make sure about the exclusive/shared terminology, does
> get_reset_control_get_exclusive() check we have an exclusive wire
> between this device and the reset controller?

AFAIU, the "exclusive" means that only a single user can obtain access to
the reset, and it does not guarantee that we have an exclusive wire between
the device and the reset controller.

The latter depends on the SoC's reset topology. If a reset wire is shared
by multiple devices (e.g. resets shared by PWM or Display Unit devices on
R-Car SoCs), exporting a subset of these devices to a guest is a bad idea,
indeed.

I guess the same thing can happen with the ACPI "_RST" method?

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/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

[Wolfram Sang]

> That should have been caught by the !soc check above, and have already
> returned with -ENODEV.

Now I get it: You mean non-0 check, not non-NULL check...



signature.asc
Description: PGP signature

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

[Geert Uytterhoeven]

Hi Wolfram,

On Thu, Apr 12, 2018 at 1:11 PM, Wolfram Sang  wrote:
>> > +   if (soc->data)
>>
>> This non-NULL check is not really needed.
>
> And if we match using the Gen3 generic compatible with a non-whitelisted
> SoC?

That should have been caught by the !soc check above, and have already
returned with -ENODEV.

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/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

[Wolfram Sang]

> > +static unsigned long global_flags;
> 
> Is the restriction on concurrent DMA RX streams global or per-device?

? Each device has only one DMA RX channel. Hey Simon, you upstreamed
this driver :) Or did I get the question wrong?

> > +   if (dir == DMA_FROM_DEVICE)
> > +   clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
> > +
> 
> Is clear_bit() expensive? If so it might be worth avoiding on SoCs that
> don't have the restriction covered by this patch.

It's an atoimc bitop, so maybe has a memory barrier. Hmm, the above
version is better on the cache lines, though, if you don't have the
restriction.

Will think about it and make sure both clear_bit() are in sync.



signature.asc
Description: PGP signature

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

[Niklas Söderlund]

Hi Vincent,

Thanks for your feedback.

On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote:
> Hi Niklas,
> 
> On 12 April 2018 at 11:18, Niklas Söderlund
>  wrote:
> > Hi Vincent,
> >
> > I have observed issues running on linus/master from a few days back [1].
> > I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue
> > by X forwarding the v4l2 test application qv4l2 over ssh and moving the
> > courser around in the GUI (best test case description award...). I'm
> > sorry about the really bad way I trigger this but I can't do it in any
> > other way, I'm happy to try other methods if you got some ideas. The
> > symptom of the issue is a complete hang of the system for more then 30
> > seconds and then this information is printed in the console:
> 
> Heiner (edded cc) also reported similar problem with his platform: a
> dual core celeron
> 
> Do you confirm that your platform is a dual cortex-A15 ? At least that
> what I have seen on web
> This would confirm that dual system is a key point.

I can confirm that my platform is a dual core.

> 
> The ssh connection is also common with Heiner's setup

Interesting, I found Heiner's mail and I can confirm that I too 
experience ssh sessions lockups. I ssh into the system and by repeatedly 
hitting the return key I can lockup the board, while locked up starting 
another ssh session unblocks the first. If I don't start another ssh 
session but keep hitting return key sporadically in the first one I can 
get the trace I reported in my first mail to be printed on the serial 
console.

When locked up the symptoms are that both the single ssh session is dead 
and the serial console. But attempting another ssh connection 
immediately unblocks both ssh and serial console. And if I allow enough 
time before starting the second ssh connection I can trigger a trace to 
be printed on the serial console, it's similar but different from the 
first I reported.

[  207.548610]  1-...!: (0 ticks this GP) idle=79a/1/1073741824 
softirq=2146/2146 fqs=0 
[  207.556442]  (detected by 0, t=12645 jiffies, g=333, c=332, q=20)
[  207.562546] rcu_sched kthread starved for 12645 jiffies! g333 c332 f0x2 
RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
[  207.572548] RCU grace-period kthread stack dump:

[  207.577166] rcu_sched   R  running task0 9  2 0x
[  207.584389] Backtrace: 
[  207.586849] [] (__schedule) from [] (schedule+0x94/0xb8)
[  207.593901]  r10:e77813c0 r9:e77813c0 r8: r7:e709bed4 r6:aa80 
r5:
[  207.601732]  r4:e000
[  207.604269] [] (schedule) from [] 
(schedule_timeout+0x380/0x3dc)
[  207.612013]  r5: r4:
[  207.615596] [] (schedule_timeout) from [] 
(rcu_gp_kthread+0x668/0xe2c)
[  207.623863]  r10:c0b79018 r9:014d r8:014c r7:0001 r6: 
r5:c0b10ad0
[  207.631693]  r4:c0b10980
[  207.634230] [] (rcu_gp_kthread) from [] 
(kthread+0x148/0x160)
[  207.641712]  r7:c0b10980
[  207.644249] [] (kthread) from [] 
(ret_from_fork+0x14/0x2c)
[  207.651472] Exception stack(0xe709bfb0 to 0xe709bff8)
[  207.656527] bfa0:   
 
[  207.664709] bfc0:       
 
[  207.672890] bfe0:     0013 
[  207.679508]  r10: r9: r8: r7: r6: 
r5:c013dc90
[  207.687340]  r4:e7026f4

Continuing the anecdotal testing, I can't seem to be able to trigger the 
lockup if i have ever had two ssh sessions open to the systems. And 
about half the time I can't trigger it at all but after a reset of the 
system it triggers with just hitting the return key 2-5 times of opening 
a ssh session and just hitting the return key. But please take this part 
with a grain of salt as it's done by the monkey testing method :-)

All tests above have been run base on c18bb396d3d261eb ("Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net").

> 
> >
> > [  142.849390] INFO: rcu_sched detected stalls on CPUs/tasks:
> > [  142.854972]  1-...!: (1 GPs behind) idle=7a4/0/0 softirq=3214/3217 fqs=0
> > [  142.861976]  (detected by 0, t=8232 jiffies, g=930, c=929, q=11)
> > [  142.868042] Sending NMI from CPU 0 to CPUs 1:
> > [  142.872443] NMI backtrace for cpu 1
> > [  142.872452] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> > 4.16.0-05506-g28aba11c1393691a #14
> > [  142.872455] Hardware name: Generic R8A7791 (Flattened Device Tree)
> > [  142.872473] PC is at arch_cpu_idle+0x28/0x44
> > [  142.872484] LR is at trace_hardirqs_on_caller+0x1a4/0x1d4
> > [  142.872488] pc : []lr : []psr: 20070013
> > [  142.872491] sp : eb0b9f90  ip : eb0b9f60  fp : eb0b9f9c
> > [  142.872495] r10:   r9 : 413fc0f2  r8 : 4000406a
> > [  142.872498] r7 : c0c08478  r6 : c0c0842c  r5 : e000  r4 : 0002
> > [  142.872502] r3 : eb0b6ec0  r2 :   r1 : 0004  r0 : 0001
> > [  

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

[Wolfram Sang]

> > +   if (soc->data)
> 
> This non-NULL check is not really needed.

And if we match using the Gen3 generic compatible with a non-whitelisted
SoC?



signature.asc
Description: PGP signature

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

[Vincent Guittot]

Hi Niklas,

On 12 April 2018 at 11:18, Niklas Söderlund
 wrote:
> Hi Vincent,
>
> I have observed issues running on linus/master from a few days back [1].
> I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue
> by X forwarding the v4l2 test application qv4l2 over ssh and moving the
> courser around in the GUI (best test case description award...). I'm
> sorry about the really bad way I trigger this but I can't do it in any
> other way, I'm happy to try other methods if you got some ideas. The
> symptom of the issue is a complete hang of the system for more then 30
> seconds and then this information is printed in the console:

Heiner (edded cc) also reported similar problem with his platform: a
dual core celeron

Do you confirm that your platform is a dual cortex-A15 ? At least that
what I have seen on web
This would confirm that dual system is a key point.

The ssh connection is also common with Heiner's setup

>
> [  142.849390] INFO: rcu_sched detected stalls on CPUs/tasks:
> [  142.854972]  1-...!: (1 GPs behind) idle=7a4/0/0 softirq=3214/3217 fqs=0
> [  142.861976]  (detected by 0, t=8232 jiffies, g=930, c=929, q=11)
> [  142.868042] Sending NMI from CPU 0 to CPUs 1:
> [  142.872443] NMI backtrace for cpu 1
> [  142.872452] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 4.16.0-05506-g28aba11c1393691a #14
> [  142.872455] Hardware name: Generic R8A7791 (Flattened Device Tree)
> [  142.872473] PC is at arch_cpu_idle+0x28/0x44
> [  142.872484] LR is at trace_hardirqs_on_caller+0x1a4/0x1d4
> [  142.872488] pc : []lr : []psr: 20070013
> [  142.872491] sp : eb0b9f90  ip : eb0b9f60  fp : eb0b9f9c
> [  142.872495] r10:   r9 : 413fc0f2  r8 : 4000406a
> [  142.872498] r7 : c0c08478  r6 : c0c0842c  r5 : e000  r4 : 0002
> [  142.872502] r3 : eb0b6ec0  r2 :   r1 : 0004  r0 : 0001
> [  142.872507] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [  142.872511] Control: 10c5387d  Table: 6a61406a  DAC: 0051
> [  142.872516] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 4.16.0-05506-g28aba11c1393691a #14
> [  142.872519] Hardware name: Generic R8A7791 (Flattened Device Tree)
> [  142.872522] Backtrace:
> [  142.872534] [] (dump_backtrace) from [] 
> (show_stack+0x18/0x1c)
> [  142.872540]  r7:c0c81388 r6: r5:60070193 r4:c0c81388
> [  142.872550] [] (show_stack) from [] 
> (dump_stack+0xa4/0xd8)
> [  142.872557] [] (dump_stack) from [] 
> (show_regs+0x14/0x18)
> [  142.872563]  r9:0001 r8: r7:c0c4f678 r6:eb0b9f40 r5:0001 
> r4:c13e1130
> [  142.872571] [] (show_regs) from [] 
> (nmi_cpu_backtrace+0xfc/0x118)
> [  142.872578] [] (nmi_cpu_backtrace) from [] 
> (handle_IPI+0x2a8/0x320)
> [  142.872583]  r7:c0c4f678 r6:eb0b9f40 r5:0007 r4:c0b75b68
> [  142.872594] [] (handle_IPI) from [] 
> (gic_handle_irq+0x8c/0x98)
> [  142.872599]  r10: r9:eb0b8000 r8:f0803000 r7:c0c4f678 r6:eb0b9f40 
> r5:c0c08a90
> [  142.872602]  r4:f0802000
> [  142.872608] [] (gic_handle_irq) from [] 
> (__irq_svc+0x70/0x98)
> [  142.872612] Exception stack(0xeb0b9f40 to 0xeb0b9f88)
> [  142.872618] 9f40: 0001 0004  eb0b6ec0 0002 e000 
> c0c0842c c0c08478
> [  142.872624] 9f60: 4000406a 413fc0f2  eb0b9f9c eb0b9f60 eb0b9f90 
> c01747a8 c01088a4
> [  142.872627] 9f80: 20070013 
> [  142.872632]  r9:eb0b8000 r8:4000406a r7:eb0b9f74 r6: r5:20070013 
> r4:c01088a4
> [  142.872642] [] (arch_cpu_idle) from [] 
> (default_idle_call+0x34/0x38)
> [  142.872650] [] (default_idle_call) from [] 
> (do_idle+0xe0/0x134)
> [  142.872656] [] (do_idle) from [] 
> (cpu_startup_entry+0x20/0x24)
> [  142.872660]  r7:c0c8e9d0 r6:10c0387d r5:0051 r4:0085
> [  142.872667] [] (cpu_startup_entry) from [] 
> (secondary_start_kernel+0x114/0x134)
> [  142.872673] [] (secondary_start_kernel) from [<401026ec>] 
> (0x401026ec)
> [  142.872676]  r5:0051 r4:6b0a406a
> [  142.873456] rcu_sched kthread starved for 8235 jiffies! g930 c929 f0x0 
> RCU_GP_WAIT_FQS(3) ->state=0x402 ->cpu=0
> [  143.135040] RCU grace-period kthread stack dump:
> [  143.139695] rcu_sched   I0 9  2 0x
> [  143.145234] Backtrace:
> [  143.147719] [] (__schedule) from [] 
> (schedule+0x94/0xb8)
> [  143.154823]  r10:c0b714c0 r9:c0c85f8a r8: r7:eb0abec4 r6:a274 
> r5:
> [  143.162712]  r4:e000
> [  143.165273] [] (schedule) from [] 
> (schedule_timeout+0x440/0x4b0)
> [  143.173076]  r5: r4:eb79c4c0
> [  143.176692] [] (schedule_timeout) from [] 
> (rcu_gp_kthread+0x958/0x150c)
> [  143.185108]  r10:c0c87274 r9: r8:c0c165b8 r7:0001 r6: 
> r5:c0c16590
> [  143.192997]  r4:c0c16300
> [  143.195560] [] (rcu_gp_kthread) from [] 
> (kthread+0x148/0x160)
> [  143.203099]  r7:c0c16300
> [  143.205660] [] (kthread) from [] 
> (ret_from_fork+0x14/0x20)
> [  143.212938] Exception stack(0xeb0abfb0 to 0xeb0abff8)
> [  143.218030] bfa0:  

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Auger Eric]

Hi Geert, Philipp,

On 11/04/18 11:15, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
> 
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem.  Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
> 
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
> 
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Philipp Zabel 
> ---
> v3:
>   - Add Reviewed-by,
>   - Merge similar checks in vfio_platform_has_reset(),
> 
> v2:
>   - Don't store error values in vdev->reset_control,
>   - Use of_reset_control_get_exclusive() instead of
> __of_reset_control_get(),
>   - Improve description.
> ---
>  drivers/vfio/platform/vfio_platform_common.c  | 20 ++--
>  drivers/vfio/platform/vfio_platform_private.h |  1 +
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..ef9b9e3220ebe939 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -112,11 +113,13 @@ static bool vfio_platform_has_reset(struct 
> vfio_platform_device *vdev)
>   if (VFIO_PLATFORM_IS_ACPI(vdev))
>   return vfio_platform_acpi_has_reset(vdev);
>  
> - return vdev->of_reset ? true : false;
> + return vdev->of_reset || vdev->reset_control;
>  }
>  
>  static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
>  {
> + struct reset_control *rstc;
> +
>   if (VFIO_PLATFORM_IS_ACPI(vdev))
>   return vfio_platform_acpi_has_reset(vdev) ? 0 : -ENOENT;
>  
> @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
> vfio_platform_device *vdev)
>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>   >reset_module);
>   }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);

Shouldn't we prefer the top level reset_control_get_exclusive()?

To make sure about the exclusive/shared terminology, does
get_reset_control_get_exclusive() check we have an exclusive wire
between this device and the reset controller?

Thanks

Eric
> + if (!IS_ERR(rstc)) {
> + vdev->reset_control = rstc;
> + return 0;
> + }
>  
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(rstc);
>  }
>  
>  static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> @@ -138,6 +149,8 @@ static void vfio_platform_put_reset(struct 
> vfio_platform_device *vdev)
>  
>   if (vdev->of_reset)
>   module_put(vdev->reset_module);
> +
> + reset_control_put(vdev->reset_control);
>  }
>  
>  static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
> @@ -217,6 +230,9 @@ static int vfio_platform_call_reset(struct 
> vfio_platform_device *vdev,
>   } else if (vdev->of_reset) {
>   dev_info(vdev->device, "reset\n");
>   return vdev->of_reset(vdev);
> + } else if (vdev->reset_control) {
> + dev_info(vdev->device, "reset\n");
> + return reset_control_reset(vdev->reset_control);
>   }
>  
>   dev_warn(vdev->device, "no reset function found!\n");
> diff --git a/drivers/vfio/platform/vfio_platform_private.h 
> b/drivers/vfio/platform/vfio_platform_private.h
> index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -60,6 +60,7 @@ struct vfio_platform_device {
>   const char  *compat;
>   const char  *acpihid;
>   struct module   *reset_module;
> + struct reset_control*reset_control;
>   struct device   *device;
>  
>   /*
> 

Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

[Niklas Söderlund]

Hi Vincent,

I have observed issues running on linus/master from a few days back [1]. 
I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue 
by X forwarding the v4l2 test application qv4l2 over ssh and moving the 
courser around in the GUI (best test case description award...). I'm 
sorry about the really bad way I trigger this but I can't do it in any 
other way, I'm happy to try other methods if you got some ideas. The 
symptom of the issue is a complete hang of the system for more then 30 
seconds and then this information is printed in the console:

[  142.849390] INFO: rcu_sched detected stalls on CPUs/tasks:
[  142.854972]  1-...!: (1 GPs behind) idle=7a4/0/0 softirq=3214/3217 fqs=0
[  142.861976]  (detected by 0, t=8232 jiffies, g=930, c=929, q=11)
[  142.868042] Sending NMI from CPU 0 to CPUs 1:
[  142.872443] NMI backtrace for cpu 1
[  142.872452] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
4.16.0-05506-g28aba11c1393691a #14
[  142.872455] Hardware name: Generic R8A7791 (Flattened Device Tree)
[  142.872473] PC is at arch_cpu_idle+0x28/0x44
[  142.872484] LR is at trace_hardirqs_on_caller+0x1a4/0x1d4
[  142.872488] pc : []lr : []psr: 20070013
[  142.872491] sp : eb0b9f90  ip : eb0b9f60  fp : eb0b9f9c
[  142.872495] r10:   r9 : 413fc0f2  r8 : 4000406a
[  142.872498] r7 : c0c08478  r6 : c0c0842c  r5 : e000  r4 : 0002
[  142.872502] r3 : eb0b6ec0  r2 :   r1 : 0004  r0 : 0001
[  142.872507] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  142.872511] Control: 10c5387d  Table: 6a61406a  DAC: 0051
[  142.872516] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
4.16.0-05506-g28aba11c1393691a #14
[  142.872519] Hardware name: Generic R8A7791 (Flattened Device Tree)
[  142.872522] Backtrace:
[  142.872534] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[  142.872540]  r7:c0c81388 r6: r5:60070193 r4:c0c81388
[  142.872550] [] (show_stack) from [] 
(dump_stack+0xa4/0xd8)
[  142.872557] [] (dump_stack) from [] (show_regs+0x14/0x18)
[  142.872563]  r9:0001 r8: r7:c0c4f678 r6:eb0b9f40 r5:0001 
r4:c13e1130
[  142.872571] [] (show_regs) from [] 
(nmi_cpu_backtrace+0xfc/0x118)
[  142.872578] [] (nmi_cpu_backtrace) from [] 
(handle_IPI+0x2a8/0x320)
[  142.872583]  r7:c0c4f678 r6:eb0b9f40 r5:0007 r4:c0b75b68
[  142.872594] [] (handle_IPI) from [] 
(gic_handle_irq+0x8c/0x98)
[  142.872599]  r10: r9:eb0b8000 r8:f0803000 r7:c0c4f678 r6:eb0b9f40 
r5:c0c08a90
[  142.872602]  r4:f0802000
[  142.872608] [] (gic_handle_irq) from [] 
(__irq_svc+0x70/0x98)
[  142.872612] Exception stack(0xeb0b9f40 to 0xeb0b9f88)
[  142.872618] 9f40: 0001 0004  eb0b6ec0 0002 e000 
c0c0842c c0c08478
[  142.872624] 9f60: 4000406a 413fc0f2  eb0b9f9c eb0b9f60 eb0b9f90 
c01747a8 c01088a4
[  142.872627] 9f80: 20070013 
[  142.872632]  r9:eb0b8000 r8:4000406a r7:eb0b9f74 r6: r5:20070013 
r4:c01088a4
[  142.872642] [] (arch_cpu_idle) from [] 
(default_idle_call+0x34/0x38)
[  142.872650] [] (default_idle_call) from [] 
(do_idle+0xe0/0x134)
[  142.872656] [] (do_idle) from [] 
(cpu_startup_entry+0x20/0x24)
[  142.872660]  r7:c0c8e9d0 r6:10c0387d r5:0051 r4:0085
[  142.872667] [] (cpu_startup_entry) from [] 
(secondary_start_kernel+0x114/0x134)
[  142.872673] [] (secondary_start_kernel) from [<401026ec>] 
(0x401026ec)
[  142.872676]  r5:0051 r4:6b0a406a
[  142.873456] rcu_sched kthread starved for 8235 jiffies! g930 c929 f0x0 
RCU_GP_WAIT_FQS(3) ->state=0x402 ->cpu=0
[  143.135040] RCU grace-period kthread stack dump:
[  143.139695] rcu_sched   I0 9  2 0x
[  143.145234] Backtrace:
[  143.147719] [] (__schedule) from [] (schedule+0x94/0xb8)
[  143.154823]  r10:c0b714c0 r9:c0c85f8a r8: r7:eb0abec4 r6:a274 
r5:
[  143.162712]  r4:e000
[  143.165273] [] (schedule) from [] 
(schedule_timeout+0x440/0x4b0)
[  143.173076]  r5: r4:eb79c4c0
[  143.176692] [] (schedule_timeout) from [] 
(rcu_gp_kthread+0x958/0x150c)
[  143.185108]  r10:c0c87274 r9: r8:c0c165b8 r7:0001 r6: 
r5:c0c16590
[  143.192997]  r4:c0c16300
[  143.195560] [] (rcu_gp_kthread) from [] 
(kthread+0x148/0x160)
[  143.203099]  r7:c0c16300
[  143.205660] [] (kthread) from [] 
(ret_from_fork+0x14/0x20)
[  143.212938] Exception stack(0xeb0abfb0 to 0xeb0abff8)
[  143.218030] bfa0:   
 
[  143.226271] bfc0:       
 
[  143.234511] bfe0:     0013 
[  143.241177]  r10: r9: r8: r7: r6: 
r5:c0145d70
[  143.249065]  r4:eb037b00

After the freeze the system becomes responsive again and I can sometimes 
trigger the hang multiple times. I tried to bisect the problem and I 
found that by reverting [2] I can no longer reproduce the issue. I can 
also 

RE: [PATCH 3/4] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

[Yoshihiro Shimoda]

Hi Geert-san, Simon-san,

> From: Simon Horman , Sent: Thursday, April 12, 2018 4:55 
> PM
> 
> On Wed, Apr 11, 2018 at 05:10:02PM +0200, Geert Uytterhoeven wrote:
> > Hi Shimoda-san,
> >
> > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
> >  wrote:
> > > From: Takeshi Kihara 
> > >
> > > This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
> > > A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.
> >
> > Thanks for your patch!
> >
> > > NOTE:
> > > - The 3DG power domain resume order of R-Car E3 is [3DG-B] -> [3DG-A],
> >
> > So 3DG-B is the parent of 3DG-A?
> > I have to take your word on this, as I cannot find this in the 
> > documentation.

Geert-san, you're correct. the documentation doesn't have any description about 
this.
So, software team are asking HW guys about this.
This means, should we drop 3DGs (or always on these domains) at initial support?

> > >   which is different from R-Car H3, M3 and M3N SoCs.
> >
> > M3-W and M3-N?
> 
> Shimoda-san, could you confirm the above?

I agreed with Geert-san. These words should be M3-W and M3-N.

Best regards,
Yoshihiro Shimoda

> > > Signed-off-by: Takeshi Kihara 
> > > [shimoda: add SPDX-License-Identifier]
> > > Signed-off-by: Yoshihiro Shimoda 
> >
> > 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
> >

[PATCH v3 2/5] arm64: dts: renesas: r8a77970: add VSPD support

[Jacopo Mondi]

From: Sergei Shtylyov 

Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
the next patch...

Based on the original (and large) patch by Daisuke Matsushita
.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Niklas Söderlund 
Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 

---
v1 -> v2 (Jacopo) :
- Extend the memory region to include V6_CLUTn_TBL* registers.
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 97c27ef..a3ef3bd 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -625,6 +625,16 @@
power-domains = < R8A77970_PD_ALWAYS_ON>;
resets = < 603>;
};
+
+   vspd0: vsp@fea2 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea2 0 0x8000>;
+   interrupts = ;
+   clocks = < CPG_MOD 623>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 623>;
+   renesas,fcp = <>;
+   };
};
 
timer {
-- 
2.7.4

[PATCH v3 3/5] arm64: dts: renesas: r8a77970: add DU support

[Jacopo Mondi]

From: Sergei Shtylyov 

Define the generic R8A77970 part of the DU device node.

Based on the original (and large) patch by Daisuke Matsushita
.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index a3ef3bd..5860b0fb 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -635,6 +635,35 @@
resets = < 623>;
renesas,fcp = <>;
};
+
+   du: display@feb0 {
+   compatible = "renesas,du-r8a77970";
+   reg = <0 0xfeb0 0 0x8>;
+   interrupts = ;
+   clocks = < CPG_MOD 724>;
+   clock-names = "du.0";
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 724>;
+   vsps = <>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   du_out_rgb: endpoint {
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   du_out_lvds0: endpoint {
+   };
+   };
+   };
+   };
};
 
timer {
-- 
2.7.4

[PATCH v3 4/5] arm64: dts: renesas: r8a77970: add LVDS support

[Jacopo Mondi]

From: Sergei Shtylyov 

Define the generic R8A77970 part of the LVDS device node.

Signed-off-by: Sergei Shtylyov 
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 5860b0fb..614b571 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -660,6 +660,34 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds-encoder@feb9 {
+   compatible = "renesas,r8a77970-lvds";
+   reg = <0 0xfeb9 0 0x14>;
+   clocks = < CPG_MOD 727>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 727>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint =
+   <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
2.7.4

[PATCH v3 1/5] arm64: dts: renesas: r8a77970: add FCPVD support

[Jacopo Mondi]

From: Sergei Shtylyov 

Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in
the next patch...

Based on the original (and large) patch by Daisuke Matsushita
.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index c6db8ea..97c27ef 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -617,6 +617,14 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+   fcpvd0: fcp@fea27000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfea27000 0 0x200>;
+   clocks = < CPG_MOD 603>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 603>;
+   };
};
 
timer {
-- 
2.7.4

[PATCH v3 5/5] arm64: dts: renesas: eagle: Enable HDMI output

[Jacopo Mondi]

Enable HDMI output on Renesas R-Car V3M Eagle board.

The HDMI ouput is enabled connecting the DU LVDS output to the
transparent LVDS converter THC63LVD1024, and successively routing its
RGB output to the ADV7511W HDMI encoder.

Signed-off-by: Niklas Söderlund 
Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
[for THC63LVD1024: ]
Reviewed-by: Andrzej Hajda 

---
v1 -> v2:
- Squash patches [5/7], [6/7] and [7/7] of v1 in a single patch as
  suggested by Laurent
- Remove DU pinmuxing as it is used for DU parallel RGB output only used
  by Eagle's display expander board not enabled by this series.
---
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 93 ++
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index 3c5f598..ebfbb51 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -31,6 +31,51 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_out: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   d3p3: regulator-fixed {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   thc63lvd1024_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   thc63lvd1024_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -68,6 +113,38 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con_out>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -93,3 +170,19 @@
 
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
-- 
2.7.4

[PATCH v3 0/5] V3M-Eagle HDMI output enablement

[Jacopo Mondi]

Hello,
   I have rebased the Eagle display enablement on top of (part of) Sergei's
series:
 [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

Simon: you can skip "[1/5]  arm64: dts: renesas: r8a77970: add FCPVD support"
as you already collected that

Sergei: I re-sent your series because there was an additional comment from
Laurent on [3/5]. I felt it was wrong to send a follow up patch on a series
still not collected by Simon, so I've resent it. Hope this time is ok with you.
Also, please note that [5/5] of your original series shall be re-sent using
the newly introduced (still in-review) LVDS decoder. Please see [5/5] of this
series as an example.

Niklas: [5/5] of this series is a fixup of your patches and mine. I added
your signed-off-by, hope it is ok.

The series depends on THC63LVD1024 driver, currently submitted for inclusion
"[PATCH v8 0/2]  drm: Add Thine THC63LVD1024 LVDS decoder bridge"
currently available at:
git://jmondi.org/linux lvds-bridge/linus-master/v8

Thanks
   j

v2 -> v3:
- Use Sergei's series for patches [1-4] with a minor comment from Laurent
- Remove the lvds-decoder node label and add Laurent's Reviewed-by in [5/5]

v1 -> v2:
- Add Laurent's reviewed by tags
- Fixup patch 5, 6 and 7 of v1
- Remove DU digital output pin muxing
- Update thc63lvd1024 to use the new bindings with mandatory power supply
- Minor fixes (changes are described individually in each patch)

Jacopo Mondi (1):
  arm64: dts: renesas: eagle: Enable HDMI output

Sergei Shtylyov (4):
  arm64: dts: renesas: r8a77970: add FCPVD support
  arm64: dts: renesas: r8a77970: add VSPD support
  arm64: dts: renesas: r8a77970: add DU support
  arm64: dts: renesas: r8a77970: add LVDS support

 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 93 ++
 arch/arm64/boot/dts/renesas/r8a77970.dtsi  | 75 +
 2 files changed, 168 insertions(+)

--
2.7.4

[PATCH v3 0/5] V3M-Eagle HDMI output enablement

[Jacopo Mondi]

Hello,
   I have rebased the Eagle display enablement on top of (part of) Sergei's
series:
 [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

Simon: you can skip "[1/5]  arm64: dts: renesas: r8a77970: add FCPVD support"
as you already collected that

Sergei: I re-sent your series because there was an additional comment from
Laurent on [3/5]. I felt it was wrong to send a follow up patch on a series
still not collected by Simon, so I've resent it. Hope this time is ok with you.
Also, please note that [5/5] of your original series shall be re-sent using
the newly introduced (still in-review) LVDS decoder. Please see [5/5] of this
series as an example.

Niklas: [5/5] of this series is a fixup of your patches and mine. I added
your signed-off-by, hope it is ok.

The series depends on THC63LVD1024 driver, currently submitted for inclusion
"[PATCH v8 0/2]  drm: Add Thine THC63LVD1024 LVDS decoder bridge"
currently available at:
git://jmondi.org/linux lvds-bridge/linus-master/v8

Thanks
   j

v2 -> v3:
- Use Sergei's series for patches [1-4] with a minor comment from Laurent
- Remove the lvds-decoder node label and add Laurent's Reviewed-by in [5/5]

v1 -> v2:
- Add Laurent's reviewed by tags
- Fixup patch 5, 6 and 7 of v1
- Remove DU digital output pin muxing
- Update thc63lvd1024 to use the new bindings with mandatory power supply
- Minor fixes (changes are described individually in each patch)

Jacopo Mondi (1):
  arm64: dts: renesas: eagle: Enable HDMI output

Sergei Shtylyov (4):
  arm64: dts: renesas: r8a77970: add FCPVD support
  arm64: dts: renesas: r8a77970: add VSPD support
  arm64: dts: renesas: r8a77970: add DU support
  arm64: dts: renesas: r8a77970: add LVDS support

 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 93 ++
 arch/arm64/boot/dts/renesas/r8a77970.dtsi  | 75 +
 2 files changed, 168 insertions(+)

--
2.7.4

Re: [PATCH v3 0/5] V3M-Eagle HDMI output enablement

[jacopo mondi]

Hi Simon,

On Thu, Apr 12, 2018 at 10:08:27AM +0200, Simon Horman wrote:
> On Wed, Apr 11, 2018 at 02:43:05PM +0200, Jacopo Mondi wrote:
> > Hello,
> >I have rebased the Eagle display enablement on top of (part of) Sergei's
> > series:
> >  [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support
>
> Hi Jacopo,
>
> the emails with the patches of this series do not
> seem to have hit my inbox or patchwork.
>

Damn, I've noticed! I have no idea what happened, I have 3 out of 5
patches in my inbox, but it seems most of them didn't went out.

ISP problems again? :(

I'll resend right away


signature.asc
Description: PGP signature

RE: [PATCH 4/4] soc: renesas: rcar-rst: Add support for R-Car E3

[Yoshihiro Shimoda]

Hi Simon-san,

> From: Simon Horman, Sent: Thursday, April 12, 2018 4:55 PM
> 
> On Wed, Apr 11, 2018 at 05:18:28PM +0200, Geert Uytterhoeven wrote:
> > Hi Shimoda-san,
> >
> > Thanks for your patch!
> >
> > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
> >  wrote:
> > > From: Takeshi Kihara 
> > >
> > > This patch adds definition of reset vector for the R8A77990 SoC.
> >
> > The description doesn't seem to match what the patch does?
> 
> How about this text, based on Sergei's test for the R8a77980?
> 
> Add support for R-Car E3 (R8A77990) to the R-Car RST driver.
> This driver is needed for the clock driver to work.

It's good to me. So, should I submit v2 patch?

Best regards,
Yoshihiro Shimoda

> > > Signed-off-by: Takeshi Kihara 
> > > [shimoda: rebase]
> > > Signed-off-by: Yoshihiro Shimoda 
> >
> > The actual patch contents are fine, so:
> > 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 v3 0/5] V3M-Eagle HDMI output enablement

[Simon Horman]

On Wed, Apr 11, 2018 at 02:43:05PM +0200, Jacopo Mondi wrote:
> Hello,
>I have rebased the Eagle display enablement on top of (part of) Sergei's
> series:
>  [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

Hi Jacopo,

the emails with the patches of this series do not
seem to have hit my inbox or patchwork.

Re: [PATCH v4 1/8] arm: shmobile: Add the RZ/N1 arch to the shmobile Kconfig

[Simon Horman]

On Tue, Apr 10, 2018 at 09:30:01AM +0100, Michel Pollet wrote:
> Add the RZ/N1 Family (Part #R9A06G0xx) ARCH config to the rest of
> the Renesas SoC collection.
> 
> Signed-off-by: Michel Pollet 
> Reviewed-by: Geert Uytterhoeven 

This change has already been accepted for v4.18.

Re: [PATCH 3/4] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

[Simon Horman]

On Wed, Apr 11, 2018 at 05:10:02PM +0200, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
> 
> On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
>  wrote:
> > From: Takeshi Kihara 
> >
> > This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
> > A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.
> 
> Thanks for your patch!
> 
> > NOTE:
> > - The 3DG power domain resume order of R-Car E3 is [3DG-B] -> [3DG-A],
> 
> So 3DG-B is the parent of 3DG-A?
> I have to take your word on this, as I cannot find this in the documentation.
> 
> >   which is different from R-Car H3, M3 and M3N SoCs.
> 
> M3-W and M3-N?

Shimoda-san, could you confirm the above?

> > Signed-off-by: Takeshi Kihara 
> > [shimoda: add SPDX-License-Identifier]
> > Signed-off-by: Yoshihiro Shimoda 
> 
> 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 4/4] soc: renesas: rcar-rst: Add support for R-Car E3

[Simon Horman]

On Wed, Apr 11, 2018 at 05:18:28PM +0200, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
> 
> Thanks for your patch!
> 
> On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
>  wrote:
> > From: Takeshi Kihara 
> >
> > This patch adds definition of reset vector for the R8A77990 SoC.
> 
> The description doesn't seem to match what the patch does?

How about this text, based on Sergei's test for the R8a77980?

Add support for R-Car E3 (R8A77990) to the R-Car RST driver.
This driver is needed for the clock driver to work.

> > Signed-off-by: Takeshi Kihara 
> > [shimoda: rebase]
> > Signed-off-by: Yoshihiro Shimoda 
> 
> The actual patch contents are fine, so:
> 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 2/4] soc: renesas: Add r8a77990 SYSC PM Domain Binding Definitions

[Simon Horman]

On Wed, Apr 11, 2018 at 04:55:46PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
>  wrote:
> > From: Takeshi Kihara 
> >
> > This patch adds power domain indices for R-Car E3.
> >
> > Signed-off-by: Takeshi Kihara 
> > [shimoda: add commit log and SPDX-License-Identifier]
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 1/4] soc: renesas: identify R-Car E3

[Simon Horman]

On Wed, Apr 11, 2018 at 03:26:49PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
>  wrote:
> > From: Takeshi Kihara 
> >
> > This patch adds support for identifying the R-Car E3 (R8A77990) SoC.
> >
> > Signed-off-by: Takeshi Kihara 
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 3/3] arm64: renesas: Add Renesas R8A77990 Kconfig support

[Simon Horman]

On Wed, Apr 11, 2018 at 03:25:06PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda
>  wrote:
> > Add configuration option for the R-Car E3 (R8A77990) SoC.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 2/3] dt-bindings: arm: Document Renesas Ebisu board DT bindings

[Simon Horman]

On Wed, Apr 11, 2018 at 03:24:39PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda
>  wrote:
> > This patch adds device tree bindings documentation for Renesas
> > Ebisu board (RTP0RC77990SEB0010S).
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 1/3] dt-bindings: arm: Document R-Car E3 SoC DT bindings

[Simon Horman]

On Wed, Apr 11, 2018 at 01:42:08PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda
>  wrote:
> > This patch adds device tree bindings documentation for Renesas R-Car
> > E3 (r8a77990).
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

[Simon Horman]

On Wed, Apr 11, 2018 at 11:24:08AM +0200, Geert Uytterhoeven wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM.  Without Runtime PM, the device
> may not be powered up, causing subtle failures, crashes, or system
> lock-ups when the device is accessed by the guest.
> 
> Fix this by adding Runtime PM support, powering the device when the VFIO
> device is opened by the guest.
> 
> Note that while more fine-grained power management could be implemented
> on the guest side, if exported, this would be inherently unsafe, as
> abusing it may kill the whole system.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Simon Horman]

On Wed, Apr 11, 2018 at 11:15:49AM +0200, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
> 
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem.  Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
> 
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
> 
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Philipp Zabel 

Reviewed-by: Simon Horman 

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

[Simon Horman]

Hi Geert,

On Wed, Apr 11, 2018 at 10:39:19AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Apr 11, 2018 at 10:22 AM, Simon Horman  wrote:
> > On Tue, Apr 10, 2018 at 05:53:47PM +0200, Geert Uytterhoeven wrote:

...

> >> @@ -217,6 +236,9 @@ static int vfio_platform_call_reset(struct 
> >> vfio_platform_device *vdev,
> >>   } else if (vdev->of_reset) {
> >>   dev_info(vdev->device, "reset\n");
> >>   return vdev->of_reset(vdev);
> >> + } else if (vdev->reset_control) {
> >> + dev_info(vdev->device, "reset\n");
> >
> > Would it be useful to differentiate between the above two informational
> > messages?
> 
> Probably not, there's also no differentiation with the message for the
> ACPI case above (out of visible context).

Thanks, I agree that it seems fine to leave things as you have them above.