* 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
* 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
[parent not found: <57ECF4EA.4010704@jinso.co.jp>]
* 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: 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
* 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 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
[parent not found: <9d9a647b-d75f-e89a-2d4d-55e409ccabae@jinso.co.jp>]
* 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
[parent not found: <b7e9b4c2-1d5d-2e76-c0f4-fcc50150dc30@jinso.co.jp>]
* 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
[parent not found: <125b4831-cbdf-f8e1-da97-8ea9cf458c22@jinso.co.jp>]
* 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 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: 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 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
[parent not found: <a101cec4-c9ee-48fa-4f16-5e4cb2b8fab7@jinso.co.jp>]
* 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 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
[parent not found: <58060015.3020702@jinso.co.jp>]
* 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 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
[parent not found: <b4efb8cc-bf55-cf34-a537-4ffa5041291a@jinso.co.jp>]
* 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
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.