All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Cc: DongCV <cv-dong@jinso.co.jp>,
	"Wolfram Sang" <wsa@sang-engineering.com>,
	duclm <lm-duc@jinso.co.jp>,
	"Ryusuke Sakato" <ryusuke.sakato.bx@renesas.com>,
	"Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	稲吉 <h-inayoshi@jinso.co.jp>,
	"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
	Dung:人ソ <nv-dung@jinso.co.jp>,
	"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
	"Simon Horman" <horms+renesas@verge.net.au>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	na-hoan@jinso.co.jp
Subject: Re: The failure summary report of GEN2 for linux stable v4.10-rc2
Date: Tue, 14 Feb 2017 23:53:48 +0200	[thread overview]
Message-ID: <1952286.6MMkHMyL63@avalon> (raw)
In-Reply-To: <5885B7AA.4030403@jinso.co.jp>

Hello Hiep,

On Monday 23 Jan 2017 16:58:34 Hiep Cao Minh wrote:
> > On Friday 20 Jan 2017 12:11:50 DongCV wrote:
> >> Dear Mr Laurent,
> >> 
> >> Thank you for your quick reply.
> >> This is the log file contains information about the command "modetest -M
> >> rcar-du" (with the HDMI cable plugged).
> > 
> > Thank you. I think I know what's wrong. The default mode picked by the
> > system in your case uses positive H/V sync polarities, while in my cases
> > the sync signals have negative polarities. Could you try to select
> > 1024x768 @60Hz instead of 1024x768 @75Hz ? I think the HDMI output would
> > then work correctly, which would confirm that the problem is indeed
> > caused by sync polarities.
>
> Dong is sick, so he did not attend today. He will reply to you tomorrow.
> Could you explain more how to set 1024x768 @60Hz and negative polarities
> for the HDMI output?,

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 ?

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2017-02-14 21:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16  9:29 The failure summary report of GEN2 for linux stable v4.10-rc2 "カオ・ヴァン・ドン"
2017-01-16 15:34 ` Laurent Pinchart
     [not found]   ` <d7f4a948-37a2-e912-6e25-5690ad8ecef9@jinso.co.jp>
2017-01-18  6:53     ` DongCV
2017-01-18 22:47       ` Laurent Pinchart
2017-01-18 22:26     ` Laurent Pinchart
     [not found]       ` <8a056d37-3de9-30ac-74bc-e1393d1b193a@jinso.co.jp>
2017-01-19 23:49         ` Laurent Pinchart
2017-01-20  3:11           ` DongCV
2017-01-20 12:36             ` Laurent Pinchart
2017-01-23  7:58               ` Hiep Cao Minh
2017-02-14 21:53                 ` Laurent Pinchart [this message]
2017-02-17 10:49                   ` Hiep Cao Minh
     [not found]                     ` <2653919.pRB2KAMlVt@avalon>
2017-02-22 12:23                       ` Hiep Cao Minh
2017-02-22 17:41                         ` Laurent Pinchart
2017-02-24  0:52                           ` Hiep Cao Minh
2017-01-17  2:40 ` The failure summary report of GEN3 for linux upstream v4.10-rc2 Hoan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1952286.6MMkHMyL63@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=cm-hiep@jinso.co.jp \
    --cc=cv-dong@jinso.co.jp \
    --cc=geert+renesas@glider.be \
    --cc=h-inayoshi@jinso.co.jp \
    --cc=horms+renesas@verge.net.au \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lm-duc@jinso.co.jp \
    --cc=magnus.damm@gmail.com \
    --cc=na-hoan@jinso.co.jp \
    --cc=nv-dung@jinso.co.jp \
    --cc=ryusuke.sakato.bx@renesas.com \
    --cc=wsa@sang-engineering.com \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.