All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: Andrzej Hajda <a.hajda@samsung.com>,
	dri-devel@lists.freedesktop.org,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>,
	daniel.vetter@intel.com, Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [PATCH v3] drm/edid: Complete CEA modedb(VIC 1-107)
Date: Mon, 30 Jan 2017 15:12:19 +0530	[thread overview]
Message-ID: <3cb903b4-8b01-6dbe-9a79-72932b0861fc@intel.com> (raw)
In-Reply-To: <28e81468-661b-e9a4-6c9f-d96b0b9eec4c@samsung.com>

Regards

Shashank


On 1/30/2017 2:52 PM, Andrzej Hajda wrote:
> On 30.01.2017 09:45, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 1/30/2017 1:30 PM, Andrzej Hajda wrote:
>>> On 29.01.2017 06:41, Shashank Sharma wrote:
>>>> CEA-861-F specs defines new 4k video modes to be used with
>>>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>>>> way till VIC=107.
>>>>
>>>> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
>>>> to be able to parse 4k modes using the existing techniques, we have
>>>> to complete the modedb (VIC=65 onwards).
>>>>
>>>> This patch adds:
>>>> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
>>>> - Newly added 4k modes (from VIC=93 to VIC=107).
>>>>
>>>> Cc: Jose Abreu <Jose.Abreu@synopsys.com>
>>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>>> Cc: Andrzej Hajda <a.hajda@samsung.com>
>>>>
>>>> V2: Addressed review comments from Jose:
>>>> - fix the timings for VIC 83, 90 and 91
>>>> - fix formatting for VIC 93-107
>>>>
>>>> V3: Rebase on drm-tip
>>>>
>>>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>>>> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
>>>> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com>
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>> ---
>>> Have you addressed in some other patch my concerns regarding polluting
>>> infoframes generated for HDMI 1.4 devices (CEA-861-E) with VICs specific
>>> only for HDMI 2.0 (CEA-861-F) ? It will happen
>>> for all UHD modes, see [1][2] for previous discussion.
>> Hello Andrzej
>>
>> As you already know, the aspect ratio is indexed with the VIC, which
>> comes from EDID.
>> Now, why would a HDMI 1.4 monitor, contain a HDMI 2.0 VIC ? If it does,
>> its not compliant.
> Have you forgot our previous discussion? Let me cite myself:
>
> For example 3840x2160@30Hz has no VIC in HDMI 1.4 but it can
> be present in HDMI vendor specific block with HDMI_VIC 1, on the
> other side it has VIC 95 in HDMI 2.0. So before your patch
> AVI infoframe.video_code is set to 0, after your patch is set to 95.
>
>
> And your discussion with Ville:
>
>>> />>> No. The user is free to specify any mode they wish. It doesn't
>> have to/
>>> />>> come from the EDID. Not sure specifying a modern VIC for an older/
>>> />>> display is a good idea or not. If not, we could always check the
>> cea_rev/
>>> />>> assuming it changed whenever the list if VICs was expanded./
>>> />> I agree, that user can specify a mode, out of EDID too./
>>> />> I am anyways planning to add a patch, where before loading HDMI 2.0
>> VICs/
>>> />> in AVI IF, we are checking the EDID rev./
>>> />> That should solve our problem./
>>> />>/
>>> />> So if edid_rev < 2.0/
>>> />> do_not_load VICs from 93 - 107, but keep it 0./
>>> /> Why edid_rev and not cea_rev?/
>>> /We can do that also, but in the current structure, we are already /
>>> /caching EDID rev, its just about re-using it./
>>> /AFAIK, we don't have CEA extension cached anywhere./
>> Yes we do.
>
> It does not seem to be addressed.
>
> Regards
> Andrzej
Hey, thanks for bringing this out again. I checked the specs again, 
there are three things here:
- The spec has a section on this, and it states that in such cases CEA 
VIC should be supplied to the AVI IF.
- Also, for HDMI infoframe blocks, we dont refer to cea_edid_modes[] 
rather we go to edid_4k_modes[]
- Again, as there is no aspect ratio parsing layer in DRM right now 
(after the revert), we are doing the right thing to give aspect as per 
CEA, which is suggested by spec too.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-01-30  9:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170129052952epcas1p241f5ad9f0396def0e260c5bad44cce27@epcas1p2.samsung.com>
2017-01-29  5:41 ` [PATCH v3] drm/edid: Complete CEA modedb(VIC 1-107) Shashank Sharma
2017-01-30  8:00   ` Andrzej Hajda
2017-01-30  8:45     ` Sharma, Shashank
2017-01-30  8:46       ` Sharma, Shashank
2017-01-30  9:22       ` Andrzej Hajda
2017-01-30  9:42         ` Sharma, Shashank [this message]
2017-01-30 10:17           ` Andrzej Hajda
2017-01-30 11:01             ` Sharma, Shashank
2017-01-30 11:29             ` Sharma, Shashank
2017-01-30 20:43   ` Harry Wentland
2017-01-31 14:52   ` [gfx-internal-devel] " Ville Syrjälä

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=3cb903b4-8b01-6dbe-9a79-72932b0861fc@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=a.hajda@samsung.com \
    --cc=alexander.deucher@amd.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.