From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-fbdev@vger.kernel.org, airlied@linux.ie,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
daniel.vetter@intel.com, plagnioj@jcrosoft.com
Subject: Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add support for new aspect ratios
Date: Fri, 22 Apr 2016 05:40:34 +0000 [thread overview]
Message-ID: <5719B682.1030504@intel.com> (raw)
In-Reply-To: <20160421150414.GB2510@phenom.ffwll.local>
Thanks for the review Daniel.
My comments inline.
Regards
Shashank
On 4/21/2016 8:34 PM, Daniel Vetter wrote:
> On Fri, Mar 25, 2016 at 01:47:35PM +0530, Shashank Sharma wrote:
>> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
>> - 64:27
>> - 256:135
>>
>> This patch adds support for these aspect ratios in
>> I915 driver, at various places.
>>
>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>
> Ok, we discussed this a bit internally and I had some questions. Reading
> this series patches make sense up to this one, but here I have a few
> questions/comments.
>
>> ---
>> drivers/gpu/drm/drm_modes.c | 12 ++++++++++++
>> drivers/gpu/drm/i915/intel_hdmi.c | 6 ++++++
>> drivers/gpu/drm/i915/intel_sdvo.c | 6 ++++++
>> 3 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index 6e66136..11f219a 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -1482,6 +1482,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
>> case HDMI_PICTURE_ASPECT_16_9:
>> out->flags |= DRM_MODE_FLAG_PAR16_9;
>> break;
>> + case HDMI_PICTURE_ASPECT_64_27:
>> + out->flags |= DRM_MODE_FLAG_PAR64_27;
>> + break;
>> + case DRM_MODE_PICTURE_ASPECT_256_135:
>> + out->flags |= DRM_MODE_FLAG_PAR256_135;
>> + break;
>> case HDMI_PICTURE_ASPECT_NONE:
>> case HDMI_PICTURE_ASPECT_RESERVED:
>> default:
>> @@ -1544,6 +1550,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
>> case DRM_MODE_FLAG_PAR16_9:
>> out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
>> break;
>> + case DRM_MODE_FLAG_PAR64_27:
>> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
>> + break;
>> + case DRM_MODE_FLAG_PAR256_135:
>> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
>> + break;
>> default:
>> out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>> }
>
> Above two parts is core enabling, I guess those should be squashed into
> the preceeding patch?
>
Sure, we can do this.
The idea was to create a separate patch for new aspect ratio, so that
one can segregate HDMI 2.0 patches and HDMI 1.4 patches. If you still
recommend this, I can move this part in next patch.
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
>> index e2dab48..bc8e2c8 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1545,6 +1545,12 @@ intel_hdmi_set_property(struct drm_connector *connector,
>> case DRM_MODE_PICTURE_ASPECT_16_9:
>> intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
>> break;
>> + case DRM_MODE_PICTURE_ASPECT_64_27:
>> + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
>> + break;
>> + case DRM_MODE_PICTURE_ASPECT_256_135:
>> + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
>> + break;
>> default:
>> return -EINVAL;
>> }
>> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c
>> index fae64bc..370e4f9 100644
>> --- a/drivers/gpu/drm/i915/intel_sdvo.c
>> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
>> @@ -2071,6 +2071,12 @@ intel_sdvo_set_property(struct drm_connector *connector,
>> case DRM_MODE_PICTURE_ASPECT_16_9:
>> intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
>> break;
>> + case DRM_MODE_PICTURE_ASPECT_64_27:
>> + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
>> + break;
>> + case DRM_MODE_PICTURE_ASPECT_256_135:
>> + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
>> + break;
>> default:
>> return -EINVAL;
>> }
>
> The trouble with the aspect_ratio prop as currently implemented is that we
> currently unconditionally overwrite adjusted_mode->picture_aspect_ratio
> with it.
>
> But your patches here move the aspect ratio handling into
> drm_mode_modeinfo (uabi) and drm_display_mode (kernel-internal), where it
> imo belongs. But we need to figure out how to the interaction with the
> property correctly. What's probably needed is a new value in the
> aspect_ratio enum called "default", which selects the aspect_ratio from
> the mode. Only when userspace overrides (NONE, or one of the CEA aspect
> ratios) would we obey the aspect_ratio of the property. Otherwise the
> aspect ratio stored in the mode would be lost.
This is exactly how we have handled this in Android branch(with NONE as
default), thanks for the suggestion. I will incorporate this in next
patch set.
>
> The other bit that I can't find in this series is making sure we compute
> the VIC correctly for the new modes. Or does that magically work correctly
> since we compare the full mode when selecting VICs?
>
Yes, we are saving the right VIC from EDID, so the VIC is now a part of
the mode flags, all we have to do extract this and write during
preparing AVI-IF, we have a small one line patch for that. I will add
that too in the next series.
> Thanks, Daniel
>
next prev parent reply other threads:[~2016-04-22 5:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 8:29 [PATCH 0/5] Add aspect ratio parsing Shashank Sharma
2016-03-25 8:29 ` [PATCH 1/5] drm: add picture aspect ratio flags Shashank Sharma
2016-03-25 8:29 ` [PATCH 2/5] drm: Add aspect ratio parsing in DRM layer Shashank Sharma
2016-03-25 8:29 ` [PATCH 3/5] video: Add new aspect ratios for HDMI 2.0 Shashank Sharma
2016-03-25 8:29 ` [PATCH 4/5] drm: Add flags for new aspect ratios Shashank Sharma
2016-03-25 8:29 ` [PATCH 5/5] drm/i915: Add support " Shashank Sharma
2016-04-21 15:04 ` [Intel-gfx] " Daniel Vetter
2016-04-22 5:40 ` Sharma, Shashank [this message]
2016-04-22 8:09 ` Daniel Vetter
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=5719B682.1030504@intel.com \
--to=shashank.sharma@intel.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=plagnioj@jcrosoft.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;
as well as URLs for NNTP newsgroup(s).