These tests were specifically designed for host Turbo. Skip
them when SLPC is enabled as they fail frequently. We will look
to keep adding to SLPC test coverage with these scenarios.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
Bug:
Hi Daniele,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Daniele-Ceraolo-Spurio/drm-i915-HuC-loading-for-DG2/20220819-070704
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config:
== Series Details ==
Series: series starting with [1/2] drm/i915/dsc/mtl: Update the DSC minor
version (rev2)
URL : https://patchwork.freedesktop.org/series/107366/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11997_full -> Patchwork_107366v2_full
== Series Details ==
Series: drm/i915: HuC loading for DG2
URL : https://patchwork.freedesktop.org/series/107477/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12002 -> Patchwork_107477v1
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: HuC loading for DG2
URL : https://patchwork.freedesktop.org/series/107477/
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 for DG2
URL : https://patchwork.freedesktop.org/series/107477/
State : warning
== Summary ==
Error: dim checkpatch failed
d4bf856f76e1 HAX: mei: GSC support for XeHP SDV and DG2 platform
Traceback (most recent call last):
File
These tests were specifically designed for host Turbo. Skip
them when SLPC is enabled as they fail frequently. We will look
to keep adding to SLPC test coverage with these scenarios.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
Bug:
From: Imre Deak
Add the proper VBT port,AUX_CH -> i915 port,AUX_CH mapping which just
follows the ADL_P one.
Reviewed-by: Matt Roper
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bios.c | 14 +++---
1 file changed, 7
From: Imre Deak
On MTL TypeC ports the AUX_CH_CTL and AUX_CH_DATA addresses have
changed wrt. previous platforms, adjust the code accordingly.
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 45 -
Add support for Meteorpoint(MTP) PCH used with Meteorlake.
Cc: Matt Roper
Reviewed-by: Anusha Srivatsa
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pch.c | 9 -
drivers/gpu/drm/i915/intel_pch.h | 4
2 files changed, 12
Watermark latency is adjusted in cases when latency is 0us for level
greater than 1, the subsequent levels are disabled. Extract this logic
into its own function.
Suggested-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 88
Since Xe LPD+, Memory latency data are in LATENCY_LPX_LPY registers
instead of GT driver mailbox.
v2: Use the extracted wm latency adjustment function(Matt)
Bspec: 64608
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_reg.h | 7
From: José Roberto de Souza
Display version 14 also supports MBUS joining just like ADL-P
and also it does not need MBUS initialization, so extending ADL-P
code paths to display version 14 and higher.
Bspec: 49213
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by:
Display version 14 platforms have different credits values compared to ADL-P.
Update the credits based on pipe usage.
v2: Simplify DBOX BW Credit definition(MattR)
Bspec: 49213
Cc: Jose Roberto de Souza
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: José Roberto de Souza
From: Matt Roper
Previously only dgfx platforms had a 4MB MMIO range, but starting with
MTL we now use the larger range for all platforms.
Bspec: 63834, 63830
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_uncore.c | 11 ++-
1 file
From: Matt Roper
Unlike the Xe_HP platforms, MTL only has a single CCS engine; the
quad-based engine masking logic does not apply to this platform (or
presumably any future platforms that only have 0 or 1 CCS).
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
Like ADL_P, Meteorlake has different memory characteristics from
past platforms. Update the values used by our memory bandwidth
calculations accordingly.
Bspec: 64631
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
---
From: Madhumitha Tolakanahalli Pradeep
In Display version 14, Transcoder Chicken Registers are moved from DPRZ to DRPOS
to reduce register signal crossings for Unit Interface Optimization.
This patch modifies the CHICKEN_TRANS macro to add a DISPLAY_VER check for
calculating the correct
From: Imre Deak
Add support for display power wells on MTL. The differences from XE_LPD:
- The AUX HW block is moved to the PICA block, where the registers are on
an always-on power well and the functionality needs to be powered on/off
via the AUX_CH_CTL register: [1], [2]
- The DDI IO power
Meteorlake uses a similar DBUF calculations as ADL-P.
Reuse the call flow for meteorlake.
Bspec: 49255
Original Author: Caz Yokoyama
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
>From spec we have registers GPIO_CTL[1-5] mapped to native display phys and
GPIO_CTL[9-14] are mapped to TC ports.
BSpec: 49306
Original Author: Brian J Lovin
Signed-off-by: Radhakrishna Sripada
---
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state are the same on MTL as they were on DG2
(and PVC), so we need to update the driver conditions to re-use the DG2
context table.
For render/compute engines, the part of the
The initialization sequence for Meteorlake reuses the sequence for
icelake for most parts. Some changes viz. reset PICA handshake
are added.
Bspec: 49189
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
No need to update mask value/restrict because
"Pcode only wants to use GV bandwidth value, not the mask value."
for Display version greater than 14.
Bspec: 646365
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 18
From: Matt Roper
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be
From: José Roberto de Souza
The GMD step field do not properly match the current stepping convention
that we use(STEP_A0, STEP_A1, STEP_B0...).
One platform could have { arch = 12, rel = 70, step = 1 } and the
actual stepping is STEP_B0 but without the translation of the step
field would mean
The PCI Id's and platform definition are posted earlier.
This series adds handful of early enablement patches including
support for display power wells, VBT and AUX Channel mapping,
PCH and gmbus support, dbus, mbus, sagv and memory bandwidth support.
This series also add the support for a new
== Series Details ==
Series: drm/i915/mtl: Introduce FBC B (rev3)
URL : https://patchwork.freedesktop.org/series/107365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11997_full -> Patchwork_107365v3_full
Summary
---
Both are required for HuC loading.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..a6576ffbc4dc 100644
---
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.
The full HuC loading flow on boot DG2 is as
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return
Wait on the fence to be signalled to avoid the submissions finding HuC
not yet loaded.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tony Ye
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 6 ++
drivers/gpu/drm/i915/i915_request.c| 24
2
From: Tomas Winkler
Add support for loading HuC via a pxp stream command.
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 3 +-
From: Tomas Winkler
With on-boards graphics card, both i915 and MEI
are in the same device hierarchy with the same parent,
while for discrete gfx card the MEI is its child device.
Adjust the match function for that scenario
by matching MEI parent device with i915.
V2:
1. More detailed commit
The GSC will perform both the load and teh authentication, so we just
need to check the auth bit after the GSC has replied.
Since we require the PXP module to load the HuC, the earliest we can
trigger the load is during the pxp_bind operation.
Note that GSC-loaded HuC survives GT reset, so we
From: Vitaly Lubart
The discrete graphics card with GSC firmware
using command streamer API hence it requires to enhance
pxp module with the new gsc_command() handler.
The handler is implemented via mei_pxp_gsc_command() which is
just just a thin wrapper around mei_cldev_send_gsc_command()
V2:
From: Vitaly Lubart
Command to be sent via the stream interface are written to a local
memory page, whose address is then provided to the GSC.
The interface supports providing a full sg with multiple pages for both
input and output messages, but since for now we only aim to support short
and
The fw name is different and we need to record the fact that the blob is
gsc-loaded, so add a new macro to help.
Note: A-step DG2 G10 does not support HuC loading via GSC and would
require a separate firmware to be loaded the legacy way, but that's
not a production stepping so we're not going to
The mei_pxp module is required to send the command to load authenticate
the HuC to the GSC even if pxp is not in use for protected content
management.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile| 10 +++---
From: Tomas Winkler
GSC extend header is of variable size and data
is provided in a sgl list inside the header
and not in the data buffers, need to enable the path.
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Cc: Vitaly Lubart
---
drivers/misc/mei/client.c| 55
From: Tomas Winkler
GSC command is and extended header containing a scatter gather
list and without a data buffer. Using MEI_CL_IO_SGL flag,
the caller send the GSC command as a data and the function internally
moves it to the extended header.
Signed-off-by: Tomas Winkler
Signed-off-by:
From: Vitaly Lubart
Add mei bus API for sending gsc commands: mei_cldev_send_gsc_command()
The GSC commands are originated in the graphics stack
and are in form of SGL DMA buffers.
The GSC commands are synchronous, the response is received
in the same call on the out sg list buffers.
The
This is a squash of the GSC support for XeHP SDV and DG2 series, which
is being reviewed separately at:
https://patchwork.freedesktop.org/series/106638/
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gsc.c | 118 +---
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need
Hi Wolfram,
Thank you for the patch.
On Thu, Aug 18, 2022 at 11:00:07PM +0200, Wolfram Sang wrote:
> Follow the advice of the below link and prefer 'strscpy' in this
> subsystem. Conversion is 1:1 because the return value is not used.
> Generated by a coccinelle script.
>
> Link:
>
Hello everyone!
The X.org board is soliciting proposals to host XDC in 2023. Since
XDC 2022 is being held in North America this year, XDC 2023 is expected
to be in Europe. However, the board is open to other locations,
especially if there's an interesting co-location with another
conference.
If
On Wed, Aug 17, 2022 at 11:07:46AM +0300, Jani Nikula wrote:
On Wed, 17 Aug 2022, Jani Nikula wrote:
On Tue, 16 Aug 2022, Lucas De Marchi wrote:
On Thu, Aug 11, 2022 at 06:07:12PM +0300, Jani Nikula wrote:
In another long-overdue cleanup, add a display sub-struct to
drm_i915_private, and
On 8/16/2022 19:05, Alan Previn wrote:
From: Matthew Brost
Add a delay, configurable via debugfs (default 34ms), to disable
scheduling of a context after the pin count goes to zero. Disable
scheduling is a costly operation as it requires synchronizing with
the GuC. So the idea is that a delay
These tests were specifically designed for host Turbo. Skip
them when SLPC is enabled as they fail frequently. We will look
to keep adding to SLPC test coverage with these scenarios.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
Bug:
On Thu, 2022-08-18 at 13:42 -0700, Vinay Belgaumkar wrote:
> These tests were specifically designed for host Turbo. Skip
> them when SLPC is enabled as they fail frequently. We will look
> to keep adding to SLPC test coverage with these scenarios.
>
> Bug:
These tests were specifically designed for host Turbo. Skip
them when SLPC is enabled as they fail frequently. We will look
to keep adding to SLPC test coverage with these scenarios.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
Bug:
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
- Use HWMON_CHANNEL_INFO to define
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use
This series adds the HWMON support for DGFX
v2:
- Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
- Fixed review comments (Jani)
- Fixed review comments (Ashutosh)
v3:
- Fixed review comments from Guenter
- Exposed energy
From: Ville Syrjälä
Validate the LFP data block a bit hardwer by making sure the
fp_timing terminators (0x) are where we expect them to be.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 60 ---
1 file changed, 32 insertions(+), 28
From: Ville Syrjälä
Turns out the current code for generating the LFP
data pointers doensn't work with certain VBTs, so
switch to just hardcoding the fp_timing table size,
and make the validator a bit more strict just to be
extra safe.
Ville Syrjälä (2):
drm/i915/bios: Validate fp_timing
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class
Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.
The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/
Signed-off-by: Hans de Goede
---
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
Remove this check from the asus-wmi backlight handling:
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.
So remove the handling for this from the apple-gmux driver.
Signed-off-by: Hans de Goede
---
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Acked-by: Rafael J.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec
check. This will make nvidia-wmi-ec-backlight properly honor the user
selecting a different backlight driver through the acpi_backlight=...
kernel commandline option.
Since the auto-detect code check for
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
MAINTAINERS | 1 +
.../platform/x86/nvidia-wmi-ec-backlight.c| 66
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type
backlight devices call acpi_video_backlight_use_native() now. This sets
__acpi_video_get_backlight_type()'s internal static native_available flag.
This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check
unnecessary.
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step towards this is to deal with some existing technical debt
in backlight handling on
== Series Details ==
Series: drm/i915/pxp: don't start pxp without mei_pxp bind (rev3)
URL : https://patchwork.freedesktop.org/series/107099/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11998 -> Patchwork_107099v3
pxp will not start correctly until after mei_pxp bind completes and
intel_pxp_init_hw() is called.
Wait for the bind to complete before proceeding with startup.
This fixes a race condition during bootup where we observed a small
window for pxp commands to be sent, starting pxp before mei_pxp bind
On Thu, 2022-08-18 at 17:27 +0300, Jani Nikula wrote:
On Thu, 18 Aug 2022, Jani Nikula
mailto:jani.nik...@intel.com>> wrote:
On Wed, 17 Aug 2022, "Colin King (gmail)"
mailto:colin.i.k...@gmail.com>> wrote:
On 17/08/2022 21:07, Vivi, Rodrigo wrote:
On Tue, 2022-08-16 at 12:43 +0800, Zhenyu Wang
Hi Mauro,
Thanks for reviewing this series, I've just pushed it.
On Wednesday, 17 August 2022 14:53:48 CEST Mauro Carvalho Chehab wrote:
> Hi Janusz,
>
> On Fri, 12 Aug 2022 11:53:44 +0200
> Janusz Krzysztofik wrote:
>
> It seems that there is a numeration issue on this series, as the patches
On 27.07.2022 20:46, Radhakrishna Sripada wrote:
> From: Matt Roper
>
> Going forward, the hardware teams no longer consider new platforms to
> have a "generation" in the way we've defined it for past platforms.
> Instead, each IP block (graphics, media, display) will have their own
>
On Thu, 18 Aug 2022, Jani Nikula wrote:
> On Wed, 17 Aug 2022, "Colin King (gmail)" wrote:
>> On 17/08/2022 21:07, Vivi, Rodrigo wrote:
>>> On Tue, 2022-08-16 at 12:43 +0800, Zhenyu Wang wrote:
On 2022.08.16 12:05:08 +0800, Zhenyu Wang wrote:
> On 2022.08.15 19:32:45 -0400, Rodrigo Vivi
== Series Details ==
Series: Enable Pipewriteback
URL : https://patchwork.freedesktop.org/series/107440/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11997 -> Patchwork_107440v1
Summary
---
**FAILURE**
Serious
== Series Details ==
Series: Enable Pipewriteback
URL : https://patchwork.freedesktop.org/series/107440/
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: Enable Pipewriteback
URL : https://patchwork.freedesktop.org/series/107440/
State : warning
== Summary ==
Error: dim checkpatch failed
c89414f4d5ea drm/i915: Define WD trancoder for i915
-:68: CHECK:LINE_SPACING: Please don't use multiple blank lines
#68: FILE:
== Series Details ==
Series: series starting with [1/2] drm/i915/dsc/mtl: Update the DSC minor
version (rev2)
URL : https://patchwork.freedesktop.org/series/107366/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11997 -> Patchwork_107366v2
== Series Details ==
Series: series starting with [1/2] drm/i915/dsc/mtl: Update the DSC minor
version (rev2)
URL : https://patchwork.freedesktop.org/series/107366/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
1 - 100 of 117 matches
Mail list logo
