Re: The failure summary report of GEN2 for linux stable v4.10-rc2

[Hiep Cao Minh <cm-hiep@jinso.co.jp>]

Hello Laurent,

Thanks for your reply.

>>>>> I've investigated the problem further here now that I'm back home with
>>>>> access to my Lager board, but have been unable to reproduce it even by
>>>>> testing all sync signal polarities.
>>>>>
>>>>> First of all, the "CMA enabled" kernel configuration file attached to a
>>>>> previous e-mail in this series indeed enables CMA, but doesn't enable
>>>>> CMA usage for DMA buffers. You need to additionally set
>>>>>
>>>>> CONFIG_DMA_CMA=y
>>>>> CONFIG_CMA_SIZE_MBYTES=128
>>>>>
>>>>> The amount of CMA memory to reserve can vary depending on the tests you
>>>>> perform. The larger the resolutions and the number of buffers are, the
>>>>> more memory you will need. 128MB should be a safe bet for most cases.
>>>>> Feel free to reduce that if you need to use a lot of memory outside of
>>>>> CMA, or increase it if you run into buffer allocation failures with
>>>>> multimedia devices (DU, VIN, VSP, ...). You can then let the HDMI cable
>>>>> plugged at all time and you should not get framebuffer allocation
>>>>> failures when booting the board with the cable plugged in.
>>>>>
>>>>> Then, I tried to modify the H/V sync polarities by using different video
>>>>> modes. If you look at the output of "modetest -M rcar-du", you should
>>>>> get a list of modes similar to the following for the HDMI output.
>>>>>
>>>>> 1440x900  60 1440 1520 1672 1904  900  903  909  934 flags: nhsync,
>>>>> pvsync
>>>>> 1280x1024 75 1280 1296 1440 1688 1024 1025 1028 1066 flags: phsync,
>>>>> pvsync
>>>>> 1280x1024 60 1280 1328 1440 1688 1024 1025 1028 1066 flags: phsync,
>>>>> pvsync
>>>>> 1440x900  75 1440 1536 1688 1936  900  903  909  942 flags: nhsync,
>>>>> pvsync
>>>>> 1280x800  60 1280 1328 1360 1440  800  803  809  823 flags: phsync,
>>>>> nvsync
>>>>> 1152x864  75 1152 1216 1344 1600  864  865  868  900 flags: phsync,
>>>>> pvsync
>>>>> 1024x768  75 1024 1040 1136 1312  768  769  772  800 flags: phsync,
>>>>> pvsync
>>>>> 1024x768  70 1024 1048 1184 1328  768  771  777  806 flags: nhsync,
>>>>> nvsync
>>>>> 1024x768  60 1024 1048 1184 1344  768  771  777  806 flags: nhsync,
>>>>> nvsync
>>>>> 832x624   75  832  864  928 1152  624  625  628  667 flags: nhsync,
>>>>> nvsync
>>>>> 800x600   75  800  816  896 1056  600  601  604  625 flags: phsync,
>>>>> pvsync
>>>>> 800x600   72  800  856  976 1040  600  637  643  666 flags: phsync,
>>>>> pvsync
>>>>> 800x600   60  800  840  968 1056  600  601  605  628 flags: phsync,
>>>>> pvsync
>>>>> 800x600   56  800  824  896 1024  600  601  603  625 flags: phsync,
>>>>> pvsync
>>>>> 640x480   75  640  656  720  840  480  481  484  500 flags: nhsync,
>>>>> nvsync
>>>>> 640x480   73  640  664  704  832  480  489  492  520 flags: nhsync,
>>>>> nvsync
>>>>> 640x480   67  640  704  768  864  480  483  486  525 flags: nhsync,
>>>>> nvsync
>>>>> 640x480   60  640  656  752  800  480  490  492  525 flags: nhsync,
>>>>> nvsync
>>>>> 720x400   70  720  738  846  900  400  412  414  449 flags: nhsync,
>>>>> pvsync
>>>>>
>>>>> Each mode has a defined horizontal and vertical polarity. If you pick
>>>>> your modes carefully you will be able to test all four combinations of
>>>>> polarities. I tried them all, and couldn't reproduce the reported
>>>>> problem with the test procedure that Dong specified.
>>>>>
>>>>> The easiest way to select a video mode for the fbdev compatibility layer
>>>>> is to specify it as the default mode on the kernel command line using
>>>>> the video= argument. The mode value is in the form of
>>>>> <width>x<height>@<refresh rate>. For instance, to select the 1024x768
>>>>> 75Hz mode, simply add
>>>>>
>>>>> 	video=1024x768@75
>>>>>
>>>>> to the kernel command line arguments (there are multiple ways to do so
>>>>> depending on how you configured your boot loader, I personally like to
>>>>> modify the bootargs value in the .dts file for the board).
>>>>>
>>>>> Could you please check if the problem occurs with all video modes
>>>>> supported by your HDMI monitor or with some of them only ?
>>>> We have tried to configure our test environment based on your
>>>> explanation, then tested it again.
>>>> But It didn't work. (we tried all of video parameters
>>>> <width>x<height>@<refresh rate> we have )
>>>> And we tried to confirm the issue on Simon's tree of renesas-backport
>>>> bsp v3.10.31-rcar-gen2-1.9.9.
>>>> It worked with the same test method.
>>>>
>>>> Did you check the issue on Upstream mainline version? or your own tree?
>>> I tested both my own tree and mainline v4.10-rc2.
>>>
>>>> Could you attach your config file?
>>>> I was wondering that your config and ours might be different.
>>> Sure. The configuration is based on the CONFIG_CMA_ENABLE.txt sent by Dong
>>> in this mail thread, with the following changes.
>>>
>>> --- CONFIG_CMA_ENABLE.txt 2017-02-17 15:21:57.974816277 +0200
>>> +++ .config  2017-02-17 15:20:31.618818828 +0200
>>> @@ -872,7 +872,17 @@
>>>   CONFIG_REGMAP_IRQ=y
>>>   CONFIG_DMA_SHARED_BUFFER=y
>>>   # CONFIG_DMA_FENCE_TRACE is not set
>>> -# CONFIG_DMA_CMA is not set
>>> +CONFIG_DMA_CMA=y
>>> +
>>> +#
>>> +# Default contiguous memory area size:
>>> +#
>>> +CONFIG_CMA_SIZE_MBYTES=128
>>> +CONFIG_CMA_SIZE_SEL_MBYTES=y
>>> +# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
>>> +# CONFIG_CMA_SIZE_SEL_MIN is not set
>>> +# CONFIG_CMA_SIZE_SEL_MAX is not set
>>> +CONFIG_CMA_ALIGNMENT=8
>>>
>>>   #
>>>   # Bus devices
>> Thanks for your config file.
>> We have tested it on our test environments and using many difference
>> options of video parameters.
>> But It still didn't work.
>> Could you show me your rootfs's name and version?.
> I use a buildroot-based rootfs with a custom configuration. I don't think the
> rootfs makes a difference here, I would instead suspect that the issue is
> related to the HDMI monitor. Would you be able to try a different screen ?
>
We have used three different screens we have.
Dell s2240L, Panasonic TH-L 19C3 and LG 23MP48HQ-P.
In there, Dell and LG screens are quite new.
What kind of screen are you using?

Thank you.
Hiep.