== Series Details ==
Series: Fixes for damage clips handling (rev2)
URL : https://patchwork.freedesktop.org/series/106388/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12014_full -> Patchwork_106388v2_full
Summary
---
== Series Details ==
Series: series starting with [1/4] drm/i915: Move display pcode requests to
intel_de (rev2)
URL : https://patchwork.freedesktop.org/series/107610/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked se
== Series Details ==
Series: series starting with [1/4] drm/i915: Move display pcode requests to
intel_de (rev2)
URL : https://patchwork.freedesktop.org/series/107610/
State : warning
== Summary ==
Error: dim checkpatch failed
65b635139e84 drm/i915: Move display pcode requests to intel_de
-:2
On 8/23/2022 4:32 PM, Jani Nikula wrote:
On Mon, 22 Aug 2022, Ankit Nautiyal wrote:
Add helper function to check if Downstream HDMI 2.1 sink supports
DSC1.2.
If we do this, are we going to add helpers for all the details in
display_info, when there's no conversions being done? I think the an
== Series Details ==
Series: series starting with [1/4] drm/i915: Move display pcode requests to
intel_de (rev2)
URL : https://patchwork.freedesktop.org/series/107610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12018 -> Patchwork_107610v2
==
On 8/23/2022 4:33 PM, Jani Nikula wrote:
On Mon, 22 Aug 2022, Ankit Nautiyal wrote:
The decision to use DFP output format conversion capabilities should be
during compute_config phase.
This patch:
-uses the members of intel_dp->dfp to only store the
format conversion capabilities of the DP d
On 18.08.2022 16:41, Radhakrishna Sripada wrote:
> 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
On Wed, 24 Aug 2022, "Nautiyal, Ankit K" wrote:
> On 8/23/2022 4:33 PM, Jani Nikula wrote:
>> On Mon, 22 Aug 2022, Ankit Nautiyal wrote:
>>> The decision to use DFP output format conversion capabilities should be
>>> during compute_config phase.
>>>
>>> This patch:
>>> -uses the members of intel_
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 build break when the types are different and can be used to detect
explicit
From: Chris Wilson
There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the o
This patch series fixes integer overflow or integer truncation issues in
page lookups, ttm place configuration and scatterlist creation, etc.
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain integer
instead o
The __shmem_file_setup() function returns -EINVAL if size is greater than
MAX_LFS_FILESIZE. To handle the same error as other code that returns
-E2BIG when the size is too large, it add a code that returns -E2BIG when
the size is larger than the size that can be handled.
v4: If BITS_PER_LONG is 32
From: Chris Wilson
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
A
From: Chris Wilson
Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warnin
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big
to add vma. The direct function that returns -ENOSPC is
drm_mm_insert_node_in_range().
To handle the same error as other code returning -E2BIG when the size is
too large, it converts return value to -E2BIG.
Signed-off-by:
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 an assigning source value into destination ptr along with an
overflow che
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we
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 existing drm.debug variable or anything else
but addding 3 new module parameters.
For future reference, please do
== 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 : warning
== Summary ==
Error: dim checkpatch failed
fc66062eee1c overflow: Move and
On 8/23/22 9:35 PM, Andrzej Hajda wrote:
On 23.08.2022 12:17, 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() ma
On 24.08.2022 10:45, 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 an assigning source valu
On Fri, 19 Aug 2022, Matt Roper wrote:
> On Thu, Aug 18, 2022 at 04:41:42PM -0700, 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 I
On Tue, 23 Aug 2022, John Harrison wrote:
> On 8/19/2022 05:02, Jani Nikula wrote:
>> Commit 368d179adbac ("drm/i915/guc: Add GuC <-> kernel time stamp
>> translation information") added intel_device_info_print_runtime() in the
>> time info dump for no obvious reason or explanation in the commit
>
On Fri, 19 Aug 2022, Jani Nikula wrote:
> v3 of https://patchwork.freedesktop.org/series/105358/
>
> Add a patch resolving guc time stamp logging related conflicts in the
> front, and remove the last two patches, for now, to avoid any
> potentially regressing functional changes. Leave them for lat
On 8/24/2022 2:07 PM, Jani Nikula wrote:
On Wed, 24 Aug 2022, "Nautiyal, Ankit K" wrote:
On 8/23/2022 4:33 PM, Jani Nikula wrote:
On Mon, 22 Aug 2022, Ankit Nautiyal wrote:
The decision to use DFP output format conversion capabilities should be
during compute_config phase.
This patch:
-us
Nice!
Acked-by: Hans Verkuil
Regards,
Hans
On 24/08/2022 12:22, Dmitry Osipenko wrote:
> All drivers that use dma-bufs have been moved to the updated locking
> specification and now dma-buf reservation is guaranteed to be locked
> by importers during the mapping operations. There is no
On Tue, 16 Aug 2022, Lucas De Marchi wrote:
> On Thu, Aug 11, 2022 at 06:07:24PM +0300, Jani Nikula wrote:
>>diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
>>b/drivers/gpu/drm/i915/display/intel_display_core.h
>>index 748d2a84e20e..f12ff36fef07 100644
>>--- a/drivers/gpu/drm/i915/
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 - drm_dp_mst, the former
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-next. Thanks for the patch.
This patch is completely lacking the commit messag
Hi Daniel,
On 8/17/22 22:18, Daniel Dadap wrote:
> On 8/17/22 10:05 AM, Hans de Goede wrote:
>>> One further potential difficulty that I anticipate is that not all dynamic
>>> mux systems use the EC backlight driver (or a similar, GPU-agnostic
>>> driver), and rather have whichever GPU happen
Hi Dave & Daniel,
Here goes the first drm-intel-gt-next PR towards 6.1. Quite a small one.
As primary things, there's the parallel support of GuC v69 and v70
which already went in via -fixes, improvements to the TLB invalidation
performance regressions, further DG2 enabling and improved debugging
On Tue, Aug 23, 2022 at 08:15:48PM +0300, Jani Nikula wrote:
> On Fri, 19 Aug 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > EDID 1.4 introduced some extra flags in the range
> > descriptor to support min/max h/vfreq >= 255. Consult them
> > to correctly parse the vfreq limits.
> >
>
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
acpi_video_get_backlight_t
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
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
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
---
Documentation/gpu/t
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 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.
In case of the acpi_video backlight, acpi_v
On Wed, Aug 24, 2022 at 03:02:33AM +, Murthy, Arun R wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Tuesday, August 23, 2022 6:27 PM
> > To: Murthy, Arun R
> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> > Subject: Re: [PATCHv3] drm/i915: Support Async Flip o
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
On Wed, 24 Aug 2022, Hans de Goede wrote:
> 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
Hi,
On 8/24/22 14:47, Jani Nikula wrote:
> On Wed, 24 Aug 2022, Hans de Goede wrote:
>> 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
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 on userspace preferring
> firmware type backlight
v2 of https://patchwork.freedesktop.org/series/107170/
Mostly just rebases, commit message updates and some trivial checkpatch
fixes, and dropping the clock gating function move patch.
BR,
Jani.
Jani Nikula (38):
drm/i915: add display sub-struct to drm_i915_private
drm/i915: move cdclk_funcs
Move display dpll functions under drm_i915_private display sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Reviewed-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_display_core.h | 4
drivers/gpu/drm/i915/display/intel_dpll.c | 24 +--
drivers
Move display watermark functions under drm_i915_private display
sub-struct.
Rename struct drm_i915_wm_disp_funcs to intel_wm_funcs while at it.
Signed-off-by: Jani Nikula
Reviewed-by: Arun R Murthy
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 34 +++
In another long-overdue cleanup, add a display sub-struct to
drm_i915_private, and start moving display related members there. Start
with display funcs that need a rename anyway to not collide with the new
display member.
Add a new header under display/ for defining struct intel_display.
Rename s
Move display hotplug functions under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Reviewed-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_display_core.h | 4
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i91
Move display color functions under drm_i915_private display sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Arun R Murthy
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_color.c| 34 +--
.../gpu/drm/i915/display/intel_display_core.h | 4 +++
drivers
Move display PPS related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Arun R Murthy
Reviewed-by: Lucas De Marchi
---
.../gpu/drm/i915/display/intel_display_core.h | 7 +++
drivers/gpu/drm/i915/display/intel_pps.c | 48 +--
dri
Move display fdi functions under drm_i915_private display sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Arun R Murthy
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display_core.h | 4
drivers/gpu/drm/i915/display/intel_fdi.c | 8
drivers/gpu/d
Move display cdclk functions under drm_i915_private display sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 70 +--
.../gpu/drm/i915/display/intel_display_core.h | 4 ++
drivers/gpu/drm/i915/i915_drv.h
Move display fbdev related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Reviewed-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_display_core.h | 8 ++
.../drm/i915/display/intel_display_debugfs.c | 2 +-
drivers/gpu/drm
Move display gmbus related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Arun R Murthy
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 6 +--
.../gpu/drm/i915/display/intel_display_core.h | 23 ++
drivers/gp
Move display sagv related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bw.c | 10 ++---
.../gpu/drm/i915/display/intel_display_core.h | 11 ++
drivers/gpu/drm/i915/i915_drv.h
Move display backlight related members under drm_i915_private display
sub-struct.
Prefer adding anonymous sub-structs even for single members that aren't
our own structs.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
.../gpu/drm/i915/display/intel_backlight.c| 28 +---
Move display cdclk related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/hsw_ips.c| 2 +-
drivers/gpu/drm/i915/display/intel_audio.c| 6 +-
.../gpu/drm/i915/display/intel_backlight.c
Move display DSI related members under drm_i915_private display
sub-struct.
Prefer adding anonymous sub-structs even for single members that aren't
our own structs.
Abstract mmio base member access in register definitions in a macro.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
Move display bandwidth related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bw.c | 42 +--
.../gpu/drm/i915/display/intel_display_core.h | 21 ++
.../drm/i915/displ
Move display hdcp related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Reviewed-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_display_core.h | 9 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 134 +-
dr
Move display hotplug related members under drm_i915_private display
sub-struct.
Rename struct i915_hotplug to intel_hotplug while at it.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
drivers/gpu/drm/i915/display/intel_ddi.c
Move display opregion related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bios.c | 4 +-
.../gpu/drm/i915/display/intel_display_core.h | 2 +
.../drm/i915/display/intel_display_debugfs.c
Move display FBC related members under drm_i915_private display
sub-struct.
Pointers and arrays of pointers to structs that we defined are fine
without a sub-struct wrapping.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 2 +-
Move display dmc related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
.../gpu/drm/i915/display/intel_display_core.h | 4 ++
.../drm/i915/display/intel_display_power.c| 18 +++
.../i915/display/intel_display_power_well.c
The window2_delay member has been functionally unused (always set to 0)
since it was added in commit bb265dbdf38d ("drm/i915/xelpd: Add VRR
guardband for VRR CTL"). Replace it with a FIXME comment.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_di
Move display VBT related members under drm_i915_private display
sub-struct.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bios.c | 212 +-
drivers/gpu/drm/i915/display/intel_crt.c | 4 +-
drivers/gpu/drm/i91
Move display dbuf related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display_core.h | 7 +++
drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++---
.../drm/i915/display/intel_di
Move display audio related members under drm_i915_private display
sub-struct.
Split audio funcs to display.funcs to follow the same pattern as all the
other display functions.
Signed-off-by: Jani Nikula
Reviewed-by: Arun R Murthy
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/i
Move display workqueue related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 20 +--
.../gpu/drm/i915/display/intel_display_core.h | 8
drivers/gpu/drm/i915
The macros clearly don't belong in i915_drv.h. Move to
intel_frontbuffer.h.
Also split the BUILD_BUG_ON()s to intel_frontbuffer_track() to avoid
depending on some other macros in the header.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
.../gpu/drm/i915/display/intel_frontbuffer.
Move display quirk related members under drm_i915_private display
sub-struct.
Prefer adding anonymous sub-structs even for single members that aren't
our own structs.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display_core.h | 4
drivers
Move display frontbuffer tracking related members under drm_i915_private
display sub-struct.
Rename struct i915_frontbuffer_tracking to intel_frontbuffer_tracking
while at it.
FIXME: fb_tracking.lock mutex init should be moved away from
i915_gem_init_early().
Signed-off-by: Jani Nikula
Reviewed
Turn the quirk ids to enums instead of bits, and hide the masking inside
intel_quirks.c. Define the enums in intel_quirks.h to declutter
i915_drv.h while at it.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_quirks.c | 21 +
dr
The lone gem quirk is an outlier, not even handled by the common quirk
code. Split it to a separate gem_quirks member.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c
Move display fdi related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_crt.c | 4 ++--
drivers/gpu/drm/i915/display/intel_display_core.h | 5 +
drivers/gpu/drm/i915/display/intel_f
Move display overlay related members under drm_i915_private display
sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++
drivers/gpu/drm/i915/display/intel_overlay.c | 12 ++--
Move display watermark related members under drm_i915_private display
sub-struct.
It's a bit arbitrary when to define a named struct for grouping, but
clearly intel_wm is big enough to warrant a separate definition.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Reviewed-by: Arun R Mur
Move display atomic helper related members under drm_i915_private
display sub-struct.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
drivers/gpu/drm/i915/display/intel_display_core.h | 6 ++
drivers/gpu/drm
On 18.08.2022 16:41, Radhakrishna Sripada wrote:
> 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
Reviewe
1 - 100 of 217 matches
Mail list logo
