== Series Details ==
Series: Drop version numbers from firmware files (rev3)
URL : https://patchwork.freedesktop.org/series/107340/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12029 -> Patchwork_107340v3
Summary
---
== Series Details ==
Series: Drop version numbers from firmware files (rev3)
URL : https://patchwork.freedesktop.org/series/107340/
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: Drop version numbers from firmware files (rev3)
URL : https://patchwork.freedesktop.org/series/107340/
State : warning
== Summary ==
Error: dim checkpatch failed
e1d3119cb4c3 drm/i915/uc: Support for version reduced and multiple firmware
files
-:171:
From: John Harrison
With the move to un-versioned filenames, it becomes more difficult to
know exactly what version of a given firmware is being used. So add
the patch level version number to the debugfs output.
Also, support matching by patch level when selecting code paths for
firmware
From: John Harrison
Going forwards, the intention is for GuC firmware files to be named
for their major version only and HuC firmware files to have no version
number in the name at all. This patch adds those entries for DG1/2 and
ADL-P/S.
Signed-off-by: John Harrison
---
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases forever
new minor firmware releases should replace prior versions
only backwards compatibility
From: John Harrison
Upstream direction is to include the bare minimum of version numbers
in firmware files and to replace them in the repo rather than
accumulating them. For HuC, that means going completely versionless.
For GuC, the major version needs to be kept as that indicates a break
in
== Series Details ==
Series: drm/i915: Add new ADL-S pci id
URL : https://patchwork.freedesktop.org/series/107678/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12021_full -> Patchwork_107678v1_full
Summary
---
== Series Details ==
Series: linux-next: build failure after merge of the drm-intel tree (rev4)
URL : https://patchwork.freedesktop.org/series/42839/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/42839/revisions/4/mbox/ not
applied
Applying:
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/gt/uc/intel_guc.c: In function 'intel_guc_dump_time_info':
drivers/gpu/drm/i915/gt/uc/intel_guc.c:399:9: error: implicit declaration of
function
On Thu, 04 Aug 2022 16:21:25 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh, I am fairly new to this code so some questions will be below will
be newbie questions, thanks for bearing with me.
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
>
== Series Details ==
Series: drm/i915/slpc: Set rps' min and max frequencies even with SLPC. (rev2)
URL : https://patchwork.freedesktop.org/series/107766/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/107766/revisions/2/mbox/ not
applied
On 8/24/2022 21:49, Ceraolo Spurio, Daniele wrote:
On 8/16/2022 1:28 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware
On Thu, 25 Aug 2022 15:23:15 -0700, Rodrigo Vivi wrote:
>
> We need to inform PCODE of a desired ring frequencies so PCODE update
> the memory frequencies to us. rps->min_freq and rps->max_freq are the
> frequencies used in that request. However they were unset when SLPC was
> enabled and PCODE
On 8/23/2022 2:15 PM, Juston Li wrote:
On Fri, Aug 19, 2022 at 4:53 AM Andrzej Hajda wrote:
On 18.08.2022 19:42, Juston Li wrote:
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.
== Series Details ==
Series: drm/i915/slpc: Set rps' min and max frequencies even with SLPC.
URL : https://patchwork.freedesktop.org/series/107766/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12026 -> Patchwork_107766v1
On Thu, Aug 25, 2022 at 06:23:15PM -0400, Rodrigo Vivi wrote:
> We need to inform PCODE of a desired ring frequencies so PCODE update
> the memory frequencies to us. rps->min_freq and rps->max_freq are the
> frequencies used in that request. However they were unset when SLPC was
> enabled and
We need to inform PCODE of a desired ring frequencies so PCODE update
the memory frequencies to us. rps->min_freq and rps->max_freq are the
frequencies used in that request. However they were unset when SLPC was
enabled and PCODE never updated the memory freq.
Let's at least for now get these
On Wed, 24 Aug 2022 22:03:19 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 04 Aug 2022 16:21:25 -0700, Umesh Nerlige Ramappa wrote:
> >
>
> Hi Umesh,
>
> Still reviewing but I have a question below.
Please ignore this mail for now, mostly a result of my misunderstanding the
code. I will ask again if
On Wed, Aug 24, 2022 at 02:26:38PM +0300, Joonas Lahtinen wrote:
> Quoting Matt Roper (2022-08-02 18:09:16)
> > On Mon, Aug 01, 2022 at 02:38:39PM -0700, Harish Chegondi wrote:
> > > Bspec: 46052
> > > Reviewed-by: Matt Roper
> > > Signed-off-by: Harish Chegondi
> >
> > Applied to
Hi G.G,
> -Original Message-
> From: Mun, Gwan-gyeong
> Sent: Tuesday, August 23, 2022 11:14 PM
> To: Roper, Matthew D ; Sripada, Radhakrishna
>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Skip Bit12 fw domain reset for
> gen12+
>
>
>
> On
== Series Details ==
Series: drm/i915/selftests: allow misaligned_pin test work with unmappable
memory
URL : https://patchwork.freedesktop.org/series/107760/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12025 -> Patchwork_107760v1
On Wed, Aug 24, 2022 at 05:45:08PM +0900, Gwan-gyeong Mun wrote:
> It adds exact_type and exactly_pgoff_t macro to catch type mis-match while
> compiling. The existing typecheck() macro outputs build warnings, but the
> newly added exact_type() macro uses the BUILD_BUG_ON() macro to generate
> a
== Series Details ==
Series: drm/i915/selftests: do not try misaligned_pin test on unmappable memory
URL : https://patchwork.freedesktop.org/series/107758/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12025 -> Patchwork_107758v1
On Wed, Aug 24, 2022 at 05:45:07PM +0900, Gwan-gyeong Mun wrote:
> It moves overflows_type utility macro into overflow header from i915_utils
> header. The overflows_type can be used to catch the truncaion (overflow)
> between different data types. And it adds check_assign() macro which
> performs
On 8/25/2022 00:15, Joonas Lahtinen wrote:
Quoting John Harrison (2022-08-24 21:45:09)
On 8/24/2022 02:01, Joonas Lahtinen wrote:
NACK on this one. Let's get this reverted or fixed to eliminate
new module parameters.
What prevents us just from using the maximum sizes? Or alternatively
we
== Series Details ==
Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a
single display
URL : https://patchwork.freedesktop.org/series/107755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12025 -> Patchwork_107755v1
Reviewed-by: Vinod Govindapillai
On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> Adding DP DSC register definitions, we might need for further
> DSC implementation, supporting MST and DP branch pass-through mode.
>
> v2: - Fixed checkpatch comment warning
> v3: - Removed
== Series Details ==
Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a
single display
URL : https://patchwork.freedesktop.org/series/107755/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a
single display
URL : https://patchwork.freedesktop.org/series/107755/
State : warning
== Summary ==
Error: dim checkpatch failed
9770bde2adbd ACPI: video: Add acpi_video_backlight_use_native()
On Thu, 2022-08-25 at 18:17 +0300, Lisovskiy, Stanislav wrote:
> On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> > Hi Stan,
> >
> > Some comments inline..
> >
> > On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > > Whenever we are not able to get enough
On 25/08/2022 16:42, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be unmappable.
Since the test does not touch the memory, passing I915_BO_ALLOC_GPU_ONLY
flag to i915_gem_object_create_region, will prevent -ENOSPC error from
_i915_gem_object_stolen_init.
In case of Small BAR configurations stolen local memory can be unmappable.
Since the test does not touch the memory, passing I915_BO_ALLOC_GPU_ONLY
flag to i915_gem_object_create_region, will prevent -ENOSPC error from
_i915_gem_object_stolen_init.
Closes:
On 25.08.2022 17:13, Matthew Auld wrote:
On 25/08/2022 15:52, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be
unmappable.
Trying to test it causes -ENOSPC error from
_i915_gem_object_stolen_init.
Closes:
On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> Hi Stan,
>
> Some comments inline..
>
> On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> > using DSC, just
On 25/08/2022 15:52, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be unmappable.
Trying to test it causes -ENOSPC error from _i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
Ah right.
Hi Stan,
Some comments inline..
On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> Whenever we are not able to get enough timeslots
> for required PBN, let's try to allocate those
> using DSC, just same way as we do for SST.
>
> v2: Removed intel_dp_mst_dsc_compute_config and
On Thu, Aug 25, 2022 at 01:24:04PM +0200, Andrzej Hajda wrote:
> On 24.08.2022 13:22, Imre Deak wrote:
> > On Tue, Aug 23, 2022 at 11:48:01PM +0200, Andrzej Hajda wrote:
> > >
> > >
> > > On 22.08.2022 19:27, Imre Deak wrote:
> > > > On Fri, Jul 22, 2022 at 02:51:42PM +0200, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be unmappable.
Trying to test it causes -ENOSPC error from _i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4
On Thu, 25 Aug 2022, Ville Syrjälä wrote:
> On Thu, Jun 16, 2022 at 03:41:37PM +0300, Jani Nikula wrote:
>> From: Diego Santa Cruz
>>
>> The quirk added in upstream commit 90c3e2198777 ("drm/i915/glk: Add
>> Quirk for GLK NUC HDMI port issues.") is also required on the ECS Liva
>> Q2.
>>
>>
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is
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.
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
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_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
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/
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
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_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,
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
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"))
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
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 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
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
Suggested-by: Daniel Dadap
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.
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
---
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid
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
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
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
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
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
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
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(-)
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
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
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
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
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: Add HWMON support (rev5)
URL : https://patchwork.freedesktop.org/series/104278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12024 -> Patchwork_104278v5
Summary
---
== Series Details ==
Series: drm/i915: Add HWMON support (rev5)
URL : https://patchwork.freedesktop.org/series/104278/
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: Add HWMON support (rev5)
URL : https://patchwork.freedesktop.org/series/104278/
State : warning
== Summary ==
Error: dim checkpatch failed
4d2dbe77d024 drm/i915/hwmon: Add HWMON infrastructure
Traceback (most recent call last):
File
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
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 power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up
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
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: 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
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
== Series Details ==
Series: DGFX mmap with rpm (rev2)
URL : https://patchwork.freedesktop.org/series/107400/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12024 -> Patchwork_107400v2
Summary
---
**SUCCESS**
No
== Series Details ==
Series: DGFX mmap with rpm (rev2)
URL : https://patchwork.freedesktop.org/series/107400/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Thu, Jun 16, 2022 at 03:41:37PM +0300, Jani Nikula wrote:
> From: Diego Santa Cruz
>
> The quirk added in upstream commit 90c3e2198777 ("drm/i915/glk: Add
> Quirk for GLK NUC HDMI port issues.") is also required on the ECS Liva
> Q2.
>
> Note: Would be nicer to figure out the extra delay
On 24.08.2022 13:22, Imre Deak wrote:
On Tue, Aug 23, 2022 at 11:48:01PM +0200, Andrzej Hajda wrote:
On 22.08.2022 19:27, Imre Deak wrote:
On Fri, Jul 22, 2022 at 02:51:42PM +0200, Andrzej Hajda wrote:
HPD events during driver removal can be generated by hardware and
software frameworks -
Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access
to memory mappings will raise a userfault.
Runtime resume the dgpu(when gem object lies in lmem).
This will transition the dgpu graphics function to D0
state if it
As per PCIe Spec Section 5.3.1.4.1
When pcie function is in d3hot state,
Configuration and Message requests are the only TLPs accepted by a
Function in the D3hot state. All other received Requests must be
handled as Unsupported Requests, and all received Completions
may optionally be handled as
On Tue, Aug 23, 2022 at 03:56:56PM +0300, Golani, Mitulkumar Ajitkumar wrote:
> > Hi Imre,
> >
> > > On Fri, Aug 12, 2022 at 10:17:24AM +0530, Mitul Golani wrote:
> > > > While executing i915_selftest, wakeref imbalance warning is seen
> > > > with i915_selftest failure.
> > > >
> > > > When
== Series Details ==
Series: Fixes integer overflow or integer truncation issues in page lookups,
ttm place configuration and scatterlist creation
URL : https://patchwork.freedesktop.org/series/107667/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12018_full ->
On Wed, Aug 24, 2022 at 7:50 PM Kai-Heng Feng
wrote:
>
> On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula
> wrote:
> >
> > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > dGFX so external monitors are routed to dGFX, and
On 18.08.2022 16:41, Radhakrishna Sripada wrote:
> 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
>
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> 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:
>
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Typically the acpi_video driver will initialize before nouveau, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> nouveau would register its own nv_backlight device later. After
Just one tiny nitpick below:
On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote:
> 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
== Series Details ==
Series: drm/i915: Remove references to uncore from display. (rev2)
URL : https://patchwork.freedesktop.org/series/107610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12018_full -> Patchwork_107610v2_full
Hi All,
On 8/24/22 14:50, Jani Nikula wrote:
> On Wed, 24 Aug 2022, Hans de Goede wrote:
>> 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
Hi Lyude,
Thank you for the review.
On 8/24/22 19:41, Lyude Paul wrote:
> Just one tiny nitpick below:
>
> On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight
On Thu, Aug 25, 2022 at 10:54:48AM +0300, Lisovskiy, Stanislav wrote:
> On Fri, Jun 17, 2022 at 07:07:30PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We currently fail to reconstruct the bw related cdclk limits
> > during readout, which triggers a cdclk reclaculation during
> >
1 - 100 of 115 matches
Mail list logo
