* GEN2: Initialization of VSP1 failed at upstream v4.8-rc2
[not found] ` <f2bb791e-8973-10a9-a2ac-1a944b38d4ad@jinso.co.jp>
@ 2016-09-12 8:57 ` Hiep Cao Minh
2016-09-12 9:06 ` Geert Uytterhoeven
2016-09-12 9:33 ` GEN2: Initialization of VIN failed at upstream v4.8-rc2 Hiep Cao Minh
[not found] ` <9d9a647b-d75f-e89a-2d4d-55e409ccabae@jinso.co.jp>
1 sibling, 2 replies; 33+ messages in thread
From: Hiep Cao Minh @ 2016-09-12 8:57 UTC (permalink / raw)
To: Xuan Truong Nguyen, laurent.pinchart+renesas
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
horms+renesas, linux-renesas-soc, wsa
Hi Laurent,
As you know the information about Initialization of VSP1 failed at
upstream v4.8-rc2
from the report of "The failure summary report of GEN2 for Linux
v4.8-rc2".
"[ 5.237049] vsp1: probe of fe920000.vsp1 failed with error -38
[ 5.254664] vsp1: probe of fe928000.vsp1 failed with error -38
[ 5.272277] vsp1: probe of fe930000.vsp1 failed with error -38
[ 5.289891] vsp1: probe of fe938000.vsp1 failed with error -38"
I have found the patch that causing of this issue:
"94fcdf8 [media] v4l: vsp1: Add FCP support"
In this patch,
"@@ -528,7 +533,7 @@ static int vsp1_pm_runtime_resume(struct device *dev)
return ret;
}
- return 0;
+ return rcar_fcp_enable(vsp1->fcp);
}"
vsp1_pm_runtime_resume() function should be returned "0" if it success.
I tried to debug this place, and I realize that the rcar_fcp_enable()
function returned "-38" during Initialization.
That's why the error message occurs.
We know that the rcar_fcp_enable() function also returns 0 on success or
a negative error code if an error occurs.
So, I am thinking of something just before it happens.
Please have a look at this issue when you have time.
Best regards,
Hiep.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2: Initialization of VSP1 failed at upstream v4.8-rc2
2016-09-12 8:57 ` GEN2: Initialization of VSP1 failed at upstream v4.8-rc2 Hiep Cao Minh
@ 2016-09-12 9:06 ` Geert Uytterhoeven
2016-09-12 9:25 ` Hiep Cao Minh
` (2 more replies)
2016-09-12 9:33 ` GEN2: Initialization of VIN failed at upstream v4.8-rc2 Hiep Cao Minh
1 sibling, 3 replies; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-09-12 9:06 UTC (permalink / raw)
To: Hiep Cao Minh
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Hiep,
On Mon, Sep 12, 2016 at 10:57 AM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
> As you know the information about Initialization of VSP1 failed at upstream
> v4.8-rc2
> from the report of "The failure summary report of GEN2 for Linux v4.8-rc2".
> "[ 5.237049] vsp1: probe of fe920000.vsp1 failed with error -38
> [ 5.254664] vsp1: probe of fe928000.vsp1 failed with error -38
> [ 5.272277] vsp1: probe of fe930000.vsp1 failed with error -38
> [ 5.289891] vsp1: probe of fe938000.vsp1 failed with error -38"
>
> I have found the patch that causing of this issue:
> "94fcdf8 [media] v4l: vsp1: Add FCP support"
>
> In this patch,
>
> "@@ -528,7 +533,7 @@ static int vsp1_pm_runtime_resume(struct device *dev)
> return ret;
> }
>
> - return 0;
> + return rcar_fcp_enable(vsp1->fcp);
> }"
>
> vsp1_pm_runtime_resume() function should be returned "0" if it success.
> I tried to debug this place, and I realize that the rcar_fcp_enable()
> function returned "-38" during Initialization.
> That's why the error message occurs.
> We know that the rcar_fcp_enable() function also returns 0 on success or a
> negative error code if an error occurs.
> So, I am thinking of something just before it happens.
Please see commits d0cd1e773fee06ed "[media] rcar-fcp: Make sure
rcar_fcp_enable() returns 0 on success" in renesas-drivers and ba75faf43dc60744
in media-next.
But we indeed need this fix in v4.8, not v4.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2: Initialization of VSP1 failed at upstream v4.8-rc2
2016-09-12 9:06 ` Geert Uytterhoeven
@ 2016-09-12 9:25 ` Hiep Cao Minh
2016-09-12 10:31 ` Laurent Pinchart
[not found] ` <57ECF4EA.4010704@jinso.co.jp>
2 siblings, 0 replies; 33+ messages in thread
From: Hiep Cao Minh @ 2016-09-12 9:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Geert,
Thanks for your quick reply!
>> As you know the information about Initialization of VSP1 failed at upstream
>> v4.8-rc2
>> from the report of "The failure summary report of GEN2 for Linux v4.8-rc2".
>> "[ 5.237049] vsp1: probe of fe920000.vsp1 failed with error -38
>> [ 5.254664] vsp1: probe of fe928000.vsp1 failed with error -38
>> [ 5.272277] vsp1: probe of fe930000.vsp1 failed with error -38
>> [ 5.289891] vsp1: probe of fe938000.vsp1 failed with error -38"
>>
>> I have found the patch that causing of this issue:
>> "94fcdf8 [media] v4l: vsp1: Add FCP support"
>>
>> In this patch,
>>
>> "@@ -528,7 +533,7 @@ static int vsp1_pm_runtime_resume(struct device *dev)
>> return ret;
>> }
>>
>> - return 0;
>> + return rcar_fcp_enable(vsp1->fcp);
>> }"
>>
>> vsp1_pm_runtime_resume() function should be returned "0" if it success.
>> I tried to debug this place, and I realize that the rcar_fcp_enable()
>> function returned "-38" during Initialization.
>> That's why the error message occurs.
>> We know that the rcar_fcp_enable() function also returns 0 on success or a
>> negative error code if an error occurs.
>> So, I am thinking of something just before it happens.
> Please see commits d0cd1e773fee06ed "[media] rcar-fcp: Make sure
> rcar_fcp_enable() returns 0 on success" in renesas-drivers and ba75faf43dc60744
> in media-next.
>
> But we indeed need this fix in v4.8, not v4.9.
Thanks for your fixed patch.
I'll re-confirm it on my environment.
Sorry for the late investigation.
Best regards,
Hiep.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* GEN2: Initialization of VIN failed at upstream v4.8-rc2
2016-09-12 8:57 ` GEN2: Initialization of VSP1 failed at upstream v4.8-rc2 Hiep Cao Minh
2016-09-12 9:06 ` Geert Uytterhoeven
@ 2016-09-12 9:33 ` Hiep Cao Minh
2016-09-12 11:09 ` Niklas Söderlund
1 sibling, 1 reply; 33+ messages in thread
From: Hiep Cao Minh @ 2016-09-12 9:33 UTC (permalink / raw)
To: Niklas Söderlund
Cc: laurent.pinchart+renesas, duclm, ryusuke.sakato.bx,
kuninori.morimoto.gx, magnus.damm, geert+renesas, h-inayoshi,
yoshihiro.shimoda.uh, nv-dung, horms+renesas, linux-renesas-soc,
wsa, harunaga,
人ソ)ドンさん,
Na Hoan
Hi Niklas
As you know the information about initialization of VIN failed at
upstream v4.8-rc2
from the report of "The failure summary report of GEN2 for Linux
v4.8-rc2".
"…
[ 5.589485] [<c0549114>] (of_node_put) from [<c0510558>]
(rcar_vin_probe+0x1c4/0x2d0)
[ 5.612949] [<c0510394>] (rcar_vin_probe) from [<c040dd60>]
(platform_drv_probe+0x58/0xa4)
…
[ 5.942909] [<c040e6f0>] (__platform_driver_register) from [<c091fa58>]
(rcar_vin_driver_init+0x18/0x20)
[ 5.971318] [<c091fa40>] (rcar_vin_driver_init) from [<c0900e44>]
(do_one_initcall+0xb4/0x164) ...
...”
I have found the patch that causing of this issue:
"f00add9 [media] rcar-vin: add Renesas R-Car VIN driver"
Please have a look at this issue when you have time.
Best regards,
Hiep.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2: Initialization of VSP1 failed at upstream v4.8-rc2
2016-09-12 9:06 ` Geert Uytterhoeven
2016-09-12 9:25 ` Hiep Cao Minh
@ 2016-09-12 10:31 ` Laurent Pinchart
[not found] ` <57ECF4EA.4010704@jinso.co.jp>
2 siblings, 0 replies; 33+ messages in thread
From: Laurent Pinchart @ 2016-09-12 10:31 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Geert Uytterhoeven, Hiep Cao Minh, Xuan Truong Nguyen, duclm,
Ryusuke Sakato, Kuninori Morimoto, Magnus Damm,
Geert Uytterhoeven, 稲吉,
Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hello,
On Monday 12 Sep 2016 11:06:02 Geert Uytterhoeven wrote:
> On Mon, Sep 12, 2016 at 10:57 AM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
> > As you know the information about Initialization of VSP1 failed at
> > upstream v4.8-rc2 from the report of "The failure summary report of GEN2
> > for Linux v4.8-rc2".
> >
> > "[ 5.237049] vsp1: probe of fe920000.vsp1 failed with error -38
> > [ 5.254664] vsp1: probe of fe928000.vsp1 failed with error -38
> > [ 5.272277] vsp1: probe of fe930000.vsp1 failed with error -38
> > [ 5.289891] vsp1: probe of fe938000.vsp1 failed with error -38"
> >
> > I have found the patch that causing of this issue:
> > "94fcdf8 [media] v4l: vsp1: Add FCP support"
> >
> > In this patch,
> >
> > "@@ -528,7 +533,7 @@ static int vsp1_pm_runtime_resume(struct device *dev)
> > return ret;
> > }
> >
> > - return 0;
> > + return rcar_fcp_enable(vsp1->fcp);
> > }"
> >
> > vsp1_pm_runtime_resume() function should be returned "0" if it success.
> > I tried to debug this place, and I realize that the rcar_fcp_enable()
> > function returned "-38" during Initialization.
> > That's why the error message occurs.
> > We know that the rcar_fcp_enable() function also returns 0 on success or a
> > negative error code if an error occurs.
> > So, I am thinking of something just before it happens.
>
> Please see commits d0cd1e773fee06ed "[media] rcar-fcp: Make sure
> rcar_fcp_enable() returns 0 on success" in renesas-drivers and
> ba75faf43dc60744 in media-next.
>
> But we indeed need this fix in v4.8, not v4.9.
Mauro, you've queued
commit ba75faf43dc60744608ffa1412fdeceff2126cbc
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Aug 9 12:36:41 2016 -0300
[media] rcar-fcp: Make sure rcar_fcp_enable() returns 0 on success
to the media tree master branch, but it fixes a v4.8 regression. Could you
please apply it to the fixes branch and push it upstream for v4.8 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2: Initialization of VIN failed at upstream v4.8-rc2
2016-09-12 9:33 ` GEN2: Initialization of VIN failed at upstream v4.8-rc2 Hiep Cao Minh
@ 2016-09-12 11:09 ` Niklas Söderlund
2016-09-13 5:12 ` Hiep Cao Minh
0 siblings, 1 reply; 33+ messages in thread
From: Niklas Söderlund @ 2016-09-12 11:09 UTC (permalink / raw)
To: Hiep Cao Minh
Cc: laurent.pinchart+renesas, duclm, ryusuke.sakato.bx,
kuninori.morimoto.gx, magnus.damm, geert+renesas, h-inayoshi,
yoshihiro.shimoda.uh, nv-dung, horms+renesas, linux-renesas-soc,
wsa, harunaga,
人ソ)ドンさん,
Na Hoan
Hi Hiep,
On 2016-09-12 18:33:49 +0900, Hiep Cao Minh wrote:
> Hi Niklas
>
> As you know the information about initialization of VIN failed at upstream
> v4.8-rc2
> from the report of "The failure summary report of GEN2 for Linux v4.8-rc2".
> "…
> [ 5.589485] [<c0549114>] (of_node_put) from [<c0510558>]
> (rcar_vin_probe+0x1c4/0x2d0)
> [ 5.612949] [<c0510394>] (rcar_vin_probe) from [<c040dd60>]
> (platform_drv_probe+0x58/0xa4)
> …
> [ 5.942909] [<c040e6f0>] (__platform_driver_register) from [<c091fa58>]
> (rcar_vin_driver_init+0x18/0x20)
> [ 5.971318] [<c091fa40>] (rcar_vin_driver_init) from [<c0900e44>]
> (do_one_initcall+0xb4/0x164) ...
> ...”
>
> I have found the patch that causing of this issue:
> "f00add9 [media] rcar-vin: add Renesas R-Car VIN driver"
>
> Please have a look at this issue when you have time.
Thanks for finding this. I found out about this issue (which is only
printed if some OF debug option is enabled) after the patch was picked
up.
The issue is already fixed and picked up in the media tree, see 83fba2c
([media] rcar-vin: rework how subdevice is found and bound).
--
Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2: Initialization of VIN failed at upstream v4.8-rc2
2016-09-12 11:09 ` Niklas Söderlund
@ 2016-09-13 5:12 ` Hiep Cao Minh
0 siblings, 0 replies; 33+ messages in thread
From: Hiep Cao Minh @ 2016-09-13 5:12 UTC (permalink / raw)
To: Niklas Söderlund
Cc: laurent.pinchart+renesas, duclm, ryusuke.sakato.bx,
kuninori.morimoto.gx, magnus.damm, geert+renesas, h-inayoshi,
yoshihiro.shimoda.uh, nv-dung, horms+renesas, linux-renesas-soc,
wsa, harunaga,
人ソ)ドンさん,
Na Hoan
Hi Niklas,
On 09/12/2016 08:09 PM, Niklas Söderlund wrote:
> Hi Hiep,
>
> On 2016-09-12 18:33:49 +0900, Hiep Cao Minh wrote:
>> Hi Niklas
>>
>> As you know the information about initialization of VIN failed at upstream
>> v4.8-rc2
>> from the report of "The failure summary report of GEN2 for Linux v4.8-rc2".
>> "…
>> [ 5.589485] [<c0549114>] (of_node_put) from [<c0510558>]
>> (rcar_vin_probe+0x1c4/0x2d0)
>> [ 5.612949] [<c0510394>] (rcar_vin_probe) from [<c040dd60>]
>> (platform_drv_probe+0x58/0xa4)
>> …
>> [ 5.942909] [<c040e6f0>] (__platform_driver_register) from [<c091fa58>]
>> (rcar_vin_driver_init+0x18/0x20)
>> [ 5.971318] [<c091fa40>] (rcar_vin_driver_init) from [<c0900e44>]
>> (do_one_initcall+0xb4/0x164) ...
>> ...”
>>
>> I have found the patch that causing of this issue:
>> "f00add9 [media] rcar-vin: add Renesas R-Car VIN driver"
>>
>> Please have a look at this issue when you have time.
> Thanks for finding this. I found out about this issue (which is only
> printed if some OF debug option is enabled) after the patch was picked
> up.
>
> The issue is already fixed and picked up in the media tree, see 83fba2c
> ([media] rcar-vin: rework how subdevice is found and bound).
Thanks for your fixed patch, We'll try it on our environment.
Jinso/Linux Team.
Hiep.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4
[not found] ` <57ECF4EA.4010704@jinso.co.jp>
@ 2016-09-29 13:40 ` Geert Uytterhoeven
2016-09-30 9:55 ` Hiep Cao Minh
0 siblings, 1 reply; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-09-29 13:40 UTC (permalink / raw)
To: Hiep Cao Minh
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Hiep,
On Thu, Sep 29, 2016 at 1:03 PM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
> I'd like to report the issue of the CPU operation.
> We tested and found it on Lager board at linux-v4.8-rcx.
>
> The test procedure is the following:
>
> Confirmation command:
>
> # cat /proc/interrupts
> CPU0
> 19: 2509 GIC-0 27 Level arch_timer
> 21: 0 GIC-0 36 Level e6050000.gpio
> 22: 0 GIC-0 37 Level e6051000.gpio
> 23: 0 GIC-0 38 Level e6052000.gpio
> 24: 0 GIC-0 39 Level e6053000.gpio
> 25: 0 GIC-0 40 Level e6054000.gpio
> 26: 0 GIC-0 41 Level e6055000.gpio
> 27: 23 GIC-0 101 Level e61f0000.thermal
> …”
>
> This issue appears when we changed the SW8-PIN4 of Lager board.
>
> SW8-PIN4: ON
>
> + At linux-v4.7: OK (4 cores work together normally).
> + At linux-v4.8-rc2: OK (4 cores work together normally).
>
> SW8-PIN4: OFF
>
> + At linux-v4.7: -> OK(4 cores work together normally).
> + At linux-v4.8-rc2: -> NG(Only 1 core works).
And the kernel prints "Unable to boot CPU%u when MD21 is set", right?
> We tried to find out the issued patch and we realize that it happens from
> the following patch:
> " 043248c Merge tag 'armsoc-dt' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc"
The issue you're seeing is due to a combination of commits 5f3bca0db8ac01a7
("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs may
lock up the system after a cold boot, depending of boot load version. Hence
we explicitly prohibit that. BTW, this has been the case on Koelsch since commit
277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting
secondary CPU cores in debug mode" (included in all renesas-drivers releases
during September) fix it for you?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4
2016-09-29 13:40 ` GEN2:Lager: Only 1 core works when turning off the SW8-PIN4 Geert Uytterhoeven
@ 2016-09-30 9:55 ` Hiep Cao Minh
2016-09-30 9:58 ` Geert Uytterhoeven
0 siblings, 1 reply; 33+ messages in thread
From: Hiep Cao Minh @ 2016-09-30 9:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Geert,
Thanks for your reply!
On 09/29/2016 10:40 PM, Geert Uytterhoeven wrote:
> Hi Hiep,
>
> On Thu, Sep 29, 2016 at 1:03 PM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
>> I'd like to report the issue of the CPU operation.
>> We tested and found it on Lager board at linux-v4.8-rcx.
>>
>> The test procedure is the following:
>>
>> Confirmation command:
>>
>> # cat /proc/interrupts
>> CPU0
>> 19: 2509 GIC-0 27 Level arch_timer
>> 21: 0 GIC-0 36 Level e6050000.gpio
>> 22: 0 GIC-0 37 Level e6051000.gpio
>> 23: 0 GIC-0 38 Level e6052000.gpio
>> 24: 0 GIC-0 39 Level e6053000.gpio
>> 25: 0 GIC-0 40 Level e6054000.gpio
>> 26: 0 GIC-0 41 Level e6055000.gpio
>> 27: 23 GIC-0 101 Level e61f0000.thermal
>> …”
>>
>> This issue appears when we changed the SW8-PIN4 of Lager board.
>>
>> SW8-PIN4: ON
>>
>> + At linux-v4.7: OK (4 cores work together normally).
>> + At linux-v4.8-rc2: OK (4 cores work together normally).
>>
>> SW8-PIN4: OFF
>>
>> + At linux-v4.7: -> OK(4 cores work together normally).
>> + At linux-v4.8-rc2: -> NG(Only 1 core works).
> And the kernel prints "Unable to boot CPU%u when MD21 is set", right?
>
>> We tried to find out the issued patch and we realize that it happens from
>> the following patch:
>> " 043248c Merge tag 'armsoc-dt' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc"
> The issue you're seeing is due to a combination of commits 5f3bca0db8ac01a7
> ("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
> dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
>
> When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs may
> lock up the system after a cold boot, depending of boot load version. Hence
> we explicitly prohibit that. BTW, this has been the case on Koelsch since commit
> 277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
>
> Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting
> secondary CPU cores in debug mode" (included in all renesas-drivers releases
> during September) fix it for you?
Thanks for your series patches.
I have had some problems of receiving post mail from Linux-Renesas
Mailing List recently.
Could you please forward these series patches to me?
Thank you!.
Jinso/Linux-Team
Hiep.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4
2016-09-30 9:55 ` Hiep Cao Minh
@ 2016-09-30 9:58 ` Geert Uytterhoeven
2016-09-30 10:05 ` Hiep Cao Minh
0 siblings, 1 reply; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-09-30 9:58 UTC (permalink / raw)
To: Hiep Cao Minh
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Hiep,
On Fri, Sep 30, 2016 at 11:55 AM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
> On 09/29/2016 10:40 PM, Geert Uytterhoeven wrote:
>> On Thu, Sep 29, 2016 at 1:03 PM, Hiep Cao Minh <cm-hiep@jinso.co.jp>
>> wrote:
>>> I'd like to report the issue of the CPU operation.
>>> We tested and found it on Lager board at linux-v4.8-rcx.
>>>
>>> The test procedure is the following:
>>>
>>> Confirmation command:
>>>
>>> # cat /proc/interrupts
>>> CPU0
>>> 19: 2509 GIC-0 27 Level arch_timer
>>> 21: 0 GIC-0 36 Level e6050000.gpio
>>> 22: 0 GIC-0 37 Level e6051000.gpio
>>> 23: 0 GIC-0 38 Level e6052000.gpio
>>> 24: 0 GIC-0 39 Level e6053000.gpio
>>> 25: 0 GIC-0 40 Level e6054000.gpio
>>> 26: 0 GIC-0 41 Level e6055000.gpio
>>> 27: 23 GIC-0 101 Level e61f0000.thermal
>>> …”
>>>
>>> This issue appears when we changed the SW8-PIN4 of Lager board.
>>>
>>> SW8-PIN4: ON
>>>
>>> + At linux-v4.7: OK (4 cores work together normally).
>>> + At linux-v4.8-rc2: OK (4 cores work together normally).
>>>
>>> SW8-PIN4: OFF
>>>
>>> + At linux-v4.7: -> OK(4 cores work together normally).
>>> + At linux-v4.8-rc2: -> NG(Only 1 core works).
>>
>> And the kernel prints "Unable to boot CPU%u when MD21 is set", right?
>>
>>> We tried to find out the issued patch and we realize that it happens from
>>> the following patch:
>>> " 043248c Merge tag 'armsoc-dt' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc"
>>
>> The issue you're seeing is due to a combination of commits
>> 5f3bca0db8ac01a7
>> ("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
>> dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
>>
>> When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs
>> may
>> lock up the system after a cold boot, depending of boot load version.
>> Hence
>> we explicitly prohibit that. BTW, this has been the case on Koelsch since
>> commit
>> 277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
>>
>> Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting
>> secondary CPU cores in debug mode" (included in all renesas-drivers
>> releases
>> during September) fix it for you?
>
> Thanks for your series patches.
> I have had some problems of receiving post mail from Linux-Renesas Mailing
> List recently.
>
> Could you please forward these series patches to me?
They're included in renesas-drivers.
You can also get them from gitweb at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/rcar-secondary-booting-in-debug-mode-v1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4
2016-09-30 9:58 ` Geert Uytterhoeven
@ 2016-09-30 10:05 ` Hiep Cao Minh
2016-11-07 9:44 ` Geert Uytterhoeven
0 siblings, 1 reply; 33+ messages in thread
From: Hiep Cao Minh @ 2016-09-30 10:05 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Geert,
>>> The issue you're seeing is due to a combination of commits
>>> 5f3bca0db8ac01a7
>>> ("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
>>> dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
>>>
>>> When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs
>>> may
>>> lock up the system after a cold boot, depending of boot load version.
>>> Hence
>>> we explicitly prohibit that. BTW, this has been the case on Koelsch since
>>> commit
>>> 277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
>>>
>>> Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting
>>> secondary CPU cores in debug mode" (included in all renesas-drivers
>>> releases
>>> during September) fix it for you?
>> Thanks for your series patches.
>> I have had some problems of receiving post mail from Linux-Renesas Mailing
>> List recently.
>>
>> Could you please forward these series patches to me?
> They're included in renesas-drivers.
> You can also get them from gitweb at
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/rcar-secondary-booting-in-debug-mode-v1
Thanks, I'll confirm these patches on my board.
Thank you.
Hiep.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
[not found] ` <9d9a647b-d75f-e89a-2d4d-55e409ccabae@jinso.co.jp>
@ 2016-10-18 13:17 ` Wolfram Sang
[not found] ` <b7e9b4c2-1d5d-2e76-c0f4-fcc50150dc30@jinso.co.jp>
2016-10-18 14:13 ` Laurent Pinchart
[not found] ` <58060015.3020702@jinso.co.jp>
2 siblings, 1 reply; 33+ messages in thread
From: Wolfram Sang @ 2016-10-18 13:17 UTC (permalink / raw)
To: Xuan Truong Nguyen, duclm, ryusuke.sakato.bx,
kuninori.morimoto.gx, magnus.damm, geert+renesas, h-inayoshi,
yoshihiro.shimoda.uh, nv-dung, cm-hiep, laurent.pinchart+renesas,
horms+renesas, linux-renesas-soc
Hi all,
> We have tested the linux stable v4.8 for Gen2 Koelsch and Lager
>
> So we would like to report the summary of the failure.
Thank you!
Is it possible to get access to the full logfiles? I am especially
interested in the backtraces after the Kernel oops or warning.
Kind regards,
Wolfram
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
[not found] ` <9d9a647b-d75f-e89a-2d4d-55e409ccabae@jinso.co.jp>
2016-10-18 13:17 ` The failure summary report of GEN2 for linux stable v4.8 Wolfram Sang
@ 2016-10-18 14:13 ` Laurent Pinchart
2016-10-18 15:55 ` Laurent Pinchart
` (2 more replies)
[not found] ` <58060015.3020702@jinso.co.jp>
2 siblings, 3 replies; 33+ messages in thread
From: Laurent Pinchart @ 2016-10-18 14:13 UTC (permalink / raw)
To: Xuan Truong Nguyen
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hello Truong,
On Tuesday 18 Oct 2016 19:06:52 Xuan Truong Nguyen wrote:
> Hi all,
>
> We have tested the linux stable v4.8 for Gen2 Koelsch and Lager
The document mentions that you have used shmobile_defconfig. However, that
configuration in v4.8 doesn't enable CONFIG_CMA, which causes at least the DU
driver to fail probing the device. I thus assume you have modified the
configuration to enable CMA. The fact that shmobile_defconfig doesn't include
the uvcvideo driver used by test 14 seems to confirm local modifications to
the configuration.
It would be useful to attach the kernel .config file to future reports to help
reproducing the test failures with the exact same configuration.
By the way, while at it, your e-mails are filtered out by the vger.kernel.org
server as they contain HTML. If you could send future reports without HTML it
would help them reaching the mailing list archive (although the presence of an
attachment might not be appreciated by vger.kernel.org, I'm not sure about
that).
> So we would like to report the summary of the failure.
Issue 8 ("Lager: bad image quality when shown on HDMI display") can't be
reproduced on my system when displaying a test pattern with the modetest
application. Could you please share more information on how to reproduce the
problem ?
Issue 11 ("VSP1:error message appears on initilization") has been introduced
in
commit 94fcdf829793b141dc93e20a2bbd9eeaa44ea25f
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Thu Feb 11 22:49:14 2016 -0200
[media] v4l: vsp1: Add FCP support
and fixed in
commit fd44aa9a254b18176ec3792a18e7de6977030ca8
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Wed Aug 17 09:57:37 2016 -0300
[media] v4l: rcar-fcp: Don't force users to check for disabled FCP support
The fix is available in v4.9-rc1. I've also submitted it for inclusion in the
v4.8 stable series.
Issue 14 ("USB-CAM: Warning message appears if remove the usb-camera cable
under using") is likely not a Renesas-specific problem, but as I'm the
maintainer of the uvcvideo webcam driver you used for testing I'll investigate
that.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-10-18 14:13 ` Laurent Pinchart
@ 2016-10-18 15:55 ` Laurent Pinchart
2016-10-19 2:39 ` Xuan Truong Nguyen
[not found] ` <a101cec4-c9ee-48fa-4f16-5e4cb2b8fab7@jinso.co.jp>
2 siblings, 0 replies; 33+ messages in thread
From: Laurent Pinchart @ 2016-10-18 15:55 UTC (permalink / raw)
To: Xuan Truong Nguyen
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hello,
On Tuesday 18 Oct 2016 17:13:32 Laurent Pinchart wrote:
[snip]
> Issue 14 ("USB-CAM: Warning message appears if remove the usb-camera cable
> under using") is likely not a Renesas-specific problem, but as I'm the
> maintainer of the uvcvideo webcam driver you used for testing I'll
> investigate that.
I confirm that this issue can be reproduced on an x86 machine running v4.4.6.
It isn't Renesas-specific.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN3(RCAR H3) for linux stable v4.8
[not found] ` <58060015.3020702@jinso.co.jp>
@ 2016-10-19 0:40 ` Kuninori Morimoto
2016-10-19 2:45 ` Xuan Truong Nguyen
[not found] ` <b4efb8cc-bf55-cf34-a537-4ffa5041291a@jinso.co.jp>
1 sibling, 1 reply; 33+ messages in thread
From: Kuninori Morimoto @ 2016-10-19 0:40 UTC (permalink / raw)
To: duclm
Cc: Xuan Truong Nguyen, ryusuke.sakato.bx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hi
> We have tested the linux stable v4.8 for Gen3(RCAR H3).
>
> So we would like to report the summary of the failure.
About 2 thermal issue, as you already know, fix patches are
applied. These should be solved in next version.
About sound unbind issue, ALSA SoC framework will be cleanuped
and upgraded soon. I talked this issue with ALSA SoC Maintainer
in this LinuxCon Europe timing, and we agreed about fixup idea.
Maybe it will be solved on +2 or +3 version.
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-10-18 14:13 ` Laurent Pinchart
2016-10-18 15:55 ` Laurent Pinchart
@ 2016-10-19 2:39 ` Xuan Truong Nguyen
[not found] ` <a101cec4-c9ee-48fa-4f16-5e4cb2b8fab7@jinso.co.jp>
2 siblings, 0 replies; 33+ messages in thread
From: Xuan Truong Nguyen @ 2016-10-19 2:39 UTC (permalink / raw)
To: Laurent Pinchart
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hello Laurent
> The document mentions that you have used shmobile_defconfig. However, that
> configuration in v4.8 doesn't enable CONFIG_CMA, which causes at least the DU
> driver to fail probing the device. I thus assume you have modified the
> configuration to enable CMA. The fact that shmobile_defconfig doesn't include
> the uvcvideo driver used by test 14 seems to confirm local modifications to
> the configuration.
We will retest it and report again.
> It would be useful to attach the kernel .config file to future reports to help
> reproducing the test failures with the exact same configuration.
Thank you. we will attach the configs file for each issue next time.
> By the way, while at it, your e-mails are filtered out by the vger.kernel.org
> server as they contain HTML. If you could send future reports without HTML it
> would help them reaching the mailing list archive (although the presence of an
> attachment might not be appreciated by vger.kernel.org, I'm not sure about
> that).
Thanks for your info. next time I will notice that.
> Issue 11 ("VSP1:error message appears on initilization") has been introduced
> in
Sorry about this. We will add more info in the detail (like Issue 10)
For Issue 14, if you need any information to debug, please lets us know.
thanks and best regards.
truong
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN3(RCAR H3) for linux stable v4.8
2016-10-19 0:40 ` The failure summary report of GEN3(RCAR H3) " Kuninori Morimoto
@ 2016-10-19 2:45 ` Xuan Truong Nguyen
0 siblings, 0 replies; 33+ messages in thread
From: Xuan Truong Nguyen @ 2016-10-19 2:45 UTC (permalink / raw)
To: Kuninori Morimoto, duclm
Cc: ryusuke.sakato.bx, magnus.damm, geert+renesas, h-inayoshi,
yoshihiro.shimoda.uh, nv-dung, cm-hiep, laurent.pinchart+renesas,
horms+renesas, linux-renesas-soc, wsa
Hi Morimoto
> About 2 thermal issue, as you already know, fix patches are
> applied. These should be solved in next version.
I will understand that you are talking about t thermal issue on Gen2.
(is that right ?)
Sorry about this, we are just report the issue still happened in v4.8.
we also marked that
the fix patch were already posted to ML in the detail info.
> About sound unbind issue, ALSA SoC framework will be cleanuped
> and upgraded soon. I talked this issue with ALSA SoC Maintainer
> in this LinuxCon Europe timing, and we agreed about fixup idea.
> Maybe it will be solved on +2 or +3 version.
thanks for your information.
best regards
truong
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
[not found] ` <a101cec4-c9ee-48fa-4f16-5e4cb2b8fab7@jinso.co.jp>
@ 2016-10-21 11:20 ` Laurent Pinchart
2016-10-24 5:51 ` Xuan Truong Nguyen
2016-11-11 1:31 ` Laurent Pinchart
0 siblings, 2 replies; 33+ messages in thread
From: Laurent Pinchart @ 2016-10-21 11:20 UTC (permalink / raw)
To: Xuan Truong Nguyen
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hi Truong,
On Friday 21 Oct 2016 19:53:47 Xuan Truong Nguyen wrote:
> Hello Laurent.
>
> > The document mentions that you have used shmobile_defconfig. However, that
> > configuration in v4.8 doesn't enable CONFIG_CMA, which causes at least the
> > DU driver to fail probing the device. I thus assume you have modified the
> > configuration to enable CMA. The fact that shmobile_defconfig doesn't
> > include the uvcvideo driver used by test 14 seems to confirm local
> > modifications to the configuration.
> > Issue 8 ("Lager: bad image quality when shown on HDMI display") can't be
> > reproduced on my system when displaying a test pattern with the modetest
> > application. Could you please share more information on how to reproduce
> > the problem ?
>
> We retested this issue No 8 again with the CONFIG_CMA enabled but the
> result is the same. you could see it by the error.jpg image in attachments.
> the display device used is Panasonic TH-L19C3 (refer the device.jpg). we
> also send you my configs file, too (lager_du.config).
Thank you for the information, I'll try to reproduce the problem here with
your kernel configuration.
> just one more thing, with CONFIG_CMA enabled, the driver fails on
> probing if we boot the board without the HDMI cable inserted in advance.
> we have to insert the cable before booting the board. and not all the
> display work with current HDMI driver (as our LG display will not work)
> we are using the mainline upstream version 4.8
Interesting, I'll check that too.
> if you need any information to debug, please lets us know.
Could you please tell me what you're using to test the display ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-10-21 11:20 ` Laurent Pinchart
@ 2016-10-24 5:51 ` Xuan Truong Nguyen
2016-11-11 1:31 ` Laurent Pinchart
1 sibling, 0 replies; 33+ messages in thread
From: Xuan Truong Nguyen @ 2016-10-24 5:51 UTC (permalink / raw)
To: Laurent Pinchart
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hi laurent.
> Could you please tell me what you're using to test the display ?
Sorry if I misunderstand what you wanted to know.
I'm using the LG 23MP48HQ-P and VIERA TH-L19C3-P - Panasonic (White)
http://www.lg.com/ca_en/desktop-monitors/lg-23MP48HQ-P
http://panasonic.jp/viera/p-db/TH-L19C3.html
I tested using the command: bmap /dev/fb0 picture.bmp
on M2 board (Koelsch) the image is displayed clearly.
but on H2 board (Lager) the image is displayed not clearly.
I also retested on V4.9-rc2 and something weird happened.
for VIERA TH-L19C3-P:
- if I boot the board before inserting the cable, the display is not
working.
- but if I inserted the cable before booting, it works, but the image is
not displayed clearly.
for LG 23MP48HQ-P:
- if I boot the board before inserting the cable, the driver probes
successfully.
but after inserting the cable, the display almost does not work (no signal).
- if I boot the board with the cable inserted in advance, the driver
fails on probe.
I checked with dmesg:
root@linaro-nano:~# dmesg | grep rcar-du
[ 5.749231] rcar-du feb00000.display: failed to allocate buffer with
size 8294400
[ 5.771675] rcar-du feb00000.display: Failed to set initial hw
configuration.
[ 5.793075] rcar-du fdmesg | grep rcar-dueb00000.display: failed to
initialize DRM/KMS (-12)
[ 5.813564] rcar-du: probe of feb00000.display failed with error -12
root@linaro-nano:~#
The cables are ok, two screens work normally on Ubuntu.
thanks and best regards
JINSO/Truong
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
[not found] ` <b7e9b4c2-1d5d-2e76-c0f4-fcc50150dc30@jinso.co.jp>
@ 2016-10-24 7:00 ` Geert Uytterhoeven
[not found] ` <125b4831-cbdf-f8e1-da97-8ea9cf458c22@jinso.co.jp>
0 siblings, 1 reply; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-10-24 7:00 UTC (permalink / raw)
To: Xuan Truong Nguyen
Cc: Wolfram Sang, duclm, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, 稲吉,
Yoshihiro Shimoda, Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas
Hi Truong,
On Wed, Oct 19, 2016 at 4:20 AM, Xuan Truong Nguyen
<nx-truong@jinso.co.jp> wrote:
> For Issue 9 (related to SCIF) we'll describe how we reproduce that as below:
> on the controller console minicom (ttySC0 on board) we execute the command
> #stty -F /dev/ttySC1 speed 38400 cs8 -cstopb;cat /dev/ttySC1
> then we send the 10M file from the host PC to ttySC1 via gtkterm program.
> the 10M file must contain a lot of lines ( \n character ) as we created by
> #< /dev/urandom tr -dc "a-zA-Z0-9\n" | head -c"$size" > file10M.txt
> every thing runs normally for a while (after about 2/3 of data was
> transmitted), then the kernel hangs up. some time the warning message is
> output.
This is with shmobile_defconfig?
Does it work better if you enable CONFIG_SERIAL_SH_SCI_DMA?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
[not found] ` <125b4831-cbdf-f8e1-da97-8ea9cf458c22@jinso.co.jp>
@ 2016-10-24 9:21 ` Geert Uytterhoeven
2016-10-25 2:07 ` Xuan Truong Nguyen
2016-10-28 8:14 ` Yoshihiro Shimoda
0 siblings, 2 replies; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-10-24 9:21 UTC (permalink / raw)
To: Xuan Truong Nguyen
Cc: Wolfram Sang, duclm, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, 稲吉,
Yoshihiro Shimoda, Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Niklas Söderlund
On Mon, Oct 24, 2016 at 11:13 AM, Xuan Truong Nguyen
<nx-truong@jinso.co.jp> wrote:
>> This is with shmobile_defconfig?
>
> yes. we also attach the configs file we used
> (lager-scif-pio-v4.9-rc2.config)
>
>> Does it work better if you enable CONFIG_SERIAL_SH_SCI_DMA?
>
> yes, it's better a little bit. the kernel does not hangs up, but the warning
> message is output.
> please refer lager-scif-dma.log.
>
> we tested on v4.9-rc2. the issue is the same.
>
> if you need any information, please let us know.
> WARNING: CPU: 0 PID: 2249 at drivers/dma/sh/rcar-dmac.c:1257 rcar_dmac_tx_status+0x128/0x4
> No descriptor for cookie!
> [<c03419e8>] (rcar_dmac_tx_status) from [<c0371e04>] (rx_timer_fn+0x48/0x148)
> [<c0371dbc>] (rx_timer_fn) from [<c016dedc>] (call_timer_fn+0x2c/0xa0)
That looks like a race condition between timeout handling and actual completion
of the DMA?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-10-24 9:21 ` Geert Uytterhoeven
@ 2016-10-25 2:07 ` Xuan Truong Nguyen
2016-10-28 8:14 ` Yoshihiro Shimoda
1 sibling, 0 replies; 33+ messages in thread
From: Xuan Truong Nguyen @ 2016-10-25 2:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wolfram Sang, duclm, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, 稲吉,
Yoshihiro Shimoda, Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Niklas Söderlund
Hi Geert
> That looks like a race condition between timeout handling and actual completion
> of the DMA?
Sorry, I don't know exactly what you mean.
We use the baudrate of 38400 for all. (ttySC0, ttySC1,ttyUSB0,ttyUSB1).
The transfer works normally for a while before the warning message is
output.
Thanks and best regards
JINSO/Truong
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: The failure summary report of GEN2 for linux stable v4.8
2016-10-24 9:21 ` Geert Uytterhoeven
2016-10-25 2:07 ` Xuan Truong Nguyen
@ 2016-10-28 8:14 ` Yoshihiro Shimoda
2016-10-28 10:29 ` Xuan Truong Nguyen
2016-11-07 0:30 ` Xuan Truong Nguyen
1 sibling, 2 replies; 33+ messages in thread
From: Yoshihiro Shimoda @ 2016-10-28 8:14 UTC (permalink / raw)
To: Geert Uytterhoeven, Xuan Truong Nguyen
Cc: Wolfram Sang, duclm, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, hideo inayoshi,
Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Niklas Söderlund
Hi Geert-san, Xuan-san,
> From: linux-renesas-soc-owner@vger.kernel.org [mailto:linux-renesas-soc-owner@vger.kernel.org] On Behalf Of Geert
> Uytterhoeven
> Sent: Monday, October 24, 2016 6:21 PM
>
> On Mon, Oct 24, 2016 at 11:13 AM, Xuan Truong Nguyen
> <nx-truong@jinso.co.jp> wrote:
> >> This is with shmobile_defconfig?
> >
> > yes. we also attach the configs file we used
> > (lager-scif-pio-v4.9-rc2.config)
> >
> >> Does it work better if you enable CONFIG_SERIAL_SH_SCI_DMA?
> >
> > yes, it's better a little bit. the kernel does not hangs up, but the warning
> > message is output.
> > please refer lager-scif-dma.log.
> >
> > we tested on v4.9-rc2. the issue is the same.
> >
> > if you need any information, please let us know.
>
> > WARNING: CPU: 0 PID: 2249 at drivers/dma/sh/rcar-dmac.c:1257 rcar_dmac_tx_status+0x128/0x4
> > No descriptor for cookie!
>
> > [<c03419e8>] (rcar_dmac_tx_status) from [<c0371e04>] (rx_timer_fn+0x48/0x148)
>
> > [<c0371dbc>] (rx_timer_fn) from [<c016dedc>] (call_timer_fn+0x2c/0xa0)
>
> That looks like a race condition between timeout handling and actual completion
> of the DMA?
I found an issue in sh-sci.c and made a patch to resolve it.
But, I'm not sure this is correct way.
If this is correct way, we also have to fix dev_dbg() in some functions.
Best regards,
Yoshihiro Shimoda
Since I send this email using Outlook, the patch format may be not good.
---
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Fri, 28 Oct 2016 16:52:36 +0900
Subject: [PATCH] serial: sh-sci: remove dev_warn() to avoid double spin lock
held
If we use serial console and CONFIG_SERIAL_SH_SCI_DMA=y, since
sci_dma_rx_push() is called with port->lock held and dev_warn() will
call serial_console_write() finally, this is possible to call
spin_lock{_irqsave}() twice.
To avoid this, this patch remove dev_warn() in sci_dma_rx_push().
Reported-by: Xuan Truong Nguyen <nx-truong@jinso.co.jp>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/tty/serial/sh-sci.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 4b26252..380b5d7 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1142,11 +1142,8 @@ static int sci_dma_rx_push(struct sci_port *s, void *buf, size_t count)
int copied;
copied = tty_insert_flip_string(tport, buf, count);
- if (copied < count) {
- dev_warn(port->dev, "Rx overrun: dropping %zu bytes\n",
- count - copied);
+ if (copied < count)
port->icount.buf_overrun++;
- }
port->icount.rx += copied;
--
1.9.1
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-10-28 8:14 ` Yoshihiro Shimoda
@ 2016-10-28 10:29 ` Xuan Truong Nguyen
2016-11-07 0:30 ` Xuan Truong Nguyen
1 sibling, 0 replies; 33+ messages in thread
From: Xuan Truong Nguyen @ 2016-10-28 10:29 UTC (permalink / raw)
To: Yoshihiro Shimoda, Geert Uytterhoeven
Cc: Wolfram Sang, duclm, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, hideo inayoshi,
Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Niklas Söderlund
Hi Shimoda-san
Thanks for your patch.
We will apply your patch and retest this issue on v4.9-rc2 then report
you again.
Thanks and best regards
JINSO/Truong
On 2016年10月28日 17:14, Yoshihiro Shimoda wrote:
> Hi Geert-san, Xuan-san,
>
>> From: linux-renesas-soc-owner@vger.kernel.org [mailto:linux-renesas-soc-owner@vger.kernel.org] On Behalf Of Geert
>> Uytterhoeven
>> Sent: Monday, October 24, 2016 6:21 PM
>>
>> On Mon, Oct 24, 2016 at 11:13 AM, Xuan Truong Nguyen
>> <nx-truong@jinso.co.jp> wrote:
>>>> This is with shmobile_defconfig?
>>> yes. we also attach the configs file we used
>>> (lager-scif-pio-v4.9-rc2.config)
>>>
>>>> Does it work better if you enable CONFIG_SERIAL_SH_SCI_DMA?
>>> yes, it's better a little bit. the kernel does not hangs up, but the warning
>>> message is output.
>>> please refer lager-scif-dma.log.
>>>
>>> we tested on v4.9-rc2. the issue is the same.
>>>
>>> if you need any information, please let us know.
>>> WARNING: CPU: 0 PID: 2249 at drivers/dma/sh/rcar-dmac.c:1257 rcar_dmac_tx_status+0x128/0x4
>>> No descriptor for cookie!
>>> [<c03419e8>] (rcar_dmac_tx_status) from [<c0371e04>] (rx_timer_fn+0x48/0x148)
>>> [<c0371dbc>] (rx_timer_fn) from [<c016dedc>] (call_timer_fn+0x2c/0xa0)
>> That looks like a race condition between timeout handling and actual completion
>> of the DMA?
> I found an issue in sh-sci.c and made a patch to resolve it.
> But, I'm not sure this is correct way.
> If this is correct way, we also have to fix dev_dbg() in some functions.
>
> Best regards,
> Yoshihiro Shimoda
>
> Since I send this email using Outlook, the patch format may be not good.
> ---
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Date: Fri, 28 Oct 2016 16:52:36 +0900
> Subject: [PATCH] serial: sh-sci: remove dev_warn() to avoid double spin lock
> held
>
> If we use serial console and CONFIG_SERIAL_SH_SCI_DMA=y, since
> sci_dma_rx_push() is called with port->lock held and dev_warn() will
> call serial_console_write() finally, this is possible to call
> spin_lock{_irqsave}() twice.
> To avoid this, this patch remove dev_warn() in sci_dma_rx_push().
>
> Reported-by: Xuan Truong Nguyen <nx-truong@jinso.co.jp>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> drivers/tty/serial/sh-sci.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 4b26252..380b5d7 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1142,11 +1142,8 @@ static int sci_dma_rx_push(struct sci_port *s, void *buf, size_t count)
> int copied;
>
> copied = tty_insert_flip_string(tport, buf, count);
> - if (copied < count) {
> - dev_warn(port->dev, "Rx overrun: dropping %zu bytes\n",
> - count - copied);
> + if (copied < count)
> port->icount.buf_overrun++;
> - }
>
> port->icount.rx += copied;
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2
[not found] ` <b4efb8cc-bf55-cf34-a537-4ffa5041291a@jinso.co.jp>
@ 2016-10-31 13:16 ` Geert Uytterhoeven
2016-11-02 1:29 ` duclm
0 siblings, 1 reply; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 13:16 UTC (permalink / raw)
To: duclm
Cc: Xuan Truong Nguyen, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, 稲吉,
Yoshihiro Shimoda, Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Wolfram Sang
Hi Duc-san,
On Mon, Oct 31, 2016 at 2:10 PM, duclm <lm-duc@jinso.co.jp> wrote:
> We have tested the linux upstream v4.9-rc2 for Gen3(RCAR H3).
>
> So we would like to report the summary of the failure.
Issue 1 ("PM: Automatically resumes after suspending system. "): suspend
and resume are handled by PSCI. To gix the issue, you have to upgrade the
firmware to v2.12.0, and follow the accompanying procedures to prepare the
system for suspend, and to resume.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2
2016-10-31 13:16 ` The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2 Geert Uytterhoeven
@ 2016-11-02 1:29 ` duclm
2016-11-02 7:46 ` Geert Uytterhoeven
0 siblings, 1 reply; 33+ messages in thread
From: duclm @ 2016-11-02 1:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xuan Truong Nguyen, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, 稲吉,
Yoshihiro Shimoda, Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Wolfram Sang
Dear Mr Geert,
Thank you for your information.
Sorry for my stupid question, could you tell me what kind of firmware
(v2.12.0) are you mentioning?
On 2016年10月31日 22:16, Geert Uytterhoeven wrote:
> Hi Duc-san,
>
> On Mon, Oct 31, 2016 at 2:10 PM, duclm <lm-duc@jinso.co.jp> wrote:
>> We have tested the linux upstream v4.9-rc2 for Gen3(RCAR H3).
>>
>> So we would like to report the summary of the failure.
> Issue 1 ("PM: Automatically resumes after suspending system. "): suspend
> and resume are handled by PSCI. To gix the issue, you have to upgrade the
> firmware to v2.12.0, and follow the accompanying procedures to prepare the
> system for suspend, and to resume.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2
2016-11-02 1:29 ` duclm
@ 2016-11-02 7:46 ` Geert Uytterhoeven
0 siblings, 0 replies; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-11-02 7:46 UTC (permalink / raw)
To: duclm
Cc: Xuan Truong Nguyen, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, 稲吉,
Yoshihiro Shimoda, Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Wolfram Sang
Hi Duc-san,
On Wed, Nov 2, 2016 at 2:29 AM, duclm <lm-duc@jinso.co.jp> wrote:
> Sorry for my stupid question, could you tell me what kind of firmware
> (v2.12.0) are you mentioning?
I mean the firmware for the Salvator-X board, containing the various stages
of boot loaders.
> On 2016年10月31日 22:16, Geert Uytterhoeven wrote:
>> On Mon, Oct 31, 2016 at 2:10 PM, duclm <lm-duc@jinso.co.jp> wrote:
>>> We have tested the linux upstream v4.9-rc2 for Gen3(RCAR H3).
>>>
>>> So we would like to report the summary of the failure.
>>
>> Issue 1 ("PM: Automatically resumes after suspending system. "): suspend
>> and resume are handled by PSCI. To gix the issue, you have to upgrade the
>> firmware to v2.12.0, and follow the accompanying procedures to prepare the
>> system for suspend, and to resume.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-10-28 8:14 ` Yoshihiro Shimoda
2016-10-28 10:29 ` Xuan Truong Nguyen
@ 2016-11-07 0:30 ` Xuan Truong Nguyen
1 sibling, 0 replies; 33+ messages in thread
From: Xuan Truong Nguyen @ 2016-11-07 0:30 UTC (permalink / raw)
To: Yoshihiro Shimoda, Geert Uytterhoeven
Cc: Wolfram Sang, duclm, Ryusuke Sakato, Kuninori Morimoto,
Magnus Damm, Geert Uytterhoeven, hideo inayoshi,
Dung:人ソ,
Cao Minh Hiep, Laurent Pinchart, Simon Horman, Linux-Renesas,
Niklas Söderlund
Hi. I confirm that the patch from Shimoda-san works ok on V4.9-rc2
with CONFIG_SERIAL_SH_SCI_DMA enabled.
On 2016年10月28日 17:14, Yoshihiro Shimoda wrote:
> Hi Geert-san, Xuan-san,
>
>> From: linux-renesas-soc-owner@vger.kernel.org [mailto:linux-renesas-soc-owner@vger.kernel.org] On Behalf Of Geert
>> Uytterhoeven
>> Sent: Monday, October 24, 2016 6:21 PM
>>
>> On Mon, Oct 24, 2016 at 11:13 AM, Xuan Truong Nguyen
>> <nx-truong@jinso.co.jp> wrote:
>>>> This is with shmobile_defconfig?
>>> yes. we also attach the configs file we used
>>> (lager-scif-pio-v4.9-rc2.config)
>>>
>>>> Does it work better if you enable CONFIG_SERIAL_SH_SCI_DMA?
>>> yes, it's better a little bit. the kernel does not hangs up, but the warning
>>> message is output.
>>> please refer lager-scif-dma.log.
>>>
>>> we tested on v4.9-rc2. the issue is the same.
>>>
>>> if you need any information, please let us know.
>>> WARNING: CPU: 0 PID: 2249 at drivers/dma/sh/rcar-dmac.c:1257 rcar_dmac_tx_status+0x128/0x4
>>> No descriptor for cookie!
>>> [<c03419e8>] (rcar_dmac_tx_status) from [<c0371e04>] (rx_timer_fn+0x48/0x148)
>>> [<c0371dbc>] (rx_timer_fn) from [<c016dedc>] (call_timer_fn+0x2c/0xa0)
>> That looks like a race condition between timeout handling and actual completion
>> of the DMA?
> I found an issue in sh-sci.c and made a patch to resolve it.
> But, I'm not sure this is correct way.
> If this is correct way, we also have to fix dev_dbg() in some functions.
>
> Best regards,
> Yoshihiro Shimoda
>
> Since I send this email using Outlook, the patch format may be not good.
> ---
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Date: Fri, 28 Oct 2016 16:52:36 +0900
> Subject: [PATCH] serial: sh-sci: remove dev_warn() to avoid double spin lock
> held--
>
> さん
>
> おはいようございます。ベトナムのチュオンです。
> いつもお世話になっております。
>
> では、よろしくお願い致します。
>
> チュオン
> nx-truong
>
>
> If we use serial console and CONFIG_SERIAL_SH_SCI_DMA=y, since
> sci_dma_rx_push() is called with port->lock held and dev_warn() will
> call serial_console_write() finally, this is possible to call
> spin_lock{_irqsave}() twice.
> To avoid this, this patch remove dev_warn() in sci_dma_rx_push().
>
> Reported-by: Xuan Truong Nguyen <nx-truong@jinso.co.jp>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> drivers/tty/serial/sh-sci.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 4b26252..380b5d7 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1142,11 +1142,8 @@ static int sci_dma_rx_push(struct sci_port *s, void *buf, size_t count)
> int copied;
>
> copied = tty_insert_flip_string(tport, buf, count);
> - if (copied < count) {
> - dev_warn(port->dev, "Rx overrun: dropping %zu bytes\n",
> - count - copied);
> + if (copied < count)
> port->icount.buf_overrun++;
> - }
>
> port->icount.rx += copied;
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4
2016-09-30 10:05 ` Hiep Cao Minh
@ 2016-11-07 9:44 ` Geert Uytterhoeven
2016-11-07 10:37 ` Hiep Cao Minh
0 siblings, 1 reply; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-11-07 9:44 UTC (permalink / raw)
To: Hiep Cao Minh
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Hiep,
On Fri, Sep 30, 2016 at 12:05 PM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
>>>> The issue you're seeing is due to a combination of commits
>>>> 5f3bca0db8ac01a7
>>>> ("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
>>>> dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
>>>>
>>>> When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs
>>>> may
>>>> lock up the system after a cold boot, depending of boot load version.
>>>> Hence
>>>> we explicitly prohibit that. BTW, this has been the case on Koelsch
>>>> since
>>>> commit
>>>> 277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
>>>>
>>>> Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow
>>>> booting
>>>> secondary CPU cores in debug mode" (included in all renesas-drivers
>>>> releases
>>>> during September) fix it for you?
>>>
>>> Thanks for your series patches.
>>> I have had some problems of receiving post mail from Linux-Renesas
>>> Mailing
>>> List recently.
>>>
>>> Could you please forward these series patches to me?
>>
>> They're included in renesas-drivers.
>> You can also get them from gitweb at
>>
>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/rcar-secondary-booting-in-debug-mode-v1
>
> Thanks, I'll confirm these patches on my board.
Have you tried this series on your Lager? If yes, can I add your Tested-by?
Which ES version of R-Car H1 do you have? If you don't know, you can
tell me the result of "md.l 0xff000044 1" in U-Boot.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4
2016-11-07 9:44 ` Geert Uytterhoeven
@ 2016-11-07 10:37 ` Hiep Cao Minh
2016-11-07 12:19 ` Geert Uytterhoeven
0 siblings, 1 reply; 33+ messages in thread
From: Hiep Cao Minh @ 2016-11-07 10:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Geert
On 11/07/2016 06:44 PM, Geert Uytterhoeven wrote:
> Hi Hiep,
>
> On Fri, Sep 30, 2016 at 12:05 PM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
>>>>> The issue you're seeing is due to a combination of commits
>>>>> 5f3bca0db8ac01a7
>>>>> ("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
>>>>> dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
>>>>>
>>>>> When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs
>>>>> may
>>>>> lock up the system after a cold boot, depending of boot load version.
>>>>> Hence
>>>>> we explicitly prohibit that. BTW, this has been the case on Koelsch
>>>>> since
>>>>> commit
>>>>> 277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
>>>>>
>>>>> Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow
>>>>> booting
>>>>> secondary CPU cores in debug mode" (included in all renesas-drivers
>>>>> releases
>>>>> during September) fix it for you?
>>>> Thanks for your series patches.
>>>> I have had some problems of receiving post mail from Linux-Renesas
>>>> Mailing
>>>> List recently.
>>>>
>>>> Could you please forward these series patches to me?
>>> They're included in renesas-drivers.
>>> You can also get them from gitweb at
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/rcar-secondary-booting-in-debug-mode-v1
>> Thanks, I'll confirm these patches on my board.
> Have you tried this series on your Lager? If yes, can I add your Tested-by?
Sorry for the late reply!.
I have totally forgotten my reporting test result to you.
I have tested this series on my Lager board. The bug has been fixed.
> Which ES version of R-Car H1 do you have? If you don't know, you can
> tell me the result of "md.l 0xff000044 1" in U-Boot.
My board information:
LAGER SPI_LOADER V0.28 2014.09.29
DEVICE S25FL512
U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)
CPU: Renesas Electronics R8A7790 rev 2.0
-----
=> md.l 0xff000044 1
ff000044: 00004510 .E..
----
Thanks,
Jinzai Solution Inc,
Hiep.
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4
2016-11-07 10:37 ` Hiep Cao Minh
@ 2016-11-07 12:19 ` Geert Uytterhoeven
0 siblings, 0 replies; 33+ messages in thread
From: Geert Uytterhoeven @ 2016-11-07 12:19 UTC (permalink / raw)
To: Hiep Cao Minh
Cc: Xuan Truong Nguyen, Laurent Pinchart, duclm, Ryusuke Sakato,
Kuninori Morimoto, Magnus Damm, Geert Uytterhoeven,
稲吉, Yoshihiro Shimoda, Dung:人ソ,
Simon Horman, Linux-Renesas, Wolfram Sang
Hi Hiep,
On Mon, Nov 7, 2016 at 11:37 AM, Hiep Cao Minh <cm-hiep@jinso.co.jp> wrote:
> On 11/07/2016 06:44 PM, Geert Uytterhoeven wrote:
>> On Fri, Sep 30, 2016 at 12:05 PM, Hiep Cao Minh <cm-hiep@jinso.co.jp>
>> wrote:
>>>>>>
>>>>>> The issue you're seeing is due to a combination of commits
>>>>>> 5f3bca0db8ac01a7
>>>>>> ("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
>>>>>> dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
>>>>>>
>>>>>> When debug mode is enabled (SW8-4 = OFF), trying to boot secondary
>>>>>> CPUs
>>>>>> may
>>>>>> lock up the system after a cold boot, depending of boot load version.
>>>>>> Hence
>>>>>> we explicitly prohibit that. BTW, this has been the case on Koelsch
>>>>>> since
>>>>>> commit
>>>>>> 277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
>>>>>>
>>>>>> Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow
>>>>>> booting
>>>>>> secondary CPU cores in debug mode" (included in all renesas-drivers
>>>>>> releases
>>>>>> during September) fix it for you?
>>>>>
>>>>> Thanks for your series patches.
>>>>> I have had some problems of receiving post mail from Linux-Renesas
>>>>> Mailing
>>>>> List recently.
>>>>>
>>>>> Could you please forward these series patches to me?
>>>>
>>>> They're included in renesas-drivers.
>>>> You can also get them from gitweb at
>>>>
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/rcar-secondary-booting-in-debug-mode-v1
>>>
>>> Thanks, I'll confirm these patches on my board.
>>
>> Have you tried this series on your Lager? If yes, can I add your
>> Tested-by?
>
> Sorry for the late reply!.
> I have totally forgotten my reporting test result to you.
> I have tested this series on my Lager board. The bug has been fixed.
Thanks, I will add your Tested-by.
>> Which ES version of R-Car H1 do you have? If you don't know, you can
>> tell me the result of "md.l 0xff000044 1" in U-Boot.
>
> My board information:
> LAGER SPI_LOADER V0.28 2014.09.29
> DEVICE S25FL512
>
>
> U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)
>
> CPU: Renesas Electronics R8A7790 rev 2.0
> -----
> => md.l 0xff000044 1
> ff000044: 00004510 .E..
R-Car H2 ES2.0.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-10-21 11:20 ` Laurent Pinchart
2016-10-24 5:51 ` Xuan Truong Nguyen
@ 2016-11-11 1:31 ` Laurent Pinchart
2016-11-11 2:44 ` Xuan Truong Nguyen
1 sibling, 1 reply; 33+ messages in thread
From: Laurent Pinchart @ 2016-11-11 1:31 UTC (permalink / raw)
To: Xuan Truong Nguyen
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hello Truong,
On Friday 21 Oct 2016 14:20:24 Laurent Pinchart wrote:
> On Friday 21 Oct 2016 19:53:47 Xuan Truong Nguyen wrote:
> > Hello Laurent.
> >
> > > The document mentions that you have used shmobile_defconfig. However,
> > > that configuration in v4.8 doesn't enable CONFIG_CMA, which causes at
> > > least the DU driver to fail probing the device. I thus assume you have
> > > modified the configuration to enable CMA. The fact that
> > > shmobile_defconfig doesn't include the uvcvideo driver used by test 14
> > > seems to confirm local modifications to the configuration.
> > > Issue 8 ("Lager: bad image quality when shown on HDMI display") can't be
> > > reproduced on my system when displaying a test pattern with the modetest
> > > application. Could you please share more information on how to reproduce
> > > the problem ?
> >
> > We retested this issue No 8 again with the CONFIG_CMA enabled but the
> > result is the same. you could see it by the error.jpg image in
> > attachments. the display device used is Panasonic TH-L19C3 (refer the
> > device.jpg). we also send you my configs file, too (lager_du.config).
>
> Thank you for the information, I'll try to reproduce the problem here with
> your kernel configuration.
I've been able to reproduce the problem here, and at this point I'm not sure
what goes wrong. I've tested older kernels up to the point where HDMI support
for Lager was introduced, and the bug was present in all of them. I'll try to
fix it, but I have other higher priority tasks at the moment.
> > just one more thing, with CONFIG_CMA enabled, the driver fails on
> > probing if we boot the board without the HDMI cable inserted in advance.
> > we have to insert the cable before booting the board. and not all the
> > display work with current HDMI driver (as our LG display will not work)
> > we are using the mainline upstream version 4.8
>
> Interesting, I'll check that too.
I haven't had time to check this yet.
> > if you need any information to debug, please lets us know.
>
> Could you please tell me what you're using to test the display ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: The failure summary report of GEN2 for linux stable v4.8
2016-11-11 1:31 ` Laurent Pinchart
@ 2016-11-11 2:44 ` Xuan Truong Nguyen
0 siblings, 0 replies; 33+ messages in thread
From: Xuan Truong Nguyen @ 2016-11-11 2:44 UTC (permalink / raw)
To: Laurent Pinchart
Cc: duclm, ryusuke.sakato.bx, kuninori.morimoto.gx, magnus.damm,
geert+renesas, h-inayoshi, yoshihiro.shimoda.uh, nv-dung,
cm-hiep, laurent.pinchart+renesas, horms+renesas,
linux-renesas-soc, wsa
Hi Laurent
please check this when you have time.
If you need any information, let us know.
thanks and best regard
JINSO/Truong
On 2016年11月11日 10:31, Laurent Pinchart wrote:
> Hello Truong,
>
> On Friday 21 Oct 2016 14:20:24 Laurent Pinchart wrote:
>> On Friday 21 Oct 2016 19:53:47 Xuan Truong Nguyen wrote:
>>> Hello Laurent.
>>>
>>>> The document mentions that you have used shmobile_defconfig. However,
>>>> that configuration in v4.8 doesn't enable CONFIG_CMA, which causes at
>>>> least the DU driver to fail probing the device. I thus assume you have
>>>> modified the configuration to enable CMA. The fact that
>>>> shmobile_defconfig doesn't include the uvcvideo driver used by test 14
>>>> seems to confirm local modifications to the configuration.
>>>> Issue 8 ("Lager: bad image quality when shown on HDMI display") can't be
>>>> reproduced on my system when displaying a test pattern with the modetest
>>>> application. Could you please share more information on how to reproduce
>>>> the problem ?
>>> We retested this issue No 8 again with the CONFIG_CMA enabled but the
>>> result is the same. you could see it by the error.jpg image in
>>> attachments. the display device used is Panasonic TH-L19C3 (refer the
>>> device.jpg). we also send you my configs file, too (lager_du.config).
>> Thank you for the information, I'll try to reproduce the problem here with
>> your kernel configuration.
> I've been able to reproduce the problem here, and at this point I'm not sure
> what goes wrong. I've tested older kernels up to the point where HDMI support
> for Lager was introduced, and the bug was present in all of them. I'll try to
> fix it, but I have other higher priority tasks at the moment.
>
>>> just one more thing, with CONFIG_CMA enabled, the driver fails on
>>> probing if we boot the board without the HDMI cable inserted in advance.
>>> we have to insert the cable before booting the board. and not all the
>>> display work with current HDMI driver (as our LG display will not work)
>>> we are using the mainline upstream version 4.8
>> Interesting, I'll check that too.
> I haven't had time to check this yet.
>
>>> if you need any information to debug, please lets us know.
>> Could you please tell me what you're using to test the display ?
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2016-11-11 2:44 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <57A46D20.7040106@jinso.co.jp>
[not found] ` <57C9764F.2070802@jinso.co.jp>
[not found] ` <f2bb791e-8973-10a9-a2ac-1a944b38d4ad@jinso.co.jp>
2016-09-12 8:57 ` GEN2: Initialization of VSP1 failed at upstream v4.8-rc2 Hiep Cao Minh
2016-09-12 9:06 ` Geert Uytterhoeven
2016-09-12 9:25 ` Hiep Cao Minh
2016-09-12 10:31 ` Laurent Pinchart
[not found] ` <57ECF4EA.4010704@jinso.co.jp>
2016-09-29 13:40 ` GEN2:Lager: Only 1 core works when turning off the SW8-PIN4 Geert Uytterhoeven
2016-09-30 9:55 ` Hiep Cao Minh
2016-09-30 9:58 ` Geert Uytterhoeven
2016-09-30 10:05 ` Hiep Cao Minh
2016-11-07 9:44 ` Geert Uytterhoeven
2016-11-07 10:37 ` Hiep Cao Minh
2016-11-07 12:19 ` Geert Uytterhoeven
2016-09-12 9:33 ` GEN2: Initialization of VIN failed at upstream v4.8-rc2 Hiep Cao Minh
2016-09-12 11:09 ` Niklas Söderlund
2016-09-13 5:12 ` Hiep Cao Minh
[not found] ` <9d9a647b-d75f-e89a-2d4d-55e409ccabae@jinso.co.jp>
2016-10-18 13:17 ` The failure summary report of GEN2 for linux stable v4.8 Wolfram Sang
[not found] ` <b7e9b4c2-1d5d-2e76-c0f4-fcc50150dc30@jinso.co.jp>
2016-10-24 7:00 ` Geert Uytterhoeven
[not found] ` <125b4831-cbdf-f8e1-da97-8ea9cf458c22@jinso.co.jp>
2016-10-24 9:21 ` Geert Uytterhoeven
2016-10-25 2:07 ` Xuan Truong Nguyen
2016-10-28 8:14 ` Yoshihiro Shimoda
2016-10-28 10:29 ` Xuan Truong Nguyen
2016-11-07 0:30 ` Xuan Truong Nguyen
2016-10-18 14:13 ` Laurent Pinchart
2016-10-18 15:55 ` Laurent Pinchart
2016-10-19 2:39 ` Xuan Truong Nguyen
[not found] ` <a101cec4-c9ee-48fa-4f16-5e4cb2b8fab7@jinso.co.jp>
2016-10-21 11:20 ` Laurent Pinchart
2016-10-24 5:51 ` Xuan Truong Nguyen
2016-11-11 1:31 ` Laurent Pinchart
2016-11-11 2:44 ` Xuan Truong Nguyen
[not found] ` <58060015.3020702@jinso.co.jp>
2016-10-19 0:40 ` The failure summary report of GEN3(RCAR H3) " Kuninori Morimoto
2016-10-19 2:45 ` Xuan Truong Nguyen
[not found] ` <b4efb8cc-bf55-cf34-a537-4ffa5041291a@jinso.co.jp>
2016-10-31 13:16 ` The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2 Geert Uytterhoeven
2016-11-02 1:29 ` duclm
2016-11-02 7:46 ` Geert Uytterhoeven
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.