Clean up i915_reg.h by splitting out SKL+ watermark regs to
display/skl_watermark_regs.h.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_power.c| 1 +
drivers/gpu/drm/i915/display/skl_watermark.c | 1 +
.../gpu/drm/i915/display/skl_watermark_regs.h | 165
Clean up i915_reg.h by splitting out FDI regs to
display/intel_fdi_regs.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_crt.c | 1 +
drivers/gpu/drm/i915/display/intel_fdi.c | 1 +
drivers/gpu/drm/i915/display/intel_fdi_regs.h | 151 ++
On Thu, 2023-03-16 at 15:17 +0200, Imre Deak wrote:
> The commit renaming icl_tc_phy_is_in_safe_mode() to
> icl_tc_phy_take_ownership() didn't flip the function's return value
> accordingly, fix this up.
>
> This didn't cause an actual problem besides state check errors, since
> the function is
The current way to determine during HW state sanitization if a PHY is
connected in the expected way doesn't work in all cases. The check for
this considers only the PHY ready/owned state and the initial TC mode
which was determined earlier by the TC port HW readout - using the
sink's HPD and the
For consistency detect the initial TC mode in the PHY owned state the
same way this is done in the not owned state (w/o changing the
behavior). While at it, add more details to the PHY state debug print.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 43
Atm, a TC port's initial mode will be read out as TBT mode in any case
the PHY ownership is not held. This isn't correct for legacy ports which
should be used only in legacy mode.
Fix the above initial mode to be disconnected mode for a legacy port and
TBT mode for DP-alt/TBT ports. Determine the
For clarity factor out the function to determine if there are active
links on a TC port. This prepares for the next patch also checking the
port's PLL type.
No functional changes.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 35 -
1 file
Add an encoder hook, which can be called on enabled TC ports to
determine if the port uses a TBT or a non-TBT PLL. An upcoming patch
will use this to sanity check active TC port's PHY state wrt. the PLL
type used by the port.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c
Since an HDMI output can only be enabled in legacy mode on TC ports,
assume that VBT is wrong and the port is legacy if VBT says the port is
non-legacy and has HDMI.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
A legacy TC port can't be switched to TBT mode, even if the PHY
initialization wasn't ready yet for some reason, so prevent this.
This shouldn't normally happen as the driver waits for the IOM/TCSS
PHY initialization during driver loading and system resume.
Signed-off-by: Imre Deak
---
Atm, the target TC mode - which the PHY should be switched to at any
point it's used - is TBT in case there is no sink connected. However
legacy ports are only used in the legacy mode regardless of the sink
connected state. Fix the mode returned by
intel_tc_port_get_target_mode() accordingly.
During boot-up/system resume, the TC PHY on legacy ports will be
initialized by the IOM/TCSS firmware regardless of a sink being
connected or not (as opposed to DP-alt/TBT ports, which the FW only
inits once a sink is connected).
Wait for the above initialization to complete during HW readout, so
Factor out helpers used later in the patchset to convert an HPD
status mask to TC mode or target TC mode.
No functional changes.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 44 ++---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git
On TC ports the 4ms AUX timeout combined with the 5 * 32 retry
attempts during DPCD accesses adds a 640ms delay to each access if the
sink is disconnected. This in turn slows down a modeset during which the
sink is disconnected (for instance a disabling modeset).
Prevent the above delay by
An enabled TC MST port holds one TC port link reference, regardless of
the number of enabled streams on it, but the TC port HW readout takes
one reference for each active MST stream.
Fix the HW readout, taking only one reference for MST ports.
This didn't cause an actual problem, since the
The commit renaming icl_tc_phy_is_in_safe_mode() to
icl_tc_phy_take_ownership() didn't flip the function's return value
accordingly, fix this up.
This didn't cause an actual problem besides state check errors, since
the function is only used during HW readout.
Cc: José Roberto de Souza
Fixes:
At least restoring the MST topology during system resume needs to use
AUX before the display HW readout->sanitization sequence is complete,
but on TC ports the PHY may be in the wrong mode for this, resulting in
the AUX transfers to fail.
The initial TC port mode is kept fixed as BIOS left it for
This patchset fixes a few issues on TypeC ports, related to the legacy
port handling, HW state readout/verification. It also fixes an issue on
TC port/MST outputs during system suspend/resume, where the modeset
restoring the pre-suspend state fails atm.
Tested on ICL, TGL, ADLP.
Imre Deak (14):
Clean up i915_reg.h by splitting out DP AUX regs to
display/intel_dp_aux_regs.h.
Signed-off-by: Jani Nikula
---
.../i915/display/intel_display_power_well.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 +
.../gpu/drm/i915/display/intel_dp_aux_regs.h | 84 +++
Clean up i915_reg.h by splitting out TV regs to display/intel_tv_regs.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_tv.c | 3 +-
drivers/gpu/drm/i915/display/intel_tv_regs.h | 490 +++
drivers/gpu/drm/i915/i915_reg.h | 479
Clean up i915_reg.h by splitting out PPS regs to
display/intel_pps_regs.h.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_power.c| 1 +
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 1 +
drivers/gpu/drm/i915/display/intel_lvds.c | 1 +
Shave off 1.2k lines from i915_reg.h.
Jani Nikula (7):
drm/i915/pps: split out PPS regs to a separate file
drm/i915/tv: split out TV regs to a separate file
drm/i915/aux: split out DP AUX regs to a separate file
drm/i915/fdi: split out FDI regs to a separate file
drm/i915/wm: split out
> From: Nicolin Chen
> Sent: Thursday, March 16, 2023 2:49 PM
>
> On Thu, Mar 16, 2023 at 06:28:28AM +, Liu, Yi L wrote:
>
> > > Anyway let's not wait here. Send your v7 and we can have more
> > > focused discussion in your split series about hot reset.
> >
> > Sure. Once Nicolin's patch is
Hi Dave & Daniel,
Here's the first batch of drm-intel-gt-next towards v6.4.
There is an important performance monitoring fix (#6333), more
resiliency to pcode load delay and avoiding caching problems on LLC
systems for ring buffers. Stolen memory probing fix and a
missing register whitelisting
This gives notes for userspace applications on device cdev usage.
Signed-off-by: Yi Liu
---
Documentation/driver-api/vfio.rst | 125 ++
1 file changed, 125 insertions(+)
diff --git a/Documentation/driver-api/vfio.rst
b/Documentation/driver-api/vfio.rst
index
group code is not needed for vfio device cdev, so with vfio device cdev
introduced, the group infrastructures can be compiled out if only cdev
is needed.
Reviewed-by: Kevin Tian
Signed-off-by: Yi Liu
---
drivers/iommu/iommufd/Kconfig | 4 +-
drivers/vfio/Kconfig | 16 -
to align with the coming vfio device cdev support.
Signed-off-by: Yi Liu
---
drivers/vfio/group.c | 18 ++
drivers/vfio/iommufd.c | 33 ++---
drivers/vfio/vfio.h| 9 +
3 files changed, 37 insertions(+), 23 deletions(-)
diff --git
This adds ioctl for userspace to attach device cdev fd to and detach
from IOAS/hw_pagetable managed by iommufd.
VFIO_DEVICE_ATTACH_IOMMUFD_PT: attach vfio device to IOAS, hw_pagetable
managed by iommufd. Attach can be
undo
This adds ioctl for userspace to bind device cdev fd to iommufd.
VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA
control provided by the iommufd. open_device
op is called after bind_iommufd op.
From: Nicolin Chen
Previously, the detach routine is only done by the destroy(). And it was
called by vfio_iommufd_emulated_unbind() when the device runs close(), so
all the mappings in iopt were cleaned in that setup, when the call trace
reaches this detach() routine.
Now, there's a need of a
this prepares for adding DETACH ioctl for emulated VFIO devices.
Reviewed-by: Kevin Tian
Tested-by: Terrence Xu
Tested-by: Nicolin Chen
Tested-by: Matthew Rosato
Signed-off-by: Yi Liu
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
This allows user to directly open a vfio device w/o using the legacy
container/group interface, as a prerequisite for supporting new iommu
features like nested translation.
The device fd opened in this manner doesn't have the capability to access
the device as the fops open() doesn't open the
this prepares for adding DETACH ioctl for physical VFIO devices.
Reviewed-by: Kevin Tian
Tested-by: Terrence Xu
Tested-by: Nicolin Chen
Tested-by: Matthew Rosato
Signed-off-by: Yi Liu
---
Documentation/driver-api/vfio.rst | 8 +---
drivers/vfio/fsl-mc/vfio_fsl_mc.c
VFIO group has historically allowed multi-open of the device FD. This
was made secure because the "open" was executed via an ioctl to the
group FD which is itself only single open.
However, no known use of multiple device FDs today. It is kind of a
strange thing to do because new device FDs can
vfio_device_first_open() requires the caller to provide either a valid
iommufd (the group path in iommufd compat mode) or a valid container
(the group path in legacy container mode). As preparation for noiommu
support in device cdev path it's extended to allow both being NULL. The
caller is
into vfio_device_group_open(). This is also more consistent with what
will be done in vfio device cdev path.
Signed-off-by: Yi Liu
---
drivers/vfio/group.c | 9 +
drivers/vfio/iommufd.c | 35 ++-
drivers/vfio/vfio.h| 9 +
3 files changed,
for counting the devices that are opened via the cdev path. This count
is increased and decreased by the cdev path. The group path checks it
to achieve exclusion with the cdev path. With this, only one path (group
path or cdev path) will claim DMA ownership. This avoids scenarios in
which devices
.bind_iommufd() will generate an ID to represent this bond, which is
needed by userspace for further usage. Store devid in vfio_device_file
to avoid passing the pointer in multiple places.
Signed-off-by: Yi Liu
---
drivers/vfio/iommufd.c | 12 +++-
drivers/vfio/vfio.h | 10
This avoids passing too much parameters in multiple functions.
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Tested-by: Terrence Xu
Tested-by: Nicolin Chen
Tested-by: Matthew Rosato
Signed-off-by: Yi Liu
---
drivers/vfio/group.c | 20 ++--
drivers/vfio/vfio.h
Allow the vfio_device file to be in a state where the device FD is
opened but the device cannot be used by userspace (i.e. its .open_device()
hasn't been called). This inbetween state is not used when the device
FD is spawned from the group FD, however when we create the device FD
directly by
This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*.
Old userspace uses KVM_DEV_VFIO_GROUP* works as well.
Reviewed-by: Jason Gunthorpe
Tested-by: Terrence Xu
Tested-by: Nicolin Chen
Tested-by: Matthew Rosato
Signed-off-by: Yi Liu
---
Meanwhile, rename related helpers. No functional change is intended.
Reviewed-by: Kevin Tian
Reviewed-by: Eric Auger
Reviewed-by: Jason Gunthorpe
Tested-by: Terrence Xu
Tested-by: Nicolin Chen
Tested-by: Matthew Rosato
Signed-off-by: Yi Liu
---
virt/kvm/vfio.c | 115
This makes the vfio file kAPIs to accept vfio device files, also a
preparation for vfio device cdev support.
For the kvm set with vfio device file, kvm pointer is stored in struct
vfio_device_file, and use kvm_ref_lock to protect kvm set and kvm
pointer usage within VFIO. This kvm pointer will be
This is preparation for adding vfio device cdev support. vfio device
cdev requires:
1) A per device file memory to store the kvm pointer set by KVM. It will
be propagated to vfio_device:kvm after the device cdev file is bound
to an iommufd.
2) A mechanism to block device access through
since no user of vfio_file_is_group() now.
Signed-off-by: Yi Liu
---
drivers/vfio/group.c | 10 --
include/linux/vfio.h | 1 -
2 files changed, 11 deletions(-)
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index ede4723c5f72..4f937ebaf6f7 100644
--- a/drivers/vfio/group.c
This prepares for making the below kAPIs to accept both group file
and device file instead of only vfio group file.
bool vfio_file_enforced_coherent(struct file *file);
void vfio_file_set_kvm(struct file *file, struct kvm *kvm);
Reviewed-by: Kevin Tian
Reviewed-by: Eric Auger
Reviewed-by:
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
This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept
device file from the vfio PCI hot reset.
Signed-off-by: Yi Liu
---
drivers/vfio/vfio_main.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio_main.c
No functional change is intended.
Signed-off-by: Yi Liu
---
drivers/vfio/pci/vfio_pci_core.c | 55
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index
Now user can also provide an array of device fds as a 3rd method to verify
the reset ownership. It's not useful at this point when the device fds are
acquired via group fds. But it's necessary when moving to device cdev which
allows the user to directly acquire device fds by skipping group. In
This prepares vfio core to accept vfio device file from the vfio PCI
hot reset path. vfio_file_is_group() is still kept for KVM usage.
Signed-off-by: Yi Liu
---
drivers/vfio/group.c | 32 ++--
drivers/vfio/pci/vfio_pci_core.c | 4 ++--
If the affected device is not opened by any user, it's safe to reset it
given it's not in use.
Reviewed-by: Kevin Tian
Signed-off-by: Yi Liu
---
drivers/vfio/pci/vfio_pci_core.c | 14 +++---
include/uapi/linux/vfio.h| 8
2 files changed, 19 insertions(+), 3
as an alternative method for ownership check when iommufd is used. In
this case all opened devices in the affected dev_set are verified to
be bound to a same valid iommufd value to allow reset. It's simpler
and faster as user does not need to pass a set of fds and kernel no
need to search the
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. This series introduces several extensions to allow the ownership
check better aligned with iommufd and coming vfio device cdev support.
First,
this suits more on what the code does.
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/vfio/pci/vfio_pci_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
== Series Details ==
Series: drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev5)
URL : https://patchwork.freedesktop.org/series/112196/
State : warning
== Summary ==
Error: dim checkpatch failed
25a3d4a31296 drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct
page"
iommufd_ctx is stored in vfio_device for emulated devices per bind_iommufd.
However, as iommufd_access is created in bind, no more need to stored it
since iommufd_access implicitly stores it.
Reviewed-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/vfio/iommufd.c | 10 +-
vfio device cdev needs to return iommufd_access ID to userspace if
bind_iommufd succeeds.
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/iommu/iommufd/device.c | 4 +++-
drivers/iommu/iommufd/selftest.c | 3 ++-
drivers/vfio/iommufd.c | 2 +-
This harmonizes the no-DMA devices (the vfio-mdev sample drivers) with
the emulated devices (gvt-g, vfio-ap etc.). It makes it easier to add
BIND_IOMMUFD user interface which requires to return an iommufd ID to
represent the device/iommufd bond.
Reviewed-by: Jason Gunthorpe
Signed-off-by: Yi Liu
After making the no-DMA drivers (samples/vfio-mdev) providing iommufd
callbacks, __vfio_register_dev() should check the presence of the iommufd
callbacks if CONFIG_IOMMUFD is enabled.
Reviewed-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/vfio/iommufd.c | 3 ---
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
From: Nicolin Chen
There are needs to created iommufd_access prior to have an IOAS and set
IOAS later. Like the vfio device cdev needs to have an iommufd object
to represent the bond (iommufd_access) and IOAS replacement.
Moves the iommufd_access_create() call into vfio_iommufd_emulated_bind(),
>
> On Thu, Mar 16, 2023 at 01:52:32PM +0530, Suraj Kandpal wrote:
> > Remove drm_modeset_lock in intel_conn_to_vcpi as we don't need it
> > anymore since all the required locks are taken in atomic check and
> > prepare phases.
> >
> > Signed-off-by: Suraj Kandpal
> > ---
> >
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next-fixes linus/master v6.3-rc2]
[cannot apply to drm-tip/drm-tip drm-intel/for-linux-next tegra/for-next
next-20230316]
[If your patch
Hi Manasi,
I just realized that there is a newer version of the patch in another
series for DSC 420 support [1].
I added this patch when I was debugging an issue with PCON + 8k YCbCr420
only mode, and noticed that we set the output_format first and then
check for DSC.
Later this patch was
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.
v2: Call
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
Cc: Mika Kahola
Cc: Imre Deak
Cc: Matt Roper
Signed-off-by: Anusha Srivatsa
Signed-off-by:
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
Signed-off-by: Anusha Srivatsa
Signed-off-by: Imre Deak
Signed-off-by: Mika Kahola
---
Finally, we can enable TC ports for Meteorlake.
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
b/drivers/gpu/drm/i915/display/intel_display.c
index
Enabling and disabling sequence for Thunderbolt PLL.
v2: Use __intel_de_wait_for_register() instead of
__intel_wait_for_register() (Jani)
Use '0' instead of ~XELPDP_TBT_CLOCK_ACK (Gustavo)
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 136
Use MPLLA for DP2.0 rates 20G and 20G, when ssc is enabled.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
Add C20 HDMI state calculations and put HDMI table definitions
in use.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
Readout hw state for Thunderbolt.
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 changed, 32 insertions(+), 2
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
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/i915_irq.c | 5 -
1 file changed, 4
PICA is used for DP alt mode and TBT modes. Hotplug interruption is routed
from PICA chip to south display engine and from there to north display
engine. This patch adds functionality to enable hotplug detection for
all Type-C ports (4 ports available).
Differently from HPD in south display, PICA
DP1.4 and DP20 voltage swing sequence for C20 phy.
Bspec: 65449, 67636, 67610
v2: DP2.0 Tx Eq tables has been updated in BSpec.
Update also the driver code as per BSpec 65449
Signed-off-by: Mika Kahola
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Clint Taylor
---
Calculate port clock with C20 phy.
v2: Initialize parameters
v3: Revised formula for port clock check
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 70 ++-
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +
As we already do with C10 chip, let's dump the pll
hw state for C20 as well.
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 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
3 files
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: Rename intel_c20_write() to intel_c20_sram_write() (Gustavo)
Remove unnecessary bit masks (Gustavo)
Fix comments on C20
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: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
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
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
XE_LPD+ 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
Create a separate file to store registers for PICA chips
C10 and C20.
v2: Rename file (Jani)
v3: Use _PICK_EVEN_2RANGES() macro (Lucas)
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 139 ++
1 file changed,
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
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
From: Clint Taylor
Initialize c10 combo phy ports. TODO Type-C ports.
Cc: Radhakrishna Sripada
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
PHY programming support for PICA C10 and C20 Type-C chips.
v2: Move intel_cx0_reg_defs.h to intel_cx0_phy_regs.h (Jani)
Move pmdemand as part of intel_display structure
PLL table updates
v3: Renaming C20 read/write functions (Gustavo)
Code readibility fixes (Gustavo)
HDMI PLL
== Series Details ==
Series: drm/i915/hdcp: Remove drm_modeset_lock in intel_conn_to_vcpi
URL : https://patchwork.freedesktop.org/series/115240/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12867_full -> Patchwork_115240v1_full
From: Tvrtko Ursulin
It appears we had an off by one of a kind where we were not using the full
width of the terminal window for the global metrics section.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
From: Tvrtko Ursulin
So far the width of the PID column was hardcoded to six characters which
is not enough on systems with high uptime, where PID numbers can grow
large, and results in broken line formatting.
Fix it by tracking the largest width for both the pid and name fields and
use them
On Thu, Mar 16, 2023 at 01:52:32PM +0530, Suraj Kandpal wrote:
> Remove drm_modeset_lock in intel_conn_to_vcpi as we don't need it
> anymore since all the required locks are taken in atomic check and
> prepare phases.
>
> Signed-off-by: Suraj Kandpal
> ---
>
On Wed, Mar 15, 2023 at 09:21:34AM -0700, Sean Christopherson wrote:
> On Wed, Mar 15, 2023, Yan Zhao wrote:
> > Nit: there is a typo in the commit header: "iff" -> "if"
> >
> > > -void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8
> > > *new,
> > > - int
On Wed, Mar 15, 2023 at 08:43:54AM -0700, Sean Christopherson wrote:
> > So, in theory, the new GFNs are not write tracked though the old ones are.
> >
> > Is that acceptable for the internal page-track user?
>
> It works because KVM zaps all SPTEs when a memslot is moved, i.e. the fact
> that
On Thu, Mar 16, 2023 at 08:43:12AM +, Hogander, Jouni wrote:
> On Tue, 2023-03-14 at 15:02 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add definitions for various pipe timestamp registers:
> > - frame timestamp (last start of vblank) (g4x+), already had this
> > defined
> > -
On Wed, Mar 15, 2023 at 08:13:37AM -0700, Sean Christopherson wrote:
> > A curious question:
> > are arch/x86/include/asm/kvm_*.h all expected to be external accessible?
>
> Depends on what you mean by "expected". Currently, yes, everything in there
> is
> globally visible. But the vast
On Thu, Mar 16, 2023 at 09:12:00AM +, Hogander, Jouni wrote:
> On Tue, 2023-03-14 at 15:02 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Might as well complete the SURFLIVE register definitions
> > for all platforms/plane types. We are only missing the
> > VLV/CHV sprite
On Thu, Mar 16, 2023 at 08:55:01AM +, Hogander, Jouni wrote:
> On Tue, 2023-03-14 at 15:02 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > VLV/CHV have an extra register to configure some stereo3d
> > signalling details via DP MSA. Make sure we reset that
> > register to zero
There are more than type of content protection security firmware.
Make the name generic
%s/_mei_/_
--v3
-Changing names to drop cp_fw to make naming more agnostic[Jani]
--v4
-remove header reference in intel_display_core.h [Uma]
-fix commit message and prefix drm [Uma]
Cc: Tomas Winkler
Cc:
Add function that takes care of sending command to gsc cs. We start
of with allocation of memory for our command intel_hdcp_gsc_message that
contains gsc cs memory header as directed in specs followed by the
actual payload hdcp message that we want to send.
Spec states that we need to poll pending
101 - 200 of 238 matches
Mail list logo
