== Series Details ==
Series: drm/i915: Use gt_err inplace of pr_err
URL : https://patchwork.freedesktop.org/series/117116/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13074_full -> Patchwork_117116v1_full
Summary
---
== Series Details ==
Series: dma-buf/dma-fence: Use a successful read_trylock() annotation for
dma_fence_begin_signalling()
URL : https://patchwork.freedesktop.org/series/117115/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13073_full -> Patchwork_117115v1_full
== Series Details ==
Series: drm/i915/mtl: Add support for C20 phy (rev2)
URL : https://patchwork.freedesktop.org/series/116755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13073_full -> Patchwork_116755v2_full
Summary
On 4/28/2023 5:32 PM, John Harrison wrote:
On 4/28/2023 17:30, John Harrison wrote:
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
Fixed the parenthesis alignment in patch 02 and pushed the series.
Thank you for the patches.
-Radhakrishna(RK) Sripada
> -Original Message-
> From: Intel-gfx On Behalf Of Mika
> Kahola
> Sent: Friday, April 28, 2023 2:54 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx]
On 4/28/2023 17:30, John Harrison wrote:
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available
On 4/28/2023 17:19, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If the DEBUG_GEM config option is set then escalate the 'unexpected
firmware version' message from a notice to an error. This will ensure
that the CI system treats
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If the DEBUG_GEM config option is set then escalate the 'unexpected
firmware version' message from a notice to an error. This will ensure
that the CI system treats such occurences as a failure and logs a bug
about it
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that duplicate entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out into a separate function that is only
called once
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification reported if it was older. However,
the patch version
On Thu, 2023-04-27 at 18:04 +0300, Ville Syrjälä wrote:
> On Thu, Apr 27, 2023 at 06:00:10PM +0300, Vinod Govindapillai wrote:
> > > From MTL onwwards, pcode locks the QGV point based on peak BW of
> > the intended QGV point passed by the driver. So the peak BW
> > calculation must match the value
On Thu, 27 Apr 2023 15:47:05 -0700, Umesh Nerlige Ramappa wrote:
>
> Enable fdinfo for GuC based platforms with the exception that long
> running contexts will not provide reliable busyness data unless they
> switch out at some reasonable point in time.
>
> Link:
On Thu, 27 Apr 2023 15:47:04 -0700, Umesh Nerlige Ramappa wrote:
>
> GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
> in the context image. This value is saved/restored on context switches.
> KMD accumulates these values into a 64 bit counter taking care of any
> overflows
== Series Details ==
Series: drm/i915: HuC loading and authentication for MTL (rev2)
URL : https://patchwork.freedesktop.org/series/117080/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13075 -> Patchwork_117080v2
Summary
== Series Details ==
Series: drm/i915: HuC loading and authentication for MTL (rev2)
URL : https://patchwork.freedesktop.org/series/117080/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: HuC loading and authentication for MTL (rev2)
URL : https://patchwork.freedesktop.org/series/117080/
State : warning
== Summary ==
Error: dim checkpatch failed
4f134a76627f DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
Traceback (most recent
On Fri, Apr 28, 2023 at 12:54:22PM +0300, Mika Kahola wrote:
> Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> The PLL settings are based on table, not for algorithmic alternative.
> For DP 1.4 only MPLLB is in use.
>
> Once register settings are done, we read back C20 HW state.
>
>
== Series Details ==
Series: Improvements to GuC error capture
URL : https://patchwork.freedesktop.org/series/117120/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13074 -> Patchwork_117120v1
Summary
---
**SUCCESS**
== Series Details ==
Series: Improvements to GuC error capture
URL : https://patchwork.freedesktop.org/series/117120/
State : warning
== Summary ==
Error: dim checkpatch failed
2a554128572f drm/i915/guc: Don't capture Gen8 regs on Xe devices
-:36: ERROR:COMPLEX_MACRO: Macros with complex
== Series Details ==
Series: drm/i915: Use gt_err inplace of pr_err
URL : https://patchwork.freedesktop.org/series/117116/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13074 -> Patchwork_117116v1
Summary
---
> On 27/04/2023 17:07, Yang, Fei wrote:
>>> On 26/04/2023 16:41, Yang, Fei wrote:
> On 26/04/2023 07:24, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These
On Fri, Apr 28, 2023 at 05:21:53PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2023 at 07:53:00PM +0300, Imre Deak wrote:
> > Add functions for printing link training debug and error messages, both
> > to prepare for the next patch, which downgrades an error to debug if the
> > sink is
The full authentication via the GSC requires an heci packet submission
to the GSC FW via the GSC CS. The GSC has new PXP command for this
(literally called NEW_HUC_AUTH).
The intel_huc_auth fuction is also updated to handle both authentication
types.
Signed-off-by: Daniele Ceraolo Spurio
Cc:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case
On MTL, for obvious reasons, HuC is only available on the media tile.
We already disable SW support for HuC on the root gt due to the
absence of VCS engines, but we also need to update the getparam to point
to the HuC struct in the media GT.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John
Follow the same logic as DG2, so just a meu binary with no version number.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
The new binaries that support the 2-step authentication have contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the meu
manifest of the GSC binary. The manifest consist of a partition header
followed by
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Given that we use dummy vmas for the pinning, we
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
binaries being considered fully authenticated only after the GSC auth
step.
To report the
The HuC loading and authentication flow is once again changing and a new
"clear-media only" authentication step is introduced. The flow is as
follows:
1) The HuC is loaded via DMA - same as all non-GSC HuC binaries.
2) The HuC is authenticated by the GuC - this is the same step as
performed for
This is a squash of the GSC proxy series, which is being reviewed
separately [1]. It's being included here because some of the patches in
this series depend on it. This is not a functional dependencies, the
patches just touch the same code and the proxy patches are planned to be
merged first, so
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
Don't add Xe only GSC registers to pre-Xe devices that don't
even have a GSC engine.
Fix Xe_LP name.
Don't use GEN9 as a prefix for register lists that contain all GEN8
registers.
Rename the
From: John Harrison
The GuC error capture list creation was including Gen8 registers on Xe
platforms. While fixing that, it was noticed that there were other
issues. The platform naming was wrong, the naming of lists was
misleading, the steered register code was duplicated and steered
registers
From: John Harrison
A pair of pre-Xe registers were being included in the Xe capture list.
GuC was rejecting those as being invalid and logging errors about
them. So, stop doing it.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers
From: John Harrison
Remove 99% duplicated steered register list code. Also, include the
pre-Xe steered registers in the pre-Xe list generation.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 112 +-
1 file changed, 29
From: John Harrison
GuC based register dumps in error capture logs were basically broken
for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
[IGT] gem_exec_balancer: starting subtest hang
[drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
[drm] GT0: GUC: No
On Fri, Apr 28, 2023 at 05:32:44PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2023 at 07:53:04PM +0300, Imre Deak wrote:
> > Factor out a helper to call a function with the atomic locks held,
> > required by a follow-up patch resetting an active DP link.
> >
> > No functional changes.
> >
> >
On 4/26/2023 14:14, Teres Alexis, Alan Previn wrote:
On Wed, 2023-04-26 at 10:23 -0700, Harrison, John C wrote:
On 4/25/2023 10:55, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
From: John Harrison
A pair of pre-Xe registers were being included
On Fri, Apr 28, 2023 at 12:54:21PM +0300, Mika Kahola wrote:
> C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
> HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
> 4 lane support for c20.
>
> v2: Add 6.48Gbps and 6.75Gbps modes for eDP (RK)
> Fix
== Series Details ==
Series: dma-buf/dma-fence: Use a successful read_trylock() annotation for
dma_fence_begin_signalling()
URL : https://patchwork.freedesktop.org/series/117115/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13073 -> Patchwork_117115v1
On Fri, Apr 28, 2023 at 08:22:54PM +0300, Imre Deak wrote:
> On Fri, Apr 28, 2023 at 05:02:35PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 26, 2023 at 07:52:59PM +0300, Imre Deak wrote:
> > > During HW readout/sanitization CRTCs can be disabled only if they don't
> > > have an attached encoder
>> On 4/28/23 17:19, Yang, Fei wrote:
>>> On 4/28/23 07:47, fei.y...@intel.com wrote:
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has
On Fri, Apr 28, 2023 at 05:02:35PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2023 at 07:52:59PM +0300, Imre Deak wrote:
> > During HW readout/sanitization CRTCs can be disabled only if they don't
> > have an attached encoder (and so the encoder disable hooks don't need to
> > be called). An
== Series Details ==
Series: drm/i915/mtl: Add support for C20 phy (rev2)
URL : https://patchwork.freedesktop.org/series/116755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13073 -> Patchwork_116755v2
Summary
---
== Series Details ==
Series: drm/i915/mtl: Add support for C20 phy (rev2)
URL : https://patchwork.freedesktop.org/series/116755/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/mtl: Add support for C20 phy (rev2)
URL : https://patchwork.freedesktop.org/series/116755/
State : warning
== Summary ==
Error: dim checkpatch failed
7bd367a64eec drm/i915/mtl: C20 PLL programming
-:175: WARNING:LONG_LINE: line length of 109 exceeds 100
On 2023/4/28 02:32, Alex Williamson wrote:
On Thu, 27 Apr 2023 06:59:17 +
"Liu, Yi L" wrote:
[...]
I'm not quite sure about it so far. For mdev devices, the device driver
may use vfio_pin_pages/vfio_dma_rw () to pin page. Hence such drivers
need to listen to dma_unmap() event. But for
On 4/28/23 17:19, Yang, Fei wrote:
> On 4/28/23 07:47, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the
On 2023/4/28 20:07, Jason Gunthorpe wrote:
On Fri, Apr 28, 2023 at 02:21:26PM +0800, Yi Liu wrote:
but this patch needs to use vfio_iommufd_emulated_bind() and
vfio_iommufd_emulated_unbind() for the noiommu devices when binding
to iommufd. So needs to check noiommu in the vfio_iommufd_bind()
> -Original Message-
> From: Jiang, Yanting [mailto:yanting.ji...@intel.com]
> Sent: 28 April 2023 10:30
> To: Liu, Yi L ; alex.william...@redhat.com;
> j...@nvidia.com; Tian, Kevin
> Cc: j...@8bytes.org; robin.mur...@arm.com; coh...@redhat.com;
> eric.au...@redhat.com;
> On 4/28/23 07:47, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the pat_index refactor.
>>
>> This series
On Wed, Apr 26, 2023 at 07:53:04PM +0300, Imre Deak wrote:
> Factor out a helper to call a function with the atomic locks held,
> required by a follow-up patch resetting an active DP link.
>
> No functional changes.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c
On 4/27/2023 10:25 PM, Saarinen, Jani wrote:
Hi,
-Original Message-
From: Intel-gfx On Behalf Of Ye, Tony
Sent: perjantai 28. huhtikuuta 2023 6.11
To: Ceraolo Spurio, Daniele ; intel-
g...@lists.freedesktop.org
Cc: Teres Alexis, Alan Previn ; dri-
de...@lists.freedesktop.org;
On Wed, Apr 26, 2023 at 07:53:00PM +0300, Imre Deak wrote:
> Add functions for printing link training debug and error messages, both
> to prepare for the next patch, which downgrades an error to debug if the
> sink is disconnected and to remove some code duplication.
>
> Signed-off-by: Imre Deak
On Wed, Apr 26, 2023 at 07:52:59PM +0300, Imre Deak wrote:
> During HW readout/sanitization CRTCs can be disabled only if they don't
> have an attached encoder (and so the encoder disable hooks don't need to
> be called). An upcoming patch will need to disable CRTCs also with an
> attached an
Hi Tejas,
On Fri, Apr 28, 2023 at 06:29:52PM +0530, Tejas Upadhyay wrote:
> It will be more informative regarding
> GT if we use gt_err instead.
>
> Cc: Andi Shyti
> Signed-off-by: Tejas Upadhyay
Reviewed-by: Andi Shyti
Andi
Hi Tejas,
On Fri, Apr 28, 2023 at 06:29:51PM +0530, Tejas Upadhyay wrote:
> It will be more informative regarding
> GT if we use gt_err instead.
>
> Cc: Andi Shyti
> Signed-off-by: Tejas Upadhyay
Thanks for this cleanup!
Reviewed-by: Andi Shyti
Andi
On Fri, Apr 28, 2023 at 12:31:10AM +0200, Xaver Hugl wrote:
> I can't say anything about the other commits in this series, but
> "Document in which order the CTM matrix elements are stored" is
> Reviewed-by: Xaver Hugl
Thanks for the review+ack. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
On 4/28/23 14:52, Thomas Hellström wrote:
Condsider the following call sequence:
/* Upper layer */
dma_fence_begin_signalling();
lock(tainted_shared_lock);
/* Driver callback */
dma_fence_begin_signalling();
...
The "Upper layer" here currently being the drm scheduler and "Driver
callback"
When we use gt_err we get GT info when that failure
hits which helps in debugging.
Cc: Andi Shyti
Signed-off-by: Tejas Upadhyay
Tejas Upadhyay (2):
drm/i915/gt: Use gt_err for GT info
drm/i915/selftests: Use gt_err for GT info
drivers/gpu/drm/i915/gt/selftest_engine_pm.c| 3 ++-
It will be more informative regarding
GT if we use gt_err instead.
Cc: Andi Shyti
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
It will be more informative regarding
GT if we use gt_err instead.
Cc: Andi Shyti
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
Condsider the following call sequence:
/* Upper layer */
dma_fence_begin_signalling();
lock(tainted_shared_lock);
/* Driver callback */
dma_fence_begin_signalling();
...
The driver might here use a utility that is annotated as intended for the
dma-fence signalling critical path. Now if the upper
On Fri, Apr 28, 2023 at 02:21:26PM +0800, Yi Liu wrote:
> but this patch needs to use vfio_iommufd_emulated_bind() and
> vfio_iommufd_emulated_unbind() for the noiommu devices when binding
> to iommufd. So needs to check noiommu in the vfio_iommufd_bind()
> and vfio_iommu_unbind() as well.
I'm
On Fri, 2023-04-28 at 14:36 +0300, Ville Syrjälä wrote:
> On Fri, Apr 28, 2023 at 11:19:39AM +, Hogander, Jouni wrote:
> > On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > All known issues fixed now, so re-enable PSR1 on hsw/bdw.
> >
> > Please
Hi Janusz,
On Mon, Apr 24, 2023 at 02:35:24PM +0200, Janusz Krzysztofik wrote:
> Visible glitches have been observed when running graphics applications on
> Linux under Xen hypervisor. Those observations have been confirmed with
> failures from kms_pwrite_crc Intel GPU test that verifies data
On Fri, Apr 28, 2023 at 11:19:39AM +, Hogander, Jouni wrote:
> On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > All known issues fixed now, so re-enable PSR1 on hsw/bdw.
>
> Please note s/hdw/hsw/ in subject.
>
> >
> > Signed-off-by: Ville Syrjälä
>
On 26.04.2023 23:28, Andrzej Hajda wrote:
This patchset patches sent by Jonathan and Andi, with
addressed CI failures:
1. Fixed checking alignment of 64K pages on both Pre-Gen12 and Gen12.
2. Fixed start alignment of 2M pages.
Regards
Andrzej
Jonathan Cavitt (2):
drm/i915: Migrate
On Fri, 2023-04-28 at 14:03 +0300, Ville Syrjälä wrote:
> On Fri, Apr 28, 2023 at 10:18:34AM +, Hogander, Jouni wrote:
> > Hello,
> >
> > Please check my inline comments below.
> >
> > On Fri, 2023-04-21 at 15:02 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Reintroduce
On Fri, 2023-04-28 at 13:55 +0300, Ville Syrjälä wrote:
> On Fri, Apr 28, 2023 at 10:36:17AM +, Hogander, Jouni wrote:
> > On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware
> > >
On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> All known issues fixed now, so re-enable PSR1 on hsw/bdw.
Please note s/hdw/hsw/ in subject.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_pci.c | 4 ++--
> 1 file changed, 2
On Tue, Apr 25, 2023 at 09:44:41PM +0200, Hans de Goede wrote:
> The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
> a version of 3 or newer and the panel is in vid-mode.
>
> This is based on the big comment around line 730 which starts with
> "Panel enable/disable sequences
On Fri, Apr 28, 2023 at 10:18:34AM +, Hogander, Jouni wrote:
> Hello,
>
> Please check my inline comments below.
>
> On Fri, 2023-04-21 at 15:02 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
> > of it was even
On Fri, Apr 28, 2023 at 10:36:17AM +, Hogander, Jouni wrote:
> On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware
> > generate the extra vblank between link training and first frame
> > being
On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware
> generate the extra vblank between link training and first frame
> being transmitted. This is the same thing that's controlled by
> TRANS_CHICKEN[21]
Hello,
Please check my inline comments below.
On Fri, 2023-04-21 at 15:02 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
> of it was even removed (BDW AUX data registers were left behind).
> Update the code to use REG_BIT() &
Hi Janusz,
On Mon, Apr 24, 2023 at 02:35:24PM +0200, Janusz Krzysztofik wrote:
> Visible glitches have been observed when running graphics applications on
> Linux under Xen hypervisor. Those observations have been confirmed with
> failures from kms_pwrite_crc Intel GPU test that verifies data
From: Gustavo Sousa
Xe_LPD+ defines interrupt bits for only DDI ports in the DE Port
Interrupt registers. The bits for Type-C ports are defined in the PICA
interrupt registers.
BSpec: 50064
Reviewed-by: Radhakrishna Sripada
Signed-off-by: Gustavo Sousa
Signed-off-by: Mika Kahola
---
From: Anusha Srivatsa
Unlike previous platforms that used PORT_TX_DFLEXDPSP
for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
from which the max_lanes has to be calculated.
Bspec: 50235, 65380
Reviewed-by: Matt Atwood
Signed-off-by: Anusha Srivatsa
Signed-off-by: Jose Roberto de Souza
Finally, we can enable TC ports for Meteorlake.
Reviewed-by: Clint Taylor
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
Readout hw state for Thunderbolt.
Reviewed-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 27
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 5 +++-
3 files
From: Imre Deak
The HPD live status for MTL has to be read from different set of
registers. MTL deserves a new function for this purpose
and cannot reuse the existing HPD live status detection
Reviewed-by: Matt Atwood
Signed-off-by: Anusha Srivatsa
Signed-off-by: Imre Deak
Signed-off-by:
Enabling and disabling sequence for Thunderbolt PLL.
Bspec: 64568
v2: Use intel_de_wait_for_register() (RK)
Reviewed-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 135 ++-
drivers/gpu/drm/i915/display/intel_cx0_phy.h |
Add register writes to enable powering up Type-C subsystem i.e. TCSS.
For MeteorLake we need to request TCSS to power up and check the TCSS
power state after 500 us.
In addition, for PICA we need to set/clear the Type-C PHY ownnership
bit when Type-C device is connected/disconnected.
DP1.4 and DP20 voltage swing sequence for C20 phy.
Bspec: 65449, 67636, 67610
Reviewed-by: Arun R Murthy
Signed-off-by: Mika Kahola
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
---
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 4 ++
Use MPLLA for DP2.0 rates 10G and 20G, when ssc is enabled.
v2: Fix typo in commit message (Animesh)
Reviewed-by: Radhakrishna Sripada
Reviewed-by: Arun R Murthy
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +--
1 file changed, 5 insertions(+), 2
As we already do with C10 chip, let's dump the pll
hw state for C20 as well.
Reviewed-by: Radhakrishna Sripada
Reviewed-by: Arun R Murthy
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 ++
Calculate port clock with C20 phy.
BSpec: 64568
Reviewed-by: Radhakrishna Sripada
Reviewed-by: Arun R Murthy
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 45 +++
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +
Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
The PLL settings are based on table, not for algorithmic alternative.
For DP 1.4 only MPLLB is in use.
Once register settings are done, we read back C20 HW state.
BSpec: 64568
v2: Updated pll tables (RK)
MPLLB selection fix (RK)
C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
4 lane support for c20.
v2: Add 6.48Gbps and 6.75Gbps modes for eDP (RK)
Fix lane check (RK)
Fix multiline commenting (Arun)
use usleep_range()
Add support for C20 phy for Type-C connections. C20 phy differs from
C10 and hence we need to separately handle this case.
v2: Fixes for C20 pll programming and hw readout
Signed-off-by: Mika Kahola
Anusha Srivatsa (1):
drm/i915/mtl: Pin assignment for TypeC
Gustavo Sousa (1):
On 28/04/2023 06:47, fei.y...@intel.com wrote:
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at
On 27/04/2023 17:07, Yang, Fei wrote:
> On 26/04/2023 16:41, Yang, Fei wrote:
>>> On 26/04/2023 07:24, fei.y...@intel.com wrote:
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches
> Subject: [PATCH v10 00/22] Add vfio_device cdev for iommufd support
>
> 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
> VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group fds to
> prove that it owns all devices affected by resetting the calling device.
> While for
> cdev devices, user can use an iommufd-based ownership checking model and
> invoke VFIO_DEVICE_PCI_HOT_RESET with a zero-length fd
Acked-by: Simon Ser
1 - 100 of 129 matches
Mail list logo
