On Thu, 25 Aug 2022, Lv qian wrote:
> If the kmalloc allocation is successful, the if is judged twice,
> so I move the second judgment in to the first judgment.
The code is fine as it is.
BR,
Jani.
>
> Signed-off-by: Lv qian
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 8 -
On Thu, 04 Aug 2022 16:21:25 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
Still reviewing but I have a question below.
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 654a092ed3d6..e2d70a9fdac0 100644
> --- a/drivers/gpu/drm/i915/gt/
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 could check the already existin
On Wed, 15 Jun 2022 10:42:08 -0700, Umesh Nerlige Ramappa wrote:
>
> +static void __guc_context_update_clks(struct intel_context *ce)
> +{
> + struct intel_guc *guc = ce_to_guc(ce);
> + struct intel_gt *gt = ce->engine->gt;
> + u32 *pphwsp, last_switch, engine_id;
== Series Details ==
Series: drm/i915/display: compute config for audio
URL : https://patchwork.freedesktop.org/series/107647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12018_full -> Patchwork_107647v1_full
Summary
On 23-08-2022 20:11, Jani Nikula wrote:
On Tue, 23 Aug 2022, "Nilawar, Badal" wrote:
On 23-08-2022 19:05, Jani Nikula wrote:
On Tue, 23 Aug 2022, Guenter Roeck wrote:
On Tue, Aug 23, 2022 at 12:46:14PM +0300, Jani Nikula wrote:
[ ... ]
So why not do this in i915 Kconfig:
config DRM_I91
On Fri, Jun 17, 2022 at 10:59:48PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The stuff programmed into the wm/ddb registers of planes
> on disabled pipes doesn't matter. So during readout just
> leave our software state tracking for those zeroed.
>
> This should avoid us trying too h
On Tue, 23 Aug 2022, Łukasz Bartosik wrote:
>>
>> Hi all,
>>
>> Apologies in advance if you see this twice. I did not see the original
>> make it to either lore.kernel.org or the freedesktop.org archives so I
>> figured it might have been sent into the void.
>>
>> On Tue, Feb 01, 2022 at 04:33:54P
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 releases forever
new minor firmware releases sho
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
> fastboot, which is then likely forces a full modeset anyway.
> Reconstruct some of
Hi Bartosz Golaszewski,
would you mind taking a look at this patch?
Thanks,
G.G.
On 8/24/22 5:45 PM, 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_typ
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
> >
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 de
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 relies
== 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
==
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 user
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 whi
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:
> https://lore.kernel.org/dri-devel/2022051
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
> contex
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
== 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 -> Patchwork_1076
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 device
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
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
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 - dr
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 requ
== 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.
== 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 re
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 infer
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 power1_crit,
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 hwm
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 hwm
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 (Jan
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
---
.../ABI/testing/sysfs-driver-inte
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)
== 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 "scripts/spdxcheck.p
== 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 : success
== Summary ==
CI Bug Log - changes from CI_DRM_12024 -> Patchwork_104278v5
Summary
---
**SUCCESS**
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 x86/AC
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
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
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 acpi_video
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.
Relyin
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(-)
dif
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 drivers/acpi/vide
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 b
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 b
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 n
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 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 o
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 the
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
---
drivers
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. Wy
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
-
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 nvidia-wmi-ec-backlight
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 th
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
acpi_video_get_backlight_t
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"))
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 troubl
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_v
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_v
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_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 backlig
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=[vendor|native]
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 devi
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.
But
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 troub
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.
>>
>> Not
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, 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:
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 refact
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.
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 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: https://gitlab.freedesktop.org/drm/intel/-/issues/
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: https://gitlab.freedesktop.org/drm/intel/
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.
Close
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 tim
== 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() help
== 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 sepa
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 function
== 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
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 could
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
== 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: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 bu
== 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
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 8/18/
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 drm-intel-gt-n
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 I
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 freq
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 PCODE
== 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
S
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.
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 nev
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 re
== 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
Applying
1 - 100 of 113 matches
Mail list logo
