From: Ville Syrjälä
The gamma readout stuff was left half finished. No degamma
readout, and no readout whatsoever on ivb/bdw/skl/bxt.
Let's finish it.
Since we have the {pre,post}_csc_lut stuff this is fairly
easy to do now. The implementation of the LUT checker is
a bit more repetitive than I'd
From: Ville Syrjälä
Use consistent bit definitions for the legacy gamma LUT. We just
define these alongside the pre-ilk register definitions and point
to those from the ilk+ defines.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Signed-off-by: Ville Syrjälä
---
driv
From: Ville Syrjälä
Use consistent bit definitions for the 10bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the ivb+ defines.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Signed-off-by: Ville Syrjäl
From: Ville Syrjälä
Add the missing ldw vs. udw information to the CGM (de)gamma
bit definitions to make it a bit easier to see which should
be used where.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/in
From: Ville Syrjälä
Use consistent bit definitions for the 12.4bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the icl+ superfine segment defines (and we also
already pointed to them from the ivb+ precision palette defines).
Als
From: Ville Syrjälä
The degamma LUT is interpolated so we need the 128th (==1.0)
entry to represent the full < 1.0 input range. Only the 129th
and 130th entries are strictly for the >=1.0 extended range
inputs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file cha
From: Ville Syrjälä
Since CHV has the dedicate CGM degamma unit readout is trivial.
Just do it.
v2: deal with post_csc_lut
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 36 ++
1 file changed, 36 insertions(+)
diff
From: Ville Syrjälä
Satisfy my ocd and define ilk_lut_12p4_ldw() before ilk_lut_12p4_udw().
That is the order all the other similar functions use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
From: Ville Syrjälä
Just like ivb+, ilk/snb can select whether the hw lut acts as
gamma or degamma. Make the readout cognizant of that fact.
v2: deal with pre_csc_lut
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 10 +-
1 file
From: Ville Syrjälä
Read out the degamma LUT on glk+. No state cheker as of yet since
it requires dealing with the glk csc vs. degamma mess.
v2: deal with post_csc_lut
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 44 ++
From: Ville Syrjälä
We now have all the code necessary for gamma/degamma readout on
ivb/hsw. Plug it all in. As with bdw+ the cooked {pre,post}_csc_lut
make this trivial even in split gamma mode.
Note that on HSW if IPS is enabled the hardware will hang if
you try to access the LUT in split gamm
From: Ville Syrjälä
We have full readout now for all platforms (sans the icl+
multi-segment readout hw fail), so hook up the LUT state
checker for everyone.
We add a new vfunc for this since different platforms need
to handle the details a bit differently.
The implementation is rather repetitiv
From: Ville Syrjälä
On glk we can no longer reorder the hw LUTS vs. pipe CSC like
we could on eaerlier platforms, and neither do we have a
separate output CSC like on icl+. That means if we use the
pipe CSC for YCbCr output we are currently applying the gamma
LUT after the RGB->YCbCr conversion,
From: Ville Syrjälä
Currently crtc_state_is_legacy_gamma() has a very specific set
of conditions, not all of which are actually necessary. Also
Also when we detect those conditions check_luts() just skips
all the checks. That will no longer work for glk soon when we'll
start to use the hw degamma
From: Ville Syrjälä
Every platform now implemnts .read_luts(). Make it mandatory.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915
From: Ville Syrjälä
Read out the gamma/degamma LUT on bdw+. Now that the
{pre,post}_csc_lut match the hardware LUT size even
in split gamma mode this is trivial.
v2: deal with {pre,post}_csc_lut
split gamma is no longer a problem
Reviewed-by: Uma Shankar #v1
Signed-off-by: Ville Syrjälä
-
From: Ville Syrjälä
On ilk+ and glk class hardware we current make a mess of
things when we have to both generate limited range output
and use the hw gamma LUT. Since we do the range compression
using the pipe CSC unit (which is situated before the gamma
LUT in the pipe) we are in fact applying t
From: Ville Syrjälä
Some gen2/gen3 parts have a 10bit gamma mode, on some pipes.
Expose it.
The format is different to the later i965+ style in that we
store a 10bit value and a 6 bit floating point slope for each
entry. Ie. the hardware extrapolates the intermediate steps
from the current LUT e
From: Ville Syrjälä
In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.
Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening. May
Hi Dave, Daniel,
Here's this week drm-misc-next PR.
It looks like Daniel put a fixup for nouveau in drm-tip that I have to
remind you about :)
Maxime
drm-misc-next-2022-11-10-1:
drm-misc-next for 6.2:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- atomic-helper: Add begin_fb_access a
Hi Dave, Daniel,
Some more fixes for the release candidate window.
Most important are the SG table handling fix for map_dma_buf import, the
userptr probe fixup after VMA iterator conversion and then a display/mouse
stuttering fix for PSR2. Last one only relates to discrete platforms, so
still beh
Hi,
On Mon, Nov 07, 2022 at 06:49:57PM +0100, Noralf Trønnes wrote:
> Den 07.11.2022 15.16, skrev Maxime Ripard:
> > The framework will get the drm_display_mode from the drm_cmdline_mode it
> > got by parsing the video command line argument by calling
> > drm_connector_pick_cmdline_mode().
> >
>
Use HAS_DSC(__i915) wrapper containing runtime info of has_dsc
member. Platforms supporting dsc has this flag enabled; no need of
DISPLAY_VER() check.
Also, simplified intel_dsc_source_support() based on above changes.
Suggested-by: Jani Nikula
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i
Thanks Jani/Manasi for the review comments.
Have addressed those in https://patchwork.freedesktop.org/patch/511033/
On 04-Nov-22 3:58 PM, Jani Nikula wrote:
On Thu, 03 Nov 2022, "Navare, Manasi" wrote:
On Thu, Nov 03, 2022 at 11:32:22AM +0530, Swati Sharma wrote:
Lets use RUNTIME_INFO->has_ds
On 09/11/2022 17:46, John Harrison wrote:
On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wr
On 09/11/2022 19:57, Michal Wajdeczko wrote:
[snip]
Is it really a problem to merge this patch now to get the process
started? And other sub-components get updated as and when people get the
time to do them? You could maybe even help rather than posting
completely conflicting patch sets that
Hi,
On 09/11/2022 18:03, Thomas Hellström wrote:
Hi, Andi,
This has been on the list before (three times I think) and at that
point it (the guard pages) was NAK'd by Daniel as yet another
complication, and a VT-d
scanout workaround was implemented and pushed using a different
approach, initia
On Tue, Nov 08, 2022 at 05:18:26PM +0200, Imre Deak wrote:
> Factor out functions to get/put the AUX_IO power domain for the main
> link on DDI ports.
>
> While at it clarify the corresponding code comment.
>
> No functional change.
>
> v2:
> - s/(get/put)_aux_power_for_main_link/main_link_aux_p
Hi Thomas,
> This has been on the list before (three times I think) and at that
> point it (the guard pages) was NAK'd by Daniel as yet another
> complication, and a VT-d
> scanout workaround was implemented and pushed using a different
> approach, initially outlined by Daniel.
I reckon that this
On Wed, 09 Nov 2022, Michal Wajdeczko wrote:
> Instead of merging this patch now, oriented on GT only, I would rather
> wait until we discuss and plan solution for the all sub-components.
>
> Once that's done (with agreement on naming and output) we can start
> converting exiting messages.
>
> My
On 10.11.2022 10:55, Tvrtko Ursulin wrote:
>
> On 09/11/2022 19:57, Michal Wajdeczko wrote:
>
> [snip]
>
>>> Is it really a problem to merge this patch now to get the process
>>> started? And other sub-components get updated as and when people get the
>>> time to do them? You could maybe even
On Tue, Nov 08, 2022 at 10:40:07AM +0100, Noralf Trønnes wrote:
>
>
> Den 07.11.2022 18.49, skrev Noralf Trønnes:
> >
> >
> > Den 07.11.2022 15.16, skrev Maxime Ripard:
> >> The framework will get the drm_display_mode from the drm_cmdline_mode it
> >> got by parsing the video command line argum
On Tue, Nov 08, 2022 at 05:18:27PM +0200, Imre Deak wrote:
> Combo PHY ports require the AUX_IO power only for eDP/PSR, so don't
> enable it otherwise on these ports. So far the external DP and eDP case
> was handled the same way due to unclarity when AUX_IO for the main link
> is needed. However B
On Wed, Nov 09, 2022 at 05:55:36PM +0100, Lukas Satin wrote:
> That's great, I will test it on Ubuntu + Nouveau x86_64 and Batocera-Linux.
>
> I'm not interested in Raspberry Pi. I see you have some commit in
> RaspberryPi/Linux. Will this go to some Nouveau driver, so I can test it on
> x86_64 ma
On Thu, 10 Nov 2022, Ville Syrjälä wrote:
> On Tue, Nov 08, 2022 at 05:18:26PM +0200, Imre Deak wrote:
>> +static void
>> +main_link_aux_power_domain_put(struct intel_digital_port *dig_port,
>> + const struct intel_crtc_state *crtc_state)
>> +{
>> +struct drm_i915_pri
Hi!
On Wed, Nov 09, 2022 at 02:15:29AM +0100, Mateusz Kwiatkowski wrote:
> I ran your v7 patchset on my Pi with Xorg, and the mode switching, as well as
> the preferred mode handling, all work really well now!
Thanks again for all your help
> I just noted that the downstream version of the vc4 d
Hi,
Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.
The named modes support were initially introduced to allow to specify the
analog TV mode to be used.
However, this was causing multiple issues:
* The
As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.
Let's add a file meant to provide those kind of helpers to avoid
duplication.
Reviewed-by: No
The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.
Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away
The drm_create_tv_properties() will create the TV mode property
unconditionally.
However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.
Acked-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-
drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.
However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that fu
The current named mode parsing relies only on the mode name, and doesn't
allow to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwi
The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.
Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and
On 09.11.2022 11:46, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
v2:
* Don't have struct drm_device as local. (Jani, Ville)
v3:
* Store gt, not i915, in workaround list. (
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usual
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v7:
- Add
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Reviewed-by: Noralf Trønnes
Tested-by: M
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Acked-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-
Commit 3aeeb13d8996 ("drm/modes: Support modes names on the command
line") initially introduced the named modes support by essentially
matching the name passed on the command-line to the mode names defined
by the drivers.
This proved to be difficult to work with, since all drivers had to
provide p
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.
The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though, the
From: Noralf Trønnes
Most of the TV connectors will need a similar get_modes implementation
that will, depending on the drivers' capabilities, register the 480i and
576i modes.
That implementation will also need to set the preferred flag and order
the modes based on the driver and users preferre
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Renamed the tests to follow DRM test namin
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV atomic_check
Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.
Let's add some code to allow it, and some unit tests to exercise that code.
Reviewed-by:
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
Tes
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Convert to new get_modes helper
Changes in v5:
- Removed the count var
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
broadcas
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by: Mate
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
drivers/gpu
On Thu, 10 Nov 2022, Swati Sharma wrote:
> Use HAS_DSC(__i915) wrapper containing runtime info of has_dsc
> member. Platforms supporting dsc has this flag enabled; no need of
> DISPLAY_VER() check.
>
> Also, simplified intel_dsc_source_support() based on above changes.
>
> Suggested-by: Jani Nikul
On Wed, 09 Nov 2022, Anusha Srivatsa wrote:
> cdclk_sanitize() function was written assuming vco was a signed integer.
> vco gets assigned to -1 (essentially ~0) for the case where PLL
> might be enabled and vco is not a frequency that will ever
> get used. In such a scenario the right thing to do
On Wednesday, 9 November 2022 20:09:34 CET Janusz Krzysztofik wrote:
> Fixes for issues discovered via code review while working on
> https://gitlab.freedesktop.org/drm/intel/issues/7349.
>
> Janusz Krzysztofik (3):
> drm/i915: Fix timeout handling when retiring requests
> drm/i915: Fix uninte
On 10/11/2022 11:07, Andrzej Hajda wrote:
On 09.11.2022 11:46, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
v2:
* Don't have struct drm_device as local. (Jani, Ville)
v3:
On Thu, Nov 10, 2022 at 12:37:30PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 08, 2022 at 05:18:27PM +0200, Imre Deak wrote:
> > Combo PHY ports require the AUX_IO power only for eDP/PSR, so don't
> > enable it otherwise on these ports. So far the external DP and eDP case
> > was handled the same wa
On Thu, Nov 10, 2022 at 12:21:26PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 08, 2022 at 05:18:26PM +0200, Imre Deak wrote:
> > Factor out functions to get/put the AUX_IO power domain for the main
> > link on DDI ports.
> >
> > While at it clarify the corresponding code comment.
> >
> > No functi
From: Tvrtko Ursulin
Since we are now storing the GT backpointer in the wa list we can drop the
explicit struct intel_gt * argument to wa_list_apply.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
1 file changed, 5 insertions(+
From: Ville Syrjälä
Read out the ELD from the hw so the state checker can verify it.
v2: Check the "ELD valid" bit separately
v3: Fix ELD tx rate handling during readout
Cc: Chaitanya Kumar Borah
Cc: Kai Vehmanen
Cc: Takashi Iwai
Reviewed-by: Jani Nikula #v1
Signed-off-by: Ville Syrjälä
--
On 07.11.2022 16:30, Lucas De Marchi wrote:
> There were several updates in the driver on how the workarounds are
> handled since its documentation was written. Update the documentation to
> reflect the current reality.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_wor
> -Original Message-
> From: Ville Syrjala
> Sent: Wednesday, November 9, 2022 4:47 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh
> Subject: [PATCH 4/6] drm/i915: Try to use the correct power sequencer
> intiially
> on bxt/glk
>
> From: Ville Syrjälä
>
> Currently on
> -Original Message-
> From: Ville Syrjala
> Sent: Wednesday, November 9, 2022 4:47 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh
> Subject: [PATCH 5/6] drm/915: Extend dual PPS handlind for ICP+
>
> From: Ville Syrjälä
>
> On the PCH side the second PPS was introduce
Tvrtko Ursulin writes:
> From: Tvrtko Ursulin
>
> Since we are now storing the GT backpointer in the wa list we can drop the
> explicit struct intel_gt * argument to wa_list_apply.
There is room for more dropping, all the platform lists inits.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andrzej Ha
On Thu, Nov 10, 2022 at 01:56:46PM +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Ville Syrjala
> > Sent: Wednesday, November 9, 2022 4:47 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Manna, Animesh
> > Subject: [PATCH 4/6] drm/i915: Try to use the correct power
On Wed, Nov 09, 2022 at 01:16:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On the PCH side the second PPS was introduced in ICP. Let's
> make sure we examine both power sequencer on ICP+ as well.
>
> Note that DG1/2 south block only has the single PPS, so need
> to exclude the fake
On 10/11/2022 05:49, Niranjana Vishwanathapura wrote:
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
buffer objects (BOs) or sections of a BOs
On 10/11/2022 05:31, Mani Milani wrote:
At present, the gpu thread crashes at times when grab_vma() attempts to
acquire a gem object lock when in a deadlock state.
Problems:
I identified the following 4 issues in the current code:
1. Since grab_vma() calls i915_gem_object_trylock(), which conseq
On 10/11/2022 14:47, Tvrtko Ursulin wrote:
On 10/11/2022 05:49, Niranjana Vishwanathapura wrote:
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GE
Panel Replay is a power saving feature for DP 2.0 monitor and similar
to PSR on EDP.
These patches are basic enablement patches added on top of
existing psr framework to enable full-screen live active frame
update mode of panel replay. Panel replay also can be enabled
in selective update mode whic
Platforms having Display 13 and above will support panel
replay feature of DP 2.0 monitor. Added a HAS_PANEL_REPLAY()
macro to check for panel replay capability.
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git
DPCD register definition added to check and enable panel replay
capability of the sink.
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
include/drm/display/drm_dp.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
i
TRANS_DP2_CTL register is programmed to enable panel replay from source
and sink is enabled through panel replay dpcd configuration address.
Note: Currently enabled full-screen live active frame update mode
of panel replay. Panel replay also can be enabled in selective
update mode which will be en
As panel replay feature similar to PSR feature of EDP panel, so currently
utilized existing psr framework for panel replay.
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 15 +++
drivers/gpu/drm/i915/display/intel_dp.c | 44
On Thu, 2022-11-10 at 14:49 +, Matthew Auld wrote:
> On 10/11/2022 05:31, Mani Milani wrote:
> > At present, the gpu thread crashes at times when grab_vma()
> > attempts to
> > acquire a gem object lock when in a deadlock state.
> >
> > Problems:
> > I identified the following 4 issues in the
On Wed, Nov 09, 2022 at 05:28:59PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl
== Series Details ==
Series: series starting with [1/4] drm/i915/hti: abstract hti handling
URL : https://patchwork.freedesktop.org/series/110712/
State : warning
== Summary ==
Error: dim checkpatch failed
47ca7795e29c drm/i915/hti: abstract hti handling
Traceback (most recent call last):
Fi
== Series Details ==
Series: series starting with [1/4] drm/i915/hti: abstract hti handling
URL : https://patchwork.freedesktop.org/series/110712/
State : warning
== Summary ==
Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or
On Thu, 10 Nov 2022 06:57:57 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, November 10, 2022 3:53 AM
> >
> > On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
> >
> > > DPDK supports no-iommu mode.
> >
> > Er? Huh? How? I thought no-iommu was for
On Thu, Nov 10, 2022 at 03:11:16AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, November 8, 2022 8:53 AM
> >
> > +
> > +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> > +{
> > + u32 ioas_id;
> > + u32 device_id;
> > + int ret;
> > +
> >
Fix live busy stats selftest failure in BAT. The issue is seen more easily on
DG1 runs.
v2: (Tvrtko)
In addition refactor intel_uncore_read64_2x32 to obtain the forcewake
once before reading upper and lower register dwords.
v3: (Ashutosh)
Update commit msg
Signed-off-by: Umesh Nerlige Ramappa
Engine busyness samples around a 10ms period is failing with busyness
ranging approx. from 87% to 115% as shown below. The expected range is
+/- 5% of the sample period. Fail 10% of the time.
rcs0: reported 11716042ns [91%] busyness while spinning [for 12805719ns]
When determining busyness of act
PMU reads the GT timestamp as a 2x32 mmio read and since upper and lower
32 bit registers are read in a loop, there is a latency involved between
getting the GT timestamp and the CPU timestamp. As part of the
resolution, refactor intel_uncore_read64_2x32 to acquire forcewake and
uncore lock prior t
== Series Details ==
Series: series starting with [1/4] drm/i915/hti: abstract hti handling
URL : https://patchwork.freedesktop.org/series/110712/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12365 -> Patchwork_110712v1
Su
On Thu, Nov 10, 2022 at 01:28:19PM +0200, Jani Nikula wrote:
> On Wed, 09 Nov 2022, Anusha Srivatsa wrote:
> > cdclk_sanitize() function was written assuming vco was a signed integer.
> > vco gets assigned to -1 (essentially ~0) for the case where PLL
> > might be enabled and vco is not a frequenc
On Thu, Nov 10, 2022 at 06:57:57AM +, Tian, Kevin wrote:
> > + /*
> > +* Emulation for NOIMMU is imperfect in that VFIO blocks almost all
> > +* other ioctls. We let them keep working but they mostly fail since no
> > +* IOAS should exist.
> > +*/
> > + if (IS_ENABLED(CONFI
Invalidating the GuC TLBs while GuC is not loaded does not have negative
consequences, so if we're starting the driver with GuC enabled we can
use the GGTT invalidation function from the get-go, iinstead of switching
to it when we initialize the GuC objects.
In MTL, this fixes and issue where we t
== Series Details ==
Series: drm/i915: header cleanups, cont'd
URL : https://patchwork.freedesktop.org/series/110716/
State : warning
== Summary ==
Error: dim checkpatch failed
a1c8e7edfaca drm/i915/reg: move masked field helpers to i915_reg_defs.h
-:48: CHECK:MACRO_ARG_REUSE: Macro argument r
== Series Details ==
Series: drm/i915: header cleanups, cont'd
URL : https://patchwork.freedesktop.org/series/110716/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, Nov 08, 2022 at 05:18:25PM +0200, Imre Deak wrote:
> Starting with TGL eDP is supported on ports B+ (besides port A), so make
> sure DC states are not blocked on any such ports. For this add an
> AUX_IO_ power domain for each port with eDP support. These domains
> similarly to AUX_IO_A enab
1 - 100 of 187 matches
Mail list logo
