[Intel-gfx] [PATCH] drm/i915/dgfx: Temporary hammer to keep autosuspend control 'on'

[Rodrigo Vivi]

On Wed, Oct 12, 2022 at 11:21:59AM +0200, Andi Shyti wrote:
> Hi Anshuman,
> 
> On Wed, Oct 12, 2022 at 02:04:02PM +0530, Anshuman Gupta wrote:
> > DGFX platforms has lmem and cpu can access the lmem objects
> > via mmap and i915 internal i915_gem_object_pin_map() for
> > i915 own usages. Both of these methods has pre-requisite
> > requirement to keep GFX PCI endpoint in D0 for a supported
> > iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)
> > 
> > Both DG1/DG2 have a hardware bug that violates the PCIe specs
> > and support the iomem read write transaction over PCIe bus despite
> > endpoint is D3 state.
> > Due to above H/W bug, we had never observed any issue with i915 runtime
> > PM versus lmem access.
> > But this issue becomes visible when PCIe gfx endpoint's upstream
> > bridge enters to D3, at this point any lmem read/write access will be
> > returned as unsupported request. But again this issue is not observed
> > on every platform because it has been observed on few host machines
> > DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.
> > which really disables the PCIe  power savings and leaves the bridge
> > at D0 state.
> > 
> > Till we fix all issues related to runtime PM, we need
> > to keep autosupend control to 'on' on all discrete platforms with lmem.
> 
> if it's only DG1 and DG2... why do we need to do it for every
> platform?

The HW bug on DG1 and DG2 makes our sw to work well so we didn't noticed that!
But the SW bug exist in all the dgfx

> 
> Besides... is this a hack, workaround, permanent solution?

Yeap, probably better to move the "temporary hammer" from the subject
to the commit message.
Also the FIXME comment in the code states the temporary hack nature of it.

> 
> Andi