From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: Jose Abreu <Jose.Abreu@synopsys.com>,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@intel.com>,
Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH v2 1/2] drm: Create new structure for HDMI info
Date: Wed, 21 Dec 2016 16:01:19 +0530 [thread overview]
Message-ID: <16b2c5d9-9529-fab9-d757-deef44e17036@intel.com> (raw)
In-Reply-To: <6d953cee-8604-6bd0-3ec6-fa932f2bf872@synopsys.com>
Regards
Shashank
On 12/21/2016 3:02 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 21-12-2016 03:49, Sharma, Shashank wrote:
>> Thanks for the review Jose.
>>
>> My comments, inline.
>>
>> Regards
>> Shashank
>> On 12/20/2016 7:49 PM, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>> On 20-12-2016 13:47, Shashank Sharma wrote:
>>>> This patch creates a new structure drm_hdmi_info (inspired from
>>>> drm_display_info). Driver will parse HDMI sink's advance
>>>> capabilities
>>>> from HF-VSDB and populate this structure. This structure will
>>>> be kept
>>>> and used as a sub-class within drm_display_info.
>>> You populate the structure but I think you should add a helper to
>>> reset it when there is a new EDID or when the previous EDID is no
>>> longer valid. The same applies to other fields in
>>> drm_display_info structure. I've had problems before because of
>>> incorrect values in this structure.
>> I agree, will add a clean-up function too, and will attach it
>> with hot-unplug.
>>>> We are adding parsing of HF-VSDB In the next patch.
>>>>
>>>> Cc: Thierry Reding <treding@nvidia.com>
>>>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>>>> Cc: Jose Abreu <joabreu@synopsys.com>
>>>> Suggested-by: Thierry Reding <thierry.reding@gmail.com>
>>>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>>>> ---
>>>> drivers/gpu/drm/drm_edid.c | 6 ++--
>>>> include/drm/drm_connector.h | 79
>>>> ++++++++++++++++++++++++++++++++++++++++++---
>>>> 2 files changed, 77 insertions(+), 8 deletions(-)
>>>>
>>> [snip]
>>>
>>>> /**
>>>> + * struct drm_hdmi_info - runtime data specific to a
>>>> connected hdmi sink
>>>> + *
>>>> + * Describes a given hdmi display (e.g. CRT or flat panel)
>>>> and its capabilities.
>>>> + * Mostly refects the advanced features added in HDMI 2.0
>>>> specs and the deep
>>>> + * color support. This is a sub-segment of struct
>>>> drm_display_info and should be
>>>> + * used within.
>>>> + *
>>>> + * For sinks which provide an EDID this can be filled out by
>>>> calling
>>>> + * drm_add_edid_modes().
>>>> + */
>>>> +
>>>> +struct drm_hdmi_info {
>>> [snip]
>>>
>>>> +
>>>> + /**
>>>> + * @edid_yuv420_dc_modes: bpc for deep color yuv420
>>>> encoding.
>>>> + * various sinks can support 10/12/16 bit per channel deep
>>>> + * color encoding. edid_yuv420_dc_modes = 0 means sink
>>>> doesn't
>>>> + * support deep color yuv420 encoding.
>>>> + */
>>>> + u8 edid_yuv420_dc_modes;
>>>> +
>>>> +
>>>> +#define DRM_HFVSDB_SCDC_SUPPORT (1<<7)
>>>> +#define DRM_HFVSDB_SCDC_RR_CAP (1<<6)
>>>> +#define DRM_HFVSDB_SCRAMBLING (1<<3)
>>>> +#define DRM_HFVSDB_INDEPENDENT_VIEW (1<<2)
>>>> +#define DRM_HFVSDB_DUAL_VIEW (1<<1)
>>>> +#define DRM_HFVSDB_3D_OSD (1<<0)
>>>> +
>>>> + /**
>>>> + * @scdc_supported: Sink supports SCDC functionality.
>>>> + */
>>>> + bool scdc_supported;
>>>> +
>>>> + /**
>>>> + * @scdc_rr_cap: Sink has SCDC read request capability.
>>>> + */
>>>> + bool scdc_rr_cap;
>>>> +
>>>> + /**
>>>> + * @scrambling: Sync supports scrambling for <=340 Mcsc
>>>> TMDS
>>>> + * char rates. Above 340 Mcsc rates, scrambling is
>>>> always reqd.
>>>> + */
>>>> + bool scrambling;
>>>> +
>>>> + /**
>>>> + * @independent_view_3d: Sink supports 3d independent
>>>> view signaling
>>>> + * in HF-VSIF.
>>>> + */
>>>> + bool independent_view_3d;
>>>> +
>>>> + /**
>>>> + * @dual_view_3d: Sink supports 3d dual view signaling
>>>> in HF-VSIF.
>>>> + */
>>>> + bool dual_view_3d;
>>>> +
>>>> + /**
>>>> + * @osd_disparity_3d: Sink supports 3d osd disparity
>>>> indication
>>>> + * in HF-VSIF.
>>>> + */
>>>> + bool osd_disparity_3d;
>>> Maybe you should only add these fields in the second patch.
>> I thought it was a good idea to introduce the new fields for
>> which we are adding this new structure all together. Else this
>> patch would just contain movement of few parameters from main
>> structure to new one, and would look unnecessary. Do you think
>> so ?
> Yes, I think it is better. And besides, in this patch you also
> have to change the drivers that use drm_display_info structure to
> use the newly created drm_hdmi_info instead so, the diff will be
> bigger. If you don't do so we'll have build errors.
>
> Best regards,
> Jose Miguel Abreu
Thanks, and yes, I will extend this patch to update other drivers using
this structure.
Shashank
>>> Best regards,
>>> Jose Miguel Abreu
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-12-21 10:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-20 13:47 [PATCH v2 1/2] drm: Create new structure for HDMI info Shashank Sharma
2016-12-20 13:47 ` [PATCH v2 2/2] drm: parse hf-vsdb Shashank Sharma
2016-12-20 14:35 ` Jose Abreu
2016-12-21 3:54 ` Sharma, Shashank
2016-12-20 14:19 ` [PATCH v2 1/2] drm: Create new structure for HDMI info Jose Abreu
2016-12-21 3:49 ` Sharma, Shashank
2016-12-21 9:32 ` Jose Abreu
2016-12-21 10:31 ` Sharma, Shashank [this message]
2016-12-20 14:45 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/2] " Patchwork
2016-12-20 23:31 ` [Intel-gfx] [PATCH v2 1/2] " kbuild test robot
2016-12-20 23:34 ` kbuild test robot
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=16b2c5d9-9529-fab9-d757-deef44e17036@intel.com \
--to=shashank.sharma@intel.com \
--cc=Jose.Abreu@synopsys.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=treding@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox