public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ramalingam C <ramalingam.c@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
	rodrigo.vivi@intel.com, paulo.r.zanoni@intel.com
Subject: Re: [RFC PATCH 11/18] drm/i915: Updating the crtc modes in DRRS transitions
Date: Mon, 29 Jun 2015 20:28:53 +0530	[thread overview]
Message-ID: <55915D2D.2090100@intel.com> (raw)
In-Reply-To: <20150626171113.GH30960@phenom.ffwll.local>


On Friday 26 June 2015 10:41 PM, Daniel Vetter wrote:
> On Fri, Jun 26, 2015 at 07:21:55PM +0530, Ramalingam C wrote:
>> During the DRRS state transitions we are modifying the clock and
>> hence the vrefresh rate.
>>
>> So we need to update the drm_crtc->mode and the adjusted
>> mode in intel_crtc. So that watermark calculations will be as per the
>> new modified clock.
>>
>> Signed-off-by: Ramalingam C<ramalingam.c@intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_drrs.c     |   14 ++++++++++++++
>>   drivers/gpu/drm/i915/intel_dsi_drrs.c |   14 +++++++++++++-
>>   2 files changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drrs.c b/drivers/gpu/drm/i915/intel_drrs.c
>> index 42b420d..2901832 100644
>> --- a/drivers/gpu/drm/i915/intel_drrs.c
>> +++ b/drivers/gpu/drm/i915/intel_drrs.c
>> @@ -169,6 +169,20 @@ void intel_set_drrs_state(struct i915_drrs *drrs)
>>   		 * If it is non-DSI encoders.
>>   		 * As only DSI has SEAMLESS_DRRS_SUPPORT_SW.
>>   		 */
>> +		/*
>> +		 * TODO: Protect the access to the crtc mode with corresponding
>> +		 * mutex in case of Idleness DRRS. As media playback update
>> +		 * will happen under crtc modeset lock protection
>> +		 */
>> +		drm_modeset_lock(&intel_crtc->base.mutex, NULL);
>> +		intel_crtc->base.mode.clock = target_mode->clock;
>> +		intel_crtc->base.mode.vrefresh = target_mode->vrefresh;
>> +		intel_crtc->config->base.adjusted_mode.clock =
>> +							target_mode->clock;
>> +		intel_crtc->config->base.adjusted_mode.vrefresh =
>> +							target_mode->vrefresh;
>> +		drm_modeset_unlock(&intel_crtc->base.mutex);
> No. For video DRRS (i.e. changing the vrefresh rate to exactly what we
> want to match media content) userspace needs to do a full modeset. Maarten
> is working on infrastructure to avoid full modeset in some special mode
> changes (to implement the fast pfit change from Jesse's original fastboot
> work). And we can extend this to DRRS too.
Daniel,

But this interface that we have developed for android is not just for 
video playback.
We are trying to provide a interface where user space can request for 
custom vrefresh,
if the rate of the display content doesn't need the vrefresh of current 
applied mode.
For example scenarios like text editor or some game where lower Frame 
per second is sufficient. And if the panel supports
the seamless drrs we don't need to do a modeset in such scenarios.

Either way Please do share/point to the details of the Maarten design. 
So that we can see if we are
working on same area and if so how far we can reuse each others work.
> For seamless&transparent DRRS we can still keep the current design with
> effectively 2 dotclocks.
You mean 2 dotclocks at drm_display_mode or drrs structure?
>
> Also with atomic you can combine the clock change with the first video
> frame which is double-awesome ;-)
> -Daniel
>
>> +
>>   		drrs_state->current_rr_type = drrs_state->target_rr_type;
>>   		DRM_INFO("Refresh Rate set to : %dHz\n", refresh_rate);
>>   	}
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_drrs.c b/drivers/gpu/drm/i915/intel_dsi_drrs.c
>> index eb0758a..d4bb70a 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_drrs.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_drrs.c
>> @@ -46,6 +46,7 @@ static void intel_mipi_drrs_work_fn(struct work_struct *__work)
>>   	struct i915_drrs *drrs = work->drrs;
>>   	struct intel_encoder *intel_encoder = drrs->connector->encoder;
>>   	struct intel_dsi *intel_dsi = enc_to_intel_dsi(&intel_encoder->base);
>> +	struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
>>   	struct dsi_drrs *dsi_drrs = &intel_dsi->dsi_drrs;
>>   	struct dsi_mnp *dsi_mnp;
>>   	struct drm_display_mode *prev_mode = NULL;
>> @@ -69,11 +70,22 @@ retry:
>>   		/* PLL Programming is successful */
>>   		mutex_lock(&drrs->drrs_mutex);
>>   		drrs->drrs_state.current_rr_type = work->target_rr_type;
>> +
>> +		drm_modeset_lock(&intel_crtc->base.mutex, NULL);
>> +		intel_crtc->base.mode.clock = work->target_mode->clock;
>> +		intel_crtc->base.mode.vrefresh = work->target_mode->vrefresh;
>> +		intel_crtc->config->base.adjusted_mode.clock =
>> +						work->target_mode->clock;
>> +		intel_crtc->config->base.adjusted_mode.vrefresh =
>> +						work->target_mode->vrefresh;
>> +		drm_modeset_unlock(&intel_crtc->base.mutex);
>> +
>>   		mutex_unlock(&drrs->drrs_mutex);
>> +
>>   		DRM_INFO("Refresh Rate set to : %dHz\n",
>>   						work->target_mode->vrefresh);
>>   
>> -		/* TODO: Update crtc mode and drain ladency with watermark */
>> +		/* TODO: Update drain ladency with watermark */
>>   
>>   	} else if (ret == -ETIMEDOUT && retry_cnt) {
>>   
>> -- 
>> 1.7.9.5
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Thanks,
--Ram

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-06-29 15:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26 13:51 [RFC PATCH 00/18] Generic DRRS implementation across the encoders Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 01/18] drm/i915: Removing the eDP specific DRRS implementation Ramalingam C
2015-06-26 16:50   ` Daniel Vetter
2015-06-29 11:24     ` Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 02/18] drm/i915: Generic DRRS state Machine Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 03/18] drm/i915: Addition of the drrs_min_vrefresh in VBT Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 04/18] drm/i915: Implementation of Generic DSI DRRS Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 05/18] drm/i915: Adjusting the pclk for dual link and burst mode Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 06/18] drm/i915: VLV dsi drrs support Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 07/18] drm/i915: Generic eDP DRRS implementation Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 08/18] drm/i915: VLV eDP DRRS methods Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 09/18] drm/i915: Cloned mode check Ramalingam C
2015-06-26 17:08   ` Daniel Vetter
2015-06-26 17:14     ` Chris Wilson
2015-06-26 17:38       ` Daniel Vetter
2015-06-29 11:48     ` Ramalingam C
2015-06-29 16:16       ` Daniel Vetter
2015-06-26 13:51 ` [RFC PATCH 10/18] drm/i915: Initializing DRRS for all connectors Ramalingam C
2015-06-26 17:12   ` Daniel Vetter
2015-06-29 14:52     ` Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 11/18] drm/i915: Updating the crtc modes in DRRS transitions Ramalingam C
2015-06-26 17:11   ` Daniel Vetter
2015-06-29 14:58     ` Ramalingam C [this message]
2015-06-29 16:23       ` Daniel Vetter
2015-06-26 13:51 ` [RFC PATCH 12/18] drm/i915: Redesigning dp_set_m_n to receive divider values Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 13/18] drm/i915: MEDIA_RR support in general DRRS state machine Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 14/18] drm/i915: MEDIA_RR support in eDP DRRS module Ramalingam C
2015-06-26 13:51 ` [RFC PATCH 15/18] drm/i915: MEDIA_RR support in DSI " Ramalingam C
2015-06-26 13:52 ` [RFC PATCH 16/18] drm/i915: Filtering media playback DRRS requests Ramalingam C
2015-06-26 13:52 ` [RFC PATCH 17/18] drm/i915: Addition of downclock mode to connector modelist Ramalingam C
2015-06-26 13:52 ` [RFC PATCH 18/18] drm/i915: Connector property for DRRS capability Ramalingam C
2015-06-26 17:16 ` [RFC PATCH 00/18] Generic DRRS implementation across the encoders Daniel Vetter
2015-06-29 11:22   ` Ramalingam C
2015-06-29 16:27     ` Daniel Vetter
2015-06-30  6:29       ` Ramalingam C
2015-06-30 10:02         ` 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=55915D2D.2090100@intel.com \
    --to=ramalingam.c@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=rodrigo.vivi@intel.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