[Intel-gfx] [PATCH] drm/i915/adl_s: Fix dma_mask_size to 39 bit

[Surendrakumar Upadhyay, TejaskumarX]

> -----Original Message-----
> From: Matthew Auld <matthew.william.auld at gmail.com>
> Sent: 07 July 2021 15:45
> To: Surendrakumar Upadhyay, TejaskumarX
> <tejaskumarx.surendrakumar.upadhyay at intel.com>
> Cc: Intel Graphics Development <intel-gfx at lists.freedesktop.org>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Fix dma_mask_size to 39 bit
> 
> On Wed, 7 Jul 2021 at 09:31, Tejas Upadhyay
> <tejaskumarx.surendrakumar.upadhyay at intel.com> wrote:
> >
> > 46 bit addressing enables you to use 4 bits  to support some MKTME
> > features, and 3 more bits for Optane support that uses a subset of
> > MTKME for persistent memory.
> >
> > But display sticking to 39 bit addressing, thus setting dma_mask_size
> 
> What is meant by "display" here? Is this limited to the display part of the
> HW? Or just in general any HW access via GGTT or ppGTT?
> 

I am really not sure of in general, but all tests which were failing with intel_iommu=on and passing with off, are happy with 39 bit addressing. 

> Also do you know if this is documented somewhere in the Bspec? If so,
> adding Bspec: link would be good.

Bspec link does not show this, but there is HSD which gives information. Unfortunately not able to share HSD link in this forum. I have copied info from HSD only.
I will also try to add additional details in commit message.  

> 
> > to 39 fixes below tests :
> > igt at i915_selftest@live at mman
> > kms_big_fb --r linear-32bpp-rotate-0
> 
> This looks promising. From chatting with Chris it looks like this is
> https://gitlab.freedesktop.org/drm/intel/-/issues/3142 ?
> 
> If so, it might be good to add a References: tag and add the following
> example to the commit message:
> 
> DMAR: DRHD: handling fault status reg 2
> DMAR: [DMA Write] Request device [00:02.0] PASID ffffffff fault addr
> 7effff9000 [fault reason 05] PTE Write access is not set
> 
> Also maybe highlight that the address 0x7effff9000 is suspiciously exactly 39
> bits, so it seems likely that the HW just ends up masking off those extra bits
> or something when doing the access, hence why we might see strange DMAR
> errors?
> 

Sure I will add this.

Thanks,
Tejas
> Nice find,
> Acked-by: Matthew Auld <matthew.auld at intel.com>
> 
> >
> > Signed-off-by: Tejas Upadhyay
> > <tejaskumarx.surendrakumar.upadhyay at intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index a7bfdd827bc8..0fea4c0c6d48
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -934,7 +934,7 @@ static const struct intel_device_info adl_s_info = {
> >         .display.has_psr_hw_tracking = 0,
> >         .platform_engine_mask =
> >                 BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
> > -       .dma_mask_size = 46,
> > +       .dma_mask_size = 39,
> >  };
> >
> >  #define XE_LPD_CURSOR_OFFSETS \
> > --
> > 2.31.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx