Hello Hiep, On Wednesday 22 Feb 2017 21:23:58 Hiep Cao Minh wrote: > Hello Laurent, > > I am sorry for the late reply!. No worries. > >>> 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 ? -- Regards, Laurent Pinchart
