Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915

Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915

[Kulkarni, Vandita]

> -----Original Message-----
> From: Michel Dänzer <michel@daenzer.net>
> Sent: Wednesday, July 29, 2020 1:04 PM
> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>; Zanoni, Paulo R
> <paulo.r.zanoni@intel.com>; Vetter, Daniel <daniel.vetter@intel.com>; B S,
> Karthik <karthik.b.s@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma
> <uma.shankar@intel.com>; nicholas.kazlauskas@amd.com
> Subject: Re: [PATCH v5 0/5] Asynchronous flip implementation for i915
> 
> On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote:
> >
> > On async flips, there needs to be some clarity/guideline on the
> > behaviour and event expectation from the driver by user space.
> > Here are few assumptions that we have, 1. Our understanding is that
> > the user space doesn’t expect the timestamp for async flips (but still
> > expects vblank timestamp) , or doesn’t do anything with that, same is the
> assumption wrt the flip sequence, please correct us if we are wrong.
> > 2. In the sequence the user space still expects the counter that marks
> vblanks.
> > 3. The user space can use different event types like DRM_EVENT_VBLANK
> > or DRM_EVENT_FLIP_COMPLETE for getting the corresponding event. And
> their designs are still aligned to this even in case of async.
> >
> > If there are any more expectations from the user space wrt to the
> > event that is being sent from the driver in case of async flip, please let us
> know.
> >
> > If the user space doesn’t care much about the flip sequence then, we
> > can just not do anything like returning the flip counter like this version is
> doing and just stick to returning of the frame counter value(which marks
> vblanks).
> 
> There's no such thing as a "flip sequence" in the KMS API. There's only the
> per-CRTC vblank counter. Each flip completion event needs to contain the
> value of that counter when the hardware completed the flip, regardless of
> whether it was an async flip or not.
> 
> As for the timestamp in the event, I'm not sure what the expectations are for
> async flips, but I suspect it may not really matter. E.g. the timestamp
> calculated to correspond to the end of the previous vertical blank period
> might be fine.

Thanks Michel, Paulo, Daniel, Nicholas, Ville for your inputs.
After all the discussions, looks like the async flip time stamp is not of much
use to the userspace and the async flip sequence; hence we will stick to the approach of sending vblank time stamp
itself and have a test case in the igt to cover the async flips cases in a slightly different way.
And update the documentation.

Thanks,
Vandita
> 
> 
> --
> Earthling Michel Dänzer               |               https://redhat.com
> Libre software enthusiast             |             Mesa and X developer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915

[Karthik B S]

On 8/4/2020 11:19 AM, Kulkarni, Vandita wrote:
>> -----Original Message-----
>> From: Michel Dänzer <michel@daenzer.net>
>> Sent: Wednesday, July 29, 2020 1:04 PM
>> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>; Zanoni, Paulo R
>> <paulo.r.zanoni@intel.com>; Vetter, Daniel <daniel.vetter@intel.com>; B S,
>> Karthik <karthik.b.s@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma
>> <uma.shankar@intel.com>; nicholas.kazlauskas@amd.com
>> Subject: Re: [PATCH v5 0/5] Asynchronous flip implementation for i915
>>
>> On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote:
>>>
>>> On async flips, there needs to be some clarity/guideline on the
>>> behaviour and event expectation from the driver by user space.
>>> Here are few assumptions that we have, 1. Our understanding is that
>>> the user space doesn’t expect the timestamp for async flips (but still
>>> expects vblank timestamp) , or doesn’t do anything with that, same is the
>> assumption wrt the flip sequence, please correct us if we are wrong.
>>> 2. In the sequence the user space still expects the counter that marks
>> vblanks.
>>> 3. The user space can use different event types like DRM_EVENT_VBLANK
>>> or DRM_EVENT_FLIP_COMPLETE for getting the corresponding event. And
>> their designs are still aligned to this even in case of async.
>>>
>>> If there are any more expectations from the user space wrt to the
>>> event that is being sent from the driver in case of async flip, please let us
>> know.
>>>
>>> If the user space doesn’t care much about the flip sequence then, we
>>> can just not do anything like returning the flip counter like this version is
>> doing and just stick to returning of the frame counter value(which marks
>> vblanks).
>>
>> There's no such thing as a "flip sequence" in the KMS API. There's only the
>> per-CRTC vblank counter. Each flip completion event needs to contain the
>> value of that counter when the hardware completed the flip, regardless of
>> whether it was an async flip or not.
>>
>> As for the timestamp in the event, I'm not sure what the expectations are for
>> async flips, but I suspect it may not really matter. E.g. the timestamp
>> calculated to correspond to the end of the previous vertical blank period
>> might be fine.
> 
> Thanks Michel, Paulo, Daniel, Nicholas, Ville for your inputs.
> After all the discussions, looks like the async flip time stamp is not of much
> use to the userspace and the async flip sequence; hence we will stick to the approach of sending vblank time stamp
> itself and have a test case in the igt to cover the async flips cases in a slightly different way.
> And update the documentation.
> 

Thanks a lot for all the inputs.

I will make changes in IGT to calculate the time stamps from userspace 
itself, as we have now concluded that the kernel will be returning vbl 
timestamps even in the case of async flips.

Also, as suggested by Daniel, I will be adding one more subtest to 
verify that the async flip time stamp lies in between the timestamps of 
the previous and the next vblank.

Thanks,
Karthik.B.S
> Thanks,
> Vandita
>>
>>
>> --
>> Earthling Michel Dänzer               |               https://redhat.com
>> Libre software enthusiast             |             Mesa and X developer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler

[Karthik B S]

On 7/25/2020 4:56 AM, Paulo Zanoni wrote:
> Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
>> Add enable/disable flip done functions and the flip done handler
>> function which handles the flip done interrupt.
>>
>> Enable the flip done interrupt in IER.
>>
>> Enable flip done function is called before writing the
>> surface address register as the write to this register triggers
>> the flip done interrupt
>>
>> Flip done handler is used to send the page flip event as soon as the
>> surface address is written as per the requirement of async flips.
>> The interrupt is disabled after the event is sent.
>>
>> v2: -Change function name from icl_* to skl_* (Paulo)
>>      -Move flip handler to this patch (Paulo)
>>      -Remove vblank_put() (Paulo)
>>      -Enable flip done interrupt for gen9+ only (Paulo)
>>      -Enable flip done interrupt in power_well_post_enable hook (Paulo)
>>      -Removed the event check in flip done handler to handle async
>>       flips without pageflip events.
>>
>> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
>>      -Make the pending vblank event NULL in the beginning of
>>       flip_done_handler to remove sporadic WARN_ON that is seen.
>>
>> v4: -Calculate timestamps using flip done time stamp and current
>>       timestamp for async flips (Ville)
>>
>> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
>>       static.(Reported-by: kernel test robot <lkp@intel.com>)
>>      -Fix the typo in commit message.
>>
>> Signed-off-by: Karthik B S <karthik.b.s@intel.com>
>> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
>> ---
>>   drivers/gpu/drm/i915/display/intel_display.c | 10 +++
>>   drivers/gpu/drm/i915/i915_irq.c              | 83 ++++++++++++++++++--
>>   drivers/gpu/drm/i915/i915_irq.h              |  2 +
>>   drivers/gpu/drm/i915/i915_reg.h              |  4 +-
>>   4 files changed, 91 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
>> index db2a5a1a9b35..b8ff032195d9 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -15562,6 +15562,13 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
>>   
>>   	intel_dbuf_pre_plane_update(state);
>>   
>> +	for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
>> +		if (new_crtc_state->uapi.async_flip) {
>> +			skl_enable_flip_done(&crtc->base);
>> +			break;
> 
> Do we really want the break here? What if more than one CRTC wants an
> async flip?

Thanks for the review.
This will fail for multiple CRTC case, I will remove this break.
> 
> Perhaps you could extend IGT to try this.

Currently we cannot add this scenario of having 2 crtc's in the same 
commit, as we're using the page flip ioctl. But I did try by hacking via 
the atomic path and 2 display with async is working fine.
> 
>> +		}
>> +	}
>> +
>>   	/* Now enable the clocks, plane, pipe, and connectors that we set up. */
>>   	dev_priv->display.commit_modeset_enables(state);
>>   
>> @@ -15583,6 +15590,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
>>   	drm_atomic_helper_wait_for_flip_done(dev, &state->base);
>>   
>>   	for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
>> +		if (new_crtc_state->uapi.async_flip)
>> +			skl_disable_flip_done(&crtc->base);
> 
> Here we don't break in the first found, so at least there's an
> inconsistency.
>
I will remove the break in the earlier loop.
>> +
>>   		if (new_crtc_state->hw.active &&
>>   		    !needs_modeset(new_crtc_state) &&
>>   		    !new_crtc_state->preload_luts &&
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>> index 1fa67700d8f4..95953b393941 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
>>   	return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xffffff;
>>   }
>>   
>> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
>> +{
>> +	struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> +	enum pipe pipe = to_intel_crtc(crtc)->pipe;
>> +
>> +	return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
>> +}
>> +
>>   u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
>>   {
>>   	struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>>   	enum pipe pipe = to_intel_crtc(crtc)->pipe;
>>   
>> +	if (crtc->state->async_flip)
>> +		return g4x_get_flip_counter(crtc);
>> +
>>   	return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
> 
> I don't understand the intention behind this, can you please clarify?
> This goes back to my reply of the cover letter. It seems that here
> we're going to alternate between two different counters in our vblank
> count. So if user space alternates between sometimes using async flips
> and sometimes using normal flip it's going to get some very weird
> deltas, isn't it? At least this is what I remember from when I played
> with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
> using async flips.
> 
> IMHO we really need our IGT to exercise this possibility.
> 

As per the feedback received, I will be removing this in the next 
revision and will revert back to the original implementation.
And in the IGT, will be checking the time stamp during flip done from 
the user space itself.
>>   }
>> -
> 
> Don't remove this blank line, please.
> 

Will fix this.
>>   /*
>>    * On certain encoders on certain platforms, pipe
>>    * scanline register will not work to get the scanline,
>> @@ -737,17 +747,24 @@ static u32 __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
>>   		 * pipe frame time stamp. The time stamp value
>>   		 * is sampled at every start of vertical blank.
>>   		 */
>> -		scan_prev_time = intel_de_read_fw(dev_priv,
>> -						  PIPE_FRMTMSTMP(crtc->pipe));
>> -
>> +		if (!crtc->config->uapi.async_flip)
>> +			scan_prev_time = intel_de_read_fw(dev_priv,
>> +							  PIPE_FRMTMSTMP(crtc->pipe));
>> +		else
>> +			scan_prev_time = intel_de_read_fw(dev_priv,
>> +							  PIPE_FLIPTMSTMP(crtc->pipe));
>>   		/*
>>   		 * The TIMESTAMP_CTR register has the current
>>   		 * time stamp value.
>>   		 */
>>   		scan_curr_time = intel_de_read_fw(dev_priv, IVB_TIMESTAMP_CTR);
>>   
>> -		scan_post_time = intel_de_read_fw(dev_priv,
>> -						  PIPE_FRMTMSTMP(crtc->pipe));
>> +		if (!crtc->config->uapi.async_flip)
>> +			scan_post_time = intel_de_read_fw(dev_priv,
>> +							  PIPE_FRMTMSTMP(crtc->pipe));
>> +		else
>> +			scan_post_time = intel_de_read_fw(dev_priv,
>> +							  PIPE_FLIPTMSTMP(crtc->pipe));
>>   	} while (scan_post_time != scan_prev_time);
>>   
>>   	scanline = div_u64(mul_u32_u32(scan_curr_time - scan_prev_time,
>> @@ -937,7 +954,6 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
>>   		*vpos = position / htotal;
>>   		*hpos = position - (*vpos * htotal);
>>   	}
>> -
> 
> Please don't remove random blank lines.

Will fix this.
> 
>>   	return true;
>>   }
>>   
>> @@ -1295,6 +1311,24 @@ display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>>   			     u32 crc4) {}
>>   #endif
>>   
>> +static void flip_done_handler(struct drm_i915_private *dev_priv,
>> +			      unsigned int pipe)
>> +{
>> +	struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
>> +	struct drm_crtc_state *crtc_state = crtc->base.state;
>> +	struct drm_pending_vblank_event *e = crtc_state->event;
>> +	struct drm_device *dev = &dev_priv->drm;
>> +	unsigned long irqflags;
>> +
>> +	crtc_state->event = NULL;
>> +
>> +	drm_crtc_accurate_vblank_count(&crtc->base);
>> +	spin_lock_irqsave(&dev->event_lock, irqflags);
>> +
>> +	drm_crtc_send_vblank_event(&crtc->base, e);
> 
> Can you please explain why we need this pair of functions instead of
> relying on intel_handle_vblank() like the handler for the 'real' vblank
> interrupt? I'm not saying this is wrong, I'm just trying to understand
> the code in order to review it properly.
> 

intel_handle_vblank() would require the condition of drm_vblank_passed 
to be met, in order to send out the events. Since in async case this 
would not be true, I'm using the 'drm_crtc_send_vblank_event' function 
to send the vblank event.
Also, will remove the 'drm_crtc_accurate_vblank_count' function in the 
next revision as there will be no changes to the time stamping code now.
	
Thanks,
Karthik.B.S
> 
>> +
>> +	spin_unlock_irqrestore(&dev->event_lock, irqflags);
>> +}
>>   
>>   static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>>   				     enum pipe pipe)
>> @@ -2389,6 +2423,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
>>   		if (iir & GEN8_PIPE_VBLANK)
>>   			intel_handle_vblank(dev_priv, pipe);
>>   
>> +		if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
>> +			flip_done_handler(dev_priv, pipe);
>> +
>>   		if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
>>   			hsw_pipe_crc_irq_handler(dev_priv, pipe);
>>   
>> @@ -2710,6 +2747,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
>>   	return 0;
>>   }
>>   
>> +void skl_enable_flip_done(struct drm_crtc *crtc)
>> +{
>> +	struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> +	enum pipe pipe = to_intel_crtc(crtc)->pipe;
>> +	unsigned long irqflags;
>> +
>> +	spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
>> +
>> +	bdw_enable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
>> +
>> +	spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
>> +}
>> +
>>   /* Called from drm generic code, passed 'crtc' which
>>    * we use as a pipe index
>>    */
>> @@ -2770,6 +2820,19 @@ void bdw_disable_vblank(struct drm_crtc *crtc)
>>   	spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
>>   }
>>   
>> +void skl_disable_flip_done(struct drm_crtc *crtc)
>> +{
>> +	struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> +	enum pipe pipe = to_intel_crtc(crtc)->pipe;
>> +	unsigned long irqflags;
>> +
>> +	spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
>> +
>> +	bdw_disable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
>> +
>> +	spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
>> +}
>> +
>>   static void ibx_irq_reset(struct drm_i915_private *dev_priv)
>>   {
>>   	struct intel_uncore *uncore = &dev_priv->uncore;
>> @@ -2980,6 +3043,9 @@ void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
>>   	u32 extra_ier = GEN8_PIPE_VBLANK | GEN8_PIPE_FIFO_UNDERRUN;
>>   	enum pipe pipe;
>>   
>> +	if (INTEL_GEN(dev_priv) >= 9)
>> +		extra_ier |= GEN9_PIPE_PLANE1_FLIP_DONE;
>> +
>>   	spin_lock_irq(&dev_priv->irq_lock);
>>   
>>   	if (!intel_irqs_enabled(dev_priv)) {
>> @@ -3458,6 +3524,9 @@ static void gen8_de_irq_postinstall(struct drm_i915_private *dev_priv)
>>   	de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
>>   					   GEN8_PIPE_FIFO_UNDERRUN;
>>   
>> +	if (INTEL_GEN(dev_priv) >= 9)
>> +		de_pipe_enables |= GEN9_PIPE_PLANE1_FLIP_DONE;
>> +
>>   	de_port_enables = de_port_masked;
>>   	if (IS_GEN9_LP(dev_priv))
>>   		de_port_enables |= BXT_DE_PORT_HOTPLUG_MASK;
>> diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
>> index 25f25cd95818..2f10c8135116 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.h
>> +++ b/drivers/gpu/drm/i915/i915_irq.h
>> @@ -112,11 +112,13 @@ int i915gm_enable_vblank(struct drm_crtc *crtc);
>>   int i965_enable_vblank(struct drm_crtc *crtc);
>>   int ilk_enable_vblank(struct drm_crtc *crtc);
>>   int bdw_enable_vblank(struct drm_crtc *crtc);
>> +void skl_enable_flip_done(struct drm_crtc *crtc);
>>   void i8xx_disable_vblank(struct drm_crtc *crtc);
>>   void i915gm_disable_vblank(struct drm_crtc *crtc);
>>   void i965_disable_vblank(struct drm_crtc *crtc);
>>   void ilk_disable_vblank(struct drm_crtc *crtc);
>>   void bdw_disable_vblank(struct drm_crtc *crtc);
>> +void skl_disable_flip_done(struct drm_crtc *crtc);
>>   
>>   void gen2_irq_reset(struct intel_uncore *uncore);
>>   void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index a0d31f3bf634..8cee06314d5d 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -11144,9 +11144,11 @@ enum skl_power_gate {
>>   #define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK	(0xf << 12)
>>   
>>   #define _PIPE_FRMTMSTMP_A		0x70048
>> +#define _PIPE_FLIPTMSTMP_A		0x7004C
>>   #define PIPE_FRMTMSTMP(pipe)		\
>>   			_MMIO_PIPE2(pipe, _PIPE_FRMTMSTMP_A)
>> -
>> +#define PIPE_FLIPTMSTMP(pipe)		\
>> +			_MMIO_PIPE2(pipe, _PIPE_FLIPTMSTMP_A)
>>   /* BXT MIPI clock controls */
>>   #define BXT_MAX_VAR_OUTPUT_KHZ			39500
>>   
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler

[Karthik B S]

On 7/27/2020 5:57 PM, Michel Dänzer wrote:
> On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
>> Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>>> index 1fa67700d8f4..95953b393941 100644
>>> --- a/drivers/gpu/drm/i915/i915_irq.c
>>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>>> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
>>>   	return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xffffff;
>>>   }
>>>   
>>> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
>>> +{
>>> +	struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>>> +	enum pipe pipe = to_intel_crtc(crtc)->pipe;
>>> +
>>> +	return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
>>> +}
>>> +
>>>   u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
>>>   {
>>>   	struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>>>   	enum pipe pipe = to_intel_crtc(crtc)->pipe;
>>>   
>>> +	if (crtc->state->async_flip)
>>> +		return g4x_get_flip_counter(crtc);
>>> +
>>>   	return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
>>
>> I don't understand the intention behind this, can you please clarify?
>> This goes back to my reply of the cover letter. It seems that here
>> we're going to alternate between two different counters in our vblank
>> count. So if user space alternates between sometimes using async flips
>> and sometimes using normal flip it's going to get some very weird
>> deltas, isn't it? At least this is what I remember from when I played
>> with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
>> using async flips.
> 
> This definitely looks wrong. The counter value returned by the
> get_vblank_counter hook is supposed to increment when a vertical blank
> period occurs; page flips are not supposed to affect this in any way.
> 

Thanks for the review.
As per the feedback received, I will be removing this and will revert 
back to the original implementation in the next revision.

Thanks,
Karthik.B.S
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler

[Karthik B S]

On 7/28/2020 3:04 AM, Daniel Vetter wrote:
> On Mon, Jul 27, 2020 at 2:27 PM Michel Dänzer <michel@daenzer.net> wrote:
>>
>> On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
>>> Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>>>> index 1fa67700d8f4..95953b393941 100644
>>>> --- a/drivers/gpu/drm/i915/i915_irq.c
>>>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>>>> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
>>>>       return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xffffff;
>>>>   }
>>>>
>>>> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
>>>> +{
>>>> +    struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>>>> +    enum pipe pipe = to_intel_crtc(crtc)->pipe;
>>>> +
>>>> +    return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
>>>> +}
>>>> +
>>>>   u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
>>>>   {
>>>>       struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>>>>       enum pipe pipe = to_intel_crtc(crtc)->pipe;
>>>>
>>>> +    if (crtc->state->async_flip)
>>>> +            return g4x_get_flip_counter(crtc);
>>>> +
>>>>       return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
>>>
>>> I don't understand the intention behind this, can you please clarify?
>>> This goes back to my reply of the cover letter. It seems that here
>>> we're going to alternate between two different counters in our vblank
>>> count. So if user space alternates between sometimes using async flips
>>> and sometimes using normal flip it's going to get some very weird
>>> deltas, isn't it? At least this is what I remember from when I played
>>> with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
>>> using async flips.
>>
>> This definitely looks wrong. The counter value returned by the
>> get_vblank_counter hook is supposed to increment when a vertical blank
>> period occurs; page flips are not supposed to affect this in any way.
> 
> Also you just flat out can't access crtc->state from interrupt
> context. Anything you need in there needs to be protected by the right
> irq-type spin_lock, updates correctly synchronized against both the
> interrupt handler and atomic updates, and data copied over, not
> pointers. Otherwise just crash&burn.

Thanks for the review.
I will be removing this change in the next revision based on the 
feedback received, but I will keep this in mind whenever I'll have to 
access something from the interrupt context.

Thanks,
Karthik.B.S
> -Daniel
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx