[Intel-gfx] [PATCH] drm/i915: Read a shadowed mmio register for ggtt flush
Sripada, Radhakrishna
radhakrishna.sripada at intel.com
Wed Nov 15 19:46:23 UTC 2023
Hi Vinay,
> -----Original Message-----
> From: dri-devel <dri-devel-bounces at lists.freedesktop.org> On Behalf Of
> Belgaumkar, Vinay
> Sent: Thursday, November 9, 2023 5:02 PM
> To: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Read a shadowed mmio register for
> ggtt flush
>
>
> On 11/9/2023 12:35 PM, Ville Syrjälä wrote:
> > On Thu, Nov 09, 2023 at 12:01:26PM -0800, Belgaumkar, Vinay wrote:
> >> On 11/9/2023 11:30 AM, Ville Syrjälä wrote:
> >>> On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote:
> >>>> We read RENDER_HEAD as a part of the flush. If GT is in
> >>>> deeper sleep states, this could lead to read errors since we are
> >>>> not using a forcewake. Safer to read a shadowed register instead.
> >>> IIRC shadowing is only thing for writes, not reads.
> >> Sure, but reading from a shadowed register does return the cached value
> > Does it? I suppose that would make some sense, but I don't recall that
> > ever being stated anywhere. At least before the shadow registers
> > existed reads would just give you zeroes when not awake.
> >
> >> (even though we don't care about the vakue here). When GT is in deeper
> >> sleep states, it is better to read a shadowed (cached) value instead of
> >> trying to attempt an mmio register read without a force wake anyways.
> > So you're saying reads from non-shadowed registers fails somehow
> > when not awake? How exactly do they fail? And when reading from
> > a shadowed register that failure never happens?
>
> We could hit problems like the one being addressed here -
> https://patchwork.freedesktop.org/series/125356/. Reading from a
> shadowed register will avoid any needless references(without a wake) to
> the MMIO space. Shouldn't hurt to make this change for all gens IMO.
The proposed usage looks accurate for the issue described.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada at intel.com>
--Radhakrishna(RK) Sripada
>
> Thanks,
>
> Vinay.
>
> >
> >> Thanks,
> >>
> >> Vinay.
> >>
> >>>> Cc: John Harrison <john.c.harrison at intel.com>
> >>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> >>>> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
> >>>> ---
> >>>> drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> >>>> index ed32bf5b1546..ea814ea5f700 100644
> >>>> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> >>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> >>>> @@ -451,7 +451,7 @@ void intel_gt_flush_ggtt_writes(struct intel_gt *gt)
> >>>>
> >>>> spin_lock_irqsave(&uncore->lock, flags);
> >>>> intel_uncore_posting_read_fw(uncore,
> >>>> - RING_HEAD(RENDER_RING_BASE));
> >>>> + RING_TAIL(RENDER_RING_BASE));
> >>>> spin_unlock_irqrestore(&uncore->lock, flags);
> >>>> }
> >>>> }
> >>>> --
> >>>> 2.38.1
More information about the dri-devel
mailing list