GEN2: Initialization of VSP1 failed at upstream v4.8-rc2

GEN2: Initialization of VSP1 failed at upstream v4.8-rc2

[Hiep Cao Minh]

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.

Re: GEN2: Initialization of VSP1 failed at upstream v4.8-rc2

[Geert Uytterhoeven]

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

Re: GEN2: Initialization of VSP1 failed at upstream v4.8-rc2

[Hiep Cao Minh]

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
>

Re: GEN2: Initialization of VSP1 failed at upstream v4.8-rc2

[Laurent Pinchart]

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

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Geert Uytterhoeven]

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

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Hiep Cao Minh]

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.

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Geert Uytterhoeven]

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

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Hiep Cao Minh]

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.

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Geert Uytterhoeven]

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

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Hiep Cao Minh]

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
>

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Geert Uytterhoeven]

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

GEN2: Initialization of VIN failed at upstream v4.8-rc2

[Hiep Cao Minh]

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.

Re: GEN2: Initialization of VIN failed at upstream v4.8-rc2

[Niklas Söderlund]

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

Re: GEN2: Initialization of VIN failed at upstream v4.8-rc2

[Hiep Cao Minh]

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.

Re: The failure summary report of GEN2 for linux stable v4.8

[Wolfram Sang]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Geert Uytterhoeven]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Geert Uytterhoeven]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Xuan Truong Nguyen]

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

RE: The failure summary report of GEN2 for linux stable v4.8

[Yoshihiro Shimoda]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Xuan Truong Nguyen]

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;
>   

Re: The failure summary report of GEN2 for linux stable v4.8

[Xuan Truong Nguyen]

    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;
>   

Re: The failure summary report of GEN2 for linux stable v4.8

[Laurent Pinchart]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Laurent Pinchart]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Xuan Truong Nguyen]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Laurent Pinchart]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Xuan Truong Nguyen]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Laurent Pinchart]

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

Re: The failure summary report of GEN2 for linux stable v4.8

[Xuan Truong Nguyen]

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 ?

Re: The failure summary report of GEN3(RCAR H3) for linux stable v4.8

[Kuninori Morimoto]

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

Re: The failure summary report of GEN3(RCAR H3) for linux stable v4.8

[Xuan Truong Nguyen]

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

Re: The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2

[Geert Uytterhoeven]

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

Re: The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2

[duclm]

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
>

Re: The failure summary report of GEN3(RCAR H3) for linux upstream v4.9-rc2

[Geert Uytterhoeven]

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