| Message ID | 20221012083402.1069940-1-anshuman.gupta@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/dgfx: Temporary hammer to keep autosuspend control 'on' | expand |
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? Besides... is this a hack, workaround, permanent solution? Andi
On 12/10/2022 09:34, 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. > > Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by default") So with this change all the runtime pm stuff is disabled on dgfx? i.e intel_runtime_pm_get() always returns zero or so? Wondering if we should also revert ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend") for now, since that still needs some more fixes... > Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 6ed5786bcd29..410a5cb58a61 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm) > pm_runtime_use_autosuspend(kdev); > } > > - /* Enable by default */ > - pm_runtime_allow(kdev); > + /* > + * FIXME: Temp hammer to keep autosupend disable on lmem supported platforms. > + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe > + * function will be unsupported in case PCIe endpoint function is in D3. > + * Let's keep i915 autosuspend control 'on' till we fix all known issue > + * with lmem access in D3. > + */ > + if (!HAS_LMEM(i915)) > + pm_runtime_allow(kdev); > > /* > * The core calls the driver load handler with an RPM reference held.
I think I commented on this already, but the patch subject should really be as informative as possible like: "Disable PCI runtime PM on dGPUs" as that is exactly what the patch does. Also bit unsure if the Fixes: tag should really point to the runtime PM commit but maybe instead to the introduction of LMEM commit. Regards, Joonas Quoting Anshuman Gupta (2022-10-12 11:34:02) > 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. > > Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by default") > Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 6ed5786bcd29..410a5cb58a61 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm) > pm_runtime_use_autosuspend(kdev); > } > > - /* Enable by default */ > - pm_runtime_allow(kdev); > + /* > + * FIXME: Temp hammer to keep autosupend disable on lmem supported platforms. > + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe > + * function will be unsupported in case PCIe endpoint function is in D3. > + * Let's keep i915 autosuspend control 'on' till we fix all known issue > + * with lmem access in D3. > + */ > + if (!HAS_LMEM(i915)) > + pm_runtime_allow(kdev); > > /* > * The core calls the driver load handler with an RPM reference held. > -- > 2.25.1 >
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
On Wed, Oct 12, 2022 at 10:48:30AM +0100, Matthew Auld wrote: > On 12/10/2022 09:34, 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. > > > > Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by default") > > So with this change all the runtime pm stuff is disabled on dgfx? i.e > intel_runtime_pm_get() always returns zero or so? Wondering if we should > also revert ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend") for > now, since that still needs some more fixes... I don't believe we need to revert that. That's already one step forward towards the final solution. It is not complete but it is not wrong. And it is orthogonal to this protection right now. > > > Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > --- > > drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c > > index 6ed5786bcd29..410a5cb58a61 100644 > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm) > > pm_runtime_use_autosuspend(kdev); > > } > > - /* Enable by default */ > > - pm_runtime_allow(kdev); > > + /* > > + * FIXME: Temp hammer to keep autosupend disable on lmem supported platforms. > > + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe > > + * function will be unsupported in case PCIe endpoint function is in D3. > > + * Let's keep i915 autosuspend control 'on' till we fix all known issue > > + * with lmem access in D3. > > + */ > > + if (!HAS_LMEM(i915)) > > + pm_runtime_allow(kdev); > > /* > > * The core calls the driver load handler with an RPM reference held.
On Wed, Oct 12, 2022 at 01:26:45PM +0300, Joonas Lahtinen wrote: > I think I commented on this already, but the patch subject should really be as > informative as possible like: "Disable PCI runtime PM on dGPUs" as that is exactly > what the patch does. +1 here. > > Also bit unsure if the Fixes: tag should really point to the runtime PM > commit but maybe instead to the introduction of LMEM commit. indeed. if the runtime_pm by default came earlier then the LMEM, the HAS_LMEM() won't even exist and it will break the ports. So, I'd say to go to whatever patch is the most recent between the 2. With those changes: Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Regards, Joonas > > Quoting Anshuman Gupta (2022-10-12 11:34:02) > > 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. > > > > Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by default") > > Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > --- > > drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c > > index 6ed5786bcd29..410a5cb58a61 100644 > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm) > > pm_runtime_use_autosuspend(kdev); > > } > > > > - /* Enable by default */ > > - pm_runtime_allow(kdev); > > + /* > > + * FIXME: Temp hammer to keep autosupend disable on lmem supported platforms. > > + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe > > + * function will be unsupported in case PCIe endpoint function is in D3. > > + * Let's keep i915 autosuspend control 'on' till we fix all known issue > > + * with lmem access in D3. > > + */ > > + if (!HAS_LMEM(i915)) > > + pm_runtime_allow(kdev); > > > > /* > > * The core calls the driver load handler with an RPM reference held. > > -- > > 2.25.1 > >
On 12/10/2022 15:57, Rodrigo Vivi wrote: > On Wed, Oct 12, 2022 at 10:48:30AM +0100, Matthew Auld wrote: >> On 12/10/2022 09:34, 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. >>> >>> Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by default") >> >> So with this change all the runtime pm stuff is disabled on dgfx? i.e >> intel_runtime_pm_get() always returns zero or so? Wondering if we should >> also revert ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend") for >> now, since that still needs some more fixes... > > I don't believe we need to revert that. That's already one step forward towards > the final solution. It is not complete but it is not wrong. > And it is orthogonal to this protection right now. That commit has some known bugs though, see https://patchwork.freedesktop.org/patch/504444/?series=108972&rev=1. But that patch appears stuck for a while now, so my question was if we should just revert for now, or does this patch now effectively make those known bugs a non-issue... > >> >>> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> >>> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> >>> --- >>> drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c >>> index 6ed5786bcd29..410a5cb58a61 100644 >>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c >>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c >>> @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm) >>> pm_runtime_use_autosuspend(kdev); >>> } >>> - /* Enable by default */ >>> - pm_runtime_allow(kdev); >>> + /* >>> + * FIXME: Temp hammer to keep autosupend disable on lmem supported platforms. >>> + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe >>> + * function will be unsupported in case PCIe endpoint function is in D3. >>> + * Let's keep i915 autosuspend control 'on' till we fix all known issue >>> + * with lmem access in D3. >>> + */ >>> + if (!HAS_LMEM(i915)) >>> + pm_runtime_allow(kdev); >>> /* >>> * The core calls the driver load handler with an RPM reference held.
On Wed, 12 Oct 2022 02:48:30 -0700, Matthew Auld wrote: > > So with this change all the runtime pm stuff is disabled on dgfx? i.e > intel_runtime_pm_get() always returns zero or so? I guess it should always return non-zero (or the wakeref) since the device is always on...
> -----Original Message----- > From: Dixit, Ashutosh <ashutosh.dixit@intel.com> > Sent: Wednesday, October 12, 2022 8:49 PM > To: Auld, Matthew <matthew.auld@intel.com> > Cc: Gupta, Anshuman <anshuman.gupta@intel.com>; intel- > gfx@lists.freedesktop.org; Vivi, Rodrigo <rodrigo.vivi@intel.com> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dgfx: Temporary hammer to keep > autosuspend control 'on' > > On Wed, 12 Oct 2022 02:48:30 -0700, Matthew Auld wrote: > > > > So with this change all the runtime pm stuff is disabled on dgfx? i.e > > intel_runtime_pm_get() always returns zero or so? > > I guess it should always return non-zero (or the wakeref) since the device is > always on... This patch does not disable runtime PM completely, it just disables autosuspend i.e by grabbing the wakeref(device usage_count) at PM core level. intel_runtime_pm_get() is orthogonal to it and will get a wakeref and will increment the PM core device usage_count. This just changes default behavior of i915, our igt rpm tests still overrides the autosuspend control to 'auto'. I915 driver still vulnerable to any lmem access without a valid wakeref with our CI execution. Thanks, Anshuman Gupta.
> -----Original Message----- > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > Sent: Wednesday, October 12, 2022 8:31 PM > To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: Gupta, Anshuman <anshuman.gupta@intel.com>; intel- > gfx@lists.freedesktop.org; tvrtko.ursulin@linux.intel.com; Auld, Matthew > <matthew.auld@intel.com> > Subject: Re: [PATCH] drm/i915/dgfx: Temporary hammer to keep autosuspend > control 'on' > > On Wed, Oct 12, 2022 at 01:26:45PM +0300, Joonas Lahtinen wrote: > > I think I commented on this already, but the patch subject should > > really be as informative as possible like: "Disable PCI runtime PM on > > dGPUs" as that is exactly what the patch does. > > +1 here. Hi Joonas & Rodrigo, This patch don't disable runtime PM, it just keep autosupend control to 'on' , user or IGT tests can still enable autosupend by writing echo 'auto' > /sys/bus/pci/devices/bdf/power/control. So I believe I should keep the subject something like "Keep PCI autosupend 'on' dGPU" Other similar patch (https://patchwork.freedesktop.org/series/108477/) will disable the runtime PM completely. > > > > > Also bit unsure if the Fixes: tag should really point to the runtime > > PM commit but maybe instead to the introduction of LMEM commit. > I will remove the Fixes tag and replace it with introduction of LMEM tag. > indeed. if the runtime_pm by default came earlier then the LMEM, the > HAS_LMEM() won't even exist and it will break the ports. So here I should use IS_DGFX() instead of HAS_LMEM() ? Thanks, Anshuman Gupta. > > So, I'd say to go to whatever patch is the most recent between the 2. > > With those changes: > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > > > > Regards, Joonas > > > > Quoting Anshuman Gupta (2022-10-12 11:34:02) > > > 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. > > > > > > Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by > > > default") > > > Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > > --- > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- > > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > > > b/drivers/gpu/drm/i915/intel_runtime_pm.c > > > index 6ed5786bcd29..410a5cb58a61 100644 > > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > > @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct > intel_runtime_pm *rpm) > > > pm_runtime_use_autosuspend(kdev); > > > } > > > > > > - /* Enable by default */ > > > - pm_runtime_allow(kdev); > > > + /* > > > + * FIXME: Temp hammer to keep autosupend disable on lmem > supported platforms. > > > + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe > > > + * function will be unsupported in case PCIe endpoint function is in D3. > > > + * Let's keep i915 autosuspend control 'on' till we fix all known issue > > > + * with lmem access in D3. > > > + */ > > > + if (!HAS_LMEM(i915)) > > > + pm_runtime_allow(kdev); > > > > > > /* > > > * The core calls the driver load handler with an RPM reference held. > > > -- > > > 2.25.1 > > >
> -----Original Message----- > From: Auld, Matthew <matthew.auld@intel.com> > Sent: Wednesday, October 12, 2022 3:19 PM > To: Gupta, Anshuman <anshuman.gupta@intel.com>; intel- > gfx@lists.freedesktop.org > Cc: joonas.lahtinen@linux.intel.com; tvrtko.ursulin@linux.intel.com; Vivi, > Rodrigo <rodrigo.vivi@intel.com> > Subject: Re: [PATCH] drm/i915/dgfx: Temporary hammer to keep autosuspend > control 'on' > > On 12/10/2022 09:34, 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. > > > > Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by > > default") > > So with this change all the runtime pm stuff is disabled on dgfx? i.e > intel_runtime_pm_get() always returns zero or so? Wondering if we should also > revert ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend") for > now, since that still needs some more fixes... Hi Matt, This patch just keeps autosupend to 'on' as i915 default. User can change it to 'auto' by echo 'auto' > /sys/bus/pci/devices/bdf/power/control , so we need the above mentioned commit and need to fix the issues with it. Thanks, Anshuman Gupta. > > > Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > --- > > drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > > b/drivers/gpu/drm/i915/intel_runtime_pm.c > > index 6ed5786bcd29..410a5cb58a61 100644 > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct > intel_runtime_pm *rpm) > > pm_runtime_use_autosuspend(kdev); > > } > > > > - /* Enable by default */ > > - pm_runtime_allow(kdev); > > + /* > > + * FIXME: Temp hammer to keep autosupend disable on lmem > supported platforms. > > + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe > > + * function will be unsupported in case PCIe endpoint function is in D3. > > + * Let's keep i915 autosuspend control 'on' till we fix all known issue > > + * with lmem access in D3. > > + */ > > + if (!HAS_LMEM(i915)) > > + pm_runtime_allow(kdev); > > > > /* > > * The core calls the driver load handler with an RPM reference held.
Pushed to drm-intel-next.
Thanks for Review.
Br,
Anshuman Gupta.
From: Patchwork <patchwork@emeril.freedesktop.org>
Sent: Friday, October 14, 2022 7:01 PM
To: Gupta, Anshuman <anshuman.gupta@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: ✓ Fi.CI.IGT: success for drm/i915/dgfx: Temporary hammer to keep autosuspend control 'on' (rev2)
Patch Details
Series:
drm/i915/dgfx: Temporary hammer to keep autosuspend control 'on' (rev2)
URL:
https://patchwork.freedesktop.org/series/109612/
State:
success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/index.html
CI Bug Log - changes from CI_DRM_12242_full -> Patchwork_109612v2_full
Summary
SUCCESS
No regressions found.
Participating hosts (9 -> 11)
Additional (2): shard-rkl shard-dg1
Known issues
Here are the changes found in Patchwork_109612v2_full that come from known issues:
CI changes
Possible fixes
• boot:
o shard-skl: (https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl7/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl1/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl4/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl1/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl1/boot.html) (https://gitlab.freedesktop.org/drm/intel/issues/5032) -> (https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl1/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl7/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl7/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl6/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl6/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl6/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl5/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl5/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl4/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl4/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl4/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl2/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl2/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl1/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl1/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl10/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl10/boot.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl10/boot.html)
IGT changes
Issues hit
• igt@gem_exec_balancer@parallel-out-fence:
o shard-iclb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-iclb1/igt@gem_exec_balancer@parallel-out-fence.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb8/igt@gem_exec_balancer@parallel-out-fence.html (https://gitlab.freedesktop.org/drm/intel/issues/4525)
• igt@gem_exec_fair@basic-none-solo@rcs0:
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl7/igt@gem_exec_fair@basic-none-solo@rcs0.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl8/igt@gem_exec_fair@basic-none-solo@rcs0.html (https://gitlab.freedesktop.org/drm/intel/issues/2842)
• igt@gem_exec_fair@basic-none@vcs1:
o shard-iclb: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb1/igt@gem_exec_fair@basic-none@vcs1.html (https://gitlab.freedesktop.org/drm/intel/issues/2842)
• igt@gem_exec_fair@basic-pace@vecs0:
o shard-iclb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-iclb8/igt@gem_exec_fair@basic-pace@vecs0.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb6/igt@gem_exec_fair@basic-pace@vecs0.html (https://gitlab.freedesktop.org/drm/intel/issues/2842)
• igt@gem_huc_copy@huc-copy:
o shard-tglb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-tglb5/igt@gem_huc_copy@huc-copy.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-tglb7/igt@gem_huc_copy@huc-copy.html (https://gitlab.freedesktop.org/drm/intel/issues/2190)
• igt@gem_lmem_swapping@heavy-random:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@gem_lmem_swapping@heavy-random.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/4613) +1 similar issue
• igt@gem_userptr_blits@dmabuf-sync:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@gem_userptr_blits@dmabuf-sync.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/3323)
• igt@gen9_exec_parse@allowed-single:
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl1/igt@gen9_exec_parse@allowed-single.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@gen9_exec_parse@allowed-single.html (https://gitlab.freedesktop.org/drm/intel/issues/5566 / https://gitlab.freedesktop.org/drm/intel/issues/716)
• igt@i915_pipe_stress@stress-xrgb8888-untiled:
o shard-apl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@i915_pipe_stress@stress-xrgb8888-untiled.html (https://gitlab.freedesktop.org/drm/intel/issues/7036)
• igt@i915_selftest@live@gt_heartbeat:
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl1/igt@i915_selftest@live@gt_heartbeat.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl6/igt@i915_selftest@live@gt_heartbeat.html (https://gitlab.freedesktop.org/drm/intel/issues/5334)
• igt@kms_async_flips@alternate-sync-async-flip@pipe-b-edp-1:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip@pipe-b-edp-1.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip@pipe-b-edp-1.html (https://gitlab.freedesktop.org/drm/intel/issues/2521) +1 similar issue
• igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/3886)
• igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_rc_ccs_cc:
o shard-apl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/3886) +2 similar issues
o shard-glk: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk3/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/3886)
• igt@kms_ccs@pipe-b-bad-rotation-90-4_tiled_dg2_rc_ccs_cc:
o shard-apl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@kms_ccs@pipe-b-bad-rotation-90-4_tiled_dg2_rc_ccs_cc.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) +52 similar issues
• igt@kms_ccs@pipe-c-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs:
o shard-glk: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk3/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) +27 similar issues
• igt@kms_chamelium@hdmi-edid-change-during-suspend:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_chamelium@hdmi-edid-change-during-suspend.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://bugs.freedesktop.org/show_bug.cgi?id=111827) +3 similar issues
• igt@kms_chamelium@hdmi-hpd-storm:
o shard-apl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@kms_chamelium@hdmi-hpd-storm.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://bugs.freedesktop.org/show_bug.cgi?id=111827) +3 similar issues
o shard-glk: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk3/igt@kms_chamelium@hdmi-hpd-storm.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://bugs.freedesktop.org/show_bug.cgi?id=111827)
• igt@kms_color@ctm-0-25:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_color@ctm-0-25.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/3546)
• igt@kms_fbcon_fbt@psr-suspend:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_fbcon_fbt@psr-suspend.html (https://gitlab.freedesktop.org/drm/intel/issues/4939 / https://gitlab.freedesktop.org/drm/intel/issues/7192)
• igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2:
o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2.html (https://gitlab.freedesktop.org/drm/intel/issues/79)
• igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@c-edp1:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@c-edp1.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl2/igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@c-edp1.html (https://gitlab.freedesktop.org/drm/intel/issues/2122) +1 similar issue
• igt@kms_flip@flip-vs-expired-vblank@c-edp1:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl1/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html (https://gitlab.freedesktop.org/drm/intel/issues/79) +1 similar issue
• igt@kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling@pipe-a-default-mode:
o shard-iclb: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling@pipe-a-default-mode.html (https://gitlab.freedesktop.org/drm/intel/issues/3555)
• igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscaling@pipe-a-default-mode:
o shard-iclb: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscaling@pipe-a-default-mode.html (https://gitlab.freedesktop.org/drm/intel/issues/2672) +2 similar issues
• igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode:
o shard-iclb: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb5/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode.html (https://gitlab.freedesktop.org/drm/intel/issues/2587 / https://gitlab.freedesktop.org/drm/intel/issues/2672) +1 similar issue
• igt@kms_frontbuffer_tracking@fbcpsr-suspend:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) +116 similar issues
• igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1:
o shard-apl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1.html (https://gitlab.freedesktop.org/drm/intel/issues/4573) +2 similar issues
• igt@kms_psr2_su@page_flip-p010@pipe-b-edp-1:
o shard-iclb: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb2/igt@kms_psr2_su@page_flip-p010@pipe-b-edp-1.html (https://gitlab.freedesktop.org/drm/intel/issues/5939) +2 similar issues
• igt@kms_psr2_su@page_flip-xrgb8888:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_psr2_su@page_flip-xrgb8888.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/658) +2 similar issues
• igt@kms_psr@psr2_primary_mmap_cpu:
o shard-iclb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb1/igt@kms_psr@psr2_primary_mmap_cpu.html (https://bugs.freedesktop.org/show_bug.cgi?id=109441)
• igt@kms_vblank@pipe-b-ts-continuation-suspend:
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl8/igt@kms_vblank@pipe-b-ts-continuation-suspend.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl3/igt@kms_vblank@pipe-b-ts-continuation-suspend.html (https://gitlab.freedesktop.org/drm/intel/issues/180) +2 similar issues
• igt@kms_writeback@writeback-invalid-parameters:
o shard-skl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl9/igt@kms_writeback@writeback-invalid-parameters.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/2437)
• igt@perf@blocking:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@perf@blocking.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl6/igt@perf@blocking.html (https://gitlab.freedesktop.org/drm/intel/issues/1542)
• igt@perf@polling-parameterized:
o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk6/igt@perf@polling-parameterized.html -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk6/igt@perf@polling-parameterized.html (https://gitlab.freedesktop.org/drm/intel/issues/5639)
• igt@sysfs_clients@create:
o shard-apl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@sysfs_clients@create.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/2994)
Possible fixes
• igt@gem_exec_balancer@parallel-balancer:
o shard-iclb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-iclb5/igt@gem_exec_balancer@parallel-balancer.html (https://gitlab.freedesktop.org/drm/intel/issues/4525) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb2/igt@gem_exec_balancer@parallel-balancer.html
• igt@gem_exec_fair@basic-flow@rcs0:
o shard-tglb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-tglb7/igt@gem_exec_fair@basic-flow@rcs0.html (https://gitlab.freedesktop.org/drm/intel/issues/2842) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-tglb1/igt@gem_exec_fair@basic-flow@rcs0.html
• igt@gem_exec_fair@basic-pace-share@rcs0:
o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk3/igt@gem_exec_fair@basic-pace-share@rcs0.html (https://gitlab.freedesktop.org/drm/intel/issues/2842) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk5/igt@gem_exec_fair@basic-pace-share@rcs0.html
• igt@gen9_exec_parse@allowed-all:
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl2/igt@gen9_exec_parse@allowed-all.html (https://gitlab.freedesktop.org/drm/intel/issues/5566 / https://gitlab.freedesktop.org/drm/intel/issues/716) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@gen9_exec_parse@allowed-all.html
• igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic.html (https://gitlab.freedesktop.org/drm/intel/issues/2346) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl6/igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic.html
• igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk9/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html (https://gitlab.freedesktop.org/drm/intel/issues/2346) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk7/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html
• igt@kms_flip@busy-flip@c-edp1:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/igt@kms_flip@busy-flip@c-edp1.html (https://gitlab.freedesktop.org/drm/intel/issues/7200) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl7/igt@kms_flip@busy-flip@c-edp1.html +1 similar issue
• igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1:
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl3/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html (https://gitlab.freedesktop.org/drm/intel/issues/180) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html +1 similar issue
• igt@perf@polling-parameterized:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl10/igt@perf@polling-parameterized.html (https://gitlab.freedesktop.org/drm/intel/issues/5639) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl10/igt@perf@polling-parameterized.html
• igt@perf@stress-open-close:
o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk1/igt@perf@stress-open-close.html (https://gitlab.freedesktop.org/drm/intel/issues/5213) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk3/igt@perf@stress-open-close.html
Warnings
• igt@dmabuf@all@dma_fence_chain:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl6/igt@dmabuf@all@dma_fence_chain.html (https://gitlab.freedesktop.org/drm/intel/issues/6949 / https://gitlab.freedesktop.org/drm/intel/issues/7165) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl6/igt@dmabuf@all@dma_fence_chain.html (https://gitlab.freedesktop.org/drm/intel/issues/6949 / https://gitlab.freedesktop.org/drm/intel/issues/7165 / https://gitlab.freedesktop.org/drm/intel/issues/7192)
• igt@gem_exec_fair@basic-throttle@rcs0:
o shard-tglb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-tglb3/igt@gem_exec_fair@basic-throttle@rcs0.html (https://gitlab.freedesktop.org/drm/intel/issues/2842) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-tglb2/igt@gem_exec_fair@basic-throttle@rcs0.html (https://gitlab.freedesktop.org/drm/intel/issues/2848) +2 similar issues
• igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip:
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl7/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl8/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/7206)
o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk9/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk7/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/7206)
• igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl1/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/3886) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl5/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html (https://gitlab.freedesktop.org/drm/intel/issues/7192)
• igt@kms_dsc@dsc-with-bpc-formats:
o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk9/igt@kms_dsc@dsc-with-bpc-formats.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-glk7/igt@kms_dsc@dsc-with-bpc-formats.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/7205)
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl5/igt@kms_dsc@dsc-with-bpc-formats.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl7/igt@kms_dsc@dsc-with-bpc-formats.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/7205)
o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl7/igt@kms_dsc@dsc-with-bpc-formats.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl8/igt@kms_dsc@dsc-with-bpc-formats.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/7205)
• igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-default-mode:
o shard-skl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-default-mode.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-skl1/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-upscaling@pipe-a-default-mode.html (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/7207)
• igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf:
o shard-iclb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-iclb5/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf.html (https://gitlab.freedesktop.org/drm/intel/issues/658) -> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-iclb2/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf.html (https://gitlab.freedesktop.org/drm/intel/issues/2920)
• igt@runner@aborted:
o shard-apl: (https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl2/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl6/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl8/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl3/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-apl3/igt@runner@aborted.html) (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/3002 / https://gitlab.freedesktop.org/drm/intel/issues/4312) -> (https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl3/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl6/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl3/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl7/igt@runner@aborted.html, https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109612v2/shard-apl1/igt@runner@aborted.html) (https://bugs.freedesktop.org/show_bug.cgi?id=109271 / https://gitlab.freedesktop.org/drm/intel/issues/180 / https://gitlab.freedesktop.org/drm/intel/issues/3002 / https://gitlab.freedesktop.org/drm/intel/issues/4312)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
Build changes
• Linux: CI_DRM_12242 -> Patchwork_109612v2
CI-20190529: 20190529
CI_DRM_12242: 075a81b1efd29300194bdf7877e08b6dbe3079d9 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7012: ca6f5bdd537d26692c4b1ca011b8c4f227d95703 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_109612v2: 075a81b1efd29300194bdf7877e08b6dbe3079d9 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 6ed5786bcd29..410a5cb58a61 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -591,8 +591,15 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm) pm_runtime_use_autosuspend(kdev); } - /* Enable by default */ - pm_runtime_allow(kdev); + /* + * FIXME: Temp hammer to keep autosupend disable on lmem supported platforms. + * As per PCIe specs 5.3.1.4.1, all iomem read write request over a PCIe + * function will be unsupported in case PCIe endpoint function is in D3. + * Let's keep i915 autosuspend control 'on' till we fix all known issue + * with lmem access in D3. + */ + if (!HAS_LMEM(i915)) + pm_runtime_allow(kdev); /* * The core calls the driver load handler with an RPM reference held.
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. Fixes: 527bab0473f2 ("drm/i915/rpm: Enable runtime pm autosuspend by default") Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> --- drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)