linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>

  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).