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 16:31:31 +0530 [thread overview]
Message-ID: <3c8d928a-6fa1-382a-84cc-3debfe3d0f30@intel.com> (raw)
In-Reply-To: <ec372709-ca1e-4382-bb1e-19da4e823d83@samsung.com>
Regards
Shashank
On 1/30/2017 3:47 PM, Andrzej Hajda wrote:
> On 30.01.2017 10:42, Sharma, Shashank wrote:
>> 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.
> This phrase is not precise, but if it means that in case of
> 3840x2160@30Hz source should set VIC to 95 also for HDMI1.4 compliant
> sinks it is in opposition to statement from HDMI1.4 specification:
>> When transmitting any extended video format indicated through use of
>> the HDMI_VIC field
>> in the HDMI Vendor Specific InfoFrame or any other format which is not
>> described in the
>> above cases, an HDMI Source shall set the AVI InfoFrame VIC field to zero.
> I do not think HDMI20 could invalidate claims from HDMI1.4.
These claims are not made in HDMI 2.0 specs, CEA is the body which
defines VICs, AVI-IF and aspects, so its defined in CEA-861-F spec
IF you check the CEA-861-F spec, you will find this section.
>
>> - Also, for HDMI infoframe blocks, we dont refer to cea_edid_modes[]
>> rather we go to edid_4k_modes[]
> cea_edid_modes is used in generating AVI infoframe,
> edid_4k_modes is used in generating vendor infoframe
>> - 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.
>>
> I do not understand this phrase. Are you talking about aspect ratios or
> about video format?
As edid_cea_modes is being used in drm_hdmi_avi_if_from_display_mode,
only place where its being used to load AVI IF (with aspect ratio
information), I was talking about both.
But lets talk about VIC only from here.
Shashank
>
> Regards
> Andrzej
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-01-30 11:01 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
2017-01-30 10:17 ` Andrzej Hajda
2017-01-30 11:01 ` Sharma, Shashank [this message]
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=3c8d928a-6fa1-382a-84cc-3debfe3d0f30@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox