[Intel-gfx] ✓ Fi.CI.IGT: success for Report MMIO communication problems more clearly (rev3)
== Series Details ==
Series: Report MMIO communication problems more clearly (rev3)
URL : https://patchwork.freedesktop.org/series/115421/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12922_full -> Patchwork_115421v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115421v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_exec@basic:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-dg1-18/igt@gem_ctx_e...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-dg1-16/igt@gem_ctx_e...@basic.html
* igt@kms_flip@plain-flip-fb-recreate@a-hdmi-a1:
- {shard-tglu}: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-tglu-6/igt@kms_flip@plain-flip-fb-recre...@a-hdmi-a1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-tglu-6/igt@kms_flip@plain-flip-fb-recre...@a-hdmi-a1.html
Known issues
Here are the changes found in Patchwork_115421v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-cleanup:
- shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-snb5/igt@gem_ctx_persiste...@engines-cleanup.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-b-hdmi-a-1:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2521])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-glk6/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-hdmi-a-1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-glk8/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-hdmi-a-1.html
* igt@kms_cursor_crc@cursor-rapid-movement-512x512:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +130 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-snb5/igt@kms_cursor_...@cursor-rapid-movement-512x512.html
Possible fixes
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][9] ([i915#6268]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-tglu-10/igt@gem_ctx_e...@basic-nohangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-tglu-8/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: [FAIL][11] ([i915#2846]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-apl3/igt@gem_exec_f...@basic-deadline.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-apl2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_mmap_gtt@fault-concurrent-x:
- shard-snb: [ABORT][13] ([i915#5161]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-snb2/igt@gem_mmap_...@fault-concurrent-x.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-snb5/igt@gem_mmap_...@fault-concurrent-x.html
* igt@i915_pm_rpm@modeset-non-lpsp:
- {shard-dg1}:[SKIP][15] ([i915#1397]) -> [PASS][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-dg1-14/igt@i915_pm_...@modeset-non-lpsp.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-dg1-15/igt@i915_pm_...@modeset-non-lpsp.html
* igt@i915_pm_rps@basic-api:
- {shard-dg1}:[FAIL][17] ([i915#8308]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-dg1-15/igt@i915_pm_...@basic-api.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-dg1-18/igt@i915_pm_...@basic-api.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [FAIL][19] ([i915#2346]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-glk1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-snb: [INCOMPLETE][21] -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/shard-snb4/igt@kms_fbcon_...@fbc-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/shard-snb4/igt@kms_fbcon_...@fbc-suspend.html
{name}: This ele
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
Hi, > -Original Message- > From: Saarinen, Jani > Sent: tiistai 28. maaliskuuta 2023 9.35 > To: Zhang, Rui ; Deak, Imre > Cc: intel-gfx@lists.freedesktop.org > Subject: RE: ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous > smp_num_siblings on Intel Hybrid platform > > Hi. > > -Original Message- > > From: Zhang, Rui > > Sent: tiistai 28. maaliskuuta 2023 4.57 > > To: Deak, Imre > > Cc: Saarinen, Jani ; > > intel-gfx@lists.freedesktop.org > > Subject: Re: ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous > > smp_num_siblings on Intel Hybrid platform > > > > On Tue, 2023-03-28 at 09:14 +0800, Zhang Rui wrote: > > > Hi, Imre, > > > > > > Thanks for raising this. > > > > > > On Tue, 2023-03-28 at 00:26 +0300, Imre Deak wrote: > > > > Hi Rui, > > > > > > > > after applying your > > > > "x86/topology: fix erroneous smp_num_siblings on Intel Hybrid > > > > platform" > > > > > > > > fix on the drm-tip tree (see the patchwork URL below) the CI tests > > > > show some regression on a HSW and a KBL machine (see [2] and [4] > > > > below) in the i915 driver. However I think they can't be related > > > > to your changes, since on these machines all cores will report the > > > > same number of CPU siblings. > > > > > > Right. > > > > > > > Could you confirm this and that in general the reported siblings > > > > can only vary on platforms with both E and P cores (ADL-P being > > > > the first such platform)? > > > > > > Right. > > > > > > I don't think the patch could bring any change related. > > > It only affects hybrid platforms. > > > > Is this topology fix patch the only patch applied? or together with some > > other > patches? > This only. > > > > I can hardly imagine that the fix patch can trigger such issues, so I > > suspect they are intermittent issues. say is the regression 100% > > reproducible? > This is not regression. I assume drm-tip misses this patch (as was not part > of 6.3rc > yet.) Ignore this comment, badly read mail only. I assume it is hard to day as this test is done on CI (pre-merge) Let Imre to comment here. > > > does the warning/failure ever show without the patch? > Yes, On our local (3) system's seen on all. Again. Ignore this too. > > > > BTW, I just happened to see this thread > > > https://lore.kernel.org/all/DM8PR11MB565580BCF44661B6A392F0CEE08B9@DM8 > > P > > R11MB5655.namprd11.prod.outlook.com/ > > If the problem on hand has been verified to be not related with the > > topology fix, can we update in this thread as well? > > https://lore.kernel.org/all/20230323015640.27906-1-rui.zh...@intel.com > > / This is another issue that the patch fixes. And it's better to have > > a Buglink/Tested-by tag in the commit. > > > > thanks, > > rui > > > > > > > > Thanks, > > > rui > > > > Thanks, > > > > Imre > > > > > > > > On Mon, Mar 27, 2023 at 07:02:25PM +, Patchwork wrote: > > > > > == Series Details == > > > > > > > > > > Series: x86/topology: fix erroneous smp_num_siblings on Intel > > > > > Hybrid platform > > > > > URL : https://patchwork.freedesktop.org/series/115661/ > > > > > State : failure > > > > > > > > > > == Summary == > > > > > > > > > > CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1 > > > > > > > > > > > > > > > Summary > > > > > --- > > > > > > > > > > **FAILURE** > > > > > > > > > > Serious unknown changes coming with Patchwork_115661v1 > > > > > absolutely need to be > > > > > verified manually. > > > > > > > > > > If you think the reported changes have nothing to do with the > > > > > changes > > > > > introduced in Patchwork_115661v1, please notify your bug team > > > > > to allow them > > > > > to document this new failure mode, which will reduce false > > > > > positives in CI. > > > > > > > > > > External URL: > > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index. > > > > > html > > > > > > > > > > Participating hosts (37 -> 37) > > > > > -- > > > > > > > > > > No changes in participating hosts > > > > > > > > > > Possible new issues > > > > > --- > > > > > > > > > > Here are the unknown changes that may have been introduced in > > > > > Patchwork_115661v1: > > > > > > > > > > ### IGT changes ### > > > > > > > > > > Possible regressions > > > > > > > > > > * igt@i915_selftest@live@hangcheck: > > > > > - fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2] > > > > >[1]: > > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-hsw- > > 4770/igt@i915_selftest@l...@hangcheck.html > > > > >[2]: > > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-h > > > > > sw -4770/igt@i915_selftest@l...@hangcheck.html > > > > > > > > > > > > > > > Suppressed > > > > > > > > > > The following results come from untrusted machines, tests, or > > > > > statuses. > > > > > They do not affect the overall result. > > > > > > > > > > * igt@
Re: [Intel-gfx] [PATCH v8 19/24] vfio: Name noiommu vfio_device with "noiommu-" prefix
> From: Liu, Yi L > Sent: Monday, March 27, 2023 5:41 PM > > For noiommu device, vfio core names the cdev node with prefix "noiommu-". > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v8 18/24] vfio: Determine noiommu in vfio_device registration
> From: Liu, Yi L > Sent: Monday, March 27, 2023 5:41 PM > > This adds a noiommu flag in vfio_device, hence caller of the > vfio_device_is_noiommu() just refers to the flag for noiommu > check. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
Hi.
> -Original Message-
> From: Zhang, Rui
> Sent: tiistai 28. maaliskuuta 2023 4.57
> To: Deak, Imre
> Cc: Saarinen, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous
> smp_num_siblings
> on Intel Hybrid platform
>
> On Tue, 2023-03-28 at 09:14 +0800, Zhang Rui wrote:
> > Hi, Imre,
> >
> > Thanks for raising this.
> >
> > On Tue, 2023-03-28 at 00:26 +0300, Imre Deak wrote:
> > > Hi Rui,
> > >
> > > after applying your
> > > "x86/topology: fix erroneous smp_num_siblings on Intel Hybrid
> > > platform"
> > >
> > > fix on the drm-tip tree (see the patchwork URL below) the CI tests
> > > show some regression on a HSW and a KBL machine (see [2] and [4]
> > > below) in the i915 driver. However I think they can't be related to
> > > your changes, since on these machines all cores will report the same
> > > number of CPU siblings.
> >
> > Right.
> >
> > > Could you confirm this and that in general the reported siblings
> > > can only vary on platforms with both E and P cores (ADL-P being the
> > > first such platform)?
> >
> > Right.
> >
> > I don't think the patch could bring any change related.
> > It only affects hybrid platforms.
>
> Is this topology fix patch the only patch applied? or together with some
> other patches?
This only.
>
> I can hardly imagine that the fix patch can trigger such issues, so I suspect
> they are
> intermittent issues. say is the regression 100% reproducible?
This is not regression. I assume drm-tip misses this patch (as was not part of
6.3rc yet.)
> does the warning/failure ever show without the patch?
Yes, On our local (3) system's seen on all.
>
> BTW, I just happened to see this thread
> https://lore.kernel.org/all/DM8PR11MB565580BCF44661B6A392F0CEE08B9@DM8P
> R11MB5655.namprd11.prod.outlook.com/
> If the problem on hand has been verified to be not related with the topology
> fix, can
> we update in this thread as well?
> https://lore.kernel.org/all/20230323015640.27906-1-rui.zh...@intel.com/
> This is another issue that the patch fixes. And it's better to have a
> Buglink/Tested-by
> tag in the commit.
>
> thanks,
> rui
>
> >
> > Thanks,
> > rui
> > > Thanks,
> > > Imre
> > >
> > > On Mon, Mar 27, 2023 at 07:02:25PM +, Patchwork wrote:
> > > > == Series Details ==
> > > >
> > > > Series: x86/topology: fix erroneous smp_num_siblings on Intel
> > > > Hybrid platform
> > > > URL : https://patchwork.freedesktop.org/series/115661/
> > > > State : failure
> > > >
> > > > == Summary ==
> > > >
> > > > CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1
> > > >
> > > >
> > > > Summary
> > > > ---
> > > >
> > > > **FAILURE**
> > > >
> > > > Serious unknown changes coming with Patchwork_115661v1
> > > > absolutely need to be
> > > > verified manually.
> > > >
> > > > If you think the reported changes have nothing to do with the
> > > > changes
> > > > introduced in Patchwork_115661v1, please notify your bug team to
> > > > allow them
> > > > to document this new failure mode, which will reduce false
> > > > positives in CI.
> > > >
> > > > External URL:
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index.
> > > > html
> > > >
> > > > Participating hosts (37 -> 37)
> > > > --
> > > >
> > > > No changes in participating hosts
> > > >
> > > > Possible new issues
> > > > ---
> > > >
> > > > Here are the unknown changes that may have been introduced in
> > > > Patchwork_115661v1:
> > > >
> > > > ### IGT changes ###
> > > >
> > > > Possible regressions
> > > >
> > > > * igt@i915_selftest@live@hangcheck:
> > > > - fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2]
> > > >[1]:
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-hsw-
> 4770/igt@i915_selftest@l...@hangcheck.html
> > > >[2]:
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-hsw
> > > > -4770/igt@i915_selftest@l...@hangcheck.html
> > > >
> > > >
> > > > Suppressed
> > > >
> > > > The following results come from untrusted machines, tests, or
> > > > statuses.
> > > > They do not affect the overall result.
> > > >
> > > > * igt@fbdev@info:
> > > > - {bat-kbl-2}:[SKIP][3] ([fdo#109271]) -> [ABORT][4]
> > > >[3]:
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-kbl-
> 2/igt@fb...@info.html
> > > >[4]:
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-kb
> > > > l-2/igt@fb...@info.html
> > > >
> > > >
> > > > Known issues
> > > >
> > > >
> > > > Here are the changes found in Patchwork_115661v1 that come from
> > > > known issues:
> > > >
> > > > ### IGT changes ###
> > > >
> > > > Issues hit
> > > >
> > > > * igt@gem_exec_suspend@basic-s3@lmem0:
> > > > - bat-dg2-11: [PASS][5] -> [INCOMPLETE][6]
> > > > ([i915#6311])
> > > >[5]:
Re: [Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
> From: Liu, Yi L > Sent: Tuesday, March 28, 2023 11:32 AM > > > From: Alex Williamson > > Sent: Tuesday, March 28, 2023 3:26 AM > > > > Additionally, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO has a flags arg that > > isn't used, why do we need a new ioctl vs defining > > VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID. > > Sure. I can follow this suggestion. BTW. I have a doubt here. This new flag > is set by user. What if in the future kernel has new extensions and needs > to report something new to the user and add new flags to tell user? Such > flag is set by kernel. Then the flags field may have two kinds of flags (some > set by user while some set by kernel). Will it mess up the flags space? > flags in a GET_INFO ioctl is for output. if user needs to use flags as input to select different type of info then it should be split into multiple GET_INFO cmds.
Re: [Intel-gfx] [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
> -Original Message-
> From: Mark Yacoub
> Sent: Saturday, March 25, 2023 12:57 AM
> To: Kandpal, Suraj
> Cc: quic_khs...@quicinc.com; linux-arm-...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; freedr...@lists.freedesktop.org;
> devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; intel-
> g...@lists.freedesktop.org; quic_sbill...@quicinc.com;
> konrad.dyb...@somainline.org; Souza, Jose ;
> bjorn.anders...@linaro.org; krzysztof.kozlowski...@linaro.org;
> hbh...@gmail.com; Vasut, Marek ; Dixit, Ashutosh
> ; s...@poorly.run; abhin...@codeaurora.org;
> javi...@redhat.com; Murthy, Arun R ; Lisovskiy,
> Stanislav ; agr...@kernel.org;
> quic_jessz...@quicinc.com; Nautiyal, Ankit K ;
> Nikula, Jani ; De Marchi, Lucas
> ; quic_abhin...@quicinc.com;
> swb...@chromium.org; robh...@kernel.org;
> christophe.jail...@wanadoo.fr; max...@cerno.tech; Vivi, Rodrigo
> ; johan+lin...@kernel.org;
> tvrtko.ursu...@linux.intel.com; anders...@kernel.org;
> diand...@chromium.org; Sharma, Swati2 ;
> Navare, Manasi D ; tzimmerm...@suse.de;
> Modem, Bhanuprakash ;
> dmitry.barysh...@linaro.org; seanp...@chromium.org
> Subject: Re: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable return
> codes
>
> On Thu, Mar 23, 2023 at 3:18 AM Kandpal, Suraj
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Kandpal, Suraj
> > > Sent: Friday, March 10, 2023 1:55 PM
> > > To: Mark Yacoub ;
> quic_khs...@quicinc.com;
> > > linux-arm-...@vger.kernel.org; dri-de...@lists.freedesktop.org;
> > > freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; intel-gfx@lists.freedesktop.org
> > > Cc: quic_sbill...@quicinc.com; konrad.dyb...@somainline.org; Souza,
> > > Jose ; bjorn.anders...@linaro.org;
> > > krzysztof.kozlowski...@linaro.org; hbh...@gmail.com; Vasut, Marek
> > > ; Dixit, Ashutosh ;
> > > s...@poorly.run; abhin...@codeaurora.org; javi...@redhat.com;
> > > Murthy, Arun R ; Lisovskiy, Stanislav
> > > ; agr...@kernel.org;
> > > quic_jessz...@quicinc.com; Nautiyal, Ankit K
> > > ; Nikula, Jani ;
> > > De Marchi, Lucas ;
> > > quic_abhin...@quicinc.com; swb...@chromium.org;
> robh...@kernel.org;
> > > christophe.jail...@wanadoo.fr; max...@cerno.tech; Vivi, Rodrigo
> > > ; johan+lin...@kernel.org;
> > > tvrtko.ursu...@linux.intel.com; anders...@kernel.org;
> > > diand...@chromium.org; Sharma, Swati2 ;
> > > Navare, Manasi D ;
> tzimmerm...@suse.de;
> > > Modem, Bhanuprakash ;
> > > dmitry.barysh...@linaro.org; seanp...@chromium.org
> > > Subject: RE: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable
> > > return codes
> > >
> > > > Subject: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable
> > > > return codes
> > > >
> > > > From: Sean Paul
> > > >
> > > > The shim functions return error codes, but they are discarded in
> > > > intel_hdcp.c. This patch plumbs the return codes through so they
> > > > are properly handled.
> > > >
> > > > Acked-by: Jani Nikula
> > > > Reviewed-by: Rodrigo Vivi
> > > > Signed-off-by: Sean Paul
> > > > Signed-off-by: Mark Yacoub
> > > > Link:
> > > >
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456
> > > > -7-
> > > > s...@poorly.run #v1
> > > > Link:
> > > >
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-
> > > > 7-
> > > > s...@poorly.run #v2
> > > > Link:
> > > >
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916
> > > > -7-
> > > > s...@poorly.run #v3
> > > > Link:
> > > >
> > >
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845
> > > -
> > > > 7-s...@poorly.run #v4
> > > > Link:
> > > >
> > >
> https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308
> > > -
> > > > 7-s...@poorly.run #v5
> > > >
> > > > Changes in v2:
> > > > -None
> > > > Changes in v3:
> > > > -None
> > > > Changes in v4:
> > > > -None
> > > > Changes in v5:
> > > > -None
> > > > Changes in v6:
> > > > -Rebased
> > > >
> > > > ---
> > > > .../drm/i915/display/intel_display_debugfs.c | 9 +++-
> > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
> > > > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> > > > 3 files changed, 37 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > index 7c7253a2541c..13a4153bb76e 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > @@ -492,6 +492,7 @@ static void intel_panel_info(struct seq_file
> > > > *m, static void intel_hdcp_info(struct seq_file *m,
> > > > struct intel_connector *intel_connector)
> > > > {
> > > > + int ret;
> > > > bool hdcp_cap, hdcp2_cap;
> > > >
> > > > if (!intel_connector->hdcp.shim) { @@ -499,8 +500,12 @@ static
> > > > void intel_hdcp_info(struct seq_file *m,
> > > > goto out;
> > > > }
> > > >
Re: [Intel-gfx] [PATCH v3 1/6] iommu/iommufd: Pass iommufd_ctx pointer in iommufd_get_ioas()
> From: Liu, Yi L > Sent: Monday, March 27, 2023 5:34 PM > > no need to pass the iommufd_ucmd pointer. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/display: Restore dsparb_lock.
== Series Details ==
Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock.
URL : https://patchwork.freedesktop.org/series/115675/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12921_full -> Patchwork_115675v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_115675v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-glk8/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][4] -> [DMESG-FAIL][5] ([i915#8319])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-snb5/igt@i915_pm_...@reset.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-snb7/igt@i915_pm_...@reset.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-apl6/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-glk5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-suspend-interruptible@b-dp1:
- shard-apl: [PASS][11] -> [ABORT][12] ([i915#180])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
*
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +76 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-apl7/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0...@pipe-c-dp-1.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-apl7/igt@kms_psr2...@plane-move-sf-dmg-area.html
* igt@vc4/vc4_perfmon@create-perfmon-exceed:
- shard-glk: NOTRUN -> [SKIP][15] ([fdo#109271]) +20 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-glk8/igt@vc4/vc4_perf...@create-perfmon-exceed.html
Possible fixes
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][16] ([i915#6268]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-7/igt@gem_ctx_e...@basic-nohangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-tglu-7/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}: [FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [ABORT][20] ([i915#5566]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/shard-apl7/igt@gen9_exec_pa...@allowed-all
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/ips: Make IPS debugfs per-crtc
== Series Details ==
Series: series starting with [1/2] drm/i915/ips: Make IPS debugfs per-crtc
URL : https://patchwork.freedesktop.org/series/115669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12921_full -> Patchwork_115669v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115669v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@plain-flip-fb-recreate@a-hdmi-a1:
- {shard-tglu}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-8/igt@kms_flip@plain-flip-fb-recre...@a-hdmi-a1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-tglu-5/igt@kms_flip@plain-flip-fb-recre...@a-hdmi-a1.html
Known issues
Here are the changes found in Patchwork_115669v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-glk1/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-apl4/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#79])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1:
- shard-apl: [PASS][13] -> [FAIL][14] ([i915#79])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-apl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html
*
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271]) +76 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-apl1/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0...@pipe-c-dp-1.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-apl1/igt@kms_psr2...@plane-move-sf-dmg-area.html
* igt@vc4/vc4_perfmon@create-perfmon-exceed:
- shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271]) +20 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-glk1/igt@vc4/vc4_perf...@create-perfmon-exceed.html
Possible fixes
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}: [FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/shard-tglu-2/igt@gem_exec_fai
Re: [Intel-gfx] [PATCH v6 05/24] kvm/vfio: Accept vfio device file from userspace
> From: Xu, Yilun
> Sent: Wednesday, March 22, 2023 10:11 PM
>
> On 2023-03-08 at 05:28:44 -0800, Yi Liu wrote:
> > This defines KVM_DEV_VFIO_FILE* and make alias with
> KVM_DEV_VFIO_GROUP*.
> > Old userspace uses KVM_DEV_VFIO_GROUP* works as well.
> >
> > Signed-off-by: Yi Liu
> > Reviewed-by: Jason Gunthorpe
> > Tested-by: Terrence Xu
> > Tested-by: Nicolin Chen
> > Tested-by: Matthew Rosato
> > ---
> > Documentation/virt/kvm/devices/vfio.rst | 52 +
> > include/uapi/linux/kvm.h| 16 ++--
> > virt/kvm/vfio.c | 16
> > 3 files changed, 55 insertions(+), 29 deletions(-)
> >
> > diff --git a/Documentation/virt/kvm/devices/vfio.rst
> b/Documentation/virt/kvm/devices/vfio.rst
> > index 79b6811bb4f3..5b05b48abaab 100644
> > --- a/Documentation/virt/kvm/devices/vfio.rst
> > +++ b/Documentation/virt/kvm/devices/vfio.rst
> > @@ -9,24 +9,37 @@ Device types supported:
> >- KVM_DEV_TYPE_VFIO
> >
> > Only one VFIO instance may be created per VM. The created device
> > -tracks VFIO groups in use by the VM and features of those groups
> > -important to the correctness and acceleration of the VM. As groups
> > -are enabled and disabled for use by the VM, KVM should be updated
> > -about their presence. When registered with KVM, a reference to the
> > -VFIO-group is held by KVM.
> > +tracks VFIO files (group or device) in use by the VM and features
> > +of those groups/devices important to the correctness and acceleration
> > +of the VM. As groups/devices are enabled and disabled for use by the
> > +VM, KVM should be updated about their presence. When registered
> with
> > +KVM, a reference to the VFIO file is held by KVM.
> >
> > Groups:
> > - KVM_DEV_VFIO_GROUP
> > -
> > -KVM_DEV_VFIO_GROUP attributes:
> > - KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device
> tracking
> > - kvm_device_attr.addr points to an int32_t file descriptor
> > - for the VFIO group.
> > - KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM
> device tracking
> > - kvm_device_attr.addr points to an int32_t file descriptor
> > - for the VFIO group.
> > - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE
> table
> > + KVM_DEV_VFIO_FILE
> > + alias: KVM_DEV_VFIO_GROUP
> > +
> > +KVM_DEV_VFIO_FILE attributes:
> > + KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM
> device
> > + tracking
> > +
> > + alias: KVM_DEV_VFIO_GROUP_ADD
> > +
> > + kvm_device_attr.addr points to an int32_t file descriptor for the
> > + VFIO file.
>
> A blank line here to be consistent with other attibutes.
>
> > + KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from
> VFIO-KVM
> > + device tracking
> > +
> > + alias: KVM_DEV_VFIO_GROUP_DEL
> > +
> > + kvm_device_attr.addr points to an int32_t file descriptor for the
> > + VFIO file.
> > +
> > + KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE
> table
> > allocated by sPAPR KVM.
> > +
> > + alias: KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE
> > +
> > kvm_device_attr.addr points to a struct::
> >
> > struct kvm_vfio_spapr_tce {
> > @@ -40,9 +53,14 @@ KVM_DEV_VFIO_GROUP attributes:
> > - @tablefd is a file descriptor for a TCE table allocated via
> > KVM_CREATE_SPAPR_TCE.
> >
> > + only accepts vfio group file as SPAPR has no iommufd support
> > +
> > ::
> >
> > -The GROUP_ADD operation above should be invoked prior to accessing
> the
> > +The FILE/GROUP_ADD operation above should be invoked prior to
> accessing the
> > device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to
> support
> > drivers which require a kvm pointer to be set in their .open_device()
> > -callback.
> > +callback. It is the same for device file descriptor via character device
> > +open which gets device access via VFIO_DEVICE_BIND_IOMMUFD. For
> such file
> > +descriptors, FILE_ADD should be invoked before
> VFIO_DEVICE_BIND_IOMMUFD
> > +to support the drivers mentioned in piror sentence as well.
>
> s/piror/prior
Fixed in v8, thanks.
https://lore.kernel.org/kvm/ZCHW%2FQIKQVhBjg%2Fx@Asurada-Nvidia/T/#m7c076d3b9450c9de62b99a6fcefcc31c8ae3f8da
Re: [Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
> From: Alex Williamson
> Sent: Tuesday, March 28, 2023 4:41 AM
>
> On Mon, 27 Mar 2023 13:26:19 -0600
> Alex Williamson wrote:
>
[...]
> > > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> > > index 19f5b075d70a..45edf4e9b98b 100644
> > > --- a/drivers/vfio/pci/vfio_pci_core.c
> > > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > > @@ -1181,6 +1181,102 @@ static int vfio_pci_ioctl_reset(struct
> vfio_pci_core_device *vdev,
> > > return ret;
> > > }
> > >
> > > +static struct pci_dev *
> > > +vfio_pci_dev_set_resettable(struct vfio_device_set *dev_set);
> > > +
> > > +static int vfio_pci_ioctl_get_pci_hot_reset_group_info(
> > > + struct vfio_pci_core_device *vdev,
> > > + struct vfio_pci_hot_reset_group_info __user *arg)
> > > +{
> > > + unsigned long minsz =
> > > + offsetofend(struct vfio_pci_hot_reset_group_info, count);
> > > + struct vfio_pci_hot_reset_group_info hdr;
> > > + struct iommufd_ctx *iommufd, *cur_iommufd;
> > > + u32 count = 0, index = 0, *devices = NULL;
> > > + struct vfio_pci_core_device *cur;
> > > + bool slot = false;
> > > + int ret = 0;
> > > +
> > > + if (copy_from_user(&hdr, arg, minsz))
> > > + return -EFAULT;
> > > +
> > > + if (hdr.argsz < minsz)
> > > + return -EINVAL;
> > > +
> > > + hdr.flags = 0;
> > > +
> > > + /* Can we do a slot or bus reset or neither? */
> > > + if (!pci_probe_reset_slot(vdev->pdev->slot))
> > > + slot = true;
> > > + else if (pci_probe_reset_bus(vdev->pdev->bus))
> > > + return -ENODEV;
> > > +
> > > + mutex_lock(&vdev->vdev.dev_set->lock);
> > > + if (!vfio_pci_dev_set_resettable(vdev->vdev.dev_set)) {
[1]
> > > + ret = -EPERM;
> > > + goto out_unlock;
> > > + }
> > > +
> > > + iommufd = vfio_iommufd_physical_ictx(&vdev->vdev);
> > > + if (!iommufd) {
> > > + ret = -EPERM;
> > > + goto out_unlock;
> > > + }
> > > +
> > > + /* How many devices are affected? */
> > > + ret = vfio_pci_for_each_slot_or_bus(vdev->pdev,
> vfio_pci_count_devs,
> > > + &count, slot);
> > > + if (ret)
> > > + goto out_unlock;
> > > +
> > > + WARN_ON(!count); /* Should always be at least one */
> > > +
> > > + /*
> > > + * If there's enough space, fill it now, otherwise return -ENOSPC and
> > > + * the number of devices affected.
> > > + */
> > > + if (hdr.argsz < sizeof(hdr) + (count * sizeof(*devices))) {
> > > + ret = -ENOSPC;
> > > + hdr.count = count;
> > > + goto reset_info_exit;
> > > + }
> > > +
> > > + devices = kcalloc(count, sizeof(*devices), GFP_KERNEL);
> > > + if (!devices) {
> > > + ret = -ENOMEM;
> > > + goto reset_info_exit;
> > > + }
> > > +
> > > + list_for_each_entry(cur, &vdev->vdev.dev_set->device_list,
> vdev.dev_set_list) {
> > > + cur_iommufd = vfio_iommufd_physical_ictx(&cur->vdev);
> > > + if (cur->vdev.open_count) {
> > > + if (cur_iommufd != iommufd) {
> > > + ret = -EPERM;
> > > + break;
> > > + }
> > > + ret = vfio_iommufd_physical_devid(&cur->vdev,
> &devices[index]);
> > > + if (ret)
> > > + break;
> > > + index++;
> > > + }
> > > + }
>
> This also makes use of vfio_pci_for_each_slot_or_bus() to iterate
> affected devices, but then still assumes those affected devices are
> necessarily represented in the dev_set. For example, a two-function
> device with ACS isolation can have function 0 bound to vfio and
> function 1 bound to a native host driver. The above code requires the
> user to pass a buffer large enough for both functions, but only
> function 0 is part of the dev_set, so function 1 is not reported as
> affected, nor does it generate an error.
The vfio_pci_dev_set_resettable() is used at [1] to check if all the affected
devices are in the dev_set. If not, then it fails at the first place. So in the
following code, looping the devices in the dev_set is equivalent to looping
devices with vfio_pci_for_each_slot_or_bus(). I need to loop dev_set as
dev_set has the vfio_device which is more convenient to get dev_id.
>
> It looks like we also fail to set hdr.count except in the error path
> above, so the below copy_to_user() copies a user specified range beyond
> the end the allocated devices buffer out to userspace! Thanks,
Oops, yes, it is. My test only has one device affected, so it does not hit
the problem. ☹
Thanks,
Yi Liu
> Alex
>
> > > +
> > > +reset_info_exit:
> > > + if (copy_to_user(arg, &hdr, minsz))
> > > + ret = -EFAULT;
> > > +
> > > + if (!ret) {
> > > + if (copy_to_user(&arg->devices, devices,
> > > + hdr.count * sizeof(*devices)))
> > > + ret = -EFAULT;
> > > + }
> > > +
> > > + kfree(devices);
> > > +out_unlock:
> > > + mutex_unlock(&vdev->vdev.dev_set->lock);
> > > + return ret;
> > > +
Re: [Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
> From: Alex Williamson
> Sent: Tuesday, March 28, 2023 3:26 AM
>
> On Mon, 27 Mar 2023 02:34:58 -0700
> Yi Liu wrote:
>
> > This is a preparation for vfio device cdev as cdev gives userspace the
> > capability to open device cdev fd and management stack (e.g. libvirt)
> > could pass the device fd to the actual user (e.g. QEMU). As a result,
> > the actual user has no idea about the device's bus:devfn information.
> > This is a problem when user uses VFIO_DEVICE_GET_PCI_HOT_RESET_INFO to
> > know the hot reset affected device scope as this ioctl returns bus:devfn
> > info. For the fd passing usage, the acutal user cannot map the bus:devfn
> > to the devices it has opened via the fd passed from management stack. So
> > a new ioctl is required.
> >
> > This new ioctl reports the list of iommufd dev_id that is opened by the
> > user. If there is affected device that is not bound to vfio driver or
> > opened by another user, this command shall fail with -EPERM. For the
> > noiommu mode in the vfio device cdev path, this shall fail as no dev_id
> > would be generated, hence nothing to report.
> >
> > This ioctl is useless to the users that open vfio group as such users
> > have no idea about the iommufd dev_id and it can use the existing
> > VFIO_DEVICE_GET_PCI_HOT_RESET_INFO. The user that uses the traditional
> > mode vfio group/container would be failed if invoking this ioctl. But
> > the user that uses the iommufd compat mode vfio group/container shall
> > succeed. This is harmless as long as user cannot make use of it and
> > should use VFIO_DEVICE_GET_PCI_HOT_RESET_INFO.
>
>
> So VFIO_DEVICE_GET_PCI_HOT_RESET_INFO reports a group and bdf, but
> VFIO_DEVICE_GET_PCI_HOT_RESET_*GROUP*_INFO is meant for the non-
> group,
> cdev use case and returns a dev_id rather than a group???
Yes, this is the meaning, but poor naming here ☹ I also struggled on it.
Perhaps your below Suggestion makes more sense. Introducing a flag and
reuse the existing _INFO ioctl.
> Additionally, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO has a flags arg that
> isn't used, why do we need a new ioctl vs defining
> VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID.
Sure. I can follow this suggestion. BTW. I have a doubt here. This new flag
is set by user. What if in the future kernel has new extensions and needs
to report something new to the user and add new flags to tell user? Such
flag is set by kernel. Then the flags field may have two kinds of flags (some
set by user while some set by kernel). Will it mess up the flags space?
> In fact, we could define vfio_dependent_device as:
>
> struct vfio_pci_dependent_device {
> union {
> __u32 group_id;
> __u32 dev_id;
> }
> __u16 segment;
> __u8bus;
> __u8devfn;
> };
>
> If the user calls with the above flag, dev_id is valid, otherwise
> group_id. Perhaps segment:buus:devfn could still be filled in with a
> NULL/invalid dev_id if the user doesn't have permissions for the device
> so that debugging from userspace isn't so opaque. Thanks,
Also, have one question here. Should the invalid dev_id be defined in
the vfio uapi or iommufd uapi? Maybe the latter one since dev_id is
generated by iommufd subsystem.
Regards,
Yi Liu
>
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 98
>
> > include/uapi/linux/vfio.h| 47 +++
> > 2 files changed, 145 insertions(+)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> > index 19f5b075d70a..45edf4e9b98b 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -1181,6 +1181,102 @@ static int vfio_pci_ioctl_reset(struct
> vfio_pci_core_device *vdev,
> > return ret;
> > }
> >
> > +static struct pci_dev *
> > +vfio_pci_dev_set_resettable(struct vfio_device_set *dev_set);
> > +
> > +static int vfio_pci_ioctl_get_pci_hot_reset_group_info(
> > + struct vfio_pci_core_device *vdev,
> > + struct vfio_pci_hot_reset_group_info __user *arg)
> > +{
> > + unsigned long minsz =
> > + offsetofend(struct vfio_pci_hot_reset_group_info, count);
> > + struct vfio_pci_hot_reset_group_info hdr;
> > + struct iommufd_ctx *iommufd, *cur_iommufd;
> > + u32 count = 0, index = 0, *devices = NULL;
> > + struct vfio_pci_core_device *cur;
> > + bool slot = false;
> > + int ret = 0;
> > +
> > + if (copy_from_user(&hdr, arg, minsz))
> > + return -EFAULT;
> > +
> > + if (hdr.argsz < minsz)
> > + return -EINVAL;
> > +
> > + hdr.flags = 0;
> > +
> > + /* Can we do a slot or bus reset or neither? */
> > + if (!pci_probe_reset_slot(vdev->pdev->slot))
> > + slot = true;
> > + else if (pci_probe_reset_bus(vdev->pdev->bus))
> > + return -ENODEV;
> > +
> > + mutex_lock(&vdev->vdev.dev_set->lock);
> > + if (!vfio_pci_dev_set_resettable(vdev->vdev.dev_set)) {
> > + ret =
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: Add a function to mmap framebuffer obj (rev2)
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Add a function to mmap
framebuffer obj (rev2)
URL : https://patchwork.freedesktop.org/series/115542/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12921_full -> Patchwork_115542v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115542v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@fbdev@pan:
- {shard-dg1}:NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-dg1-18/igt@fb...@pan.html
* igt@i915_pm_rps@waitboost:
- {shard-dg1}:NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-dg1-14/igt@i915_pm_...@waitboost.html
- {shard-tglu}: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-8/igt@i915_pm_...@waitboost.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-tglu-2/igt@i915_pm_...@waitboost.html
New tests
-
New tests have been introduced between CI_DRM_12921_full and
Patchwork_115542v2_full:
### New IGT tests (1) ###
* igt@fbdev:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_115542v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk1/igt@gem_exec_f...@basic-deadline.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-glk5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-glk6/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-glk: [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk3/igt@i915_selftest@live@gt_heartbeat.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-glk6/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886]) +2
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-apl3/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#2346])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2346])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#79])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_flip@2x-plain-flip-fb-recreate@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][17] -> [FAIL][18] ([i915#2122])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk5/igt@kms_flip@2x-plain-flip-fb-recre...@ab-hdmi-a1-hdmi-a2.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recre...@ab-hdmi-a1-hdmi-a2.html
*
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271]) +76 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/shard-apl2/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0...@pipe-c-d
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN"" (rev2)
== Series Details ==
Series: series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't
select BROKEN"" (rev2)
URL : https://patchwork.freedesktop.org/series/115659/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12921_full -> Patchwork_115659v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_115659v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_115659v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115659v2_full:
### IGT changes ###
Possible regressions
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-snb: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-snb7/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-snb2/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rps@waitboost:
- {shard-tglu}: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-8/igt@i915_pm_...@waitboost.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-tglu-8/igt@i915_pm_...@waitboost.html
Known issues
Here are the changes found in Patchwork_115659v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-glk6/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][6] -> [DMESG-FAIL][7] ([i915#8319])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-snb5/igt@i915_pm_...@reset.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-snb2/igt@i915_pm_...@reset.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +2
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-apl2/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
*
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271]) +75 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-apl4/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0...@pipe-c-dp-1.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#658])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-apl4/igt@kms_psr2...@plane-move-sf-dmg-area.html
* igt@vc4/vc4_perfmon@create-perfmon-exceed:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271]) +20 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-glk6/igt@vc4/vc4_perf...@create-perfmon-exceed.html
Possible fixes
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][14] ([i915#6268]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-7/igt@gem_ctx_e...@basic-nohangcheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-tglu-7/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [ABORT][16] ([i915#5566]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/shard-apl4/igt@gen9_exec_pa...@allowed-all.html
* igt@i915_pm_rps@basic-api:
- {shard-dg1}:[FAIL][18] ([i915#8308]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-dg1-17/ig
[Intel-gfx] [PATCH i-g-t 2/2] i915_pm_freq_api: Add some basic SLPC igt tests
Validate basic api for GT freq control. Also test
interaction with GT reset. We skip rps tests with
SLPC enabled, this will re-introduce some coverage.
SLPC selftests are already covering some other workload
related scenarios.
v2: Rename test (Rodrigo)
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
tests/i915/i915_pm_freq_api.c | 151 ++
tests/meson.build | 1 +
2 files changed, 152 insertions(+)
create mode 100644 tests/i915/i915_pm_freq_api.c
diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c
new file mode 100644
index ..f1027d1c
--- /dev/null
+++ b/tests/i915/i915_pm_freq_api.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "i915/gem.h"
+#include "igt_sysfs.h"
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test SLPC freq API");
+/*
+ * Too many intermediate components and steps before freq is adjusted
+ * Specially if workload is under execution, so let's wait 100 ms.
+ */
+#define ACT_FREQ_LATENCY_US 10
+
+static uint32_t get_freq(int dirfd, uint8_t id)
+{
+ uint32_t val;
+
+ igt_require(igt_sysfs_rps_scanf(dirfd, id, "%u", &val) == 1);
+
+ return val;
+}
+
+static int set_freq(int dirfd, uint8_t id, uint32_t val)
+{
+ return igt_sysfs_rps_printf(dirfd, id, "%u", val);
+}
+
+static void test_freq_basic_api(int dirfd, int gt)
+{
+ uint32_t rpn, rp0, rpe;
+
+ /* Save frequencies */
+ rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
+ rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
+ rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
+ igt_info("System min freq: %dMHz; max freq: %dMHz\n", rpn, rp0);
+
+ /*
+* Negative bound tests
+* RPn is the floor
+* RP0 is the ceiling
+*/
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn - 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rp0 + 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn - 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0 + 1) < 0);
+
+ /* Assert min requests are respected from rp0 to rpn */
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rp0) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rp0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpe) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpe);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+
+ /* Assert max requests are respected from rpn to rp0 */
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpn);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpe) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpe);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rp0);
+
+}
+
+static void test_reset(int i915, int dirfd, int gt)
+{
+ uint32_t rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
+ int fd;
+
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
+ usleep(ACT_FREQ_LATENCY_US);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+
+ /* Manually trigger a GT reset */
+ fd = igt_debugfs_gt_open(i915, gt, "reset", O_WRONLY);
+ igt_require(fd >= 0);
+ igt_ignore_warn(write(fd, "1\n", 2));
+ close(fd);
+
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpn);
+}
+
+igt_main
+{
+ int i915 = -1;
+ uint32_t *stash_min, *stash_max;
+
+ igt_fixture {
+ int num_gts, dirfd, gt;
+
+ i915 = drm_open_driver(DRIVER_INTEL);
+ igt_require_gem(i915);
+ /* i915_pm_rps already covers execlist path */
+ igt_require(gem_using_guc_submission(i915));
+
+ num_gts = igt_sysfs_get_num_gt(i915);
+ stash_min = (uint32_t*)malloc(sizeof(uint32_t) * num_gts);
+ stash_max = (uint32_t*)malloc(sizeof(uint32_t) * num_gts);
+
+ /* Save curr min and max across GTs */
+ for_each_sysfs_gt_dirfd(i915, dirfd, gt) {
+ stash_min[gt] = get_freq(dirfd, RPS_MIN_FREQ_MHZ);
+ stash_max[gt] = get_freq(dirfd, RPS_MAX_FREQ_MHZ);
+ }
+ }
+
+ igt_describe("Test basic API for controlling min/max GT frequency");
+ igt_subtest_with_dynamic_f("freq-basic-api") {
+ int dirfd, gt;
+
+ for_each_sysfs_gt_dirfd(i915, dirfd, gt)
+ igt_dynamic_f("gt%u", gt)
+ test_freq_basic_api(
[Intel-gfx] [PATCH i-g-t 1/2] lib/debugfs: Add per GT debugfs helpers
These can be used to open per-gt debugfs files.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Vinay Belgaumkar
---
lib/igt_debugfs.c | 60 +++
lib/igt_debugfs.h | 4
2 files changed, 64 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 05889bbe..afde2da6 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -217,6 +217,37 @@ int igt_debugfs_dir(int device)
return open(path, O_RDONLY);
}
+/**
+ * igt_debugfs_gt_dir:
+ * @device: fd of the device
+ * @gt: GT instance number
+ *
+ * This opens the debugfs directory corresponding to device for use
+ * with igt_sysfs_get() and related functions.
+ *
+ * Returns:
+ * The directory fd, or -1 on failure.
+ */
+int igt_debugfs_gt_dir(int device, unsigned int gt)
+{
+ int debugfs_gt_dir_fd;
+ char path[PATH_MAX];
+ char gtpath[16];
+ int ret;
+
+ if (!igt_debugfs_path(device, path, sizeof(path)))
+ return -1;
+
+ ret = snprintf(gtpath, sizeof(gtpath), "/gt%u", gt);
+ igt_assert(ret < sizeof(gtpath));
+ strncat(path, gtpath, sizeof(path) - 1);
+
+ debugfs_gt_dir_fd = open(path, O_RDONLY);
+ igt_debug_on_f(debugfs_gt_dir_fd < 0, "path: %s\n", path);
+
+ return debugfs_gt_dir_fd;
+}
+
/**
* igt_debugfs_connector_dir:
* @device: fd of the device
@@ -313,6 +344,35 @@ bool igt_debugfs_exists(int device, const char *filename,
int mode)
return false;
}
+/**
+ * igt_debugfs_gt_open:
+ * @device: open i915 drm fd
+ * @gt: gt instance number
+ * @filename: name of the debugfs node to open
+ * @mode: mode bits as used by open()
+ *
+ * This opens a debugfs file as a Unix file descriptor. The filename should be
+ * relative to the drm device's root, i.e. without "drm/$minor".
+ *
+ * Returns:
+ * The Unix file descriptor for the debugfs file or -1 if that didn't work out.
+ */
+int
+igt_debugfs_gt_open(int device, unsigned int gt, const char *filename, int
mode)
+{
+ int dir, ret;
+
+ dir = igt_debugfs_gt_dir(device, gt);
+ if (dir < 0)
+ return dir;
+
+ ret = openat(dir, filename, mode);
+
+ close(dir);
+
+ return ret;
+}
+
/**
* igt_debugfs_simple_read:
* @dir: fd of the debugfs directory
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index 4824344a..3e6194ad 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -45,6 +45,10 @@ void __igt_debugfs_write(int fd, const char *filename, const
char *buf, int size
int igt_debugfs_simple_read(int dir, const char *filename, char *buf, int
size);
bool igt_debugfs_search(int fd, const char *filename, const char *substring);
+int igt_debugfs_gt_dir(int device, unsigned int gt);
+int igt_debugfs_gt_open(int device, unsigned int gt, const char *filename,
+ int mode);
+
/**
* igt_debugfs_read:
* @filename: name of the debugfs file
--
2.38.1
[Intel-gfx] [PATCH i-g-t 0/2] tests/slpc: Add basic IGT test
Borrow some subtests from xe_guc_pc. Also add per GT debugfs helpers. Signed-off-by: Vinay Belgaumkar Vinay Belgaumkar (2): lib/debugfs: Add per GT debugfs helpers i915_pm_freq_api: Add some basic SLPC igt tests lib/igt_debugfs.c | 60 ++ lib/igt_debugfs.h | 4 + tests/i915/i915_pm_freq_api.c | 151 ++ tests/meson.build | 1 + 4 files changed, 216 insertions(+) create mode 100644 tests/i915/i915_pm_freq_api.c -- 2.38.1
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
On Tue, 2023-03-28 at 09:14 +0800, Zhang Rui wrote:
> Hi, Imre,
>
> Thanks for raising this.
>
> On Tue, 2023-03-28 at 00:26 +0300, Imre Deak wrote:
> > Hi Rui,
> >
> > after applying your
> > "x86/topology: fix erroneous smp_num_siblings on Intel Hybrid
> > platform"
> >
> > fix on the drm-tip tree (see the patchwork URL below) the CI tests
> > show
> > some regression on a HSW and a KBL machine (see [2] and [4] below)
> > in
> > the i915 driver. However I think they can't be related to your
> > changes,
> > since on these machines all cores will report the same number of
> > CPU
> > siblings.
>
> Right.
>
> > Could you confirm this and that in general the reported
> > siblings can only vary on platforms with both E and P cores (ADL-P
> > being
> > the first such platform)?
>
> Right.
>
> I don't think the patch could bring any change related.
> It only affects hybrid platforms.
Is this topology fix patch the only patch applied?
or together with some other patches?
I can hardly imagine that the fix patch can trigger such issues, so I
suspect they are intermittent issues. say
is the regression 100% reproducible?
does the warning/failure ever show without the patch?
BTW, I just happened to see this thread
https://lore.kernel.org/all/dm8pr11mb565580bcf44661b6a392f0cee0...@dm8pr11mb5655.namprd11.prod.outlook.com/
If the problem on hand has been verified to be not related with the
topology fix, can we update in this thread as well?
https://lore.kernel.org/all/20230323015640.27906-1-rui.zh...@intel.com/
This is another issue that the patch fixes. And it's better to have a
Buglink/Tested-by tag in the commit.
thanks,
rui
>
> Thanks,
> rui
> > Thanks,
> > Imre
> >
> > On Mon, Mar 27, 2023 at 07:02:25PM +, Patchwork wrote:
> > > == Series Details ==
> > >
> > > Series: x86/topology: fix erroneous smp_num_siblings on Intel
> > > Hybrid platform
> > > URL : https://patchwork.freedesktop.org/series/115661/
> > > State : failure
> > >
> > > == Summary ==
> > >
> > > CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1
> > >
> > >
> > > Summary
> > > ---
> > >
> > > **FAILURE**
> > >
> > > Serious unknown changes coming with Patchwork_115661v1
> > > absolutely
> > > need to be
> > > verified manually.
> > >
> > > If you think the reported changes have nothing to do with the
> > > changes
> > > introduced in Patchwork_115661v1, please notify your bug team
> > > to
> > > allow them
> > > to document this new failure mode, which will reduce false
> > > positives in CI.
> > >
> > > External URL:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index.html
> > >
> > > Participating hosts (37 -> 37)
> > > --
> > >
> > > No changes in participating hosts
> > >
> > > Possible new issues
> > > ---
> > >
> > > Here are the unknown changes that may have been introduced in
> > > Patchwork_115661v1:
> > >
> > > ### IGT changes ###
> > >
> > > Possible regressions
> > >
> > > * igt@i915_selftest@live@hangcheck:
> > > - fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2]
> > >[1]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
> > >[2]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
> > >
> > >
> > > Suppressed
> > >
> > > The following results come from untrusted machines, tests, or
> > > statuses.
> > > They do not affect the overall result.
> > >
> > > * igt@fbdev@info:
> > > - {bat-kbl-2}:[SKIP][3] ([fdo#109271]) -> [ABORT][4]
> > >[3]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-kbl-2/igt@fb...@info.html
> > >[4]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-kbl-2/igt@fb...@info.html
> > >
> > >
> > > Known issues
> > >
> > >
> > > Here are the changes found in Patchwork_115661v1 that come from
> > > known issues:
> > >
> > > ### IGT changes ###
> > >
> > > Issues hit
> > >
> > > * igt@gem_exec_suspend@basic-s3@lmem0:
> > > - bat-dg2-11: [PASS][5] -> [INCOMPLETE][6]
> > > ([i915#6311])
> > >[5]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
> > >[6]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
> > >
> > > * igt@i915_selftest@live@reset:
> > > - bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983])
> > >[7]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@reset.html
> > >[8]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
> > >
> > > * igt@i915_selftest@live@slpc:
> > > - bat-rpls-2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Fix MTL stolen memory GGTT mapping
== Series Details == Series: drm/i915/mtl: Fix MTL stolen memory GGTT mapping URL : https://patchwork.freedesktop.org/series/115695/ State : success == Summary == CI Bug Log - changes from CI_DRM_12923 -> Patchwork_115695v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/index.html Participating hosts (36 -> 36) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_115695v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@lmem0: - bat-dg2-9: [PASS][1] -> [FAIL][2] ([fdo#103375]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12923/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][3] -> [ABORT][4] ([i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12923/bat-rpls-2/igt@i915_selftest@l...@reset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/bat-rpls-2/igt@i915_selftest@l...@reset.html - bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#4983]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12923/bat-rpls-1/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][7] ([i915#7828]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3: - bat-dg2-9: [PASS][8] -> [FAIL][9] ([fdo#103375] / [i915#7932]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12923/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html Possible fixes * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][10] ([i915#7609] / [i915#7913]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12923/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1: - bat-dg2-8: [FAIL][12] ([i915#7932]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12923/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 Build changes - * Linux: CI_DRM_12923 -> Patchwork_115695v1 CI-20190529: 20190529 CI_DRM_12923: cdd32ac83137835a85bad4ca4b4751ea90960e72 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7221: 4b77c6d85024d22ca521d510f8eee574128fe04f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115695v1: cdd32ac83137835a85bad4ca4b4751ea90960e72 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits ba2b456d59a7 drm/i915/mtl: Fix MTL stolen memory GGTT mapping == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115695v1/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Fix MTL stolen memory GGTT mapping
== Series Details == Series: drm/i915/mtl: Fix MTL stolen memory GGTT mapping URL : https://patchwork.freedesktop.org/series/115695/ State : warning == Summary == Error: dim checkpatch failed 290c1809ab31 drm/i915/mtl: Fix MTL stolen memory GGTT mapping -:49: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #49: FILE: drivers/gpu/drm/i915/gem/i915_gem_stolen.c:907: + GEM_BUG_ON((dsm_base + dsm_size) > lmem_size); total: 0 errors, 1 warnings, 0 checks, 40 lines checked
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Add Support for C10 chips
== Series Details ==
Series: drm/i915/mtl: Add Support for C10 chips
URL : https://patchwork.freedesktop.org/series/115664/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12921_full -> Patchwork_115664v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115664v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_vblank@pipe-b-wait-idle:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-dg1-18/igt@kms_vbl...@pipe-b-wait-idle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-dg1-17/igt@kms_vbl...@pipe-b-wait-idle.html
Known issues
Here are the changes found in Patchwork_115664v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-glk3/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][6] -> [ABORT][7] ([i915#5566])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-glk4/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +2
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-apl6/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2346]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-glk5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#2346])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_flip@plain-flip-fb-recreate@a-hdmi-a1:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2122])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-glk6/igt@kms_flip@plain-flip-fb-recre...@a-hdmi-a1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-glk8/igt@kms_flip@plain-flip-fb-recre...@a-hdmi-a1.html
*
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271]) +76 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-apl2/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0...@pipe-c-dp-1.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-apl2/igt@kms_psr2...@plane-move-sf-dmg-area.html
* igt@vc4/vc4_perfmon@create-perfmon-exceed:
- shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271]) +20 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-glk3/igt@vc4/vc4_perf...@create-perfmon-exceed.html
Possible fixes
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][18] ([i915#6268]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-tglu-7/igt@gem_ctx_e...@basic-nohangcheck.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/shard-tglu-2/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: [FAIL][20] ([i915#2846]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/shard-apl1/igt@ge
[Intel-gfx] [PATCH] drm/i915/mtl: Fix MTL stolen memory GGTT mapping
The PTEs expect the offset from the base of the fake LMEM region (i.e.
the base of stolen) and not from the base of the DSM. Quoting the specs:
"Driver will set the Device Memory bit = 1 in the PTE when pointing to a
page in DSM and program the PTE with offset from LMEM_BAR. Device Memory
Offset from LMEM_BAR is same as offset from BGSM."
DSM starts 8MBs from BGSM, so we set dsm_base = 8MB.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Jani Nikula
Cc: Nirmoy Das
Cc: Fei Yang
Cc: Radhakrishna Sripada
---
I've omitted the fixes tag from the commit message since MTL is still
under force_probe, so there isn't really any need to propagate the fixes,
but here it is for reference:
Fixes: dbb2ffbfd708 ("drm/i915/mtl: enable local stolen memory")
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index d8e06e783e30..8ac376c24aa2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -890,8 +890,9 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
if (HAS_LMEMBAR_SMEM_STOLEN(i915)) {
/*
* MTL dsm size is in GGC register.
-* Also MTL uses offset to DSMBASE in ptes, so i915
-* uses dsm_base = 0 to setup stolen region.
+* Also MTL uses offset to GSMBASE in ptes, so i915
+* uses dsm_base = 8MBs to setup stolen region, since
+* DSMBASE = GSMBASE + 8MB.
*/
ret = mtl_get_gms_size(uncore);
if (ret < 0) {
@@ -899,11 +900,11 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
return ERR_PTR(ret);
}
- dsm_base = 0;
+ dsm_base = SZ_8M;
dsm_size = (resource_size_t)(ret * SZ_1M);
GEM_BUG_ON(pci_resource_len(pdev, GEN12_LMEM_BAR) != SZ_256M);
- GEM_BUG_ON((dsm_size + SZ_8M) > lmem_size);
+ GEM_BUG_ON((dsm_base + dsm_size) > lmem_size);
} else {
/* Use DSM base address instead for stolen memory */
dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) &
GEN12_BDSM_MASK;
@@ -912,14 +913,12 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
}
- io_size = dsm_size;
- if (HAS_LMEMBAR_SMEM_STOLEN(i915)) {
- io_start = pci_resource_start(pdev, GEN12_LMEM_BAR) + SZ_8M;
- } else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
+ if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
io_start = 0;
io_size = 0;
} else {
io_start = pci_resource_start(pdev, GEN12_LMEM_BAR) + dsm_base;
+ io_size = dsm_size;
}
min_page_size = HAS_64K_PAGES(i915) ? I915_GTT_PAGE_SIZE_64K :
--
2.37.3
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
Hi, Imre,
Thanks for raising this.
On Tue, 2023-03-28 at 00:26 +0300, Imre Deak wrote:
> Hi Rui,
>
> after applying your
> "x86/topology: fix erroneous smp_num_siblings on Intel Hybrid
> platform"
>
> fix on the drm-tip tree (see the patchwork URL below) the CI tests
> show
> some regression on a HSW and a KBL machine (see [2] and [4] below) in
> the i915 driver. However I think they can't be related to your
> changes,
> since on these machines all cores will report the same number of CPU
> siblings.
Right.
> Could you confirm this and that in general the reported
> siblings can only vary on platforms with both E and P cores (ADL-P
> being
> the first such platform)?
Right.
I don't think the patch could bring any change related.
It only affects hybrid platforms.
Thanks,
rui
>
> Thanks,
> Imre
>
> On Mon, Mar 27, 2023 at 07:02:25PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: x86/topology: fix erroneous smp_num_siblings on Intel
> > Hybrid platform
> > URL : https://patchwork.freedesktop.org/series/115661/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1
> >
> >
> > Summary
> > ---
> >
> > **FAILURE**
> >
> > Serious unknown changes coming with Patchwork_115661v1 absolutely
> > need to be
> > verified manually.
> >
> > If you think the reported changes have nothing to do with the
> > changes
> > introduced in Patchwork_115661v1, please notify your bug team to
> > allow them
> > to document this new failure mode, which will reduce false
> > positives in CI.
> >
> > External URL:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index.html
> >
> > Participating hosts (37 -> 37)
> > --
> >
> > No changes in participating hosts
> >
> > Possible new issues
> > ---
> >
> > Here are the unknown changes that may have been introduced in
> > Patchwork_115661v1:
> >
> > ### IGT changes ###
> >
> > Possible regressions
> >
> > * igt@i915_selftest@live@hangcheck:
> > - fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2]
> >[1]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
> >
> >
> > Suppressed
> >
> > The following results come from untrusted machines, tests, or
> > statuses.
> > They do not affect the overall result.
> >
> > * igt@fbdev@info:
> > - {bat-kbl-2}:[SKIP][3] ([fdo#109271]) -> [ABORT][4]
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-kbl-2/igt@fb...@info.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-kbl-2/igt@fb...@info.html
> >
> >
> > Known issues
> >
> >
> > Here are the changes found in Patchwork_115661v1 that come from
> > known issues:
> >
> > ### IGT changes ###
> >
> > Issues hit
> >
> > * igt@gem_exec_suspend@basic-s3@lmem0:
> > - bat-dg2-11: [PASS][5] -> [INCOMPLETE][6]
> > ([i915#6311])
> >[5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
> >[6]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
> >
> > * igt@i915_selftest@live@reset:
> > - bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983])
> >[7]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@reset.html
> >[8]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
> >
> > * igt@i915_selftest@live@slpc:
> > - bat-rpls-2: NOTRUN -> [DMESG-FAIL][9] ([i915#6367] /
> > [i915#7913] / [i915#7996])
> >[9]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
> >
> > * igt@i915_suspend@basic-s3-without-i915:
> > - bat-rpls-2: NOTRUN -> [ABORT][10] ([i915#6687] /
> > [i915#7978])
> >[10]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html
> >
> > * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-
> > dp-1:
> > - bat-dg2-8: [PASS][11] -> [FAIL][12] ([i915#7932])
> >[11]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
> >[12]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
> >
> >
> > Possible fixes
> >
> > * igt@i915_selftest@live@gt_heartbeat:
> > - fi-kbl-soraka: [DMESG-FAIL][13] ([i915#5334
Re: [Intel-gfx] [PATCH i-g-t 2/2] i915_guc_pc: Add some basic SLPC igt tests
On 3/26/2023 4:04 AM, Rodrigo Vivi wrote:
On Fri, Mar 24, 2023 at 03:49:59PM -0700, Vinay Belgaumkar wrote:
Use the xe_guc_pc test for i915 as well. Validate basic
api for GT freq control. Also test interaction with GT
reset. We skip rps tests with SLPC enabled, this will
re-introduce some coverage. SLPC selftests are already
covering some other workload related scenarios.
Signed-off-by: Rodrigo Vivi
you probably meant 'Cc:'
Added you as Signed-off-by since you are the original author in xe igt.
Signed-off-by: Vinay Belgaumkar
---
tests/i915/i915_guc_pc.c | 151 +++
tests/meson.build| 1 +
2 files changed, 152 insertions(+)
create mode 100644 tests/i915/i915_guc_pc.c
diff --git a/tests/i915/i915_guc_pc.c b/tests/i915/i915_guc_pc.c
new file mode 100644
index ..f9a0ed83
--- /dev/null
+++ b/tests/i915/i915_guc_pc.c
since 'guc_pc' is not a thing in i915 I'm afraid this will cause
confusion later.
I know, guc_slpc also doesn't make a lot of sense here...
Should we then try to move this code to the 'tests/i915/i915_pm_rps.c'
or maybe name it i915_pm_freq_api or something like that?
Sure. I was trying to make these guc/slpc specific since host trubo/RPS
already has coverage in IGT.
Thanks,
Vinay.
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "i915/gem.h"
+#include "igt_sysfs.h"
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test GuC PM features like SLPC and its interactions");
+/*
+ * Too many intermediate components and steps before freq is adjusted
+ * Specially if workload is under execution, so let's wait 100 ms.
+ */
+#define ACT_FREQ_LATENCY_US 10
+
+static uint32_t get_freq(int dirfd, uint8_t id)
+{
+ uint32_t val;
+
+ igt_require(igt_sysfs_rps_scanf(dirfd, id, "%u", &val) == 1);
+
+ return val;
+}
+
+static int set_freq(int dirfd, uint8_t id, uint32_t val)
+{
+ return igt_sysfs_rps_printf(dirfd, id, "%u", val);
+}
+
+static void test_freq_basic_api(int dirfd, int gt)
+{
+ uint32_t rpn, rp0, rpe;
+
+ /* Save frequencies */
+ rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
+ rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
+ rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
+ igt_info("System min freq: %dMHz; max freq: %dMHz\n", rpn, rp0);
+
+ /*
+* Negative bound tests
+* RPn is the floor
+* RP0 is the ceiling
+*/
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn - 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rp0 + 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn - 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0 + 1) < 0);
+
+ /* Assert min requests are respected from rp0 to rpn */
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rp0) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rp0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpe) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpe);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+
+ /* Assert max requests are respected from rpn to rp0 */
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpn);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpe) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpe);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rp0);
+
+}
+
+static void test_reset(int i915, int dirfd, int gt)
+{
+ uint32_t rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
+ int fd;
+
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
+ usleep(ACT_FREQ_LATENCY_US);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+
+ /* Manually trigger a GT reset */
+ fd = igt_debugfs_gt_open(i915, gt, "reset", O_WRONLY);
+ igt_require(fd >= 0);
+ igt_ignore_warn(write(fd, "1\n", 2));
+ close(fd);
+
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpn);
+}
+
+igt_main
+{
+ int i915 = -1;
+ uint32_t *stash_min, *stash_max;
+
+ igt_fixture {
+ int num_gts, dirfd, gt;
+
+ i915 = drm_open_driver(DRIVER_INTEL);
+ igt_require_gem(i915);
+ /* i915_pm_rps already covers execlist path */
+ igt_require(gem_using_guc_submission(i915));
+
+ num_gts = igt_sysfs_get_num_gt(i915);
+ stash_min = (uint32_t*)malloc(sizeof(uint32_t) * num_gts);
+ stash_max = (uint32_t*)malloc
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/xe_guc_pc: Restore max freq first
On 3/26/2023 3:51 AM, Rodrigo Vivi wrote:
On Fri, Mar 24, 2023 at 05:34:42PM -0700, Vinay Belgaumkar wrote:
When min/max are both at RPn, restoring min back to 300
will not work. Max needs to be increased first.
why max needs to come first in this case? we should probably at
least document so we don't forget it again...
I was assuming we use soft limits like in i915, but looks like we don't.
So, this is not an issue.
Also, add
igt_assert() here, which would have caught the issue.
I was going to ask if we should really add asserts inside the fixture
or maybe using igt_require instead, but then I noticed more cases
doing the assert...
Do we still need to add the assert in this case?
Thanks,
Vinay.
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
tests/xe/xe_guc_pc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/xe/xe_guc_pc.c b/tests/xe/xe_guc_pc.c
index 60c93288..43bf6f48 100644
--- a/tests/xe/xe_guc_pc.c
+++ b/tests/xe/xe_guc_pc.c
@@ -489,8 +489,8 @@ igt_main
igt_fixture {
xe_for_each_gt(fd, gt) {
- set_freq(sysfs, gt, "min", stash_min);
- set_freq(sysfs, gt, "max", stash_max);
+ igt_assert(set_freq(sysfs, gt, "max", stash_max) > 0);
+ igt_assert(set_freq(sysfs, gt, "min", stash_min) > 0);
}
close(sysfs);
xe_device_put(fd);
--
2.38.1
[Intel-gfx] ✓ Fi.CI.BAT: success for Report MMIO communication problems more clearly (rev3)
== Series Details == Series: Report MMIO communication problems more clearly (rev3) URL : https://patchwork.freedesktop.org/series/115421/ State : success == Summary == CI Bug Log - changes from CI_DRM_12922 -> Patchwork_115421v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/index.html Participating hosts (35 -> 34) -- Additional (1): fi-tgl-1115g4 Missing(2): fi-kbl-soraka fi-pnv-d510 Known issues Here are the changes found in Patchwork_115421v3 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#7561]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_lrc: - bat-dg1-7: [PASS][5] -> [ABORT][6] ([i915#4983]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/bat-dg1-7/igt@i915_selftest@live@gt_lrc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/bat-dg1-7/igt@i915_selftest@live@gt_lrc.html - bat-rpls-1: [PASS][7] -> [INCOMPLETE][8] ([i915#4983]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html * igt@i915_suspend@basic-s3-without-i915: - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][9] ([i915#7443]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_edid@dp-edid-read: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#7828]) +7 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([fdo#109285]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#5354]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_psr@cursor_plane_move: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([fdo#110189]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@kms_psr@cursor_plane_move.html * igt@kms_setmode@basic-clone-single-crtc: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#3555] / [i915#4579]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][17] ([i915#6367] / [i915#7913]) -> [DMESG-FAIL][18] ([i915#6367] / [i915#7913] / [i915#7996]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12922/bat-rpls-2/igt@i915_selftest@l...@slpc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115421v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#3301]: https://gitlab.freedesktop.org/drm/i
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: Restore dsparb_lock.
== Series Details == Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. URL : https://patchwork.freedesktop.org/series/115675/ State : success == Summary == CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115675v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/index.html Participating hosts (37 -> 36) -- Missing(1): fi-kbl-soraka Known issues Here are the changes found in Patchwork_115675v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][1] -> [ABORT][2] ([i915#7911] / [i915#7913]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][3] -> [ABORT][4] ([i915#7911] / [i915#7982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][5] ([i915#6367] / [i915#7913] / [i915#7996]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#7828]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#1845]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_pm_rps@basic-api: - bat-dg2-11: [FAIL][8] ([i915#8308]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@i915_pm_...@basic-api.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@reset: - bat-rpls-2: [ABORT][10] ([i915#4983] / [i915#7913]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-2/igt@i915_selftest@l...@reset.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/bat-rpls-2/igt@i915_selftest@l...@reset.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_12921 -> Patchwork_115675v1 CI-20190529: 20190529 CI_DRM_12921: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7221: 4b77c6d85024d22ca521d510f8eee574128fe04f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115675v1: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits ce61ba3bddad drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore. fac81539ff60 drm/i915/display: Restore dsparb_lock. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115675v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/display: Restore dsparb_lock.
== Series Details == Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. URL : https://patchwork.freedesktop.org/series/115675/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
Hi Rui,
after applying your
"x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform"
fix on the drm-tip tree (see the patchwork URL below) the CI tests show
some regression on a HSW and a KBL machine (see [2] and [4] below) in
the i915 driver. However I think they can't be related to your changes,
since on these machines all cores will report the same number of CPU
siblings. Could you confirm this and that in general the reported
siblings can only vary on platforms with both E and P cores (ADL-P being
the first such platform)?
Thanks,
Imre
On Mon, Mar 27, 2023 at 07:02:25PM +, Patchwork wrote:
> == Series Details ==
>
> Series: x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
> URL : https://patchwork.freedesktop.org/series/115661/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_115661v1 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_115661v1, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index.html
>
> Participating hosts (37 -> 37)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_115661v1:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_selftest@live@hangcheck:
> - fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@fbdev@info:
> - {bat-kbl-2}:[SKIP][3] ([fdo#109271]) -> [ABORT][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-kbl-2/igt@fb...@info.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-kbl-2/igt@fb...@info.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_115661v1 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_suspend@basic-s3@lmem0:
> - bat-dg2-11: [PASS][5] -> [INCOMPLETE][6] ([i915#6311])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
>
> * igt@i915_selftest@live@reset:
> - bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@reset.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
>
> * igt@i915_selftest@live@slpc:
> - bat-rpls-2: NOTRUN -> [DMESG-FAIL][9] ([i915#6367] /
> [i915#7913] / [i915#7996])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
>
> * igt@i915_suspend@basic-s3-without-i915:
> - bat-rpls-2: NOTRUN -> [ABORT][10] ([i915#6687] / [i915#7978])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html
>
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
> - bat-dg2-8: [PASS][11] -> [FAIL][12] ([i915#7932])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
>
>
> Possible fixes
>
> * igt@i915_selftest@live@gt_heartbeat:
> - fi-kbl-soraka: [DMESG-FAIL][13] ([i915#5334] / [i915#7872]) ->
> [PASS][14]
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
>
> * igt@i915_selftest@live@reset:
> - bat-rpls-2: [ABORT][15] ([i915#4983] / [i915#7913]) ->
> [PASS][16]
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-2/igt@i915_selftest@
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/ips: Make IPS debugfs per-crtc
== Series Details == Series: series starting with [1/2] drm/i915/ips: Make IPS debugfs per-crtc URL : https://patchwork.freedesktop.org/series/115669/ State : success == Summary == CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115669v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/index.html Participating hosts (37 -> 35) -- Missing(2): fi-kbl-soraka bat-rpls-2 Known issues Here are the changes found in Patchwork_115669v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rps@basic-api: - bat-dg1-5: [PASS][1] -> [FAIL][2] ([i915#8308]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg1-5/igt@i915_pm_...@basic-api.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [PASS][3] -> [INCOMPLETE][4] ([i915#7609] / [i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@migrate: - bat-adlp-9: [PASS][5] -> [DMESG-FAIL][6] ([i915#7699]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-adlp-9/igt@i915_selftest@l...@migrate.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/bat-adlp-9/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@reset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/bat-rpls-1/igt@i915_selftest@l...@reset.html Possible fixes * igt@i915_pm_rps@basic-api: - bat-dg2-11: [FAIL][9] ([i915#8308]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@i915_pm_...@basic-api.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/bat-dg2-11/igt@i915_pm_...@basic-api.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_12921 -> Patchwork_115669v1 CI-20190529: 20190529 CI_DRM_12921: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7221: 4b77c6d85024d22ca521d510f8eee574128fe04f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115669v1: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 496e61c9f41f drm/i915/ips: Add i915_ips_false_color debugfs file 19c5be6d2a56 drm/i915/ips: Make IPS debugfs per-crtc == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115669v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/ips: Make IPS debugfs per-crtc
== Series Details == Series: series starting with [1/2] drm/i915/ips: Make IPS debugfs per-crtc URL : https://patchwork.freedesktop.org/series/115669/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
On Mon, 27 Mar 2023 13:26:19 -0600
Alex Williamson wrote:
> On Mon, 27 Mar 2023 02:34:58 -0700
> Yi Liu wrote:
>
> > This is a preparation for vfio device cdev as cdev gives userspace the
> > capability to open device cdev fd and management stack (e.g. libvirt)
> > could pass the device fd to the actual user (e.g. QEMU). As a result,
> > the actual user has no idea about the device's bus:devfn information.
> > This is a problem when user uses VFIO_DEVICE_GET_PCI_HOT_RESET_INFO to
> > know the hot reset affected device scope as this ioctl returns bus:devfn
> > info. For the fd passing usage, the acutal user cannot map the bus:devfn
> > to the devices it has opened via the fd passed from management stack. So
> > a new ioctl is required.
> >
> > This new ioctl reports the list of iommufd dev_id that is opened by the
> > user. If there is affected device that is not bound to vfio driver or
> > opened by another user, this command shall fail with -EPERM. For the
> > noiommu mode in the vfio device cdev path, this shall fail as no dev_id
> > would be generated, hence nothing to report.
> >
> > This ioctl is useless to the users that open vfio group as such users
> > have no idea about the iommufd dev_id and it can use the existing
> > VFIO_DEVICE_GET_PCI_HOT_RESET_INFO. The user that uses the traditional
> > mode vfio group/container would be failed if invoking this ioctl. But
> > the user that uses the iommufd compat mode vfio group/container shall
> > succeed. This is harmless as long as user cannot make use of it and
> > should use VFIO_DEVICE_GET_PCI_HOT_RESET_INFO.
>
>
> So VFIO_DEVICE_GET_PCI_HOT_RESET_INFO reports a group and bdf, but
> VFIO_DEVICE_GET_PCI_HOT_RESET_*GROUP*_INFO is meant for the non-group,
> cdev use case and returns a dev_id rather than a group???
>
> Additionally, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO has a flags arg that
> isn't used, why do we need a new ioctl vs defining
> VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID. In fact, we could define
> vfio_dependent_device as:
>
> struct vfio_pci_dependent_device {
> union {
> __u32 group_id;
> __u32 dev_id;
> }
> __u16 segment;
> __u8bus;
> __u8devfn;
> };
>
> If the user calls with the above flag, dev_id is valid, otherwise
> group_id. Perhaps segment:buus:devfn could still be filled in with a
> NULL/invalid dev_id if the user doesn't have permissions for the device
> so that debugging from userspace isn't so opaque. Thanks,
>
> Alex
>
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 98
> > include/uapi/linux/vfio.h| 47 +++
> > 2 files changed, 145 insertions(+)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > b/drivers/vfio/pci/vfio_pci_core.c
> > index 19f5b075d70a..45edf4e9b98b 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -1181,6 +1181,102 @@ static int vfio_pci_ioctl_reset(struct
> > vfio_pci_core_device *vdev,
> > return ret;
> > }
> >
> > +static struct pci_dev *
> > +vfio_pci_dev_set_resettable(struct vfio_device_set *dev_set);
> > +
> > +static int vfio_pci_ioctl_get_pci_hot_reset_group_info(
> > + struct vfio_pci_core_device *vdev,
> > + struct vfio_pci_hot_reset_group_info __user *arg)
> > +{
> > + unsigned long minsz =
> > + offsetofend(struct vfio_pci_hot_reset_group_info, count);
> > + struct vfio_pci_hot_reset_group_info hdr;
> > + struct iommufd_ctx *iommufd, *cur_iommufd;
> > + u32 count = 0, index = 0, *devices = NULL;
> > + struct vfio_pci_core_device *cur;
> > + bool slot = false;
> > + int ret = 0;
> > +
> > + if (copy_from_user(&hdr, arg, minsz))
> > + return -EFAULT;
> > +
> > + if (hdr.argsz < minsz)
> > + return -EINVAL;
> > +
> > + hdr.flags = 0;
> > +
> > + /* Can we do a slot or bus reset or neither? */
> > + if (!pci_probe_reset_slot(vdev->pdev->slot))
> > + slot = true;
> > + else if (pci_probe_reset_bus(vdev->pdev->bus))
> > + return -ENODEV;
> > +
> > + mutex_lock(&vdev->vdev.dev_set->lock);
> > + if (!vfio_pci_dev_set_resettable(vdev->vdev.dev_set)) {
> > + ret = -EPERM;
> > + goto out_unlock;
> > + }
> > +
> > + iommufd = vfio_iommufd_physical_ictx(&vdev->vdev);
> > + if (!iommufd) {
> > + ret = -EPERM;
> > + goto out_unlock;
> > + }
> > +
> > + /* How many devices are affected? */
> > + ret = vfio_pci_for_each_slot_or_bus(vdev->pdev, vfio_pci_count_devs,
> > + &count, slot);
> > + if (ret)
> > + goto out_unlock;
> > +
> > + WARN_ON(!count); /* Should always be at least one */
> > +
> > + /*
> > +* If there's enough space, fill it now, otherwise return -ENOSPC and
> > +* the number of devices affected.
> > +*/
> > + if (hdr.argsz < sizeof(hdr) + (count * sizeof(*devic
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Add a function to mmap framebuffer obj (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915: Add a function to mmap framebuffer obj (rev2) URL : https://patchwork.freedesktop.org/series/115542/ State : success == Summary == CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115542v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/index.html Participating hosts (37 -> 36) -- Missing(1): fi-kbl-soraka New tests - New tests have been introduced between CI_DRM_12921 and Patchwork_115542v2: ### New IGT tests (1) ### * igt@fbdev: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_115542v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_lrc: - bat-rplp-1: [PASS][1] -> [INCOMPLETE][2] ([i915#4983] / [i915#7609] / [i915#7913]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@mman: - bat-rpls-2: [PASS][3] -> [TIMEOUT][4] ([i915#6794]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-2/igt@i915_selftest@l...@mman.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/bat-rpls-2/igt@i915_selftest@l...@mman.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#1845]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][7] ([i915#6367]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@slpc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 Build changes - * Linux: CI_DRM_12921 -> Patchwork_115542v2 CI-20190529: 20190529 CI_DRM_12921: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7221: 4b77c6d85024d22ca521d510f8eee574128fe04f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115542v2: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 2989b3b19b29 drm/i915/display: Implement fb_mmap callback function 3680a32041d3 drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper d28185572875 drm/i915: Add a function to mmap framebuffer obj == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115542v2/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: Add a function to mmap framebuffer obj (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915: Add a function to mmap framebuffer obj (rev2) URL : https://patchwork.freedesktop.org/series/115542/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/3] drm/i915: Add a function to mmap framebuffer obj (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915: Add a function to mmap framebuffer obj (rev2) URL : https://patchwork.freedesktop.org/series/115542/ State : warning == Summary == Error: dim checkpatch failed 895e3b7fd231 drm/i915: Add a function to mmap framebuffer obj -:132: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #132: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1040: + GEM_BUG_ON(obj && obj->ops->mmap_ops); -:138: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #138: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1046: + GEM_BUG_ON(obj && !obj->ops->mmap_ops); total: 0 errors, 2 warnings, 0 checks, 154 lines checked 418286e89a08 drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper 124941cc4cce drm/i915/display: Implement fb_mmap callback function
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/vrr: Relocate VRR enable/disable
Hi Ville,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 21 March 2023 19:26
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 5/6] drm/i915/vrr: Relocate VRR enable/disable
>
> From: Ville Syrjälä
>
> Move VRR enabling/disabling into a place where it also works for fastsets.
>
> With this we always start the transcoder up in non-VRR mode.
> Granted we already did that but for a very short period of time. But now
> that we might end up doing a bit more with the transcoder in non-VRR mode
> it seems prudent to also update the active timings as the transcoder changes
> its operating mode.
>
> crtc_state->vrr.enable still tracks whether VRR is actually enabled or not,
> but
> now we configure all the other VRR timing registers whenever VRR is possible
> (whether we actually enable it or not). crtc_state->vrr.flipline can now serve
> as our "is VRR possible" bit of state.
Understood the change. I was thinking if it is possible to make distinguish
between
is VRR "possible" and is VRR "enabled" by adding a new param ? Although changes
looks
good to me but using Flipline value as "is VRR Possible" makes it bit confusing.
Regards,
Mitul
>
> I decided to leave the MSA timing ignore bit set all the time whether VRR is
> actually enabled or not. If the sink can figure out the timings with that
> information when VRR is active then surely it can also do it when VRR is
> inactive.
>
> v2: Protect intel_vrr_set_transcoder_timings() with HAS_VRR()
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 5 --
> drivers/gpu/drm/i915/display/intel_display.c | 29 ++-
> .../drm/i915/display/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vrr.c | 48 +++
> drivers/gpu/drm/i915/display/intel_vrr.h | 1 +
> 5 files changed, 58 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index d094485f080d..fc1da5e06006 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -68,7 +68,6 @@
> #include "intel_tc.h"
> #include "intel_vdsc.h"
> #include "intel_vdsc_regs.h"
> -#include "intel_vrr.h"
> #include "skl_scaler.h"
> #include "skl_universal_plane.h"
>
> @@ -2724,8 +2723,6 @@ static void intel_ddi_post_disable(struct
> intel_atomic_state *state,
> if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
> intel_crtc_vblank_off(old_crtc_state);
>
> - intel_vrr_disable(old_crtc_state);
> -
> intel_disable_transcoder(old_crtc_state);
>
> intel_ddi_disable_transcoder_func(old_crtc_state);
> @@ -2951,8 +2948,6 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
>
> intel_enable_transcoder(crtc_state);
>
> - intel_vrr_enable(crtc_state);
> -
> intel_crtc_vblank_on(crtc_state);
>
> if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) diff --git
> a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index fc8eafd5fa61..5fc3f716286c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1088,6 +1088,18 @@ static bool planes_disabling(const struct
> intel_crtc_state *old_crtc_state,
> return is_disabling(active_planes, old_crtc_state, new_crtc_state); }
>
> +static bool vrr_enabling(const struct intel_crtc_state *old_crtc_state,
> + const struct intel_crtc_state *new_crtc_state) {
> + return is_enabling(vrr.enable, old_crtc_state, new_crtc_state); }
> +
> +static bool vrr_disabling(const struct intel_crtc_state *old_crtc_state,
> + const struct intel_crtc_state *new_crtc_state) {
> + return is_disabling(vrr.enable, old_crtc_state, new_crtc_state); }
> +
> #undef is_disabling
> #undef is_enabling
>
> @@ -1201,6 +1213,11 @@ static void intel_pre_plane_update(struct
> intel_atomic_state *state,
> intel_atomic_get_new_crtc_state(state, crtc);
> enum pipe pipe = crtc->pipe;
>
> + if (vrr_disabling(old_crtc_state, new_crtc_state)) {
> + intel_vrr_disable(old_crtc_state);
> + intel_crtc_update_active_timings(old_crtc_state, false);
> + }
> +
> intel_drrs_deactivate(old_crtc_state);
>
> intel_psr_pre_plane_update(state, crtc); @@ -1757,6 +1774,8 @@
> static void hsw_configure_cpu_transcoder(const struct intel_crtc_state
> *crtc_sta
> }
>
> intel_set_transcoder_timings(crtc_state);
> + if (HAS_VRR(dev_priv))
> + intel_vrr_set_transcoder_timings(crtc_state);
>
> if (cpu_transcoder != TRANSCODER_EDP)
> intel_de_write(dev_priv, TRANS_MULT(cpu_transcoder), @@
> -6956,8 +6975,8 @@ static void intel_enable_crtc(struct intel_atomic_state
> *state,
>
[Intel-gfx] [PATCH v3 2/2] drm/i915: Check for unreliable MMIO during forcewake
From: Matt Roper
Although we now sanitycheck MMIO access during driver load to make sure
the MMIO BAR isn't returning all 0x, there have been a few cases
where (temporarily?) unreliable MMIO access has happened after GPU
resets or power events. We'll often notice this on our next GT register
access since forcewake handling will fail; let's change our handling
slightly so that when this happens we print a more meaningful message
clarifying that the problem is the MMIO access, not forcewake
specifically.
Signed-off-by: Matt Roper
Cc: Mika Kuoppala
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/intel_uncore.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 14ec45e6facfa..796ebfe6c5507 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -177,12 +177,19 @@ wait_ack_set(const struct intel_uncore_forcewake_domain
*d,
static inline void
fw_domain_wait_ack_clear(const struct intel_uncore_forcewake_domain *d)
{
- if (wait_ack_clear(d, FORCEWAKE_KERNEL)) {
+ if (!wait_ack_clear(d, FORCEWAKE_KERNEL))
+ return;
+
+ if (fw_ack(d) == ~0)
+ drm_err(&d->uncore->i915->drm,
+ "%s: MMIO unreliable (forcewake register returns
0x)!\n",
+ intel_uncore_forcewake_domain_to_str(d->id));
+ else
drm_err(&d->uncore->i915->drm,
"%s: timed out waiting for forcewake ack to clear.\n",
intel_uncore_forcewake_domain_to_str(d->id));
- add_taint_for_CI(d->uncore->i915, TAINT_WARN); /* CI now
unreliable */
- }
+
+ add_taint_for_CI(d->uncore->i915, TAINT_WARN); /* CI now unreliable */
}
enum ack_type {
--
2.39.2
[Intel-gfx] [PATCH v3 1/2] drm/i915: Sanitycheck MMIO access early in driver load
From: Matt Roper
We occasionally see the PCI device in a non-accessible state at the
point the driver is loaded. When this happens, all BAR accesses will
read back as 0x. Rather than reading registers and
misinterpreting their (invalid) values, let's specifically check for
0x in a register that cannot have that value to see if the
device is accessible.
Signed-off-by: Matt Roper
Cc: Mika Kuoppala
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
---
Hi,
Andrzej suggested to check the upper 16 bits of the BAR. But
after an offline discussion with Matt, we agreed that reading the
whole 32 bits is a safer choice.
Andi
drivers/gpu/drm/i915/intel_uncore.c | 34 +
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e1e1f34490c8e..14ec45e6facfa 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2602,11 +2602,45 @@ static int uncore_forcewake_init(struct intel_uncore
*uncore)
return 0;
}
+static int sanity_check_mmio_access(struct intel_uncore *uncore)
+{
+ struct drm_i915_private *i915 = uncore->i915;
+
+ if (GRAPHICS_VER(i915) < 8)
+ return 0;
+
+ /*
+* Sanitycheck that MMIO access to the device is working properly. If
+* the CPU is unable to communcate with a PCI device, BAR reads will
+* return 0x. Let's make sure the device isn't in this state
+* before we start trying to access registers.
+*
+* We use the primary GT's forcewake register as our guinea pig since
+* it's been around since HSW and it's a masked register so the upper
+* 16 bits can never read back as 1's if device access is operating
+* properly.
+*
+* If MMIO isn't working, we'll wait up to 2 seconds to see if it
+* recovers, then give up.
+*/
+#define COND (__raw_uncore_read32(uncore, FORCEWAKE_MT) != ~0)
+ if (wait_for(COND, 2000) == -ETIMEDOUT) {
+ drm_err(&i915->drm, "Device is non-operational; MMIO access
returns 0x!\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
int intel_uncore_init_mmio(struct intel_uncore *uncore)
{
struct drm_i915_private *i915 = uncore->i915;
int ret;
+ ret = sanity_check_mmio_access(uncore);
+ if (ret)
+ return ret;
+
/*
* The boot firmware initializes local memory and assesses its health.
* If memory training fails, the punit will have been instructed to
--
2.39.2
[Intel-gfx] [PATCH v3 0/2] Report MMIO communication problems more clearly
Hi, just copy pasting Matt's original cover letter. Thank you Andrzej and Jani for looking into this series. We're periodically facing problems in CI where all registers read back as 0x. In general this is what happens when the CPU is unable to communicate with a PCI device, so the transaction autocompletes with all F's as a placeholder. Sometimes the device will recover on its own, sometimes it will never come back. We already have some attempts to detect when this happens (e.g., when checking FPGA_DBG), but let's add a couple more checks with descriptive error messages to identify the problem in other cases: - When the device is first probed, we'll do an initial check of the GT forcewake register. As a masked register, the upper bits should always come back as 0's if device access is behaving properly, so if we see all F's, we can conclude that the device is already in a bad state. We'll wait two seconds to see if it recovers on its own, then give up on the device. - When we encounter a 'forcewake timed out while waiting for clear' error, we'll do one more read of the register to see if it's because we're just reading back all F's. If so, we'll print a more meaningful message clarifying that it isn't the forcewake itself that's the problem, but rather communication with the device. Note that this only captures the failure case where accessing the device is problematic (resulting in registers giving all F's). There's a separate class of problems where the device is okay, but the GT inside the device is busted and all GT registers read back as 0's (other registers like sgunit registers are usually still readable). This series does not address that class of errors. This is just a quick change to get some better CI error messages. Some ideas for future enhancements: - Try something to reset the device if we detect a problem at driver load (e.g., PCI FLR, toggling the PCI power state, etc.)? - Use something more standard like pci_read_config_dword() instead of a device register read to determine when we're not communicating properly? Generally the PCI config space is also giving all F's at this point. - Also handle the "device OK, GT dead" case by finding some GT register(s) that should never be 0 on a functioning system. Maybe one of the fuse registers would work for this? Changelog = v2 -> v3 - Restored the previous change in V1 which was wrong. - A little cosmetic suggested by Andrzej in patch 2. - Added mine and Andrzej's r-b. v1 -> v2 - The sanity check can use intel_wait_for_register_fw(). (Thanks, Jani) Matt Roper (2): drm/i915: Sanitycheck MMIO access early in driver load drm/i915: Check for unreliable MMIO during forcewake drivers/gpu/drm/i915/intel_uncore.c | 47 +++-- 1 file changed, 44 insertions(+), 3 deletions(-) -- 2.39.2
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN"" (rev2)
== Series Details == Series: series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN"" (rev2) URL : https://patchwork.freedesktop.org/series/115659/ State : success == Summary == CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115659v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/index.html Participating hosts (37 -> 36) -- Missing(1): fi-kbl-soraka Known issues Here are the changes found in Patchwork_115659v2 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rps@basic-api: - bat-dg2-11: [FAIL][1] ([i915#8308]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@i915_pm_...@basic-api.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/bat-dg2-11/igt@i915_pm_...@basic-api.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][3] ([i915#6367]) -> [DMESG-FAIL][4] ([i915#6367] / [i915#7996]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@slpc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_12921 -> Patchwork_115659v2 CI-20190529: 20190529 CI_DRM_12921: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7221: 4b77c6d85024d22ca521d510f8eee574128fe04f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115659v2: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 992436d2fe1b drm/i915: remove unused config DRM_I915_UNSTABLE 2a7fe3dd9bca Revert "Revert "drm/i915: Don't select BROKEN"" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v2/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN"" (rev2)
== Series Details ==
Series: series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't
select BROKEN"" (rev2)
URL : https://patchwork.freedesktop.org/series/115659/
State : warning
== Summary ==
Error: dim checkpatch failed
c97f32bab9eb Revert "Revert "drm/i915: Don't select BROKEN""
608381a6c060 drm/i915: remove unused config DRM_I915_UNSTABLE
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 8c26491f5853 ("drm/i915: Kill
the fake lmem support")'
#10:
removed in 8c26491f5853 ("drm/i915: Kill the fake lmem support"). Drop
-:36: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#36:
deleted file mode 100644
total: 1 errors, 1 warnings, 0 checks, 11 lines checked
Re: [Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
On Mon, 27 Mar 2023 02:34:58 -0700
Yi Liu wrote:
> This is a preparation for vfio device cdev as cdev gives userspace the
> capability to open device cdev fd and management stack (e.g. libvirt)
> could pass the device fd to the actual user (e.g. QEMU). As a result,
> the actual user has no idea about the device's bus:devfn information.
> This is a problem when user uses VFIO_DEVICE_GET_PCI_HOT_RESET_INFO to
> know the hot reset affected device scope as this ioctl returns bus:devfn
> info. For the fd passing usage, the acutal user cannot map the bus:devfn
> to the devices it has opened via the fd passed from management stack. So
> a new ioctl is required.
>
> This new ioctl reports the list of iommufd dev_id that is opened by the
> user. If there is affected device that is not bound to vfio driver or
> opened by another user, this command shall fail with -EPERM. For the
> noiommu mode in the vfio device cdev path, this shall fail as no dev_id
> would be generated, hence nothing to report.
>
> This ioctl is useless to the users that open vfio group as such users
> have no idea about the iommufd dev_id and it can use the existing
> VFIO_DEVICE_GET_PCI_HOT_RESET_INFO. The user that uses the traditional
> mode vfio group/container would be failed if invoking this ioctl. But
> the user that uses the iommufd compat mode vfio group/container shall
> succeed. This is harmless as long as user cannot make use of it and
> should use VFIO_DEVICE_GET_PCI_HOT_RESET_INFO.
So VFIO_DEVICE_GET_PCI_HOT_RESET_INFO reports a group and bdf, but
VFIO_DEVICE_GET_PCI_HOT_RESET_*GROUP*_INFO is meant for the non-group,
cdev use case and returns a dev_id rather than a group???
Additionally, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO has a flags arg that
isn't used, why do we need a new ioctl vs defining
VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID. In fact, we could define
vfio_dependent_device as:
struct vfio_pci_dependent_device {
union {
__u32 group_id;
__u32 dev_id;
}
__u16 segment;
__u8bus;
__u8devfn;
};
If the user calls with the above flag, dev_id is valid, otherwise
group_id. Perhaps segment:buus:devfn could still be filled in with a
NULL/invalid dev_id if the user doesn't have permissions for the device
so that debugging from userspace isn't so opaque. Thanks,
Alex
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 98
> include/uapi/linux/vfio.h| 47 +++
> 2 files changed, 145 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 19f5b075d70a..45edf4e9b98b 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -1181,6 +1181,102 @@ static int vfio_pci_ioctl_reset(struct
> vfio_pci_core_device *vdev,
> return ret;
> }
>
> +static struct pci_dev *
> +vfio_pci_dev_set_resettable(struct vfio_device_set *dev_set);
> +
> +static int vfio_pci_ioctl_get_pci_hot_reset_group_info(
> + struct vfio_pci_core_device *vdev,
> + struct vfio_pci_hot_reset_group_info __user *arg)
> +{
> + unsigned long minsz =
> + offsetofend(struct vfio_pci_hot_reset_group_info, count);
> + struct vfio_pci_hot_reset_group_info hdr;
> + struct iommufd_ctx *iommufd, *cur_iommufd;
> + u32 count = 0, index = 0, *devices = NULL;
> + struct vfio_pci_core_device *cur;
> + bool slot = false;
> + int ret = 0;
> +
> + if (copy_from_user(&hdr, arg, minsz))
> + return -EFAULT;
> +
> + if (hdr.argsz < minsz)
> + return -EINVAL;
> +
> + hdr.flags = 0;
> +
> + /* Can we do a slot or bus reset or neither? */
> + if (!pci_probe_reset_slot(vdev->pdev->slot))
> + slot = true;
> + else if (pci_probe_reset_bus(vdev->pdev->bus))
> + return -ENODEV;
> +
> + mutex_lock(&vdev->vdev.dev_set->lock);
> + if (!vfio_pci_dev_set_resettable(vdev->vdev.dev_set)) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> +
> + iommufd = vfio_iommufd_physical_ictx(&vdev->vdev);
> + if (!iommufd) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> +
> + /* How many devices are affected? */
> + ret = vfio_pci_for_each_slot_or_bus(vdev->pdev, vfio_pci_count_devs,
> + &count, slot);
> + if (ret)
> + goto out_unlock;
> +
> + WARN_ON(!count); /* Should always be at least one */
> +
> + /*
> + * If there's enough space, fill it now, otherwise return -ENOSPC and
> + * the number of devices affected.
> + */
> + if (hdr.argsz < sizeof(hdr) + (count * sizeof(*devices))) {
> + ret = -ENOSPC;
> + hdr.count = count;
> + goto reset_info_exit;
> + }
> +
> + devices = kcalloc(count, sizeof(*devices), GFP_KERNEL);
> + if (!devices) {
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add Support for C10 chips
== Series Details == Series: drm/i915/mtl: Add Support for C10 chips URL : https://patchwork.freedesktop.org/series/115664/ State : success == Summary == CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115664v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/index.html Participating hosts (37 -> 36) -- Missing(1): fi-kbl-soraka Known issues Here are the changes found in Patchwork_115664v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][1] -> [DMESG-WARN][2] ([i915#7699]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@i915_selftest@l...@migrate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][3] ([i915#6997] / [i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-rpls-2: NOTRUN -> [ABORT][4] ([i915#6687]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html Possible fixes * igt@i915_selftest@live@reset: - bat-rpls-2: [ABORT][5] ([i915#4983] / [i915#7913]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-2/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/bat-rpls-2/igt@i915_selftest@l...@reset.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][7] ([i915#6367]) -> [DMESG-FAIL][8] ([i915#6367] / [i915#7996]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@slpc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_12921 -> Patchwork_115664v1 CI-20190529: 20190529 CI_DRM_12921: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7221: 4b77c6d85024d22ca521d510f8eee574128fe04f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115664v1: 3de6040ce9900a94ec626662d5c6a227b37eeb1c @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 44fd26d03e78 drm/i915/mtl: Add support for PM DEMAND 0a81d023ecf3 drm/i915/mtl: Add vswing programming for C10 phys 8dc097cb04ea drm/i915/mtl: Add C10 phy programming for HDMI 5c7fcca442fa drm/i915/mtl: Add Support for C10 PHY message bus and pll programming 8c2f753b154f drm/i915/mtl: Create separate reg file for PICA registers d5b7d4eeaded drm/i915/mtl: Add DP rates be08398ebf6f drm/i915/mtl: Initial DDI port setup == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115664v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add Support for C10 chips
== Series Details == Series: drm/i915/mtl: Add Support for C10 chips URL : https://patchwork.freedesktop.org/series/115664/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add Support for C10 chips
== Series Details == Series: drm/i915/mtl: Add Support for C10 chips URL : https://patchwork.freedesktop.org/series/115664/ State : warning == Summary == Error: dim checkpatch failed acf3d3886bcc drm/i915/mtl: Initial DDI port setup fa367a60b5f5 drm/i915/mtl: Add DP rates dd49f2562c22 drm/i915/mtl: Create separate reg file for PICA registers Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:17: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #17: new file mode 100644 -:37: WARNING:LONG_LINE: line length of 117 exceeds 100 columns #37: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:16: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \ -:38: WARNING:LONG_LINE: line length of 117 exceeds 100 columns #38: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:17: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \ -:39: WARNING:LONG_LINE: line length of 121 exceeds 100 columns #39: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:18: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \ -:40: WARNING:LONG_LINE: line length of 133 exceeds 100 columns #40: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:19: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4) -:43: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #43: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:22: +#define XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1) -:44: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #44: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:23: +#define XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2) -:45: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #45: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:24: +#define XELPDP_PORT_M2P_COMMAND_READ REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3) -:47: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #47: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:26: +#define XELPDP_PORT_M2P_DATA(val) REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val) -:50: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #50: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:29: +#define XELPDP_PORT_M2P_ADDRESS(val) REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val) -:52: WARNING:LONG_LINE: line length of 117 exceeds 100 columns #52: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:31: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \ -:53: WARNING:LONG_LINE: line length of 117 exceeds 100 columns #53: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:32: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \ -:54: WARNING:LONG_LINE: line length of 121 exceeds 100 columns #54: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:33: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \ -:55: WARNING:LONG_LINE: line length of 137 exceeds 100 columns #55: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:34: + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4 + 8) -:61: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #61: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:40: +#define XELPDP_PORT_P2M_DATA(val) REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val) -:79: WARNING:LONG_LINE: line length of 111 exceeds 100 columns #79: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:58: + _XELPDP_PORT_BUF_CTL1_LN0_A, \ -:80: WARNING:LONG_LINE: line length of 111 exceeds 100 columns #80: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:59: + _XELPDP_PORT_BUF_CTL1_LN0_B, \ -:81: WARNING:LONG_LINE: line length of 115 exceeds 100 columns #81: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:60: + _XELPDP_PORT_BUF_CTL1_LN0_USBC1, \ -:82: WARNING:LONG_LINE: line length of 114 exceeds 100 columns #82: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:61: +
Re: [Intel-gfx] [PATCH v10 00/15] dma-fence: Deadline awareness
On Wed, Mar 8, 2023 at 10:53 AM Rob Clark wrote: > > From: Rob Clark > > This series adds a deadline hint to fences, so realtime deadlines > such as vblank can be communicated to the fence signaller for power/ > frequency management decisions. > > This is partially inspired by a trick i915 does, but implemented > via dma-fence for a couple of reasons: > > 1) To continue to be able to use the atomic helpers > 2) To support cases where display and gpu are different drivers > > This iteration adds a dma-fence ioctl to set a deadline (both to > support igt-tests, and compositors which delay decisions about which > client buffer to display), and a sw_sync ioctl to read back the > deadline. IGT tests utilizing these can be found at: I read through the series and didn't spot anything. Have a rather weak Reviewed-by: Matt Turner Thanks!
[Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
== Series Details ==
Series: x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
URL : https://patchwork.freedesktop.org/series/115661/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_115661v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_115661v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index.html
Participating hosts (37 -> 37)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115661v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@fbdev@info:
- {bat-kbl-2}:[SKIP][3] ([fdo#109271]) -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-kbl-2/igt@fb...@info.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-kbl-2/igt@fb...@info.html
Known issues
Here are the changes found in Patchwork_115661v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@lmem0:
- bat-dg2-11: [PASS][5] -> [INCOMPLETE][6] ([i915#6311])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-1/igt@i915_selftest@l...@reset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-FAIL][9] ([i915#6367] / [i915#7913]
/ [i915#7996])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][10] ([i915#6687] / [i915#7978])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [PASS][11] -> [FAIL][12] ([i915#7932])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][13] ([i915#5334] / [i915#7872]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][15] ([i915#4983] / [i915#7913]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/bat-rpls-2/igt@i915_selftest@l...@reset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7932]: https://gitlab.freedes
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
== Series Details == Series: x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform URL : https://patchwork.freedesktop.org/series/115661/ State : warning == Summary == Error: dim checkpatch failed e89219f0529c x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform -:57: WARNING:BAD_SIGN_OFF: 'Tested-by:' is the preferred signature form #57: Tested-By: Jani Saarinen on local MTL setup. Also tested earlier on other CI systems -:57: WARNING:BAD_SIGN_OFF: Unexpected content after email: 'Jani Saarinen on local MTL setup. Also tested earlier on other CI systems', should be: 'Jani Saarinen (on local MTL setup. Also tested earlier on other CI systems)' #57: Tested-By: Jani Saarinen on local MTL setup. Also tested earlier on other CI systems total: 0 errors, 2 warnings, 0 checks, 17 lines checked
Re: [Intel-gfx] [PATCH v8 00/24] Add vfio_device cdev for iommufd support
On Mon, Mar 27, 2023 at 02:40:23AM -0700, Yi Liu wrote: > External email: Use caution opening links or attachments > > > Existing VFIO provides group-centric user APIs for userspace. Userspace > opens the /dev/vfio/$group_id first before getting device fd and hence > getting access to device. This is not the desired model for iommufd. Per > the conclusion of community discussion[1], iommufd provides device-centric > kAPIs and requires its consumer (like VFIO) to be device-centric user > APIs. Such user APIs are used to associate device with iommufd and also > the I/O address spaces managed by the iommufd. > > This series first introduces a per device file structure to be prepared > for further enhancement and refactors the kvm-vfio code to be prepared > for accepting device file from userspace. Afte this, adds a mechanism for > blocking device access before iommufd bind. Then refactors the vfio to be > able to handle cdev path (e.g. iommufd binding, no-iommufd, [de]attach ioas). > This refactor includes making the device_open exclusive between group and > cdev path, only allow single device open in cdev path; vfio-iommufd code is > also refactored to support cdev. e.g. split the vfio_iommufd_bind() into > two steps. Eventually, adds the cdev support for vfio device and the new > ioctls, then makes group infrastructure optional as it is not needed when > vfio device cdev is compiled. > > This series is based on some preparation works done to vfio emulated > devices[2] > and vfio pci hot reset enhancements[3]. > > This series is a prerequisite for iommu nesting for vfio device[4] [5]. > > The complete code can be found in below branch, simple tests done to the > legacy group path and the cdev path. Draft QEMU branch can be found at[6] > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v8 > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > base-commit: 1d412cdf6cd17c347b5398416a60518671e13d37 > > [1] > https://lore.kernel.org/kvm/bn9pr11mb5433b1e4ae5b0480369f97178c...@bn9pr11mb5433.namprd11.prod.outlook.com/ > [2] https://lore.kernel.org/kvm/20230327093351.44505-1-yi.l@intel.com/ > [3] https://lore.kernel.org/kvm/20230327093458.44939-1-yi.l@intel.com/ > [4] > https://lore.kernel.org/linux-iommu/20230309080910.607396-1-yi.l@intel.com/ > [5] > https://lore.kernel.org/linux-iommu/20230309082207.612346-1-yi.l@intel.com/ > [6] https://github.com/yiliu1765/qemu/tree/iommufd_rfcv3 (it is based on > Eric's > QEMU iommufd rfcv3 > (https://lore.kernel.org/kvm/20230131205305.2726330-1-eric.au...@redhat.com/) > plus commits to align with vfio_device_cdev v8) > > Change log: > > v8: > - Add patch 18 to determine noiommu device at vfio_device registration > (Jason) > - Add patch 19 to name noiommu device with "noiommu-" prefix to be par with >group path > - Add r-b from Kevin > - Add t-b from Terrence This runs well with iommufd selftest on x86 and QEMU sanity on ARM64, applying nesting series on top of this series: https://github.com/nicolinc/iommufd/commits/wip/iommufd_nesting-03272023 Tested-by: Nicolin Chen
Re: [Intel-gfx] [PATCH v3 0/6] vfio: Make emulated devices prepared for vfio device cdev
On Mon, Mar 27, 2023 at 02:33:45AM -0700, Yi Liu wrote: > External email: Use caution opening links or attachments > > > The .bind_iommufd op of vfio emulated devices are either empty or does > nothing. This is different with the vfio physical devices, to add vfio > device cdev, need to make them act the same. > > This series first makes the .bind_iommufd op of vfio emulated devices > to create iommufd_access, this introduces a new iommufd API. Then let > the driver that does not provide .bind_iommufd op to use the vfio emulated > iommufd op set. This makes all vfio device drivers have consistent iommufd > operations, which is good for adding new device uAPIs in the device cdev > series. > > Change log: > > v3: > - Use iommufd_get_ioas() for ioas get, hence patch 01 is added to modify >the input parameter of iommufd_get_ioas(). (Jason) > - Add r-b from Jason and Kevin > - Add t-b from Terrence Xu This runs well with iommufd selftest on x86 and QEMU sanity on ARM64, applying nesting series on top of this and cdev series: https://github.com/nicolinc/iommufd/commits/wip/iommufd_nesting-03272023 Tested-by: Nicolin Chen
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
+Daniel
On Mon, Mar 27, 2023 at 09:58:52AM -0700, Dixit, Ashutosh wrote:
> On Sun, 26 Mar 2023 04:52:59 -0700, Rodrigo Vivi wrote:
> >
>
> Hi Rodrigo,
>
> > On Fri, Mar 24, 2023 at 04:31:22PM -0700, Dixit, Ashutosh wrote:
> > > On Fri, 24 Mar 2023 11:15:02 -0700, Belgaumkar, Vinay wrote:
> > > >
> > >
> > > Hi Vinay,
> > >
> > > Thanks for the review. Comments inline below.
> > >
> > > > On 3/15/2023 8:59 PM, Ashutosh Dixit wrote:
> > > > > On dGfx, the PL1 power limit being enabled and set to a low value
> > > > > results
> > > > > in a low GPU operating freq. It also negates the freq raise operation
> > > > > which
> > > > > is done before GuC firmware load. As a result GuC firmware load can
> > > > > time
> > > > > out. Such timeouts were seen in the GL #8062 bug below (where the PL1
> > > > > power
> > > > > limit was enabled and set to a low value). Therefore disable the PL1
> > > > > power
> > > > > limit when allowed by HW when loading GuC firmware.
> > > > v3 label missing in subject.
> > > > >
> > > > > v2:
> > > > > - Take mutex (to disallow writes to power1_max) across GuC reset/fw
> > > > > load
> > > > > - Add hwm_power_max_restore to error return code path
> > > > >
> > > > > v3 (Jani N):
> > > > > - Add/remove explanatory comments
> > > > > - Function renames
> > > > > - Type corrections
> > > > > - Locking annotation
> > > > >
> > > > > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
> > > > > Signed-off-by: Ashutosh Dixit
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++
> > > > > drivers/gpu/drm/i915/i915_hwmon.c | 39
> > > > > +++
> > > > > drivers/gpu/drm/i915/i915_hwmon.h | 7 +
> > > > > 3 files changed, 55 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > > index 4ccb4be4c9cba..aa8e35a5636a0 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > > @@ -18,6 +18,7 @@
> > > > > #include "intel_uc.h"
> > > > > #include "i915_drv.h"
> > > > > +#include "i915_hwmon.h"
> > > > > static const struct intel_uc_ops uc_ops_off;
> > > > > static const struct intel_uc_ops uc_ops_on;
> > > > > @@ -461,6 +462,7 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > > struct intel_guc *guc = &uc->guc;
> > > > > struct intel_huc *huc = &uc->huc;
> > > > > int ret, attempts;
> > > > > + bool pl1en;
> > > >
> > > > Init to 'false' here
> > >
> > > See next comment.
> > >
> > > >
> > > >
> > > > > GEM_BUG_ON(!intel_uc_supports_guc(uc));
> > > > > GEM_BUG_ON(!intel_uc_wants_guc(uc));
> > > > > @@ -491,6 +493,9 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > > else
> > > > > attempts = 1;
> > > > > + /* Disable a potentially low PL1 power limit to allow freq to be
> > > > > raised */
> > > > > + i915_hwmon_power_max_disable(gt->i915, &pl1en);
> > > > > +
> > > > > intel_rps_raise_unslice(&uc_to_gt(uc)->rps);
> > > > > while (attempts--) {
> > > > > @@ -547,6 +552,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > > intel_rps_lower_unslice(&uc_to_gt(uc)->rps);
> > > > > }
> > > > > + i915_hwmon_power_max_restore(gt->i915, pl1en);
> > > > > +
> > > > > guc_info(guc, "submission %s\n",
> > > > > str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
> > > > > guc_info(guc, "SLPC %s\n",
> > > > > str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
> > > > > @@ -563,6 +570,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > > /* Return GT back to RPn */
> > > > > intel_rps_lower_unslice(&uc_to_gt(uc)->rps);
> > > > > + i915_hwmon_power_max_restore(gt->i915, pl1en);
> > > >
> > > > if (pl1en)
> > > >
> > > > i915_hwmon_power_max_enable().
> > >
> > > IMO it's better not to have checks in the main __uc_init_hw() function (if
> > > we do this we'll need to add 2 checks in __uc_init_hw()). If you really
> > > want we could do something like this inside
> > > i915_hwmon_power_max_disable/i915_hwmon_power_max_restore. But for now I
> > > am not making any changes.
> > >
> > > (I can send a patch with the changes if you want to take a look but IMO it
> > > will add more logic/code but without real benefits (it will save a rmw if
> > > the limit was already disabled, but IMO this code is called so
> > > infrequently
> > > (only during GuC resets) as to not have any significant impact)).
> > >
> > > >
> > > > > +
> > > > > __uc_sanitize(uc);
> > > > > if (!ret) {
> > > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > index ee63a8fd88fc1..769b5bda4d53f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > @@ -444,6 +444,45 @@ hwm_power
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On Sun, 26 Mar 2023 04:52:59 -0700, Rodrigo Vivi wrote:
>
Hi Rodrigo,
> On Fri, Mar 24, 2023 at 04:31:22PM -0700, Dixit, Ashutosh wrote:
> > On Fri, 24 Mar 2023 11:15:02 -0700, Belgaumkar, Vinay wrote:
> > >
> >
> > Hi Vinay,
> >
> > Thanks for the review. Comments inline below.
> >
> > > On 3/15/2023 8:59 PM, Ashutosh Dixit wrote:
> > > > On dGfx, the PL1 power limit being enabled and set to a low value
> > > > results
> > > > in a low GPU operating freq. It also negates the freq raise operation
> > > > which
> > > > is done before GuC firmware load. As a result GuC firmware load can time
> > > > out. Such timeouts were seen in the GL #8062 bug below (where the PL1
> > > > power
> > > > limit was enabled and set to a low value). Therefore disable the PL1
> > > > power
> > > > limit when allowed by HW when loading GuC firmware.
> > > v3 label missing in subject.
> > > >
> > > > v2:
> > > > - Take mutex (to disallow writes to power1_max) across GuC reset/fw
> > > > load
> > > > - Add hwm_power_max_restore to error return code path
> > > >
> > > > v3 (Jani N):
> > > > - Add/remove explanatory comments
> > > > - Function renames
> > > > - Type corrections
> > > > - Locking annotation
> > > >
> > > > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
> > > > Signed-off-by: Ashutosh Dixit
> > > > ---
> > > > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++
> > > > drivers/gpu/drm/i915/i915_hwmon.c | 39 +++
> > > > drivers/gpu/drm/i915/i915_hwmon.h | 7 +
> > > > 3 files changed, 55 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > index 4ccb4be4c9cba..aa8e35a5636a0 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > > > @@ -18,6 +18,7 @@
> > > > #include "intel_uc.h"
> > > > #include "i915_drv.h"
> > > > +#include "i915_hwmon.h"
> > > > static const struct intel_uc_ops uc_ops_off;
> > > > static const struct intel_uc_ops uc_ops_on;
> > > > @@ -461,6 +462,7 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > struct intel_guc *guc = &uc->guc;
> > > > struct intel_huc *huc = &uc->huc;
> > > > int ret, attempts;
> > > > + bool pl1en;
> > >
> > > Init to 'false' here
> >
> > See next comment.
> >
> > >
> > >
> > > > GEM_BUG_ON(!intel_uc_supports_guc(uc));
> > > > GEM_BUG_ON(!intel_uc_wants_guc(uc));
> > > > @@ -491,6 +493,9 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > else
> > > > attempts = 1;
> > > > + /* Disable a potentially low PL1 power limit to allow freq to be
> > > > raised */
> > > > + i915_hwmon_power_max_disable(gt->i915, &pl1en);
> > > > +
> > > > intel_rps_raise_unslice(&uc_to_gt(uc)->rps);
> > > > while (attempts--) {
> > > > @@ -547,6 +552,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > intel_rps_lower_unslice(&uc_to_gt(uc)->rps);
> > > > }
> > > > + i915_hwmon_power_max_restore(gt->i915, pl1en);
> > > > +
> > > > guc_info(guc, "submission %s\n",
> > > > str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
> > > > guc_info(guc, "SLPC %s\n",
> > > > str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
> > > > @@ -563,6 +570,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> > > > /* Return GT back to RPn */
> > > > intel_rps_lower_unslice(&uc_to_gt(uc)->rps);
> > > > + i915_hwmon_power_max_restore(gt->i915, pl1en);
> > >
> > > if (pl1en)
> > >
> > > i915_hwmon_power_max_enable().
> >
> > IMO it's better not to have checks in the main __uc_init_hw() function (if
> > we do this we'll need to add 2 checks in __uc_init_hw()). If you really
> > want we could do something like this inside
> > i915_hwmon_power_max_disable/i915_hwmon_power_max_restore. But for now I
> > am not making any changes.
> >
> > (I can send a patch with the changes if you want to take a look but IMO it
> > will add more logic/code but without real benefits (it will save a rmw if
> > the limit was already disabled, but IMO this code is called so infrequently
> > (only during GuC resets) as to not have any significant impact)).
> >
> > >
> > > > +
> > > > __uc_sanitize(uc);
> > > > if (!ret) {
> > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > index ee63a8fd88fc1..769b5bda4d53f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > @@ -444,6 +444,45 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
> > > > attr, int chan, long val)
> > > > }
> > > > }
> > > > +void i915_hwmon_power_max_disable(struct drm_i915_private *i915, bool
> > > > *old)
> > > Shouldn't we call this i915_hwmon_package_pl1_disable()?
> >
> > I did think of using "pl1" in the function name but then decided to retain
> > "power_max" because other hwmon functions for PL1 limit also use
> > "power_max" (hwm_power_ma
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On Fri, 24 Mar 2023 17:06:33 -0700, Belgaumkar, Vinay wrote:
>
Hi Vinay,
> On 3/24/2023 4:31 PM, Dixit, Ashutosh wrote:
> > On Fri, 24 Mar 2023 11:15:02 -0700, Belgaumkar, Vinay wrote:
> > Hi Vinay,
> >
> > Thanks for the review. Comments inline below.
> Sorry about asking the same questions all over again :) Didn't look at
> previous versions.
Np, the previous versions were buried somewhere anyway that's why I
provided the link.
> >
> >> On 3/15/2023 8:59 PM, Ashutosh Dixit wrote:
> >>> On dGfx, the PL1 power limit being enabled and set to a low value results
> >>> in a low GPU operating freq. It also negates the freq raise operation
> >>> which
> >>> is done before GuC firmware load. As a result GuC firmware load can time
> >>> out. Such timeouts were seen in the GL #8062 bug below (where the PL1
> >>> power
> >>> limit was enabled and set to a low value). Therefore disable the PL1 power
> >>> limit when allowed by HW when loading GuC firmware.
> >> v3 label missing in subject.
> >>> v2:
> >>>- Take mutex (to disallow writes to power1_max) across GuC reset/fw
> >>> load
> >>>- Add hwm_power_max_restore to error return code path
> >>>
> >>> v3 (Jani N):
> >>>- Add/remove explanatory comments
> >>>- Function renames
> >>>- Type corrections
> >>>- Locking annotation
> >>>
> >>> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
> >>> Signed-off-by: Ashutosh Dixit
> >>> ---
> >>>drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++
> >>>drivers/gpu/drm/i915/i915_hwmon.c | 39 +++
> >>>drivers/gpu/drm/i915/i915_hwmon.h | 7 +
> >>>3 files changed, 55 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >>> index 4ccb4be4c9cba..aa8e35a5636a0 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >>> @@ -18,6 +18,7 @@
> >>>#include "intel_uc.h"
> >>> #include "i915_drv.h"
> >>> +#include "i915_hwmon.h"
> >>> static const struct intel_uc_ops uc_ops_off;
> >>>static const struct intel_uc_ops uc_ops_on;
> >>> @@ -461,6 +462,7 @@ static int __uc_init_hw(struct intel_uc *uc)
> >>> struct intel_guc *guc = &uc->guc;
> >>> struct intel_huc *huc = &uc->huc;
> >>> int ret, attempts;
> >>> + bool pl1en;
> >> Init to 'false' here
> > See next comment.
> >
> >>
> >>> GEM_BUG_ON(!intel_uc_supports_guc(uc));
> >>> GEM_BUG_ON(!intel_uc_wants_guc(uc));
> >>> @@ -491,6 +493,9 @@ static int __uc_init_hw(struct intel_uc *uc)
> >>> else
> >>> attempts = 1;
> >>>+ /* Disable a potentially low PL1 power limit to allow freq to be
> >>> raised */
> >>> + i915_hwmon_power_max_disable(gt->i915, &pl1en);
> >>> +
> >>> intel_rps_raise_unslice(&uc_to_gt(uc)->rps);
> >>> while (attempts--) {
> >>> @@ -547,6 +552,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> >>> intel_rps_lower_unslice(&uc_to_gt(uc)->rps);
> >>> }
> >>>+ i915_hwmon_power_max_restore(gt->i915, pl1en);
> >>> +
> >>> guc_info(guc, "submission %s\n",
> >>> str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
> >>> guc_info(guc, "SLPC %s\n",
> >>> str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
> >>>@@ -563,6 +570,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> >>> /* Return GT back to RPn */
> >>> intel_rps_lower_unslice(&uc_to_gt(uc)->rps);
> >>>+ i915_hwmon_power_max_restore(gt->i915, pl1en);
> >> if (pl1en)
> >>
> >> i915_hwmon_power_max_enable().
> > IMO it's better not to have checks in the main __uc_init_hw() function (if
> > we do this we'll need to add 2 checks in __uc_init_hw()). If you really
> > want we could do something like this inside
> > i915_hwmon_power_max_disable/i915_hwmon_power_max_restore. But for now I
> > am not making any changes.
> ok.
> >
> > (I can send a patch with the changes if you want to take a look but IMO it
> > will add more logic/code but without real benefits (it will save a rmw if
> > the limit was already disabled, but IMO this code is called so infrequently
> > (only during GuC resets) as to not have any significant impact)).
> >
> >>> +
> >>> __uc_sanitize(uc);
> >>> if (!ret) {
> >>> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> >>> b/drivers/gpu/drm/i915/i915_hwmon.c
> >>> index ee63a8fd88fc1..769b5bda4d53f 100644
> >>> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> >>> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> >>> @@ -444,6 +444,45 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr,
> >>> int chan, long val)
> >>> }
> >>>}
> >>>+void i915_hwmon_power_max_disable(struct drm_i915_private *i915, bool
> >>> *old)
> >> Shouldn't we call this i915_hwmon_package_pl1_disable()?
> > I did think of using "pl1" in the function name but then decided to retain
> > "power_max" because other hwmon functions for PL1 limit also use
> > "power_max" (hwm_power_max_read/hwm_power_max_w
Re: [Intel-gfx] [PATCH v3 1/6] iommu/iommufd: Pass iommufd_ctx pointer in iommufd_get_ioas()
On Mon, Mar 27, 2023 at 02:33:46AM -0700, Yi Liu wrote: > no need to pass the iommufd_ucmd pointer. > > Signed-off-by: Yi Liu > --- > drivers/iommu/iommufd/ioas.c| 14 +++--- > drivers/iommu/iommufd/iommufd_private.h | 4 ++-- > drivers/iommu/iommufd/selftest.c| 6 +++--- > drivers/iommu/iommufd/vfio_compat.c | 2 +- > 4 files changed, 13 insertions(+), 13 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup
On 27/03/2023 08:07, Lionel Landwerlin wrote:
On 26/03/2023 14:18, Rodrigo Vivi wrote:
On Sat, Mar 25, 2023 at 02:19:21AM -0400, Teres Alexis, Alan Previn
wrote:
alan:snip
@@ -353,8 +367,20 @@ int intel_pxp_start(struct intel_pxp *pxp)
alan:snip
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+ /*
+ * GSC-fw loading, GSC-proxy init (requiring an mei
component driver) and
+ * HuC-fw loading must all occur first before we start
requesting for PXP
+ * sessions. Checking HuC authentication (the last
dependency) will suffice.
+ * Let's use a much larger 8 second timeout considering
all the types of
+ * dependencies prior to that.
+ */
+ if
(wait_for(intel_huc_is_authenticated(&pxp->ctrl_gt->uc.huc), 8000))
This big timeout needs an ack from userspace drivers, as
intel_pxp_start
is called during context creation and the current way to query if the
feature is supported is to create a protected context.
Unfortunately, we
do need to wait to confirm that PXP is available (although in most
cases
it shouldn't take even close to 8 secs), because until everything is
setup we're not sure if things will work as expected. I see 2 potential
mitigations in case the timeout doesn't work as-is:
1) we return -EAGAIN (or another dedicated error code) to userspace if
the prerequisite steps aren't done yet. This would indicate that the
feature is there, but that we haven't completed the setup yet. The
caller can then decide if they want to retry immediately or later. Pro:
more flexibility for userspace; Cons: new interface return code.
2) we add a getparam to say if PXP is supported in HW and the
support is
compiled in i915. Userspace can query this as a way to check the
feature
support and only create the context if they actually need it for PXP
operations. Pro: simpler kernel implementation; Cons: new getparam,
plus
even if the getparam returns true the pxp_start could later fail, so
userspace needs to handle that case.
These two:
e6177ec586d1 ("drm/i915/huc: stall media submission until HuC is loaded")
b76c14c8fb2a ("drm/i915/huc: better define HuC status getparam possible return
values.")
They do not help here? It is not possible to use or extend the refined
I915_PARAM_HUC_STATUS return values combined with huc load fence for this all
to keep working?
Regards,
Tvrtko
alan: I've cc'd Rodrigo, Joonas and Lionel. Folks - what are your
thoughts on above issue?
Recap: On MTL, only when creating a GEM Protected (PXP) context for
the very first time after
a driver load, it will be dependent on (1) loading the GSC firmware,
(2) GuC loading the HuC
firmware and (3) GSC authenticating the HuC fw. But step 3 also
depends on additional
GSC-proxy-init steps that depend on a new mei-gsc-proxy component
driver. I'd used the
8 second number based on offline conversations with Daniele but that
is a worse-case.
Alternatively, should we change UAPI instead to return -EAGAIN as per
Daniele's proposal?
I believe we've had the get-param conversation offline recently and
the direction was to
stick with attempting to create the context as it is normal in 3D UMD
when it comes to
testing capabilities for other features too.
Thoughts?
I like the option 1 more. This extra return handling won't break
compatibility.
I like option 2 better because we have to report support as fast as we
can when enumerating devices on the system for example.
If I understand correctly, with the get param, most apps won't ever be
blocking on any PXP stuff if they don't use it.
Only the ones that require protected support might block.
-Lionel
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce new methods for verifying ownership in vfio PCI hot reset (rev2)
== Series Details ==
Series: Introduce new methods for verifying ownership in vfio PCI hot reset
(rev2)
URL : https://patchwork.freedesktop.org/series/115264/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12918_full -> Patchwork_115264v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
Additional (1): shard-rkl0
Missing(1): shard-rkl
Known issues
Here are the changes found in Patchwork_115264v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-apl1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2346])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-glk2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2346]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
Possible fixes
* igt@gem_eio@hibernate:
- {shard-tglu}: [ABORT][9] ([i915#7975]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-tglu-10/igt@gem_...@hibernate.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-tglu-9/igt@gem_...@hibernate.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][11] ([i915#2842]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- {shard-tglu}: [SKIP][13] ([i915#1397]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-tglu-9/igt@i915_pm_...@dpms-mode-unset-lpsp.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-tglu-8/igt@i915_pm_...@dpms-mode-unset-lpsp.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt:
- {shard-tglu}: [SKIP][15] ([i915#1849]) -> [PASS][16] +7 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-tglu-9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-tglu-8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html
* igt@kms_vblank@invalid:
- {shard-tglu}: [SKIP][17] ([i915#1845] / [i915#7651]) -> [PASS][18]
+9 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-tglu-9/igt@kms_vbl...@invalid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-tglu-8/igt@kms_vbl...@invalid.html
* igt@kms_vblank@pipe-b-ts-continuation-modeset-rpm:
- {shard-tglu}: [SKIP][19] ([i915#1845]) -> [PASS][20] +18 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-tglu-10/igt@kms_vbl...@pipe-b-ts-continuation-modeset-rpm.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/shard-tglu-5/igt@kms_vbl...@pipe-b-ts-continuation-modeset-rpm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109314]: https://bugs.freedesktop.org/show_bug.cgi?id=109314
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109506]: https://bugs.free
[Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.
Let's get rid of the intel_uncore calls on display side.
v2: Fix multiple CHECK:PARENTHESIS_ALIGNMENT:
Alignment should match open parenthesis
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20230308165859.235520-2-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/display/i9xx_wm.c | 366
drivers/gpu/drm/i915/display/intel_de.h | 12 +
2 files changed, 195 insertions(+), 183 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
b/drivers/gpu/drm/i915/display/i9xx_wm.c
index 8fe0b5c63d3a..22669b73d4c6 100644
--- a/drivers/gpu/drm/i915/display/i9xx_wm.c
+++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
@@ -6,6 +6,7 @@
#include "i915_drv.h"
#include "i9xx_wm.h"
#include "intel_atomic.h"
+#include "intel_de.h"
#include "intel_display.h"
#include "intel_display_trace.h"
#include "intel_mchbar_regs.h"
@@ -141,39 +142,39 @@ static bool _intel_set_memory_cxsr(struct
drm_i915_private *dev_priv, bool enabl
u32 val;
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- was_enabled = intel_uncore_read(&dev_priv->uncore,
FW_BLC_SELF_VLV) & FW_CSPWRDWNEN;
- intel_uncore_write(&dev_priv->uncore, FW_BLC_SELF_VLV, enable ?
FW_CSPWRDWNEN : 0);
- intel_uncore_posting_read(&dev_priv->uncore, FW_BLC_SELF_VLV);
+ was_enabled = intel_de_read(dev_priv, FW_BLC_SELF_VLV) &
FW_CSPWRDWNEN;
+ intel_de_write(dev_priv, FW_BLC_SELF_VLV, enable ?
FW_CSPWRDWNEN : 0);
+ intel_de_posting_read(dev_priv, FW_BLC_SELF_VLV);
} else if (IS_G4X(dev_priv) || IS_I965GM(dev_priv)) {
- was_enabled = intel_uncore_read(&dev_priv->uncore, FW_BLC_SELF)
& FW_BLC_SELF_EN;
- intel_uncore_write(&dev_priv->uncore, FW_BLC_SELF, enable ?
FW_BLC_SELF_EN : 0);
- intel_uncore_posting_read(&dev_priv->uncore, FW_BLC_SELF);
+ was_enabled = intel_de_read(dev_priv, FW_BLC_SELF) &
FW_BLC_SELF_EN;
+ intel_de_write(dev_priv, FW_BLC_SELF, enable ? FW_BLC_SELF_EN :
0);
+ intel_de_posting_read(dev_priv, FW_BLC_SELF);
} else if (IS_PINEVIEW(dev_priv)) {
- val = intel_uncore_read(&dev_priv->uncore, DSPFW3);
+ val = intel_de_read(dev_priv, DSPFW3);
was_enabled = val & PINEVIEW_SELF_REFRESH_EN;
if (enable)
val |= PINEVIEW_SELF_REFRESH_EN;
else
val &= ~PINEVIEW_SELF_REFRESH_EN;
- intel_uncore_write(&dev_priv->uncore, DSPFW3, val);
- intel_uncore_posting_read(&dev_priv->uncore, DSPFW3);
+ intel_de_write(dev_priv, DSPFW3, val);
+ intel_de_posting_read(dev_priv, DSPFW3);
} else if (IS_I945G(dev_priv) || IS_I945GM(dev_priv)) {
- was_enabled = intel_uncore_read(&dev_priv->uncore, FW_BLC_SELF)
& FW_BLC_SELF_EN;
+ was_enabled = intel_de_read(dev_priv, FW_BLC_SELF) &
FW_BLC_SELF_EN;
val = enable ? _MASKED_BIT_ENABLE(FW_BLC_SELF_EN) :
_MASKED_BIT_DISABLE(FW_BLC_SELF_EN);
- intel_uncore_write(&dev_priv->uncore, FW_BLC_SELF, val);
- intel_uncore_posting_read(&dev_priv->uncore, FW_BLC_SELF);
+ intel_de_write(dev_priv, FW_BLC_SELF, val);
+ intel_de_posting_read(dev_priv, FW_BLC_SELF);
} else if (IS_I915GM(dev_priv)) {
/*
* FIXME can't find a bit like this for 915G, and
* yet it does have the related watermark in
* FW_BLC_SELF. What's going on?
*/
- was_enabled = intel_uncore_read(&dev_priv->uncore, INSTPM) &
INSTPM_SELF_EN;
+ was_enabled = intel_de_read(dev_priv, INSTPM) & INSTPM_SELF_EN;
val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
_MASKED_BIT_DISABLE(INSTPM_SELF_EN);
- intel_uncore_write(&dev_priv->uncore, INSTPM, val);
- intel_uncore_posting_read(&dev_priv->uncore, INSTPM);
+ intel_de_write(dev_priv, INSTPM, val);
+ intel_de_posting_read(dev_priv, INSTPM);
} else {
return false;
}
@@ -269,20 +270,20 @@ static void vlv_get_fifo_size(struct intel_crtc_state
*crtc_state)
switch (pipe) {
case PIPE_A:
- dsparb = intel_uncore_read(&dev_priv->uncore, DSPARB);
- dsparb2 = intel_uncore_read(&dev_priv->uncore, DSPARB2);
+ dsparb = intel_de_read(dev_priv, DSPARB);
+ dsparb2 = intel_de_read(dev_priv, DSPARB2);
sprite0_start = VLV_FIFO_START(dsparb, dsparb2, 0, 0);
sprite1_start = VLV_FIFO_START(dsparb, dsparb2, 8, 4);
break;
case PIPE_B:
- dsparb = inte
[Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
uncore->lock only protects the forcewake domain itself,
not the register accesses.
uncore's _fw alternatives are for cases where the domains
are not needed because we are sure that they are already
awake.
So the move towards the uncore's _fw alternatives seems
right, however using the uncore-lock to protect the dsparb
registers seems an abuse of the uncore-lock.
Let's restore the previous individual lock and try to get
rid of the direct uncore accesses from the display code.
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20230308165859.235520-1-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
drivers/gpu/drm/i915/i915_driver.c| 1 +
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
b/drivers/gpu/drm/i915/display/i9xx_wm.c
index caef72d38798..8fe0b5c63d3a 100644
--- a/drivers/gpu/drm/i915/display/i9xx_wm.c
+++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
@@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
- /*
-* uncore.lock serves a double purpose here. It allows us to
-* use the less expensive I915_{READ,WRITE}_FW() functions, and
-* it protects the DSPARB registers from getting clobbered by
-* parallel updates from multiple pipes.
-*
-* intel_pipe_update_start() has already disabled interrupts
-* for us, so a plain spin_lock() is sufficient here.
-*/
- spin_lock(&uncore->lock);
+ spin_lock(&dev_priv->display.wm.dsparb_lock);
switch (crtc->pipe) {
case PIPE_A:
@@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
intel_uncore_posting_read_fw(uncore, DSPARB);
- spin_unlock(&uncore->lock);
+ spin_unlock(&dev_priv->display.wm.dsparb_lock);
}
#undef VLV_FIFO
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 0b5509f268a7..e4da8902c878 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -264,6 +264,9 @@ struct intel_wm {
*/
struct mutex wm_mutex;
+ /* protects DSPARB registers on pre-g4x/vlv/chv */
+ spinlock_t dsparb_lock;
+
bool ipc_enabled;
};
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 12b5296ee744..e90a0c0403a6 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->display.pps.mutex);
mutex_init(&dev_priv->display.hdcp.comp_mutex);
spin_lock_init(&dev_priv->display.dkl.phy_lock);
+ spin_lock_init(&dev_priv->display.wm.dsparb_lock);
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(&dev_priv->runtime_pm);
--
2.39.2
Re: [Intel-gfx] [PATCH 2/2] drm/i915/ips: Add i915_ips_false_color debugfs file
On Mon, 27 Mar 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Similar to FBC let's expose an debugfs file to control
> IPS false color. Enabling this provides an immediate visual
> feedback on whether IPS is working or not.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/hsw_ips.c| 58 ++-
> .../gpu/drm/i915/display/intel_display_core.h | 4 ++
> drivers/gpu/drm/i915/i915_reg.h | 3 +-
> 3 files changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
> b/drivers/gpu/drm/i915/display/hsw_ips.c
> index 47209c858c32..8eca0de065b6 100644
> --- a/drivers/gpu/drm/i915/display/hsw_ips.c
> +++ b/drivers/gpu/drm/i915/display/hsw_ips.c
> @@ -14,6 +14,7 @@ static void hsw_ips_enable(const struct intel_crtc_state
> *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + u32 val;
>
> if (!crtc_state->ips_enabled)
> return;
> @@ -26,10 +27,15 @@ static void hsw_ips_enable(const struct intel_crtc_state
> *crtc_state)
> drm_WARN_ON(&i915->drm,
> !(crtc_state->active_planes & ~BIT(PLANE_CURSOR)));
>
> + val = IPS_ENABLE;
> +
> + if (i915->display.ips.false_color)
> + val |= IPS_FALSE_COLOR;
> +
> if (IS_BROADWELL(i915)) {
> drm_WARN_ON(&i915->drm,
> snb_pcode_write(&i915->uncore, DISPLAY_IPS_CONTROL,
> - IPS_ENABLE | IPS_PCODE_CONTROL));
> + val | IPS_PCODE_CONTROL));
> /*
>* Quoting Art Runyan: "its not safe to expect any particular
>* value in IPS_CTL bit 31 after enabling IPS through the
> @@ -37,7 +43,7 @@ static void hsw_ips_enable(const struct intel_crtc_state
> *crtc_state)
>* so we need to just enable it and continue on.
>*/
> } else {
> - intel_de_write(i915, IPS_CTL, IPS_ENABLE);
> + intel_de_write(i915, IPS_CTL, val);
> /*
>* The bit only becomes 1 in the next vblank, so this wait here
>* is essentially intel_wait_for_vblank. If we don't have this
> @@ -268,6 +274,51 @@ void hsw_ips_get_config(struct intel_crtc_state
> *crtc_state)
> }
> }
>
> +static int hsw_ips_debugfs_false_color_get(void *data, u64 *val)
> +{
> + struct intel_crtc *crtc = data;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> +
> + *val = i915->display.ips.false_color;
> +
> + return 0;
> +}
> +
> +static int hsw_ips_debugfs_false_color_set(void *data, u64 val)
> +{
> + struct intel_crtc *crtc = data;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct intel_crtc_state *crtc_state;
> + int ret;
> +
> + ret = drm_modeset_lock(&crtc->base.mutex, NULL);
> + if (ret)
> + return ret;
> +
> + i915->display.ips.false_color = val;
> +
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> +
> + if (!crtc_state->hw.active)
> + goto unlock;
> +
> + if (crtc_state->uapi.commit &&
> + !try_wait_for_completion(&crtc_state->uapi.commit->hw_done))
> + goto unlock;
> +
> + hsw_ips_enable(crtc_state);
> +
> + unlock:
> + drm_modeset_unlock(&crtc->base.mutex);
> +
> + return ret;
> +}
> +
> +DEFINE_DEBUGFS_ATTRIBUTE(hsw_ips_debugfs_false_color_fops,
> + hsw_ips_debugfs_false_color_get,
> + hsw_ips_debugfs_false_color_set,
> + "%llu\n");
> +
> static int hsw_ips_debugfs_status_show(struct seq_file *m, void *unused)
> {
> struct intel_crtc *crtc = m->private;
> @@ -300,6 +351,9 @@ void hsw_ips_crtc_debugfs_add(struct intel_crtc *crtc)
> if (!hsw_crtc_supports_ips(crtc))
> return;
>
> + debugfs_create_file("i915_ips_false_color", 0644,
> crtc->base.debugfs_entry,
> + crtc, &hsw_ips_debugfs_false_color_fops);
> +
> debugfs_create_file("i915_ips_status", 0444, crtc->base.debugfs_entry,
> crtc, &hsw_ips_debugfs_status_fops);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index 0b5509f268a7..e36f88a39b86 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -418,6 +418,10 @@ struct intel_display {
> u32 state;
> } hti;
>
> + struct {
> + bool false_color;
> + } ips;
> +
> struct {
> struct i915_power_domains domains;
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f79e8a544f51..9362c42788ef 100644
> --- a/drivers/
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ips: Make IPS debugfs per-crtc
On Mon, 27 Mar 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> IPS is a per-pipe feature, so let's move the debugfs stuff
> under the crtc directory, and only register it when IPS
> is actually available.
>
> Signed-off-by: Ville Syrjälä
Yay!
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/hsw_ips.c| 15 +++
> drivers/gpu/drm/i915/display/hsw_ips.h| 3 +--
> .../gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
> 3 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
> b/drivers/gpu/drm/i915/display/hsw_ips.c
> index 2910f5d0f3e2..47209c858c32 100644
> --- a/drivers/gpu/drm/i915/display/hsw_ips.c
> +++ b/drivers/gpu/drm/i915/display/hsw_ips.c
> @@ -270,12 +270,10 @@ void hsw_ips_get_config(struct intel_crtc_state
> *crtc_state)
>
> static int hsw_ips_debugfs_status_show(struct seq_file *m, void *unused)
> {
> - struct drm_i915_private *i915 = m->private;
> + struct intel_crtc *crtc = m->private;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> intel_wakeref_t wakeref;
>
> - if (!HAS_IPS(i915))
> - return -ENODEV;
> -
> wakeref = intel_runtime_pm_get(&i915->runtime_pm);
>
> seq_printf(m, "Enabled by kernel parameter: %s\n",
> @@ -297,10 +295,11 @@ static int hsw_ips_debugfs_status_show(struct seq_file
> *m, void *unused)
>
> DEFINE_SHOW_ATTRIBUTE(hsw_ips_debugfs_status);
>
> -void hsw_ips_debugfs_register(struct drm_i915_private *i915)
> +void hsw_ips_crtc_debugfs_add(struct intel_crtc *crtc)
> {
> - struct drm_minor *minor = i915->drm.primary;
> + if (!hsw_crtc_supports_ips(crtc))
> + return;
>
> - debugfs_create_file("i915_ips_status", 0444, minor->debugfs_root,
> - i915, &hsw_ips_debugfs_status_fops);
> + debugfs_create_file("i915_ips_status", 0444, crtc->base.debugfs_entry,
> + crtc, &hsw_ips_debugfs_status_fops);
> }
> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.h
> b/drivers/gpu/drm/i915/display/hsw_ips.h
> index 7ed6061874f7..4eb83b350791 100644
> --- a/drivers/gpu/drm/i915/display/hsw_ips.h
> +++ b/drivers/gpu/drm/i915/display/hsw_ips.h
> @@ -8,7 +8,6 @@
>
> #include
>
> -struct drm_i915_private;
> struct intel_atomic_state;
> struct intel_crtc;
> struct intel_crtc_state;
> @@ -23,6 +22,6 @@ bool hsw_crtc_state_ips_capable(const struct
> intel_crtc_state *crtc_state);
> int hsw_ips_compute_config(struct intel_atomic_state *state,
> struct intel_crtc *crtc);
> void hsw_ips_get_config(struct intel_crtc_state *crtc_state);
> -void hsw_ips_debugfs_register(struct drm_i915_private *i915);
> +void hsw_ips_crtc_debugfs_add(struct intel_crtc *crtc);
>
> #endif /* __HSW_IPS_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index cc5026272558..d5715ccc37f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1092,7 +1092,6 @@ void intel_display_debugfs_register(struct
> drm_i915_private *i915)
>ARRAY_SIZE(intel_display_debugfs_list),
>minor->debugfs_root, minor);
>
> - hsw_ips_debugfs_register(i915);
> intel_dmc_debugfs_register(i915);
> intel_fbc_debugfs_register(i915);
> intel_hpd_debugfs_register(i915);
> @@ -1461,6 +1460,7 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
> crtc_updates_add(crtc);
> intel_drrs_crtc_debugfs_add(crtc);
> intel_fbc_crtc_debugfs_add(crtc);
> + hsw_ips_crtc_debugfs_add(crtc);
>
> debugfs_create_file("i915_current_bpc", 0444, root, crtc,
> &i915_current_bpc_fops);
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for vfio: Make emulated devices prepared for vfio device cdev (rev4)
== Series Details ==
Series: vfio: Make emulated devices prepared for vfio device cdev (rev4)
URL : https://patchwork.freedesktop.org/series/114846/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12918_full -> Patchwork_114846v4_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114846v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_plane@plane-position-hole-dpms@pipe-b-planes:
- {shard-dg1}:NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-dg1-18/igt@kms_plane@plane-position-hole-d...@pipe-b-planes.html
Known issues
Here are the changes found in Patchwork_114846v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@i915_selftest@live@sanitycheck:
- shard-snb: [PASS][4] -> [ABORT][5] ([i915#4528])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-snb4/igt@i915_selftest@l...@sanitycheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-snb2/igt@i915_selftest@l...@sanitycheck.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#72])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#2346]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a1:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#79])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-glk9/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-glk3/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a1.html
Possible fixes
* igt@api_intel_bb@object-reloc-keep-cache:
- {shard-rkl}:[SKIP][12] ([i915#3281]) -> [PASS][13] +5 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-rkl-3/igt@api_intel...@object-reloc-keep-cache.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-rkl-5/igt@api_intel...@object-reloc-keep-cache.html
* igt@fbdev@unaligned-read:
- {shard-rkl}:[SKIP][14] ([i915#2582]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-rkl-3/igt@fb...@unaligned-read.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-rkl-6/igt@fb...@unaligned-read.html
* igt@gem_eio@hibernate:
- {shard-tglu}: [ABORT][16] ([i915#7975]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-tglu-10/igt@gem_...@hibernate.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-tglu-8/igt@gem_...@hibernate.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- {shard-rkl}:[SKIP][20] ([fdo#109313]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/shard-rkl-3/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/shard-rkl-5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
* igt@gen9_exec_parse@batch-zero-length:
- {shard-rkl}:[SKIP][22] ([i915#2527]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tre
Re: [Intel-gfx] [PATCH 1/2] [core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN""
On Mon, Mar 27, 2023 at 01:53:29PM +0300, Jani Nikula wrote: > This reverts commit 211c4b0aba30d2eab9690ad61944c7bf20b33c16. > > Drop the commit from the topic/core-for-CI branch. We no longer need to > select BROKEN to enable DRM_I915_UNSTABLE. > > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: Tvrtko Ursulin > Signed-off-by: Jani Nikula Acked-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/Kconfig.debug | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 93dfb7ed9705..47e845353ffa 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -40,7 +40,6 @@ config DRM_I915_DEBUG > select DRM_I915_DEBUG_RUNTIME_PM > select DRM_I915_SW_FENCE_DEBUG_OBJECTS > select DRM_I915_SELFTEST > - select BROKEN # for prototype uAPI > default n > help > Choose this option to turn on extra driver debugging that may affect > -- > 2.39.2 >
Re: [Intel-gfx] [PATCH 2/2] drm/i915: remove unused config DRM_I915_UNSTABLE
On Mon, Mar 27, 2023 at 01:53:30PM +0300, Jani Nikula wrote:
> Essentially this is a revert of commit d9d54a530a70 ("drm/i915: Put
> future HW and their uAPIs under STAGING & BROKEN").
>
> We currently have no users for this config option. The last one was
> removed in 8c26491f5853 ("drm/i915: Kill the fake lmem support"). Drop
> it altogether; it's easy enough to resurrect if need arises.
>
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Kconfig | 6 --
> drivers/gpu/drm/i915/Kconfig.unstable | 21 -
> 2 files changed, 27 deletions(-)
> delete mode 100644 drivers/gpu/drm/i915/Kconfig.unstable
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 98f4e44976e0..06a0ca157e89 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -164,11 +164,5 @@ menu "drm/i915 Profile Guided Optimisation"
> source "drivers/gpu/drm/i915/Kconfig.profile"
> endmenu
>
> -menu "drm/i915 Unstable Evolution"
> - visible if EXPERT && STAGING && BROKEN
> - depends on DRM_I915
> - source "drivers/gpu/drm/i915/Kconfig.unstable"
> -endmenu
> -
> config DRM_I915_GVT
> bool
> diff --git a/drivers/gpu/drm/i915/Kconfig.unstable
> b/drivers/gpu/drm/i915/Kconfig.unstable
> deleted file mode 100644
> index cf151a297ed7..
> --- a/drivers/gpu/drm/i915/Kconfig.unstable
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> -config DRM_I915_UNSTABLE
> - bool "Enable unstable API for early prototype development"
> - depends on EXPERT
> - depends on STAGING
> - depends on BROKEN # should never be enabled by distros!
> - # We use the dependency on !COMPILE_TEST to not be enabled in
> - # allmodconfig or allyesconfig configurations
> - depends on !COMPILE_TEST
> - default n
> - help
> - Enable prototype uAPI under general discussion before they are
> - finalized. Such prototypes may be withdrawn or substantially
> - changed before release. They are only enabled here so that a wide
> - number of interested parties (userspace driver developers) can
> - verify that the uAPI meet their expectations. These uAPI should
> - never be used in production.
> -
> - Recommended for driver developers _only_.
> -
> - If in the slightest bit of doubt, say "N".
> --
> 2.39.2
>
[Intel-gfx] [PATCH 2/2] drm/i915/ips: Add i915_ips_false_color debugfs file
From: Ville Syrjälä
Similar to FBC let's expose an debugfs file to control
IPS false color. Enabling this provides an immediate visual
feedback on whether IPS is working or not.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/hsw_ips.c| 58 ++-
.../gpu/drm/i915/display/intel_display_core.h | 4 ++
drivers/gpu/drm/i915/i915_reg.h | 3 +-
3 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
b/drivers/gpu/drm/i915/display/hsw_ips.c
index 47209c858c32..8eca0de065b6 100644
--- a/drivers/gpu/drm/i915/display/hsw_ips.c
+++ b/drivers/gpu/drm/i915/display/hsw_ips.c
@@ -14,6 +14,7 @@ static void hsw_ips_enable(const struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ u32 val;
if (!crtc_state->ips_enabled)
return;
@@ -26,10 +27,15 @@ static void hsw_ips_enable(const struct intel_crtc_state
*crtc_state)
drm_WARN_ON(&i915->drm,
!(crtc_state->active_planes & ~BIT(PLANE_CURSOR)));
+ val = IPS_ENABLE;
+
+ if (i915->display.ips.false_color)
+ val |= IPS_FALSE_COLOR;
+
if (IS_BROADWELL(i915)) {
drm_WARN_ON(&i915->drm,
snb_pcode_write(&i915->uncore, DISPLAY_IPS_CONTROL,
- IPS_ENABLE | IPS_PCODE_CONTROL));
+ val | IPS_PCODE_CONTROL));
/*
* Quoting Art Runyan: "its not safe to expect any particular
* value in IPS_CTL bit 31 after enabling IPS through the
@@ -37,7 +43,7 @@ static void hsw_ips_enable(const struct intel_crtc_state
*crtc_state)
* so we need to just enable it and continue on.
*/
} else {
- intel_de_write(i915, IPS_CTL, IPS_ENABLE);
+ intel_de_write(i915, IPS_CTL, val);
/*
* The bit only becomes 1 in the next vblank, so this wait here
* is essentially intel_wait_for_vblank. If we don't have this
@@ -268,6 +274,51 @@ void hsw_ips_get_config(struct intel_crtc_state
*crtc_state)
}
}
+static int hsw_ips_debugfs_false_color_get(void *data, u64 *val)
+{
+ struct intel_crtc *crtc = data;
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+ *val = i915->display.ips.false_color;
+
+ return 0;
+}
+
+static int hsw_ips_debugfs_false_color_set(void *data, u64 val)
+{
+ struct intel_crtc *crtc = data;
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ struct intel_crtc_state *crtc_state;
+ int ret;
+
+ ret = drm_modeset_lock(&crtc->base.mutex, NULL);
+ if (ret)
+ return ret;
+
+ i915->display.ips.false_color = val;
+
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
+ if (!crtc_state->hw.active)
+ goto unlock;
+
+ if (crtc_state->uapi.commit &&
+ !try_wait_for_completion(&crtc_state->uapi.commit->hw_done))
+ goto unlock;
+
+ hsw_ips_enable(crtc_state);
+
+ unlock:
+ drm_modeset_unlock(&crtc->base.mutex);
+
+ return ret;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(hsw_ips_debugfs_false_color_fops,
+hsw_ips_debugfs_false_color_get,
+hsw_ips_debugfs_false_color_set,
+"%llu\n");
+
static int hsw_ips_debugfs_status_show(struct seq_file *m, void *unused)
{
struct intel_crtc *crtc = m->private;
@@ -300,6 +351,9 @@ void hsw_ips_crtc_debugfs_add(struct intel_crtc *crtc)
if (!hsw_crtc_supports_ips(crtc))
return;
+ debugfs_create_file("i915_ips_false_color", 0644,
crtc->base.debugfs_entry,
+ crtc, &hsw_ips_debugfs_false_color_fops);
+
debugfs_create_file("i915_ips_status", 0444, crtc->base.debugfs_entry,
crtc, &hsw_ips_debugfs_status_fops);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 0b5509f268a7..e36f88a39b86 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -418,6 +418,10 @@ struct intel_display {
u32 state;
} hti;
+ struct {
+ bool false_color;
+ } ips;
+
struct {
struct i915_power_domains domains;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f79e8a544f51..9362c42788ef 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1397,7 +1397,8 @@
#define IVB_FBC_RT_BASE_UPPER _MMIO(0x7024)
#define IPS_CTL_MMIO(0x43408)
-#define IPS_ENABLE (1
[Intel-gfx] [PATCH 1/2] drm/i915/ips: Make IPS debugfs per-crtc
From: Ville Syrjälä
IPS is a per-pipe feature, so let's move the debugfs stuff
under the crtc directory, and only register it when IPS
is actually available.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/hsw_ips.c| 15 +++
drivers/gpu/drm/i915/display/hsw_ips.h| 3 +--
.../gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
b/drivers/gpu/drm/i915/display/hsw_ips.c
index 2910f5d0f3e2..47209c858c32 100644
--- a/drivers/gpu/drm/i915/display/hsw_ips.c
+++ b/drivers/gpu/drm/i915/display/hsw_ips.c
@@ -270,12 +270,10 @@ void hsw_ips_get_config(struct intel_crtc_state
*crtc_state)
static int hsw_ips_debugfs_status_show(struct seq_file *m, void *unused)
{
- struct drm_i915_private *i915 = m->private;
+ struct intel_crtc *crtc = m->private;
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
intel_wakeref_t wakeref;
- if (!HAS_IPS(i915))
- return -ENODEV;
-
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
seq_printf(m, "Enabled by kernel parameter: %s\n",
@@ -297,10 +295,11 @@ static int hsw_ips_debugfs_status_show(struct seq_file
*m, void *unused)
DEFINE_SHOW_ATTRIBUTE(hsw_ips_debugfs_status);
-void hsw_ips_debugfs_register(struct drm_i915_private *i915)
+void hsw_ips_crtc_debugfs_add(struct intel_crtc *crtc)
{
- struct drm_minor *minor = i915->drm.primary;
+ if (!hsw_crtc_supports_ips(crtc))
+ return;
- debugfs_create_file("i915_ips_status", 0444, minor->debugfs_root,
- i915, &hsw_ips_debugfs_status_fops);
+ debugfs_create_file("i915_ips_status", 0444, crtc->base.debugfs_entry,
+ crtc, &hsw_ips_debugfs_status_fops);
}
diff --git a/drivers/gpu/drm/i915/display/hsw_ips.h
b/drivers/gpu/drm/i915/display/hsw_ips.h
index 7ed6061874f7..4eb83b350791 100644
--- a/drivers/gpu/drm/i915/display/hsw_ips.h
+++ b/drivers/gpu/drm/i915/display/hsw_ips.h
@@ -8,7 +8,6 @@
#include
-struct drm_i915_private;
struct intel_atomic_state;
struct intel_crtc;
struct intel_crtc_state;
@@ -23,6 +22,6 @@ bool hsw_crtc_state_ips_capable(const struct intel_crtc_state
*crtc_state);
int hsw_ips_compute_config(struct intel_atomic_state *state,
struct intel_crtc *crtc);
void hsw_ips_get_config(struct intel_crtc_state *crtc_state);
-void hsw_ips_debugfs_register(struct drm_i915_private *i915);
+void hsw_ips_crtc_debugfs_add(struct intel_crtc *crtc);
#endif /* __HSW_IPS_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index cc5026272558..d5715ccc37f0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1092,7 +1092,6 @@ void intel_display_debugfs_register(struct
drm_i915_private *i915)
ARRAY_SIZE(intel_display_debugfs_list),
minor->debugfs_root, minor);
- hsw_ips_debugfs_register(i915);
intel_dmc_debugfs_register(i915);
intel_fbc_debugfs_register(i915);
intel_hpd_debugfs_register(i915);
@@ -1461,6 +1460,7 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
crtc_updates_add(crtc);
intel_drrs_crtc_debugfs_add(crtc);
intel_fbc_crtc_debugfs_add(crtc);
+ hsw_ips_crtc_debugfs_add(crtc);
debugfs_create_file("i915_current_bpc", 0444, root, crtc,
&i915_current_bpc_fops);
--
2.39.2
Re: [Intel-gfx] [PATCH 24/29] drm/i915/tc: Don't connect the PHY in intel_tc_port_connected()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:21 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 24/29] drm/i915/tc: Don't connect the PHY in
> intel_tc_port_connected()
>
> Connecting the PHY for connector probing - also blocking TC-cold - isn't
> required
> and has some overhead. Taking only the mutex is sufficient, so do that.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 08a23ab081d74..f202ba324fd0a 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -1235,20 +1235,25 @@ bool intel_tc_port_connected_locked(struct
> intel_encoder *encoder)
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> struct intel_tc_port *tc = to_tc_port(dig_port);
> + u32 mask = ~0;
>
> drm_WARN_ON(&i915->drm, !intel_tc_port_ref_held(dig_port));
>
> - return tc_phy_hpd_live_status(tc) & BIT(tc->mode);
> + if (tc->mode != TC_PORT_DISCONNECTED)
> + mask = BIT(tc->mode);
> +
> + return tc_phy_hpd_live_status(tc) & mask;
> }
>
> bool intel_tc_port_connected(struct intel_encoder *encoder) {
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> + struct intel_tc_port *tc = to_tc_port(dig_port);
> bool is_connected;
>
> - intel_tc_port_lock(dig_port);
> + mutex_lock(&tc->lock);
> is_connected = intel_tc_port_connected_locked(encoder);
> - intel_tc_port_unlock(dig_port);
> + mutex_unlock(&tc->lock);
>
> return is_connected;
> }
> --
> 2.37.1
Re: [Intel-gfx] [core-for-CI] x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: maanantai 27. maaliskuuta 2023 15.11
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [core-for-CI] x86/topology: fix erroneous
> smp_num_siblings on
> Intel Hybrid platform
>
> From: Zhang Rui
>
> The SMT siblings value returned by CPUID.1F SMT level EBX differs among CPUs
> on
> Intel Hybrid platforms like AlderLake and MeteorLake.
> It returns 2 for Pcore CPUs which have SMT siblings and returns 1 for Ecore
> CPUs
> which do not have SMT siblings.
>
> Today, the CPU boot code sets the global variable smp_num_siblings when every
> CPU thread is brought up. The last thread to boot will overwrite it with the
> number
> of siblings of *that* thread. That last thread to boot will "win". If the
> thread is a
> Pcore, smp_num_siblings == 2. If it is an Ecore, smp_num_siblings == 1.
>
> smp_num_siblings describes if the *system* supports SMT. It should specify
> the
> maximum number of SMT threads among all cores.
>
> Ensure that smp_num_siblings represents the system-wide maximum number of
> siblings by always increasing its value. Never allow it to decrease.
>
> On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are not
> updated
> in any cpu sibling map because the system is treated as an UP system when
> probing
> Ecore CPUs.
>
> Below shows part of the CPU topology information before and after the fix,
> for both
> Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore).
Tested-By: Jani Saarinen on local MTL setup. Also
tested earlier on other CI systems
by: https://patchwork.freedesktop.org/series/115601/ trybot series.
For this there is https://gitlab.freedesktop.org/drm/intel/-/issues/8317
Br,
Jani
> ...
> -/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff
> -/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11
> +/sys/devices/system/cpu/cpu0/topology/package_cpus:3f
> +/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21
> ...
> -/sys/devices/system/cpu/cpu12/topology/package_cpus:001000
> -/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12
> +/sys/devices/system/cpu/cpu12/topology/package_cpus:3f
> +/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21
>
> And this also breaks userspace tools like lscpu
> -Core(s) per socket: 1
> -Socket(s): 11
> +Core(s) per socket: 16
> +Socket(s): 1
>
> CC: sta...@kernel.org
> Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detecting
> cpu
> topology")
> Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide
> detect_extended_topology_early()")
> Suggested-by: Len Brown
> Signed-off-by: Zhang Rui
> Acked-by: Peter Zijlstra (Intel)
> [Imre: resend for core-for-CI]
> References: https://lore.kernel.org/lkml/20230323015640.27906-1-
> rui.zh...@intel.com
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8317
> Signed-off-by: Imre Deak
> ---
> arch/x86/kernel/cpu/topology.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
> index
> 5e868b62a7c4e..0270925fe013b 100644
> --- a/arch/x86/kernel/cpu/topology.c
> +++ b/arch/x86/kernel/cpu/topology.c
> @@ -79,7 +79,7 @@ int detect_extended_topology_early(struct cpuinfo_x86 *c)
>* initial apic id, which also represents 32-bit extended x2apic id.
>*/
> c->initial_apicid = edx;
> - smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
> + smp_num_siblings = max_t(int, smp_num_siblings,
> +LEVEL_MAX_SIBLINGS(ebx));
> #endif
> return 0;
> }
> @@ -109,7 +109,8 @@ int detect_extended_topology(struct cpuinfo_x86 *c)
>*/
> cpuid_count(leaf, SMT_LEVEL, &eax, &ebx, &ecx, &edx);
> c->initial_apicid = edx;
> - core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
> + core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
> + smp_num_siblings = max_t(int, smp_num_siblings,
> +LEVEL_MAX_SIBLINGS(ebx));
> core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
> die_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
> pkg_mask_width = die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
> --
> 2.37.2
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN""
== Series Details == Series: series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN"" URL : https://patchwork.freedesktop.org/series/115659/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12918 -> Patchwork_115659v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115659v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115659v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v1/index.html Participating hosts (37 -> 36) -- Missing(1): fi-kbl-soraka Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115659v1: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@module-reload: - bat-dg2-11: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/bat-dg2-11/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v1/bat-dg2-11/igt@i915_pm_...@module-reload.html Known issues Here are the changes found in Patchwork_115659v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-2: [PASS][3] -> [ABORT][4] ([i915#7978]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v1/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-kbl-8809g: NOTRUN -> [SKIP][5] ([fdo#109271]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v1/fi-kbl-8809g/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@i915_suspend@basic-s2idle-without-i915: - fi-kbl-8809g: [ABORT][6] -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/fi-kbl-8809g/igt@i915_susp...@basic-s2idle-without-i915.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v1/fi-kbl-8809g/igt@i915_susp...@basic-s2idle-without-i915.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][8] ([i915#6997] / [i915#7913]) -> [DMESG-FAIL][9] ([i915#6367] / [i915#7913] / [i915#7996]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/bat-rpls-2/igt@i915_selftest@l...@slpc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_12918 -> Patchwork_115659v1 CI-20190529: 20190529 CI_DRM_12918: a1cb2211899ba6b8fe078586d0878aa918a5aab3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7220: 3eb7beb5c03343b29556025b1ada4b50849b5976 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115659v1: a1cb2211899ba6b8fe078586d0878aa918a5aab3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 187edd7e465b drm/i915: remove unused config DRM_I915_UNSTABLE 362d096f27db Revert "Revert "drm/i915: Don't select BROKEN"" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115659v1/index.html
Re: [Intel-gfx] [PATCH 23/29] drm/i915/tc: Get power ref for reading the HPD live status register
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 23/29] drm/i915/tc: Get power ref for reading the
> HPD live status register
>
> Enable the power required for the HPD live status register access instead of
> depending on the caller blocking the TC-cold power state (during HW readout
> and connector probing).
>
> A follow up patch will remove connecting/disconnecting the PHY around
> connector probing, so querying the HPD status can happen in this case without
> TC-cold being blocked.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 27 +
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 3122f7ce8c9a0..08a23ab081d74 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -411,24 +411,29 @@ static u32 icl_tc_phy_hpd_live_status(struct
> intel_tc_port *tc)
> struct drm_i915_private *i915 = tc_to_i915(tc);
> struct intel_digital_port *dig_port = tc->dig_port;
> u32 isr_bit = i915->display.hotplug.pch_hpd[dig_port->base.hpd_pin];
> + intel_wakeref_t wakeref;
> + u32 fia_isr;
> + u32 pch_isr;
> u32 mask = 0;
> - u32 val;
>
> - val = intel_de_read(i915, PORT_TX_DFLEXDPSP(tc->phy_fia));
> + with_intel_display_power(i915, tc_phy_cold_off_domain(tc), wakeref) {
> + fia_isr = intel_de_read(i915, PORT_TX_DFLEXDPSP(tc-
> >phy_fia));
> + pch_isr = intel_de_read(i915, SDEISR);
> + }
>
> - if (val == 0x) {
> + if (fia_isr == 0x) {
> drm_dbg_kms(&i915->drm,
> "Port %s: PHY in TCCOLD, nothing connected\n",
> tc->port_name);
> return mask;
> }
>
> - if (val & TC_LIVE_STATE_TBT(tc->phy_fia_idx))
> + if (fia_isr & TC_LIVE_STATE_TBT(tc->phy_fia_idx))
> mask |= BIT(TC_PORT_TBT_ALT);
> - if (val & TC_LIVE_STATE_TC(tc->phy_fia_idx))
> + if (fia_isr & TC_LIVE_STATE_TC(tc->phy_fia_idx))
> mask |= BIT(TC_PORT_DP_ALT);
>
> - if (intel_de_read(i915, SDEISR) & isr_bit)
> + if (pch_isr & isr_bit)
> mask |= BIT(TC_PORT_LEGACY);
>
> return mask;
> @@ -691,16 +696,22 @@ static u32 adlp_tc_phy_hpd_live_status(struct
> intel_tc_port *tc)
> enum hpd_pin hpd_pin = dig_port->base.hpd_pin;
> u32 cpu_isr_bits = i915->display.hotplug.hpd[hpd_pin];
> u32 pch_isr_bit = i915->display.hotplug.pch_hpd[hpd_pin];
> + intel_wakeref_t wakeref;
> u32 cpu_isr;
> + u32 pch_isr;
> u32 mask = 0;
>
> - cpu_isr = intel_de_read(i915, GEN11_DE_HPD_ISR);
> + with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> wakeref) {
> + cpu_isr = intel_de_read(i915, GEN11_DE_HPD_ISR);
> + pch_isr = intel_de_read(i915, SDEISR);
> + }
> +
> if (cpu_isr & (cpu_isr_bits & GEN11_DE_TC_HOTPLUG_MASK))
> mask |= BIT(TC_PORT_DP_ALT);
> if (cpu_isr & (cpu_isr_bits & GEN11_DE_TBT_HOTPLUG_MASK))
> mask |= BIT(TC_PORT_TBT_ALT);
>
> - if (intel_de_read(i915, SDEISR) & pch_isr_bit)
> + if (pch_isr & pch_isr_bit)
> mask |= BIT(TC_PORT_LEGACY);
>
> return mask;
> --
> 2.37.1
[Intel-gfx] [PATCH 6/7] drm/i915/mtl: Add vswing programming for C10 phys
From: Radhakrishna Sripada
C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.
Bspec: 65449
v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1
and preemphasis 1 instead of two times of level 1 preemphasis 0.
Fix this in the driver code as well.
v3: VSwing update (Clint)
Cc: Imre Deak
Cc: Uma Shankar
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 140 --
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 14 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
.../drm/i915/display/intel_ddi_buf_trans.c| 31 +++-
.../drm/i915/display/intel_ddi_buf_trans.h| 6 +
.../i915/display/intel_display_power_map.c| 1 +
7 files changed, 187 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 3aa8031f8373..fb54f56ac5ef 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -6,11 +6,15 @@
#include "i915_reg.h"
#include "intel_cx0_phy.h"
#include "intel_cx0_phy_regs.h"
+#include "intel_ddi.h"
+#include "intel_ddi_buf_trans.h"
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_panel.h"
+#include "intel_psr.h"
#include "intel_tc.h"
+#include "intel_uncore.h"
bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
{
@@ -20,6 +24,15 @@ bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum
phy phy)
return false;
}
+static void
+assert_dc_off(struct drm_i915_private *i915)
+{
+ bool enabled;
+
+ enabled = intel_display_power_is_enabled(i915, POWER_DOMAIN_DC_OFF);
+ drm_WARN_ON(&i915->drm, !enabled);
+}
+
static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port,
int lane)
{
enum phy phy = intel_port_to_phy(i915, port);
@@ -112,6 +125,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915,
enum port port,
int i, status = 0;
u32 val;
+ assert_dc_off(i915);
+
for (i = 0; i < 3; i++) {
status = __intel_cx0_read(i915, port, lane, addr, &val);
@@ -194,6 +209,8 @@ static void __intel_cx0_write(struct drm_i915_private
*i915, enum port port,
enum phy phy = intel_port_to_phy(i915, port);
int i, status;
+ assert_dc_off(i915);
+
for (i = 0; i < 3; i++) {
status = __intel_cx0_write_once(i915, port, lane, addr, data,
committed);
@@ -241,6 +258,89 @@ static void intel_cx0_rmw(struct drm_i915_private *i915,
enum port port,
}
}
+/*
+ * Prepare HW for CX0 phy transactions.
+ *
+ * It is required that PSR and DC5/6 are disabled before any CX0 message
+ * bus transaction is executed.
+ */
+static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder
*encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ intel_psr_pause(intel_dp);
+ return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
+}
+
+static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder,
intel_wakeref_t wakeref)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ intel_psr_resume(intel_dp);
+ intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
+}
+
+void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+ bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+ u8 master_lane = lane_reversal ? INTEL_CX0_LANE1 :
+INTEL_CX0_LANE0;
+ u8 follower_lane = lane_reversal ? INTEL_CX0_LANE0 :
+ INTEL_CX0_LANE1;
+ const struct intel_ddi_buf_trans *trans;
+ intel_wakeref_t wakeref;
+ int n_entries, ln;
+
+ wakeref = intel_cx0_phy_transaction_begin(encoder);
+
+ trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
+ if (drm_WARN_ON_ONCE(&i915->drm, !trans))
+ return;
+
+ intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES,
PHY_C10_VDR_CONTROL(1),
+ 0, C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);
+
+ for (ln = 0; ln < 4; ln++) {
+ int level = intel_ddi_level(encoder, crtc_state, ln);
+ int lane, tx;
+
+ lane = ln / 2;
+ tx = ln % 2 + 1;
+
+ i
[Intel-gfx] [PATCH 7/7] drm/i915/mtl: Add support for PM DEMAND
Display14 introduces a new way to instruct the PUnit with
power and bandwidth requirements of DE. Add the functionality
to program the registers and handle waits using interrupts.
The current wait time for timeouts is programmed for 10 msecs to
factor in the worst case scenarios. Changes made to use REG_BIT
for a register that we touched(GEN8_DE_MISC_IER _MMIO).
v2:
- Removed repeated definition of dbuf, which has been moved to struct
intel_display. (Gustavo)
- s/dev_priv->dbuf/dev_priv->display.dbuf/ (Gustavo)
Bspec: 66451, 64636, 64602, 64603
Cc: Matt Atwood
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Gustavo Sousa
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
drivers/gpu/drm/i915/display/intel_bw.h | 2 +
drivers/gpu/drm/i915/display/intel_display.c | 14 +
.../drm/i915/display/intel_display_power.c| 8 +
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/i915_irq.c | 22 +-
drivers/gpu/drm/i915/i915_reg.h | 33 +-
drivers/gpu/drm/i915/intel_pm.c | 286 ++
drivers/gpu/drm/i915/intel_pm.h | 35 +++
9 files changed, 405 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 202321ffbe2a..87c20bf52123 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -746,8 +746,8 @@ static unsigned int intel_bw_num_active_planes(struct
drm_i915_private *dev_priv
return num_active_planes;
}
-static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
- const struct intel_bw_state *bw_state)
+unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
+ const struct intel_bw_state *bw_state)
{
unsigned int data_rate = 0;
enum pipe pipe;
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index f20292143745..17fc0b61db04 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
int intel_bw_atomic_check(struct intel_atomic_state *state);
void intel_bw_crtc_update(struct intel_bw_state *bw_state,
const struct intel_crtc_state *crtc_state);
+unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
+ const struct intel_bw_state *bw_state);
int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
u32 points_mask);
int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 9fe6e33a66d6..3a9d71c80d5c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -959,6 +959,9 @@ intel_get_crtc_new_encoder(const struct intel_atomic_state
*state,
num_encoders++;
}
+ if (!encoder)
+ return NULL;
+
drm_WARN(encoder->base.dev, num_encoders != 1,
"%d encoders for pipe %c\n",
num_encoders, pipe_name(master_crtc->pipe));
@@ -6767,6 +6770,10 @@ int intel_atomic_check(struct drm_device *dev,
ret = intel_modeset_calc_cdclk(state);
if (ret)
return ret;
+
+ ret = intel_pmdemand_atomic_check(state);
+ if (ret)
+ goto fail;
}
ret = intel_atomic_check_crtcs(state);
@@ -7405,6 +7412,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
}
intel_sagv_pre_plane_update(state);
+ intel_pmdemand_pre_plane_update(state);
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -7517,6 +7525,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_verify_planes(state);
intel_sagv_post_plane_update(state);
+ intel_pmdemand_post_plane_update(state);
drm_atomic_helper_commit_hw_done(&state->base);
@@ -8248,6 +8257,7 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
intel_color_init_hooks(dev_priv);
intel_init_cdclk_hooks(dev_priv);
intel_audio_hooks_init(dev_priv);
+ intel_init_pmdemand(dev_priv);
intel_dpll_init_clock_hook(dev_priv);
@@ -8474,6 +8484,10 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
if (ret)
goto cleanup_vga_client_pw_domain_dmc;
+ ret = intel_pmdemand_init(i915);
+ if (ret)
+ goto cleanup_vga_client_pw_domain_dmc;
[Intel-gfx] [PATCH 5/7] drm/i915/mtl: Add C10 phy programming for HDMI
From: Radhakrishna Sripada
Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
can, and also add some logic to hdmi_port_clock_valid() to filter the
modelist to just the modes we can actually support with these link
rates.
Hopefully we'll have a proper / non-encumbered algorithm to calculate
these registers by the time we upstream and we'll be able to replace
this patch with something more general purpose.
Bspec: 64568
v2: Rebasing with Clint's HDMI C10 PLL tables (Mika)
v3: Add missing use_hdmi checks from Clint's HDMI implementation changes (Ankit)
Cc: Imre Deak
Cc: Uma Shankar
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Clint Taylor
Signed-off-by: Mika Kahola
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 576 +-
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 1 +
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 13 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +-
4 files changed, 579 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index ced8c8aa6c82..3aa8031f8373 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -485,6 +485,538 @@ static const struct intel_c10mpllb_state * const
mtl_c10_edp_tables[] = {
NULL,
};
+/*
+ * HDMI link rates with 38.4 MHz reference clock.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_25_2 = {
+ .clock = 25200,
+ .pll[0] = 0x4,
+ .pll[1] = 0,
+ .pll[2] = 0xB2,
+ .pll[3] = 0,
+ .pll[4] = 0,
+ .pll[5] = 0,
+ .pll[6] = 0,
+ .pll[7] = 0,
+ .pll[8] = 0x20,
+ .pll[9] = 0x1,
+ .pll[10] = 0,
+ .pll[11] = 0,
+ .pll[12] = 0,
+ .pll[13] = 0,
+ .pll[14] = 0,
+ .pll[15] = 0xD,
+ .pll[16] = 0x6,
+ .pll[17] = 0x8F,
+ .pll[18] = 0x84,
+ .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_27_0 = {
+ .clock = 27000,
+ .pll[0] = 0x34,
+ .pll[1] = 0,
+ .pll[2] = 0xC0,
+ .pll[3] = 0,
+ .pll[4] = 0,
+ .pll[5] = 0,
+ .pll[6] = 0,
+ .pll[7] = 0,
+ .pll[8] = 0x20,
+ .pll[9] = 0x1,
+ .pll[10] = 0,
+ .pll[11] = 0,
+ .pll[12] = 0x80,
+ .pll[13] = 0,
+ .pll[14] = 0,
+ .pll[15] = 0xD,
+ .pll[16] = 0x6,
+ .pll[17] = 0xCF,
+ .pll[18] = 0x84,
+ .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_74_25 = {
+ .clock = 74250,
+ .pll[0] = 0xF4,
+ .pll[1] = 0,
+ .pll[2] = 0x7A,
+ .pll[3] = 0,
+ .pll[4] = 0,
+ .pll[5] = 0,
+ .pll[6] = 0,
+ .pll[7] = 0,
+ .pll[8] = 0x20,
+ .pll[9] = 0x1,
+ .pll[10] = 0,
+ .pll[11] = 0,
+ .pll[12] = 0x58,
+ .pll[13] = 0,
+ .pll[14] = 0,
+ .pll[15] = 0xB,
+ .pll[16] = 0x6,
+ .pll[17] = 0xF,
+ .pll[18] = 0x85,
+ .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_148_5 = {
+ .clock = 148500,
+ .pll[0] = 0xF4,
+ .pll[1] = 0,
+ .pll[2] = 0x7A,
+ .pll[3] = 0,
+ .pll[4] = 0,
+ .pll[5] = 0,
+ .pll[6] = 0,
+ .pll[7] = 0,
+ .pll[8] = 0x20,
+ .pll[9] = 0x1,
+ .pll[10] = 0,
+ .pll[11] = 0,
+ .pll[12] = 0x58,
+ .pll[13] = 0,
+ .pll[14] = 0,
+ .pll[15] = 0xA,
+ .pll[16] = 0x6,
+ .pll[17] = 0xF,
+ .pll[18] = 0x85,
+ .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_594 = {
+ .clock = 594000,
+ .pll[0] = 0xF4,
+ .pll[1] = 0,
+ .pll[2] = 0x7A,
+ .pll[3] = 0,
+ .pll[4] = 0,
+ .pll[5] = 0,
+ .pll[6] = 0,
+ .pll[7] = 0,
+ .pll[8] = 0x20,
+ .pll[9] = 0x1,
+ .pll[10] = 0,
+ .pll[11] = 0,
+ .pll[12] = 0x58,
+ .pll[13] = 0,
+ .pll[14] = 0,
+ .pll[15] = 0x8,
+ .pll[16] = 0x6,
+ .pll[17] = 0xF,
+ .pll[18] = 0x85,
+ .pll[19] = 0x23,
+};
+
+/* Precomputed C10 HDMI PLL tables */
+static const struct intel_c10mpllb_state mtl_c10_hdmi_25175 = {
+ .clock = 25175,
+ .pll[0]=0x34,
+ .pll[1]=0x00,
+ .pll[2]=0xB0,
+ .pll[3]=0x00,
+ .pll[4]=0x00,
+ .pll[5]=0x00,
+ .pll[6]=0x00,
+ .pll[7]=0x00,
+ .pll[8]=0x20,
+ .pll[9]=0xFF,
+ .pll[10]=0xFF,
+ .pll[11]=0x55,
+ .pll[12]=0xE5,
+ .pll[13]=0x55,
+ .pll[14]=0x55,
+ .pll[15]=0x0D,
+ .pll[16]=0x09,
+ .pll[17]=0x8F,
+ .pll[18]=0x84,
+ .pll[19]=0x23,
+};
+
+stat
[Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
From: Radhakrishna Sripada
XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
has a dedicated PIPE 5.2 Message bus for configuration. This message
bus is used to configure the phy internal registers.
XELPDP has C10 phys to drive output to the EDP and the native output
from the display engine. Add structures, programming hardware state
readout logic. Port clock calculations are similar to DG2. Use the DG2
formulae to calculate the port clock but use the relevant pll signals.
Note: PHY lane 0 is always used for PLL programming.
Add sequences for C10 phy enable/disable phy lane reset,
powerdown change sequence and phy lane programming.
Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636
v2: Squash patches related to C10 phy message bus and pll
programming support (Jani)
Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
Move macro definitions (Jani)
DP rates as separate patch (Jani)
Spin out xelpdp register definitions into a separate file (Jani)
Replace macro to select registers based on phy lane with
function calls (Jani)
Fix styling issues (Jani)
Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
v3: Move clear request flag into try-loop
v4: On PHY idle change drm_err_once() as drm_dbg_kms() (Jani)
use __intel_de_wait_for_register() instead of __intel_wait_for_register
and uncomment intel_uncore.h (Jani)
Add DP-alt support for PHY lane programming (Khaled)
Cc: Mika Kahola
Cc: Imre Deak
Cc: Uma Shankar
Cc: Gustavo Sousa
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 1120 +
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 43 +
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 32 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 22 +-
.../drm/i915/display/intel_display_power.c|3 +-
.../i915/display/intel_display_power_well.c |2 +-
.../drm/i915/display/intel_display_types.h|6 +
drivers/gpu/drm/i915/display/intel_dpll.c | 20 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
.../drm/i915/display/intel_modeset_verify.c |2 +
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/i915_reg_defs.h | 57 +
13 files changed, 1309 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 057ef22fa9c6..57b1417792b4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -298,6 +298,7 @@ i915-y += \
display/icl_dsi.o \
display/intel_backlight.o \
display/intel_crt.o \
+ display/intel_cx0_phy.o \
display/intel_ddi.o \
display/intel_ddi_buf_trans.o \
display/intel_display_trace.o \
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
new file mode 100644
index ..ced8c8aa6c82
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -0,0 +1,1120 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "i915_reg.h"
+#include "intel_cx0_phy.h"
+#include "intel_cx0_phy_regs.h"
+#include "intel_de.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_panel.h"
+#include "intel_tc.h"
+
+bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
+{
+ if (IS_METEORLAKE(dev_priv) && (phy < PHY_C))
+ return true;
+
+ return false;
+}
+
+static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port,
int lane)
+{
+ enum phy phy = intel_port_to_phy(i915, port);
+
+ /* Bring the phy to idle. */
+ intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane - 1),
+ XELPDP_PORT_M2P_TRANSACTION_RESET);
+
+ /* Wait for Idle Clear. */
+ if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane
- 1),
+ XELPDP_PORT_M2P_TRANSACTION_RESET,
+ XELPDP_MSGBUS_TIMEOUT_SLOW)) {
+ drm_dbg_kms(&i915->drm, "Failed to bring PHY %c to idle.\n",
phy_name(phy));
+ return;
+ }
+
+ intel_de_write(i915, XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane - 1), ~0);
+}
+
+static int intel_cx0_wait_for_ack(struct drm_i915_private *i915, enum port
port, int lane, u32 *val)
+{
+ enum phy phy = intel_port_to_phy(i915, port);
+
+ if (__intel_de_wait_for_register(i915,
+XELPDP_PORT_P2M_MSGBUS_STATUS(port,
lane - 1),
+XELPDP_PORT_P2M_RESPONSE_READY,
+XELPDP_PORT_P2M_RESPON
[Intel-gfx] [PATCH 3/7] drm/i915/mtl: Create separate reg file for PICA registers
Create a separate file to store registers for PICA chips C10 and C20. v2: Rename file (Jani) v3: Use _PICK_EVEN_2RANGES() macro (Lucas) Coding style fixed (Lucas) Signed-off-by: Radhakrishna Sripada Signed-off-by: Mika Kahola --- .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 131 ++ 1 file changed, 131 insertions(+) create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h new file mode 100644 index ..d1ee8a2fc9cf --- /dev/null +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h @@ -0,0 +1,131 @@ +/* SPDX-License-Identifier: MIT + * + * Copyright © 2022 Intel Corporation + */ + +#ifndef __INTEL_CX0_PHY_REGS_H__ +#define __INTEL_CX0_PHY_REGS_H__ + +#include "i915_reg_defs.h" + +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A 0x64040 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B 0x64140 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1 0x16F240 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2 0x16F440 +#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) _MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4) +#define XELPDP_PORT_M2P_TRANSACTION_PENDING REG_BIT(31) +#define XELPDP_PORT_M2P_COMMAND_TYPE_MASKREG_GENMASK(30, 27) +#define XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1) +#define XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2) +#define XELPDP_PORT_M2P_COMMAND_READ REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3) +#define XELPDP_PORT_M2P_DATA_MASKREG_GENMASK(23, 16) +#define XELPDP_PORT_M2P_DATA(val) REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val) +#define XELPDP_PORT_M2P_TRANSACTION_RESETREG_BIT(15) +#define XELPDP_PORT_M2P_ADDRESS_MASK REG_GENMASK(11, 0) +#define XELPDP_PORT_M2P_ADDRESS(val) REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val) +#define XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane) _MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \ + _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4 + 8) +#define XELPDP_PORT_P2M_RESPONSE_READY REG_BIT(31) +#define XELPDP_PORT_P2M_COMMAND_TYPE_MASKREG_GENMASK(30, 27) +#define XELPDP_PORT_P2M_COMMAND_READ_ACK 0x4 +#define XELPDP_PORT_P2M_COMMAND_WRITE_ACK0x5 +#define XELPDP_PORT_P2M_DATA_MASKREG_GENMASK(23, 16) +#define XELPDP_PORT_P2M_DATA(val) REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val) +#define XELPDP_PORT_P2M_ERROR_SETREG_BIT(15) + +#define XELPDP_MSGBUS_TIMEOUT_SLOW 1 +#define XELPDP_MSGBUS_TIMEOUT_FAST_US 2 +#define XELPDP_PCLK_PLL_ENABLE_TIMEOUT_US 3200 +#define XELPDP_PCLK_PLL_DISABLE_TIMEOUT_US 20 +#define XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US 100 +#define XELPDP_PORT_RESET_START_TIMEOUT_US 5 +#define XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US100 +#define XELPDP_PORT_RESET_END_TIMEOUT 15 +#define XELPDP_REFCLK_ENABLE_TIMEOUT_US1 + +#define _XELPDP_PORT_BUF_CTL1_LN0_A0x64004 +#define _XELPDP_PORT_BUF_CTL1_LN0_B0x64104 +#define _XELPDP_PORT_BUF_CTL1_LN0_USBC10x16F200 +#define _XELPDP_PORT_BUF_CTL1_LN0_USBC20x16F400 +#define XELPDP_PORT_BUF_CTL1(port) _MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, \ + _XELPDP_PORT_BUF_CTL1_LN0_A, \ + _XELPDP_PORT_BUF_CTL1_LN0_B, \ + _XELPDP_PORT_BUF_CTL1_LN0_USBC1,
[Intel-gfx] [PATCH 2/7] drm/i915/mtl: Add DP rates
Add DP rates for Meteorlake.
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index da1c00ee92fb..4927aeb64f23 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -420,6 +420,11 @@ static int ehl_max_source_rate(struct intel_dp *intel_dp)
return 81;
}
+static int mtl_max_source_rate(struct intel_dp *intel_dp)
+{
+ return intel_dp_is_edp(intel_dp) ? 675000 : 81;
+}
+
static int vbt_max_link_rate(struct intel_dp *intel_dp)
{
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
@@ -444,6 +449,10 @@ static void
intel_dp_set_source_rates(struct intel_dp *intel_dp)
{
/* The values must be in increasing order */
+ static const int mtl_rates[] = {
+ 162000, 216000, 243000, 27, 324000, 432000, 54, 675000,
+ 81,
+ };
static const int icl_rates[] = {
162000, 216000, 27, 324000, 432000, 54, 648000, 81,
100, 135,
@@ -469,7 +478,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
drm_WARN_ON(&dev_priv->drm,
intel_dp->source_rates || intel_dp->num_source_rates);
- if (DISPLAY_VER(dev_priv) >= 11) {
+ if (DISPLAY_VER(dev_priv) >= 14) {
+ source_rates = mtl_rates;
+ size = ARRAY_SIZE(mtl_rates);
+ max_rate = mtl_max_source_rate(intel_dp);
+ } else if (DISPLAY_VER(dev_priv) >= 11) {
source_rates = icl_rates;
size = ARRAY_SIZE(icl_rates);
if (IS_DG2(dev_priv))
--
2.34.1
[Intel-gfx] [PATCH 1/7] drm/i915/mtl: Initial DDI port setup
From: Clint Taylor
Initialization sequences and C10 phy are in place to be able to enable
the first 2 ports of MTL. The other ports use C20 phy that still need
to be properly added. Enable the first ports for now, keeping a TODO
comment about the others.
Cc: Radhakrishna Sripada
Reviewed-by: Lucas De Marchi
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a386c7c0bc9..9fe6e33a66d6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7796,7 +7796,11 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
- if (IS_DG2(dev_priv)) {
+ if (IS_METEORLAKE(dev_priv)) {
+ /* TODO: initialize TC ports as well */
+ intel_ddi_init(dev_priv, PORT_A);
+ intel_ddi_init(dev_priv, PORT_B);
+ } else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
intel_ddi_init(dev_priv, PORT_C);
--
2.34.1
[Intel-gfx] [PATCH 0/7] drm/i915/mtl: Add Support for C10 chips
Phy programming support for C10 PICA chips. This is the first part of the series that adds support for PICA chips. Later the support for C20 chips are added. Signed-off-by: Mika Kahola Clint Taylor (1): drm/i915/mtl: Initial DDI port setup Mika Kahola (3): drm/i915/mtl: Add DP rates drm/i915/mtl: Create separate reg file for PICA registers drm/i915/mtl: Add support for PM DEMAND Radhakrishna Sripada (3): drm/i915/mtl: Add Support for C10 PHY message bus and pll programming drm/i915/mtl: Add C10 phy programming for HDMI drm/i915/mtl: Add vswing programming for C10 phys drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/display/intel_bw.c |4 +- drivers/gpu/drm/i915/display/intel_bw.h |2 + drivers/gpu/drm/i915/display/intel_cx0_phy.c | 1798 + drivers/gpu/drm/i915/display/intel_cx0_phy.h | 46 + .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 178 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 26 +- .../drm/i915/display/intel_ddi_buf_trans.c| 31 +- .../drm/i915/display/intel_ddi_buf_trans.h|6 + drivers/gpu/drm/i915/display/intel_display.c | 20 +- .../drm/i915/display/intel_display_power.c| 11 +- .../i915/display/intel_display_power_map.c|1 + .../i915/display/intel_display_power_well.c |2 +- .../drm/i915/display/intel_display_types.h|6 + drivers/gpu/drm/i915/display/intel_dp.c | 15 +- drivers/gpu/drm/i915/display/intel_dpll.c | 20 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +- drivers/gpu/drm/i915/display/intel_hdmi.c |5 +- .../drm/i915/display/intel_modeset_verify.c |2 + drivers/gpu/drm/i915/i915_drv.h |6 + drivers/gpu/drm/i915/i915_irq.c | 22 +- drivers/gpu/drm/i915/i915_reg.h | 38 +- drivers/gpu/drm/i915/i915_reg_defs.h | 57 + drivers/gpu/drm/i915/intel_pm.c | 286 +++ drivers/gpu/drm/i915/intel_pm.h | 35 + 25 files changed, 2605 insertions(+), 15 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h -- 2.34.1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN""
== Series Details ==
Series: series starting with [1/2,core-for-CI] Revert "Revert "drm/i915: Don't
select BROKEN""
URL : https://patchwork.freedesktop.org/series/115659/
State : warning
== Summary ==
Error: dim checkpatch failed
90424153487a Revert "Revert "drm/i915: Don't select BROKEN""
a8ac1f2f356f drm/i915: remove unused config DRM_I915_UNSTABLE
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 8c26491f5853 ("drm/i915: Kill
the fake lmem support")'
#10:
removed in 8c26491f5853 ("drm/i915: Kill the fake lmem support"). Drop
-:35: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#35:
deleted file mode 100644
total: 1 errors, 1 warnings, 0 checks, 11 lines checked
Re: [Intel-gfx] [PATCH 22/29] drm/i915/adlp/tc: Use the DE HPD ISR register for hotplug detection
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 22/29] drm/i915/adlp/tc: Use the DE HPD ISR
> register for hotplug detection
>
> The spec says to use the CPU ISR registers for DP-alt/TBT HPD detection on
> ADLP, so do that instead of using the related IOM/TCSS registers.
>
> Bspec: 55480, 55482, 49212, 49305
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 8f159ded501f8..3122f7ce8c9a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -688,22 +688,19 @@ static u32 adlp_tc_phy_hpd_live_status(struct
> intel_tc_port *tc) {
> struct drm_i915_private *i915 = tc_to_i915(tc);
> struct intel_digital_port *dig_port = tc->dig_port;
> - enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> - u32 isr_bit = i915->display.hotplug.pch_hpd[dig_port->base.hpd_pin];
> - u32 val, mask = 0;
> + enum hpd_pin hpd_pin = dig_port->base.hpd_pin;
> + u32 cpu_isr_bits = i915->display.hotplug.hpd[hpd_pin];
> + u32 pch_isr_bit = i915->display.hotplug.pch_hpd[hpd_pin];
> + u32 cpu_isr;
> + u32 mask = 0;
>
> - /*
> - * On ADL-P HW/FW will wake from TCCOLD to complete the read
> access of
> - * registers in IOM. Note that this doesn't apply to PHY and FIA
> - * registers.
> - */
> - val = intel_de_read(i915, TCSS_DDI_STATUS(tc_port));
> - if (val & TCSS_DDI_STATUS_HPD_LIVE_STATUS_ALT)
> + cpu_isr = intel_de_read(i915, GEN11_DE_HPD_ISR);
> + if (cpu_isr & (cpu_isr_bits & GEN11_DE_TC_HOTPLUG_MASK))
> mask |= BIT(TC_PORT_DP_ALT);
> - if (val & TCSS_DDI_STATUS_HPD_LIVE_STATUS_TBT)
> + if (cpu_isr & (cpu_isr_bits & GEN11_DE_TBT_HOTPLUG_MASK))
> mask |= BIT(TC_PORT_TBT_ALT);
>
> - if (intel_de_read(i915, SDEISR) & isr_bit)
> + if (intel_de_read(i915, SDEISR) & pch_isr_bit)
> mask |= BIT(TC_PORT_LEGACY);
>
> return mask;
> --
> 2.37.1
[Intel-gfx] [core-for-CI] x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform
From: Zhang Rui
The SMT siblings value returned by CPUID.1F SMT level EBX differs
among CPUs on Intel Hybrid platforms like AlderLake and MeteorLake.
It returns 2 for Pcore CPUs which have SMT siblings and returns 1 for
Ecore CPUs which do not have SMT siblings.
Today, the CPU boot code sets the global variable smp_num_siblings when
every CPU thread is brought up. The last thread to boot will overwrite
it with the number of siblings of *that* thread. That last thread to
boot will "win". If the thread is a Pcore, smp_num_siblings == 2. If it
is an Ecore, smp_num_siblings == 1.
smp_num_siblings describes if the *system* supports SMT. It should
specify the maximum number of SMT threads among all cores.
Ensure that smp_num_siblings represents the system-wide maximum number
of siblings by always increasing its value. Never allow it to decrease.
On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are
not updated in any cpu sibling map because the system is treated as an
UP system when probing Ecore CPUs.
Below shows part of the CPU topology information before and after the
fix, for both Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore).
...
-/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff
-/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11
+/sys/devices/system/cpu/cpu0/topology/package_cpus:3f
+/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21
...
-/sys/devices/system/cpu/cpu12/topology/package_cpus:001000
-/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12
+/sys/devices/system/cpu/cpu12/topology/package_cpus:3f
+/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21
And this also breaks userspace tools like lscpu
-Core(s) per socket: 1
-Socket(s): 11
+Core(s) per socket: 16
+Socket(s): 1
CC: sta...@kernel.org
Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detecting
cpu topology")
Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide
detect_extended_topology_early()")
Suggested-by: Len Brown
Signed-off-by: Zhang Rui
Acked-by: Peter Zijlstra (Intel)
[Imre: resend for core-for-CI]
References:
https://lore.kernel.org/lkml/20230323015640.27906-1-rui.zh...@intel.com
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8317
Signed-off-by: Imre Deak
---
arch/x86/kernel/cpu/topology.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index 5e868b62a7c4e..0270925fe013b 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -79,7 +79,7 @@ int detect_extended_topology_early(struct cpuinfo_x86 *c)
* initial apic id, which also represents 32-bit extended x2apic id.
*/
c->initial_apicid = edx;
- smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
+ smp_num_siblings = max_t(int, smp_num_siblings,
LEVEL_MAX_SIBLINGS(ebx));
#endif
return 0;
}
@@ -109,7 +109,8 @@ int detect_extended_topology(struct cpuinfo_x86 *c)
*/
cpuid_count(leaf, SMT_LEVEL, &eax, &ebx, &ecx, &edx);
c->initial_apicid = edx;
- core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
+ core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
+ smp_num_siblings = max_t(int, smp_num_siblings,
LEVEL_MAX_SIBLINGS(ebx));
core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
die_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
pkg_mask_width = die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
--
2.37.2
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce new methods for verifying ownership in vfio PCI hot reset (rev2)
== Series Details == Series: Introduce new methods for verifying ownership in vfio PCI hot reset (rev2) URL : https://patchwork.freedesktop.org/series/115264/ State : success == Summary == CI Bug Log - changes from CI_DRM_12918 -> Patchwork_115264v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/index.html Participating hosts (37 -> 36) -- Missing(1): fi-kbl-soraka Known issues Here are the changes found in Patchwork_115264v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - bat-dg1-7: [PASS][1] -> [SKIP][2] ([i915#7855]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/bat-dg1-7/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/bat-dg1-7/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][3] -> [ABORT][4] ([i915#4983]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/bat-rpls-1/igt@i915_selftest@l...@reset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_suspend@basic-s2idle-without-i915: - fi-rkl-11600: [PASS][5] -> [FAIL][6] ([fdo#103375]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/fi-rkl-11600/igt@i915_susp...@basic-s2idle-without-i915.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/fi-rkl-11600/igt@i915_susp...@basic-s2idle-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-kbl-8809g: NOTRUN -> [SKIP][7] ([fdo#109271]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/fi-kbl-8809g/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc: - bat-dg2-11: NOTRUN -> [SKIP][8] ([i915#5354]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@i915_suspend@basic-s2idle-without-i915: - fi-kbl-8809g: [ABORT][9] -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/fi-kbl-8809g/igt@i915_susp...@basic-s2idle-without-i915.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/fi-kbl-8809g/igt@i915_susp...@basic-s2idle-without-i915.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][11] ([i915#6997] / [i915#7913]) -> [DMESG-FAIL][12] ([i915#6367] / [i915#7913]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/bat-rpls-2/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7855]: https://gitlab.freedesktop.org/drm/intel/issues/7855 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 Build changes - * Linux: CI_DRM_12918 -> Patchwork_115264v2 CI-20190529: 20190529 CI_DRM_12918: a1cb2211899ba6b8fe078586d0878aa918a5aab3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7220: 3eb7beb5c03343b29556025b1ada4b50849b5976 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115264v2: a1cb2211899ba6b8fe078586d0878aa918a5aab3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 777a4de3d017 vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO 2a92707f4cc4 vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl 576175a255f8 vfio/pci: Renaming for accepting device fd in hot reset path 91c8b208c83f vfio: Accpet device file from vfio PCI hot reset path 9fe81a8d19f6 vfio: Refine vfio file kAPIs for vfio PCI hot reset 86cef152607b vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET ee577bf22ada vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device 6fb819b4ba9f vfio/pci: Move the existing hot reset logic to be a helper 6b5f8efac8f9 vfio/pci: Only check ownership of opened devices in hot reset de49aaf53338 vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v2/index.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support (rev9)
== Series Details == Series: Add vfio_device cdev for iommufd support (rev9) URL : https://patchwork.freedesktop.org/series/113696/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/9/mbox/ not applied Applying: vfio: Allocate per device file structure error: sha1 information is lacking or useless (drivers/vfio/vfio_main.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 vfio: Allocate per device file structure When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced
Re: [Intel-gfx] [PATCH 21/29] drm/i915/tc: Add TC PHY hook to init the PHY
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 21/29] drm/i915/tc: Add TC PHY hook to init the
> PHY
>
> Add a hook for platform specific PHY initialization. Move the detection of
> modular FIAs to the TGL handler, skipping this on ADLP+ where the FIAs are
> always modular, not requiring a detection.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 96 ++--
> drivers/gpu/drm/i915/i915_pci.c | 3 -
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> 3 files changed, 56 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 7bcd93f1f0597..8f159ded501f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -32,6 +32,7 @@ struct intel_tc_phy_ops {
> void (*get_hw_state)(struct intel_tc_port *tc);
> bool (*connect)(struct intel_tc_port *tc, int required_lanes);
> void (*disconnect)(struct intel_tc_port *tc);
> + void (*init)(struct intel_tc_port *tc);
> };
>
> struct intel_tc_port {
> @@ -370,6 +371,25 @@ static void tc_port_fixup_legacy_flag(struct
> intel_tc_port *tc,
> tc->legacy_port = !tc->legacy_port;
> }
>
> +static void tc_phy_load_fia_params(struct intel_tc_port *tc, bool
> +modular_fia) {
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> + enum port port = tc->dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(i915, port);
> +
> + /*
> + * Each Modular FIA instance houses 2 TC ports. In SOC that has more
> + * than two TC ports, there are multiple instances of Modular FIA.
> + */
> + if (modular_fia) {
> + tc->phy_fia = tc_port / 2;
> + tc->phy_fia_idx = tc_port % 2;
> + } else {
> + tc->phy_fia = FIA1;
> + tc->phy_fia_idx = tc_port;
> + }
> +}
> +
> /**
> * ICL TC PHY handlers
> * ---
> @@ -597,6 +617,11 @@ static void icl_tc_phy_disconnect(struct intel_tc_port
> *tc)
> }
> }
>
> +static void icl_tc_phy_init(struct intel_tc_port *tc) {
> + tc_phy_load_fia_params(tc, false);
> +}
> +
> static const struct intel_tc_phy_ops icl_tc_phy_ops = {
> .cold_off_domain = icl_tc_phy_cold_off_domain,
> .hpd_live_status = icl_tc_phy_hpd_live_status, @@ -605,6 +630,7 @@
> static const struct intel_tc_phy_ops icl_tc_phy_ops = {
> .get_hw_state = icl_tc_phy_get_hw_state,
> .connect = icl_tc_phy_connect,
> .disconnect = icl_tc_phy_disconnect,
> + .init = icl_tc_phy_init,
> };
>
> /**
> @@ -617,6 +643,20 @@ tgl_tc_phy_cold_off_domain(struct intel_tc_port *tc)
> return POWER_DOMAIN_TC_COLD_OFF;
> }
>
> +static void tgl_tc_phy_init(struct intel_tc_port *tc) {
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> + intel_wakeref_t wakeref;
> + u32 val;
> +
> + with_intel_display_power(i915, tc_phy_cold_off_domain(tc), wakeref)
> + val = intel_de_read(i915, PORT_TX_DFLEXDPSP(FIA1));
> +
> + drm_WARN_ON(&i915->drm, val == 0x);
> +
> + tc_phy_load_fia_params(tc, val & MODULAR_FIA_MASK); }
> +
> static const struct intel_tc_phy_ops tgl_tc_phy_ops = {
> .cold_off_domain = tgl_tc_phy_cold_off_domain,
> .hpd_live_status = icl_tc_phy_hpd_live_status, @@ -625,6 +665,7 @@
> static const struct intel_tc_phy_ops tgl_tc_phy_ops = {
> .get_hw_state = icl_tc_phy_get_hw_state,
> .connect = icl_tc_phy_connect,
> .disconnect = icl_tc_phy_disconnect,
> + .init = tgl_tc_phy_init,
> };
>
> /**
> @@ -720,6 +761,11 @@ static bool adlp_tc_phy_is_owned(struct intel_tc_port
> *tc)
> return val & DDI_BUF_CTL_TC_PHY_OWNERSHIP; }
>
> +static void adlp_tc_phy_init(struct intel_tc_port *tc) {
> + tc_phy_load_fia_params(tc, true);
> +}
> +
> static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> .cold_off_domain = adlp_tc_phy_cold_off_domain,
> .hpd_live_status = adlp_tc_phy_hpd_live_status, @@ -728,6 +774,7
> @@ static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> .get_hw_state = icl_tc_phy_get_hw_state,
> .connect = icl_tc_phy_connect,
> .disconnect = icl_tc_phy_disconnect,
> + .init = adlp_tc_phy_init,
> };
>
> /**
> @@ -972,6 +1019,13 @@ static void tc_phy_disconnect(struct intel_tc_port
> *tc)
> }
> }
>
> +static void tc_phy_init(struct intel_tc_port *tc) {
> + mutex_lock(&tc->lock);
> + tc->phy_ops->init(tc);
> + mutex_unlock(&tc->lock);
> +}
> +
> static void intel_tc_port_reset_mode(struct intel_tc_port *tc,
>int required_lanes, bool force_disconnect)
> {
> @@ -1292,45 +1346,6 @@ void intel_tc_port_put_link(struct intel_digital_port
> *dig_port)
> intel_tc_port_f
Re: [Intel-gfx] [PATCH 20/29] drm/i915/tc: Add asserts in TC PHY hooks that the required power is on
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 7:08 PM
> To: Jani Nikula
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 20/29] drm/i915/tc: Add asserts in TC PHY
> hooks
> that the required power is on
>
> On Thu, Mar 23, 2023 at 04:33:54PM +0200, Jani Nikula wrote:
> > On Thu, 23 Mar 2023, Imre Deak wrote:
> > > Add an assert to each TC PHY hook that their required power domain
> > > is enabled.
> > >
> > > While at it add a comment describing the domains used on each
> > > platform and TC mode.
> > >
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_tc.c | 61
> > > +
> > > 1 file changed, 61 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > index e68346c5e6036..7bcd93f1f0597 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > @@ -111,6 +111,46 @@ bool intel_tc_port_in_legacy_mode(struct
> intel_digital_port *dig_port)
> > > return intel_tc_port_in_mode(dig_port, TC_PORT_LEGACY); }
> > >
> > > +/**
> >
> > This also shouldn't be a kernel-doc comment.
>
> Ok, will change these.
Functionality looks ok to me.
Reviewed-by: Mika Kahola
>
> >
> > BR,
> > Jani.
> >
> > > + * The display power domains used for TC ports depending on the
> > > + * platform and TC mode (legacy, DP-alt, TBT):
> > > + *
> > > + * POWER_DOMAIN_DISPLAY_CORE:
> > > + * --
> > > + * ADLP/all modes:
> > > + * - TCSS/IOM access for PHY ready state.
> > > + * ADLP+/all modes:
> > > + * - DE/north-,south-HPD ISR access for HPD live state.
> > > + *
> > > + * POWER_DOMAIN_PORT_DDI_LANES_:
> > > + * ---
> > > + * ICL+/all modes:
> > > + * - DE/DDI_BUF access for port enabled state.
> > > + * ADLP/all modes:
> > > + * - DE/DDI_BUF access for PHY owned state.
> > > + *
> > > + * POWER_DOMAIN_AUX_USBC:
> > > + * -
> > > + * ICL/legacy mode:
> > > + * - TCSS/IOM,FIA access for PHY ready, owned and HPD live state
> > > + * - TCSS/PHY: block TC-cold power state for using the PHY AUX and
> > > + * main lanes.
> > > + * ADLP/legacy, DP-alt modes:
> > > + * - TCSS/PHY: block TC-cold power state for using the PHY AUX and
> > > + * main lanes.
> > > + *
> > > + * POWER_DOMAIN_TC_COLD_OFF:
> > > + * -
> > > + * TGL/legacy, DP-alt modes:
> > > + * - TCSS/IOM,FIA access for PHY ready, owned and HPD live state
> > > + * - TCSS/PHY: block TC-cold power state for using the PHY AUX and
> > > + * main lanes.
> > > + *
> > > + * ICL, TGL, ADLP/TBT mode:
> > > + * - TCSS/IOM,FIA access for HPD live state
> > > + * - TCSS/TBT: block TC-cold power state for using the (TBT DP-IN)
> > > + * AUX and main lanes.
> > > + */
> > > bool intel_tc_cold_requires_aux_pw(struct intel_digital_port
> > > *dig_port) {
> > > struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > > @@ -163,6 +203,15 @@ tc_cold_unblock(struct intel_tc_port *tc,
> intel_wakeref_t wakeref)
> > > __tc_cold_unblock(tc, domain, wakeref); }
> > >
> > > +static void
> > > +assert_display_core_power_enabled(struct intel_tc_port *tc) {
> > > + struct drm_i915_private *i915 = tc_to_i915(tc);
> > > +
> > > + drm_WARN_ON(&i915->drm,
> > > + !intel_display_power_is_enabled(i915,
> > > +POWER_DOMAIN_DISPLAY_CORE)); }
> > > +
> > > static void
> > > assert_tc_cold_blocked(struct intel_tc_port *tc) { @@ -378,6
> > > +427,8 @@ static bool icl_tc_phy_is_ready(struct intel_tc_port *tc)
> > > struct drm_i915_private *i915 = tc_to_i915(tc);
> > > u32 val;
> > >
> > > + assert_tc_cold_blocked(tc);
> > > +
> > > val = intel_de_read(i915, PORT_TX_DFLEXDPPMS(tc->phy_fia));
> > > if (val == 0x) {
> > > drm_dbg_kms(&i915->drm,
> > > @@ -395,6 +446,8 @@ static bool icl_tc_phy_take_ownership(struct
> intel_tc_port *tc,
> > > struct drm_i915_private *i915 = tc_to_i915(tc);
> > > u32 val;
> > >
> > > + assert_tc_cold_blocked(tc);
> > > +
> > > val = intel_de_read(i915, PORT_TX_DFLEXDPCSSS(tc->phy_fia));
> > > if (val == 0x) {
> > > drm_dbg_kms(&i915->drm,
> > > @@ -418,6 +471,8 @@ static bool icl_tc_phy_is_owned(struct intel_tc_port
> *tc)
> > > struct drm_i915_private *i915 = tc_to_i915(tc);
> > > u32 val;
> > >
> > > + assert_tc_cold_blocked(tc);
> > > +
> > > val = intel_de_read(i915, PORT_TX_DFLEXDPCSSS(tc->phy_fia));
> > > if (val == 0x) {
> > > drm_dbg_kms(&i915->drm,
> > > @@ -626,6 +681,8 @@ static bool adlp_tc_phy_is_ready(struct
> intel_tc_port *tc)
> > > enum tc_port tc_port = intel_port_to_tc(i915, tc->dig_port->base.port);
> > > u32 val;
> > >
> > > + assert_display_core_power_enabled(tc);
> > > +
> > > val = intel_de_read(i915, TCSS_DDI_STATUS(tc_por
Re: [Intel-gfx] [PATCH 19/29] drm/i915/tc: Add TC PHY hook to get the TC-cold blocking power domain
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 19/29] drm/i915/tc: Add TC PHY hook to get the TC-
> cold blocking power domain
>
> Instead of the corresponding if ladder, add a TC PHY hook to get the platform
> and TC mode specific power domain used for blocking the TC-cold power state.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 73 -
> 1 file changed, 59 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 943660044e37a..e68346c5e6036 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -25,6 +25,7 @@ enum tc_port_mode {
> struct intel_tc_port;
>
> struct intel_tc_phy_ops {
> + enum intel_display_power_domain (*cold_off_domain)(struct
> +intel_tc_port *tc);
> u32 (*hpd_live_status)(struct intel_tc_port *tc);
> bool (*is_ready)(struct intel_tc_port *tc);
> bool (*is_owned)(struct intel_tc_port *tc); @@ -53,6 +54,8 @@ struct
> intel_tc_port {
> u8 phy_fia_idx;
> };
>
> +static enum intel_display_power_domain
> +tc_phy_cold_off_domain(struct intel_tc_port *);
> static u32 tc_phy_hpd_live_status(struct intel_tc_port *tc); static bool
> tc_phy_is_ready(struct intel_tc_port *tc); static bool
> tc_phy_take_ownership(struct intel_tc_port *tc, bool take); @@ -113,20 +116,8
> @@ bool intel_tc_cold_requires_aux_pw(struct intel_digital_port *dig_port)
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> struct intel_tc_port *tc = to_tc_port(dig_port);
>
> - return (DISPLAY_VER(i915) == 11 && tc->legacy_port) ||
> - IS_ALDERLAKE_P(i915);
> -}
> -
> -static enum intel_display_power_domain
> -tc_phy_cold_off_domain(struct intel_tc_port *tc) -{
> - struct drm_i915_private *i915 = tc_to_i915(tc);
> - struct intel_digital_port *dig_port = tc->dig_port;
> -
> - if (tc->mode == TC_PORT_TBT_ALT ||
> !intel_tc_cold_requires_aux_pw(dig_port))
> - return POWER_DOMAIN_TC_COLD_OFF;
> -
> - return intel_display_power_legacy_aux_domain(i915, dig_port-
> >aux_ch);
> + return tc_phy_cold_off_domain(tc) ==
> +intel_display_power_legacy_aux_domain(i915, dig_port->aux_ch);
> }
>
> static intel_wakeref_t
> @@ -334,6 +325,18 @@ static void tc_port_fixup_legacy_flag(struct
> intel_tc_port *tc,
> * ICL TC PHY handlers
> * ---
> */
> +static enum intel_display_power_domain
> +icl_tc_phy_cold_off_domain(struct intel_tc_port *tc) {
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> + struct intel_digital_port *dig_port = tc->dig_port;
> +
> + if (tc->legacy_port)
> + return intel_display_power_legacy_aux_domain(i915, dig_port-
> >aux_ch);
> +
> + return POWER_DOMAIN_TC_COLD_OFF;
> +}
> +
> static u32 icl_tc_phy_hpd_live_status(struct intel_tc_port *tc) {
> struct drm_i915_private *i915 = tc_to_i915(tc); @@ -540,6 +543,27
> @@ static void icl_tc_phy_disconnect(struct intel_tc_port *tc) }
>
> static const struct intel_tc_phy_ops icl_tc_phy_ops = {
> + .cold_off_domain = icl_tc_phy_cold_off_domain,
> + .hpd_live_status = icl_tc_phy_hpd_live_status,
> + .is_ready = icl_tc_phy_is_ready,
> + .is_owned = icl_tc_phy_is_owned,
> + .get_hw_state = icl_tc_phy_get_hw_state,
> + .connect = icl_tc_phy_connect,
> + .disconnect = icl_tc_phy_disconnect,
> +};
> +
> +/**
> + * TGL TC PHY handlers
> + * ---
> + */
> +static enum intel_display_power_domain
> +tgl_tc_phy_cold_off_domain(struct intel_tc_port *tc) {
> + return POWER_DOMAIN_TC_COLD_OFF;
> +}
> +
> +static const struct intel_tc_phy_ops tgl_tc_phy_ops = {
> + .cold_off_domain = tgl_tc_phy_cold_off_domain,
> .hpd_live_status = icl_tc_phy_hpd_live_status,
> .is_ready = icl_tc_phy_is_ready,
> .is_owned = icl_tc_phy_is_owned,
> @@ -552,6 +576,18 @@ static const struct intel_tc_phy_ops icl_tc_phy_ops = {
> * ADLP TC PHY handlers
> *
> */
> +static enum intel_display_power_domain
> +adlp_tc_phy_cold_off_domain(struct intel_tc_port *tc) {
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> + struct intel_digital_port *dig_port = tc->dig_port;
> +
> + if (tc->mode != TC_PORT_TBT_ALT)
> + return intel_display_power_legacy_aux_domain(i915, dig_port-
> >aux_ch);
> +
> + return POWER_DOMAIN_TC_COLD_OFF;
> +}
> +
> static u32 adlp_tc_phy_hpd_live_status(struct intel_tc_port *tc) {
> struct drm_i915_private *i915 = tc_to_i915(tc); @@ -624,6 +660,7 @@
> static bool adlp_tc_phy_is_owned(struct intel_tc_port *tc) }
>
> static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> + .cold_off_domain = adlp_tc_phy_cold_off_domain,
>
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Liu, Yi L > Sent: Friday, March 24, 2023 5:25 PM > > > From: Jason Gunthorpe > > Sent: Thursday, March 23, 2023 8:02 PM > > > > On Thu, Mar 23, 2023 at 03:15:20AM +, Liu, Yi L wrote: > > > > From: Jason Gunthorpe > > > > Sent: Wednesday, March 22, 2023 9:43 PM > > > > > > > > On Wed, Mar 22, 2023 at 01:33:09PM +, Liu, Yi L wrote: > > > > > > > > > Thanks. So this new _INFO only reports a limited scope instead of > > > > > the full list of affected devices. Also, it is not static scope since > > > > > device > > > > > may be opened just after the _INFO returns. > > > > > > > > Yes, it would be simplest for qemu to do the query after it gains a > > > > new dev_id and then it can add the new dev_id with the correct reset > > > > group. > > > > > > I see. QEMU can decide. For now, it seems like QEMU doesn't store > > > such the info return by the existing _INFO ioctl. It is used in the hot > > > reset helper and freed before it returns. Though, I'm not sure whether > > > QEMU will store the dev_id info returned by the new _INFO. Perhaps > > > Alex can give some guidance. > > > > That seems a bit confusing, qemu should take the reset group > > information and encode it so that the guest can know it as well. > > > > If all it does is blindly invoke the hot_reset with the right > > parameters then what was the point of all this discussion? > > > > > btw. Another question about this new _INFO ioctl. If there are affected > > > devices that have not been bound to vfio driver yet, should this new > _INFO > > > ioctl fail all the same with EPERM? > > > > Yeah, it should EPERM the same as the normal hot reset if it can't > > marshal the device list. > > Hi Jason, Alex, > > I got a draft patch to add the new _INFO? It checks if all the affected > devices > are in the dev_set, and then gets the dev_id of all the opened devices within > the dev_set. There is still one thing not quite clear. It is the noiommu mode. > In this mode, there is no iommufd bind, so no dev_id. For now, I just fail > this > new _INFO ioctl if there is no iommufd_device. Hence, this new _INFO is not > available for users that operating in noiommu mode. Is this acceptable? The latest _INFO ioctl is in below link. https://lore.kernel.org/kvm/20230327093458.44939-11-yi.l@intel.com/
Re: [Intel-gfx] [PATCH 18/29] drm/i915/tc: Drop tc_cold_block()/unblock()'s power domain parameter
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 18/29] drm/i915/tc: Drop
> tc_cold_block()/unblock()'s
> power domain parameter
>
> Simplify tc_cold_block()/unblock() by dropping their power domain parameter.
> The power domain depends on the current TC mode, which - after the previous
> patch - can't change while the PHY is connected, holding a TC-cold-off power
> domain reference. Based on this the domain can be deducted from the current
> TC mode instead of having to pass this as a parameter.
>
> Blocking TC-cold for the PHY HW readout happens before the current TC mode
> is determined, so here the initial power domain must be still manually passed.
>
> For debugging still keep track of the domain used for tc_cold_block() and
> verify
> that it remained the same until tc_cold_unblock().
>
> While at it rename tc_cold_get_power_domain() to tc_phy_cold_off_domain(),
> reflecting the name of platform specific hook added in the next patch.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 61 +++--
> 1 file changed, 37 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 21c6ef8064883..943660044e37a 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -40,7 +40,9 @@ struct intel_tc_port {
>
> struct mutex lock; /* protects the TypeC port mode */
> intel_wakeref_t lock_wakeref;
> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> enum intel_display_power_domain lock_power_domain;
> +#endif
> struct delayed_work disconnect_phy_work;
> int link_refcount;
> bool legacy_port:1;
> @@ -116,43 +118,60 @@ bool intel_tc_cold_requires_aux_pw(struct
> intel_digital_port *dig_port) }
>
> static enum intel_display_power_domain
> -tc_cold_get_power_domain(struct intel_tc_port *tc, enum tc_port_mode
> mode)
> +tc_phy_cold_off_domain(struct intel_tc_port *tc)
> {
> struct drm_i915_private *i915 = tc_to_i915(tc);
> struct intel_digital_port *dig_port = tc->dig_port;
>
> - if (mode == TC_PORT_TBT_ALT ||
> !intel_tc_cold_requires_aux_pw(dig_port))
> + if (tc->mode == TC_PORT_TBT_ALT ||
> +!intel_tc_cold_requires_aux_pw(dig_port))
> return POWER_DOMAIN_TC_COLD_OFF;
>
> return intel_display_power_legacy_aux_domain(i915, dig_port-
> >aux_ch); }
>
> static intel_wakeref_t
> -tc_cold_block_in_mode(struct intel_tc_port *tc, enum tc_port_mode mode,
> - enum intel_display_power_domain *domain)
> +__tc_cold_block(struct intel_tc_port *tc, enum
> +intel_display_power_domain *domain)
> {
> struct drm_i915_private *i915 = tc_to_i915(tc);
>
> - *domain = tc_cold_get_power_domain(tc, mode);
> + *domain = tc_phy_cold_off_domain(tc);
>
> return intel_display_power_get(i915, *domain); }
>
> static intel_wakeref_t
> -tc_cold_block(struct intel_tc_port *tc, enum intel_display_power_domain
> *domain)
> +tc_cold_block(struct intel_tc_port *tc)
> {
> - return tc_cold_block_in_mode(tc, tc->mode, domain);
> + enum intel_display_power_domain domain;
> + intel_wakeref_t wakeref;
> +
> + wakeref = __tc_cold_block(tc, &domain); #if
> +IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> + tc->lock_power_domain = domain;
> +#endif
> + return wakeref;
> }
>
> static void
> -tc_cold_unblock(struct intel_tc_port *tc, enum intel_display_power_domain
> domain,
> - intel_wakeref_t wakeref)
> +__tc_cold_unblock(struct intel_tc_port *tc, enum intel_display_power_domain
> domain,
> + intel_wakeref_t wakeref)
> {
> struct drm_i915_private *i915 = tc_to_i915(tc);
>
> intel_display_power_put(i915, domain, wakeref); }
>
> +static void
> +tc_cold_unblock(struct intel_tc_port *tc, intel_wakeref_t wakeref) {
> + enum intel_display_power_domain domain =
> tc_phy_cold_off_domain(tc);
> +
> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> + drm_WARN_ON(&tc_to_i915(tc)->drm, tc->lock_power_domain !=
> domain);
> +#endif
> + __tc_cold_unblock(tc, domain, wakeref); }
> +
> static void
> assert_tc_cold_blocked(struct intel_tc_port *tc) { @@ -160,8 +179,7 @@
> assert_tc_cold_blocked(struct intel_tc_port *tc)
> bool enabled;
>
> enabled = intel_display_power_is_enabled(i915,
> -
> tc_cold_get_power_domain(tc,
> - tc-
> >mode));
> + tc_phy_cold_off_domain(tc));
> drm_WARN_ON(&i915->drm, !enabled);
> }
>
> @@ -413,13 +431,13 @@ static void icl_tc_phy_get_hw_state(struct
> intel_tc_port *tc)
> enum intel_display_power_domain domain;
> intel_wakeref_t tc_cold_wref;
>
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce new methods for verifying ownership in vfio PCI hot reset (rev2)
== Series Details ==
Series: Introduce new methods for verifying ownership in vfio PCI hot reset
(rev2)
URL : https://patchwork.freedesktop.org/series/115264/
State : warning
== Summary ==
Error: dim checkpatch failed
498fb1274097 vfio/pci: Update comment around group_fd get in
vfio_pci_ioctl_pci_hot_reset()
09b95d011880 vfio/pci: Only check ownership of opened devices in hot reset
a93e0e52bde9 vfio/pci: Move the existing hot reset logic to be a helper
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#6:
This prepares to add another method for hot reset. The major hot reset logic
total: 0 errors, 1 warnings, 0 checks, 100 lines checked
6bed441dc040 vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for
vfio_device
617ce05d9e70 vfio/pci: Allow passing zero-length fd array in
VFIO_DEVICE_PCI_HOT_RESET
4302e450c3d2 vfio: Refine vfio file kAPIs for vfio PCI hot reset
b87361e1e7b8 vfio: Accpet device file from vfio PCI hot reset path
b86ec489e81d vfio/pci: Renaming for accepting device fd in hot reset path
-:52: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 's32' over 'int32_t'
#52: FILE: drivers/vfio/pci/vfio_pci_core.c:1265:
+ int32_t *fds;
total: 0 errors, 0 warnings, 1 checks, 127 lines checked
1dbe4a480fac vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl
fb6e32ec2ecf vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
-:43: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#43: FILE: drivers/vfio/pci/vfio_pci_core.c:1187:
+static int vfio_pci_ioctl_get_pci_hot_reset_group_info(
total: 0 errors, 0 warnings, 1 checks, 163 lines checked
Re: [Intel-gfx] [PATCH 17/29] drm/i915/tc: Remove redundant wakeref=0 check from unblock_tc_cold()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 17/29] drm/i915/tc: Remove redundant wakeref=0
> check from unblock_tc_cold()
>
> After the previous patch unblock_tc_cold() will not be called in a
> disconnected
> mode, so the wakeref passed to it will be always non-zero.
> Remove the redundant check.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 253ab30c34f7a..21c6ef8064883 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -150,14 +150,6 @@ tc_cold_unblock(struct intel_tc_port *tc, enum
> intel_display_power_domain domain {
> struct drm_i915_private *i915 = tc_to_i915(tc);
>
> - /*
> - * wakeref == -1, means some error happened saving save_depot_stack
> but
> - * power should still be put down and 0 is a invalid save_depot_stack
> - * id so can be used to skip it for non TC legacy ports.
> - */
> - if (wakeref == 0)
> - return;
> -
> intel_display_power_put(i915, domain, wakeref); }
>
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 16/29] drm/i915/tc: Block/unblock TC-cold in the PHY connect/disconnect hooks
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 16/29] drm/i915/tc: Block/unblock TC-cold in the
> PHY connect/disconnect hooks
>
> Move blocking/unblocking the TC-cold power state to the platform specific PHY
> connect / disconnect hooks. This allows for adjusting the connect/disconnect
> sequence as required for each platform.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 43 -
> 1 file changed, 13 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index e8bd54d1582bc..253ab30c34f7a 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -482,6 +482,8 @@ static bool icl_tc_phy_connect(struct intel_tc_port *tc,
> {
> struct drm_i915_private *i915 = tc_to_i915(tc);
>
> + tc->lock_wakeref = tc_cold_block(tc, &tc->lock_power_domain);
> +
> if (tc->mode == TC_PORT_TBT_ALT)
> return true;
>
> @@ -491,7 +493,7 @@ static bool icl_tc_phy_connect(struct intel_tc_port *tc,
> drm_dbg_kms(&i915->drm, "Port %s: can't take PHY ownership
> (ready %s)\n",
> tc->port_name,
> str_yes_no(tc_phy_is_ready(tc)));
> - return false;
> + goto out_unblock_tc_cold;
> }
>
>
> @@ -502,6 +504,10 @@ static bool icl_tc_phy_connect(struct intel_tc_port *tc,
>
> out_release_phy:
> tc_phy_take_ownership(tc, false);
> +out_unblock_tc_cold:
> + tc_cold_unblock(tc,
> + tc->lock_power_domain,
> + fetch_and_zero(&tc->lock_wakeref));
>
> return false;
> }
> @@ -518,6 +524,9 @@ static void icl_tc_phy_disconnect(struct intel_tc_port
> *tc)
> tc_phy_take_ownership(tc, false);
> fallthrough;
> case TC_PORT_TBT_ALT:
> + tc_cold_unblock(tc,
> + tc->lock_power_domain,
> + fetch_and_zero(&tc->lock_wakeref));
> break;
> default:
> MISSING_CASE(tc->mode);
> @@ -888,32 +897,9 @@ static bool intel_tc_port_needs_reset(struct
> intel_tc_port *tc) static void intel_tc_port_update_mode(struct intel_tc_port
> *tc,
> int required_lanes, bool
> force_disconnect) {
> - enum intel_display_power_domain domain;
> - intel_wakeref_t wref;
> - bool needs_reset = force_disconnect;
> -
> - if (!needs_reset) {
> - /* Get power domain required to check the hotplug live status.
> */
> - wref = tc_cold_block(tc, &domain);
> - needs_reset = intel_tc_port_needs_reset(tc);
> - tc_cold_unblock(tc, domain, wref);
> - }
> -
> - if (!needs_reset)
> - return;
> -
> - /* Get power domain required for resetting the mode. */
> - wref = tc_cold_block_in_mode(tc, TC_PORT_DISCONNECTED,
> &domain);
> -
> - intel_tc_port_reset_mode(tc, required_lanes, force_disconnect);
> -
> - /* Get power domain matching the new mode after reset. */
> - tc_cold_unblock(tc, tc->lock_power_domain,
> - fetch_and_zero(&tc->lock_wakeref));
> - if (tc->mode != TC_PORT_DISCONNECTED)
> - tc->lock_wakeref = tc_cold_block(tc, &tc-
> >lock_power_domain);
> -
> - tc_cold_unblock(tc, domain, wref);
> + if (force_disconnect ||
> + intel_tc_port_needs_reset(tc))
> + intel_tc_port_reset_mode(tc, required_lanes,
> force_disconnect);
> }
>
> static void __intel_tc_port_get_link(struct intel_tc_port *tc) @@ -1053,9
> +1039,6 @@ void intel_tc_port_sanitize_mode(struct intel_digital_port
> *dig_port,
> tc_port_mode_name(tc->init_mode));
> tc_phy_disconnect(tc);
> __intel_tc_port_put_link(tc);
> -
> - tc_cold_unblock(tc, tc->lock_power_domain,
> - fetch_and_zero(&tc->lock_wakeref));
> }
>
> drm_dbg_kms(&i915->drm, "Port %s: sanitize mode (%s)\n",
> --
> 2.37.1
[Intel-gfx] ✓ Fi.CI.BAT: success for vfio: Make emulated devices prepared for vfio device cdev (rev4)
== Series Details == Series: vfio: Make emulated devices prepared for vfio device cdev (rev4) URL : https://patchwork.freedesktop.org/series/114846/ State : success == Summary == CI Bug Log - changes from CI_DRM_12918 -> Patchwork_114846v4 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/index.html Participating hosts (37 -> 35) -- Missing(2): fi-kbl-soraka fi-pnv-d510 Known issues Here are the changes found in Patchwork_114846v4 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-kbl-8809g: NOTRUN -> [SKIP][3] ([fdo#109271]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/fi-kbl-8809g/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@i915_suspend@basic-s2idle-without-i915: - fi-kbl-8809g: [ABORT][4] -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12918/fi-kbl-8809g/igt@i915_susp...@basic-s2idle-without-i915.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/fi-kbl-8809g/igt@i915_susp...@basic-s2idle-without-i915.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 Build changes - * Linux: CI_DRM_12918 -> Patchwork_114846v4 CI-20190529: 20190529 CI_DRM_12918: a1cb2211899ba6b8fe078586d0878aa918a5aab3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7220: 3eb7beb5c03343b29556025b1ada4b50849b5976 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114846v4: a1cb2211899ba6b8fe078586d0878aa918a5aab3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 70efbce6e0ed vfio: Check the presence for iommufd callbacks in __vfio_register_dev() 0c69ddfa320b vfio/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers f86d6fc48f42 vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID d6a35cab47d7 vfio-iommufd: No need to record iommufd_ctx in vfio_device 24038c16601f iommufd: Create access in vfio_iommufd_emulated_bind() 187d7e219ff9 iommu/iommufd: Pass iommufd_ctx pointer in iommufd_get_ioas() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v4/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for vfio: Make emulated devices prepared for vfio device cdev (rev4)
== Series Details == Series: vfio: Make emulated devices prepared for vfio device cdev (rev4) URL : https://patchwork.freedesktop.org/series/114846/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldb
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for vfio: Make emulated devices prepared for vfio device cdev (rev4)
== Series Details == Series: vfio: Make emulated devices prepared for vfio device cdev (rev4) URL : https://patchwork.freedesktop.org/series/114846/ State : warning == Summary == Error: dim checkpatch failed b5391e6b2896 iommu/iommufd: Pass iommufd_ctx pointer in iommufd_get_ioas() c01840bafa3b iommufd: Create access in vfio_iommufd_emulated_bind() -:103: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "access->ioas" #103: FILE: drivers/iommu/iommufd/device.c:487: + if (access->ioas != NULL && access->ioas->obj.id != ioas_id) total: 0 errors, 0 warnings, 1 checks, 165 lines checked f3d9dac0a268 vfio-iommufd: No need to record iommufd_ctx in vfio_device ab6fbacfb65a vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID a58e614509df vfio/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers d35b9576c6aa vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
Re: [Intel-gfx] [PATCH 15/29] drm/i915/tc: Check TC mode instead of the VBT legacy flag
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 15/29] drm/i915/tc: Check TC mode instead of the
> VBT legacy flag
>
> After the previous patch the TC mode in the connect/disconnect functions is
> always in sync with the VBT legacy port flag, so for consistency with the
> rest of
> the function check the TC mode instead of the VBT flag.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index e61daa40356b5..e8bd54d1582bc 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -449,7 +449,7 @@ static bool
> tc_phy_verify_legacy_or_dp_alt_mode(struct intel_tc_port *tc,
> int max_lanes;
>
> max_lanes = intel_tc_port_fia_max_lane_count(dig_port);
> - if (tc->legacy_port) {
> + if (tc->mode == TC_PORT_LEGACY) {
> drm_WARN_ON(&i915->drm, max_lanes != 4);
> return true;
> }
> @@ -485,16 +485,15 @@ static bool icl_tc_phy_connect(struct intel_tc_port
> *tc,
> if (tc->mode == TC_PORT_TBT_ALT)
> return true;
>
> - if (!tc_phy_is_ready(tc) &&
> - !drm_WARN_ON(&i915->drm, tc->legacy_port)) {
> - drm_dbg_kms(&i915->drm, "Port %s: PHY not ready\n",
> - tc->port_name);
> + if ((!tc_phy_is_ready(tc) ||
> + !tc_phy_take_ownership(tc, true)) &&
> + !drm_WARN_ON(&i915->drm, tc->mode == TC_PORT_LEGACY)) {
> + drm_dbg_kms(&i915->drm, "Port %s: can't take PHY ownership
> (ready %s)\n",
> + tc->port_name,
> + str_yes_no(tc_phy_is_ready(tc)));
> return false;
> }
>
> - if (!tc_phy_take_ownership(tc, true) &&
> - !drm_WARN_ON(&i915->drm, tc->legacy_port))
> - return false;
>
> if (!tc_phy_verify_legacy_or_dp_alt_mode(tc, required_lanes))
> goto out_release_phy;
> --
> 2.37.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Program pipe A PIPE_MISC_A bit 9 Pixel Extension to 0
== Series Details == Series: drm/i915/display: Program pipe A PIPE_MISC_A bit 9 Pixel Extension to 0 URL : https://patchwork.freedesktop.org/series/115652/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12914_full -> Patchwork_115652v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115652v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115652v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (7 -> 7) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115652v1_full: ### IGT changes ### Possible regressions * igt@perf_pmu@module-unload: - shard-apl: [PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-apl4/igt@perf_...@module-unload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-apl7/igt@perf_...@module-unload.html Known issues Here are the changes found in Patchwork_115652v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-glk5/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@gem_pwrite@basic-exhaustion: - shard-glk: NOTRUN -> [WARN][8] ([i915#2658]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-glk5/igt@gem_pwr...@basic-exhaustion.html * igt@i915_module_load@reload: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180] / [i915#1982] / [i915#62] / [i915#7634]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-apl2/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-apl7/igt@i915_module_l...@reload.html * igt@kms_async_flips@alternate-sync-async-flip@pipe-b-dp-1: - shard-apl: [PASS][11] -> [FAIL][12] ([i915#2521]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-apl1/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-dp-1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-apl2/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-dp-1.html * igt@kms_big_fb@linear-8bpp-rotate-180: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#62]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-apl3/igt@kms_big...@linear-8bpp-rotate-180.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-apl7/igt@kms_big...@linear-8bpp-rotate-180.html * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0: - shard-apl: [PASS][15] -> [SKIP][16] ([fdo#109271]) +36 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-apl3/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-apl7/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-0.html * igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc: - shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-glk5/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html * igt@kms_color@ctm-0-25@pipe-b-dp-1: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#180] / [i915#62]) +10 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12914/shard-apl3/igt@kms_color@ctm-0...@pipe-b-dp-1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115652v1/shard-apl7/igt@kms_color@ctm-0...@pipe-b-dp-1.html * igt@kms_cursor_crc@cursor-random-max-size: - shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271]
Re: [Intel-gfx] [PATCH 14/29] drm/i915/tc: Fix up the legacy VBT flag only in disconnected mode
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 14/29] drm/i915/tc: Fix up the legacy VBT flag
> only in
> disconnected mode
>
> A follow-up patch simplifies the tc_cold_block()/unblock() functions, dropping
> the power domain parameter. For this it must be ensured that the power domain
> - which depends on the actual TC mode and so the VBT legacy port flag - can't
> change while the PHY is in a connected state and accordingly TC-cold is
> blocked.
> Make this so, by fixing up the VBT legacy flag only in the disconnected TC
> mode,
> instead of whenever the HPD state is retrieved.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index e63e9c57e5627..e61daa40356b5 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -298,6 +298,11 @@ static void tc_port_fixup_legacy_flag(struct
> intel_tc_port *tc,
> struct drm_i915_private *i915 = tc_to_i915(tc);
> u32 valid_hpd_mask;
>
> + drm_WARN_ON(&i915->drm, tc->mode != TC_PORT_DISCONNECTED);
> +
> + if (hweight32(live_status_mask) != 1)
> + return;
> +
> if (tc->legacy_port)
> valid_hpd_mask = BIT(TC_PORT_LEGACY);
> else
> @@ -625,8 +630,7 @@ static u32 tc_phy_hpd_live_status(struct intel_tc_port
> *tc)
> mask = tc->phy_ops->hpd_live_status(tc);
>
> /* The sink can be connected only in a single mode. */
> - if (!drm_WARN_ON_ONCE(&i915->drm, hweight32(mask) > 1))
> - tc_port_fixup_legacy_flag(tc, mask);
> + drm_WARN_ON_ONCE(&i915->drm, hweight32(mask) > 1);
>
> return mask;
> }
> @@ -826,9 +830,12 @@ tc_phy_get_target_mode(struct intel_tc_port *tc)
> static void tc_phy_connect(struct intel_tc_port *tc, int required_lanes) {
> struct drm_i915_private *i915 = tc_to_i915(tc);
> + u32 live_status_mask = tc_phy_hpd_live_status(tc);
> bool connected;
>
> - tc->mode = tc_phy_get_target_mode(tc);
> + tc_port_fixup_legacy_flag(tc, live_status_mask);
> +
> + tc->mode = hpd_mask_to_target_mode(tc, live_status_mask);
>
> connected = tc->phy_ops->connect(tc, required_lanes);
> if (!connected && tc->mode != default_tc_mode(tc)) {
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 13/29] drm/i915/tc: Add TC PHY hooks to connect/disconnect the PHY
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 13/29] drm/i915/tc: Add TC PHY hooks to
> connect/disconnect the PHY
>
> Add TC PHY hooks to connect/disconnect the PHY. A follow-up patch will add
> the ADLP specific hooks for these.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index ee4db9d0eb978..e63e9c57e5627 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -29,6 +29,8 @@ struct intel_tc_phy_ops {
> bool (*is_ready)(struct intel_tc_port *tc);
> bool (*is_owned)(struct intel_tc_port *tc);
> void (*get_hw_state)(struct intel_tc_port *tc);
> + bool (*connect)(struct intel_tc_port *tc, int required_lanes);
> + void (*disconnect)(struct intel_tc_port *tc);
> };
>
> struct intel_tc_port {
> @@ -523,6 +525,8 @@ static const struct intel_tc_phy_ops icl_tc_phy_ops = {
> .is_ready = icl_tc_phy_is_ready,
> .is_owned = icl_tc_phy_is_owned,
> .get_hw_state = icl_tc_phy_get_hw_state,
> + .connect = icl_tc_phy_connect,
> + .disconnect = icl_tc_phy_disconnect,
> };
>
> /**
> @@ -605,6 +609,8 @@ static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> .is_ready = adlp_tc_phy_is_ready,
> .is_owned = adlp_tc_phy_is_owned,
> .get_hw_state = icl_tc_phy_get_hw_state,
> + .connect = icl_tc_phy_connect,
> + .disconnect = icl_tc_phy_disconnect,
> };
>
> /**
> @@ -824,10 +830,10 @@ static void tc_phy_connect(struct intel_tc_port *tc,
> int required_lanes)
>
> tc->mode = tc_phy_get_target_mode(tc);
>
> - connected = icl_tc_phy_connect(tc, required_lanes);
> + connected = tc->phy_ops->connect(tc, required_lanes);
> if (!connected && tc->mode != default_tc_mode(tc)) {
> tc->mode = default_tc_mode(tc);
> - connected = icl_tc_phy_connect(tc, required_lanes);
> + connected = tc->phy_ops->connect(tc, required_lanes);
> }
>
> drm_WARN_ON(&i915->drm, !connected);
> @@ -836,7 +842,7 @@ static void tc_phy_connect(struct intel_tc_port *tc, int
> required_lanes) static void tc_phy_disconnect(struct intel_tc_port *tc) {
> if (tc->mode != TC_PORT_DISCONNECTED) {
> - icl_tc_phy_disconnect(tc);
> + tc->phy_ops->disconnect(tc);
> tc->mode = TC_PORT_DISCONNECTED;
> }
> }
> --
> 2.37.1
[Intel-gfx] [PATCH 2/2] drm/i915: remove unused config DRM_I915_UNSTABLE
Essentially this is a revert of commit d9d54a530a70 ("drm/i915: Put
future HW and their uAPIs under STAGING & BROKEN").
We currently have no users for this config option. The last one was
removed in 8c26491f5853 ("drm/i915: Kill the fake lmem support"). Drop
it altogether; it's easy enough to resurrect if need arises.
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Kconfig | 6 --
drivers/gpu/drm/i915/Kconfig.unstable | 21 -
2 files changed, 27 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/Kconfig.unstable
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 98f4e44976e0..06a0ca157e89 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -164,11 +164,5 @@ menu "drm/i915 Profile Guided Optimisation"
source "drivers/gpu/drm/i915/Kconfig.profile"
endmenu
-menu "drm/i915 Unstable Evolution"
- visible if EXPERT && STAGING && BROKEN
- depends on DRM_I915
- source "drivers/gpu/drm/i915/Kconfig.unstable"
-endmenu
-
config DRM_I915_GVT
bool
diff --git a/drivers/gpu/drm/i915/Kconfig.unstable
b/drivers/gpu/drm/i915/Kconfig.unstable
deleted file mode 100644
index cf151a297ed7..
--- a/drivers/gpu/drm/i915/Kconfig.unstable
+++ /dev/null
@@ -1,21 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-config DRM_I915_UNSTABLE
- bool "Enable unstable API for early prototype development"
- depends on EXPERT
- depends on STAGING
- depends on BROKEN # should never be enabled by distros!
- # We use the dependency on !COMPILE_TEST to not be enabled in
- # allmodconfig or allyesconfig configurations
- depends on !COMPILE_TEST
- default n
- help
- Enable prototype uAPI under general discussion before they are
- finalized. Such prototypes may be withdrawn or substantially
- changed before release. They are only enabled here so that a wide
- number of interested parties (userspace driver developers) can
- verify that the uAPI meet their expectations. These uAPI should
- never be used in production.
-
- Recommended for driver developers _only_.
-
- If in the slightest bit of doubt, say "N".
--
2.39.2
[Intel-gfx] [PATCH 1/2] [core-for-CI] Revert "Revert "drm/i915: Don't select BROKEN""
This reverts commit 211c4b0aba30d2eab9690ad61944c7bf20b33c16. Drop the commit from the topic/core-for-CI branch. We no longer need to select BROKEN to enable DRM_I915_UNSTABLE. Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/Kconfig.debug | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 93dfb7ed9705..47e845353ffa 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -40,7 +40,6 @@ config DRM_I915_DEBUG select DRM_I915_DEBUG_RUNTIME_PM select DRM_I915_SW_FENCE_DEBUG_OBJECTS select DRM_I915_SELFTEST - select BROKEN # for prototype uAPI default n help Choose this option to turn on extra driver debugging that may affect -- 2.39.2
