On Wed, 3 Nov 2021 11:08:13 -0400
Harry Wentland wrote:
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Existing LUT precision structure is having only 16 bit
> > precision. This is not enough for upcoming enhanced hardwares
> > and advance usecases like HDR processing. Hence added a new
> > struct
John Harrison writes:
> On 11/3/2021 14:38, Jordan Justen wrote:
>> So, i915 wants to wash it's hands completely of the format? There is
>> obviously a difference between hardware features and a blob coming from
>> closed source software. (Which i915 just happens to be passing along.)
>> The hard
Hi Ville,
On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -4966,
On 04/11/2021 07:34, Christian König wrote:
Am 03.11.21 um 20:25 schrieb Matthew Auld:
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
+ spin_lock(&mgr->
Hi,
On 11/4/21 00:16, Rajat Jain wrote:
> Hello Hans,
>
> Thanks a lot for working on this diligently and getting almost all of
> it finally merged!
>
> On Wed, Oct 13, 2021 at 2:59 PM Ville Syrjälä
> wrote:
>>
>> On Tue, Oct 05, 2021 at 10:23:22PM +0200, Hans de Goede wrote:
>>> Add support fo
On 03/11/2021 18:44, John Harrison wrote:
On 11/3/2021 06:50, Tvrtko Ursulin wrote:
On 22/10/2021 00:40, john.c.harri...@intel.com wrote:
From: John Harrison
The 'many' test ended with an 'assert(count)', presumably meaning to
ensure that some objects were actually captured. However, 'count
On 04/11/2021 01:49, John Harrison wrote:
On 11/3/2021 14:38, Jordan Justen wrote:
John Harrison writes:
On 11/1/2021 08:39, Jordan Justen wrote:
writes:
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information
about the
current device.
Previously, this inform
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason[1], and we then set up
either GPU- or CPU ptes to the allocated LMEM, we can expose old
contents from other clients.
So aft
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move code out and since we will have to change the
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async callback that checks the
blit fence for errors and if there are errors perform
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason[1], and we then set up
either GPU- or CPU ptes to the allocated LMEM, we can expose old
contents from other clients.
So aft
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async callback that checks the
blit fence for errors and if there are errors perform
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move code out and since we will have to change the
mutex_acquire_nest() expects a pointer, pass the pointer.
Fixes: 12235da8c80a1 ("kernel/locking: Add context to ww_mutex_trylock()")
Signed-off-by: Sebastian Andrzej Siewior
---
Not sure why I haven't seen this earlier…
kernel/locking/ww_rt_mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 del
Quoting Christoph Hellwig (2021-11-02 09:05:34)
> Remove the separately included Makefile and just use the relative
> reference from the main i915 Makefile as for source files in other
> subdirectories.
The thinking behind the split is to avoid any merge conflicts as the
gvt/ subdirectory is handl
+ Thomas, Maarten and Matt
(Also, Zhi and Zhenyu, please see down)
Quoting Christoph Hellwig (2021-11-02 09:05:38)
> Instead of having an option to build the gvt code into the main i915
> module, just move it into the kvmgt.ko module. This only requires
> a new struct with three entries that the
Some selftests assume that nothing will attempt to grab these bitlocks
while they are held by the selftests. With GuC, for example, that is
not true because the hanging workloads may cause the GuC code to attempt
to grab them for a global reset, and that may cause it to end up
sleeping on the bit n
Hi Zhenyu and Zhi,
Can you have somebody from the GVT team to review the patches that
are fully contained in gvt/ ?
I also started discussion on patch 6 which is about defining the
interface between the modules. I remember there is prior work to shrink
the interface. Do you have links to such pat
On Tue, Nov 02, 2021 at 12:32:14PM -0700, José Roberto de Souza wrote:
> Changing the buffer in the middle of the scanout then entering an
> period of flip idleness will cause part of the previous buffer being
> diplayed to user when PSR is enabled.
>
> So here disabling PSR and scheduling activat
== Series Details ==
Series: drm/i915: Failsafe migration blits (rev7)
URL : https://patchwork.freedesktop.org/series/95617/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7fdc5097e400 drm/i915/ttm: Reorganize the ttm move code
-:511: WARNING:FILE_PATH_CHANGES: added, moved or d
From: Ville Syrjälä
We have two identical copies of the snb+ system agent
CPU fence programming code. Extract into a helper.
Also there's no real point in insisting that we
program 0 into DPFC_CPU_FENCE_OFFSET when the fence is
disabled. So just always stick the computed Y offset there
whether o
From: Ville Syrjälä
Declutter gen7_fbc_activate() by sucking the override
stride programming stuff into helpers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 53 +++-
1 file changed, 33 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/
From: Ville Syrjälä
Bunch of refactoring and cleanups, mainly as prep work
for introducing multiple FBC instances in the future.
Ville Syrjälä (17):
drm/i915/fbc: Exract snb_fbc_program_fence()
drm/i915/fbc: Extract {skl,glk}_fbc_program_cfb_stride()
drm/i915/fbc: Just use params->fence_y_
From: Ville Syrjälä
No need to tiptoe around programming DPFC_FENCE_YOFF with
params->fence_y_offset vs. 0. If the fence is not enabled
it doesn't even matter what we program here.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 10 --
1 file changed, 4 inse
From: Ville Syrjälä
Move the direct FBC status register reads from the debugfs code
behind an abstract api.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 23 +++-
drivers/gpu/drm/i915/display/intel_fbc.c | 36 +++
drivers/gpu/drm/
From: Ville Syrjälä
Declutter the *_fbc_activate() functions by pulling all the
control register value computations into helpers.
I left the enable bit in *_fbc_activate() in the hopes of maybe
using the helpers in the *_fbc_deactivate() paths as well instead
of the current rmw approach. That wo
From: Ville Syrjälä
Eliminate yet another if-ladder by adding .nuke() vfunc.
We also rename all *_recompress() stuff to *_nuke() since
that's the terminology the spec uses. Also "recompress"
is a bit confusing by perhaps implying that this triggers
an immediate recompression. Depending on the ha
From: Ville Syrjälä
"gen7" in display code is not really sensible. We shall call
these things "ivb".
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
Replace the "if-ladders everywhere" approach with vfuncs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 80 +++-
drivers/gpu/drm/i915/i915_drv.h | 3 +
2 files changed, 55 insertions(+), 28 deletions(-)
diff --git
From: Ville Syrjälä
Eliminate the last if-ladder by pulling the CFB/LLB programming
into a vfunc as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 56
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i91
From: Ville Syrjälä
Pull the direct FBC register frobbing out from the debugfs code
into the fbc code. Also add a vfunc for this so we don't need
extra platforms checks.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 18 +
drivers/gpu/drm/i915/disp
From: Ville Syrjälä
Just use a same mask for ivb/hsw as for bdw+. The extra bit
in the bdw mask is mbz on ivb/hsw anyway so this is just
pointless complexity.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 3 +--
From: Ville Syrjälä
The FBC register defines are a mess:
- namespace changes between DPFC_, FBC_, and some platform
specific prefix at a whim
- ilk+ reuses most g4x bits but still has some separate bit
defines elsewhere
- it's not clear from the defines that the bit defines are
shared
So l
From: Ville Syrjälä
Switch all the FBC1 registers over to REG_BTT()/etc.
And while at it add a few more registers/bits that
escaped the net previously.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 62 +
From: Ville Syrjälä
In the case of FBC_LLC_READ_CTRL the "FBC" stands for
frame buffer _caching_, not frame buffer compression.
Move the register definition out from the middle of the
frame buffer compression register definitions. Let's
just stick it somewhere with similar looking register
offset
From: Ville Syrjälä
Rename 'dev_priv' to 'i915' to match modern style.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 526 +++
1 file changed, 263 insertions(+), 263 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/
From: Ville Syrjälä
In preparation for multiple FBC instances start passing around
intel_fbc pointers rather than i915 pointers. And once there are
multiple of these we can't rely on container_of() to get back to
the i915, so we toss in a fbc->i915 pointer already.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
With multiple fbc instances we need to find the right one for each
plane. Rather than going looking for the right instance every time
let's just replace the has_fbc boolean with a pointer that gets us
there straight away.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i91
Hi Joonas and Christoph:
We were testing the patch series since Monday and planning to reply after we
get the test result. Mostly, we are concerned about patch 6 and how it would
affect the test result. Patch 6 changes the timing of loading GVT-g. According
to the discussion in the last email,
== Series Details ==
Series: drm/i915: Failsafe migration blits (rev7)
URL : https://patchwork.freedesktop.org/series/95617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10840 -> Patchwork_21515
Summary
---
**SUCCES
On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > > > --- a/driver
== Series Details ==
Series: kernel/locking: Add context to ww_mutex_trylock. (rev5)
URL : https://patchwork.freedesktop.org/series/94437/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10840 -> Patchwork_21516
Summary
-
On Wed, Nov 03, 2021 at 03:47:08PM -0700, Umesh Nerlige Ramappa wrote:
> Since the PMU callback runs in irq context, it synchronizes with gt
> reset using the reset count. We could run into a case where the PMU
> callback could read the reset count before it is updated. This has a
> potential of co
On Thu, Nov 04, 2021 at 01:58:44PM +0100, Thomas Hellström wrote:
> Some selftests assume that nothing will attempt to grab these bitlocks
> while they are held by the selftests. With GuC, for example, that is
> not true because the hanging workloads may cause the GuC code to attempt
> to grab them
There is a lot of historical baggage on this parameter. It is defined in
the vgacon driver as nomodeset, but its set function is called text_mode()
and the value queried with a function named vgacon_text_force().
All this implies that it's about forcing text mode for VGA, yet it is not
used in nei
Some DRM drivers check the vgacon_text_force() function return value as an
indication on whether they should be allowed to be enabled or not.
This function returns true if the nomodeset kernel command line parameter
was set. But there may be other conditions besides this to determine if a
driver s
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that are making use of it.
Let's move the vgacon_text_force() fu
With an anonymous struct, this can be pure hierarchical organization
without code changes. We'll follow up with adding a name to the
sub-struct separately.
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |
Add name to the audio sub-struct in drm_i915_private, and remove the
tautologies and other inconsistencies in the member names.
v2: Call the mutex member mutex, not lock. (Ville)
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gp
Add a standalone definition of struct intel_audio_private, and note that
all of it is private to intel_audio.c.
v2: Rebase
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 45 ++---
It's all internal to intel_audio.c.
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_audio.c | 9 +
drivers/gpu/drm/i915/i915_drv.h| 10 +-
2 files changed, 10 insertions(+),
Unify audio init/cleanup paths wrt LPE audio, and base the logic on the
return values from LPE audio calls. Move the platform device check on
cleanup to intel_lpe_audio.c, thereby limiting all audio.lpe substruct
access to that file.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/in
Follow the filename based prefix naming.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
drivers/gpu/drm/i915/display/intel_audio.h | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
> Some DRM drivers check the vgacon_text_force() function return value as an
> indication on whether they should be allowed to be enabled or not.
>
> This function returns true if the nomodeset kernel command line parameter
> was set. But there
== Series Details ==
Series: drm/i915/selftests: Use clear_and_wake_up_bit() for the per-engine
reset bitlocks
URL : https://patchwork.freedesktop.org/series/96571/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10840 -> Patchwork_21517
On 11/4/21 17:24, Jani Nikula wrote:
[snip]
>> index ab2295dd4500..45cb3e540eff 100644
>> --- a/drivers/gpu/drm/i915/i915_module.c
>> +++ b/drivers/gpu/drm/i915/i915_module.c
>> @@ -18,9 +18,12 @@
>> #include "i915_selftest.h"
>> #include "i915_vma.h"
>>
>> +static const struct drm_driver dri
From: Mark Yacoub
[Why]
The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
unique to i915 driver.
Freeing up the function name for the more generic LUT checks to folllow
Tested on Eldrid ChromeOS (TGL).
v1:
Stuff the test function from DRM to intel driver.
Signed-off-by: Mark
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. Create |degamma_lut_
== Series Details ==
Series: drm/i915: Failsafe migration blits (rev7)
URL : https://patchwork.freedesktop.org/series/95617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10840_full -> Patchwork_21515_full
Summary
---
On 03/11/2021 22:47, Umesh Nerlige Ramappa wrote:
Since the PMU callback runs in irq context, it synchronizes with gt
reset using the reset count. We could run into a case where the PMU
callback could read the reset count before it is updated. This has a
potential of corrupting the busyness sta
On Thu, 04 Nov 2021, Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
> unique to i915 driver.
> Freeing up the function name for the more generic LUT checks to folllow
>
> Tested on Eldrid ChromeOS (TGL).
>
> v1:
> Stuff the
Hi Javier,
On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
> Some DRM drivers check the vgacon_text_force() function return value as an
> indication on whether they should be allowed to be enabled or not.
>
> This function returns true if the nomodeset kernel command lin
On Thu, 2021-11-04 at 16:10 +0200, Ville Syrjälä wrote:
> On Tue, Nov 02, 2021 at 12:32:14PM -0700, José Roberto de Souza wrote:
> > Changing the buffer in the middle of the scanout then entering an
> > period of flip idleness will cause part of the previous buffer being
> > diplayed to user when P
On Thu, 04 Nov 2021, Sam Ravnborg wrote:
> Hi Javier,
>
> On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
>> Some DRM drivers check the vgacon_text_force() function return value as an
>> indication on whether they should be allowed to be enabled or not.
>>
>> This functi
== Series Details ==
Series: kernel/locking: Add context to ww_mutex_trylock. (rev5)
URL : https://patchwork.freedesktop.org/series/94437/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10840_full -> Patchwork_21516_full
Sum
Hello Sam,
On 11/4/21 18:57, Jani Nikula wrote:
> On Thu, 04 Nov 2021, Sam Ravnborg wrote:
>> Hi Javier,
>>
>> On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
>>> Some DRM drivers check the vgacon_text_force() function return value as an
>>> indication on whether they sh
== Series Details ==
Series: drm/i915/fbc: Prep work for multiple FBC instances
URL : https://patchwork.freedesktop.org/series/96574/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7fa3e082ea85 drm/i915/fbc: Exract snb_fbc_program_fence()
e1a5292108ab drm/i915/fbc: Extract {skl,
== Series Details ==
Series: drm/i915/fbc: Prep work for multiple FBC instances
URL : https://patchwork.freedesktop.org/series/96574/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_fbc.c:635: warning: Excess function
parameter '
== Series Details ==
Series: drm/i915/selftests: Use clear_and_wake_up_bit() for the per-engine
reset bitlocks
URL : https://patchwork.freedesktop.org/series/96571/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10840_full -> Patchwork_21517_full
==
== Series Details ==
Series: drm/i915/fbc: Prep work for multiple FBC instances
URL : https://patchwork.freedesktop.org/series/96574/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10841 -> Patchwork_21518
Summary
---
== Series Details ==
Series: series starting with [v3,1/6] drm/i915/audio: group audio under
anonymous struct in drm_i915_private
URL : https://patchwork.freedesktop.org/series/96578/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eaff73f1c59d drm/i915/audio: group audio under
== Series Details ==
Series: series starting with [v3,1/6] drm/i915/audio: group audio under
anonymous struct in drm_i915_private
URL : https://patchwork.freedesktop.org/series/96578/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each
Hi Javier,
>
> >>>
> >>> - if (vgacon_text_force() && i915_modparams.modeset == -1)
> >>> + ret = drm_drv_enabled(&driver);
> >>
> >> You pass the local driver variable here - which looks wrong as this is
> >> not the same as the driver variable declared in another file.
> >
>
> Yes, Jani ment
== Series Details ==
Series: Cleanups for the nomodeset kernel command line parameter logic (rev4)
URL : https://patchwork.freedesktop.org/series/96527/
State : failure
== Summary ==
Applying: drm: Add a drm_drv_enabled() to check if drivers should be enabled
error: sha1 information is lacking
== Series Details ==
Series: series starting with [v3,1/6] drm/i915/audio: group audio under
anonymous struct in drm_i915_private
URL : https://patchwork.freedesktop.org/series/96578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10841 -> Patchwork_21519
=
On Thu, 04 Nov 2021, Sam Ravnborg wrote:
> Hi Javier,
>
>>
>> >>>
>> >>> -if (vgacon_text_force() && i915_modparams.modeset == -1)
>> >>> +ret = drm_drv_enabled(&driver);
>> >>
>> >> You pass the local driver variable here - which looks wrong as this is
>> >> not the same as the
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
> +/**
> + * drm_drv_enabled - Checks if a DRM driver can be enabled
> + * @driver: DRM driver to check
> + *
> + * Checks whether a DRM driver can be enabled or not. This may be the case
> + * if the "nomodeset" kernel command line parameter is
From: Mark Yacoub
[Why]
The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
unique to i915 driver.
Freeing up the function name for the more generic LUT checks to folllow
Tested on Eldrid ChromeOS (TGL).
v2:
1. Convert the enum to #define.
2. Add INTEL_COLOR_ prefix.
v1:
Stuff
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. Create |degamma_lut_
Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
> On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
>> +/**
>> + * drm_drv_enabled - Checks if a DRM driver can be enabled
>> + * @driver: DRM driver to check
>> + *
>> + * Checks whether a DRM driver can be enabled or not. This may be the case
On Thu, Nov 4, 2021 at 4:03 PM Mark Yacoub wrote:
>
> From: Mark Yacoub
>
> [Why]
> 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> or Degamma props in the new CRTC state, allowing any invalid size to
> be passed on.
> 2. Each driver has its own LUT size, which could
Some selftests assume that nothing will attempt to grab these bitlocks
while they are held by the selftests. With GuC, for example, that is
not true because the hanging workloads may cause the GuC code to attempt
to grab them for a global reset, and that may cause it to end up
sleeping on the bit n
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 8590419be4c6..e57307f82cf0 100644
--- a/drivers
On Thu, Nov 04, 2021 at 05:37:37PM +, Tvrtko Ursulin wrote:
On 03/11/2021 22:47, Umesh Nerlige Ramappa wrote:
Since the PMU callback runs in irq context, it synchronizes with gt
reset using the reset count. We could run into a case where the PMU
callback could read the reset count before it
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
URL : https://patchwork.freedesktop.org/series/96593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5a12af63b16e drm/i915/selftests: Use cl
== Series Details ==
Series: drm/i915/fbc: Prep work for multiple FBC instances
URL : https://patchwork.freedesktop.org/series/96574/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10841_full -> Patchwork_21518_full
Summary
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
URL : https://patchwork.freedesktop.org/series/96593/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10841 -> Patchwork_21521
=
On Thu, Nov 04, 2021 at 11:43:31AM -0700, Sripada, Radhakrishna wrote:
>Link: [1]File-List
>
>
>
>
>
>From: Patchwork
>Sent: Friday, October 15, 2021 6:48 PM
>To: Sripada, Radhakrishna
>Cc: intel-gfx@lists.freedesktop.org
>Subject: ✗ Fi.CI.IGT: failure for drm
== Series Details ==
Series: series starting with [v3,1/6] drm/i915/audio: group audio under
anonymous struct in drm_i915_private
URL : https://patchwork.freedesktop.org/series/96578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10841_full -> Patchwork_21519_full
===
Hi all,
On Thu, 28 Oct 2021 18:27:53 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>
> between commit:
>
> 5740211ea442 ("drm/i915/dmabuf: fix broken build")
>
> from the drm-intel tree
From: Sean Paul
Just me with another revision of HDCP support for msm.
This v4 patch series is mostly a retread of v3 with the following
changes:
- rebased on Bjorn's displayport-controller register refactor
- another change to the dt bindings to remove the compatible string added in v3
- update
From: Sean Paul
This patch moves the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Acked-by: Jani Nikula
Reviewed-by: Abhinav Kumar
Signed-off-by: Sean Paul
Link:
https:
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, simply return
true if the content protection value is changing and let the driver
decide whether a modeset is required or not.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/ms
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to
From: Sean Paul
This patch expands upon the HDCP helper library to manage HDCP
enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could m
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-6-s...@poorly.run
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-7-s..
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or fully
From: Sean Paul
Make includes alphabetical in dpu_kms.c
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-9-s...@poorly.run
#v1
Link:
https://patchwork.freede
From: Sean Paul
A couple more useless checks to remove in dpu_encoder.
Reviewed-by: Stephen Boyd
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-10-s...@poorly.run
#v1
Link:
https://
1 - 100 of 112 matches
Mail list logo
