Hi,
Here's one left GVT fix against 5.9 is for kernel oops with VFIO edid
on BDW.
Thanks
--
The following changes since commit a291e4fba259a56a6a274c1989997acb6f0bb03a:
drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context
(2020-06-17 12:36:19 +0800)
are available in the Git
Hi
Am 15.09.20 um 17:25 schrieb Christian König:
> Added my rb to the amdgpu and radeon patches.
>
> Should we pick those up through the amd branches or do you want to push
> everything to drm-misc-next?
>
> I think the later since this should result in much merge clash.
Yes, preferable, I'd me
Hi
Am 15.09.20 um 17:05 schrieb Christian König:
> Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in amdgpu. The only exceptio
On Thu, Sep 17, 2020 at 12:39 AM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney
> > wrote:
> > >
> > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> > > > On Wed, Sep 16, 2020 at
Hi Dave & Daniel -
Due to the separate feature pull we haven't picked up gem fixes until
now. Here's the first batch; there's potentially a few more to come [1].
I also just received a gvt fixes pull that didn't make it this week, so
there are still more fixes coming.
BR,
Jani.
[1] http://lo
From: Thomas Hellström
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm
From: Thomas Hellström
With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function prototypes become
bloated passing the ww_acquire_ctx around. Furthermore it's not
always easy to get
A ww transaction utility intended to help removing the
obj->mm.lock from the driver and introduce ww transactions
in a robust way.
Patch 1/2 breaks the current i915 utilities out to separate files
Patch 2/2 introduces the ww transaction utility
A similar utility could easily be introduced in the
Op 11-09-2020 om 09:52 schreef Dan Carpenter:
> This code should use "vma[1]" instead of "vma". The "vma" variable is a
> valid pointer.
>
> Fixes: 6b05030496f7 ("drm/i915: Convert i915_gem_object/client_blt.c to use
> ww locking as well, v2.")
> Signed-off-by: Dan Carpenter
> Reviewed-by: Mika
On Tue, Sep 15, 2020 at 04:59:51PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in tegra.
>
> Signed-off-by: Thomas Zimmermann
> ---
> driver
== Series Details ==
Series: Introduce a ww transaction utility
URL : https://patchwork.freedesktop.org/series/81787/
State : failure
== Summary ==
Applying: drm/i915: Break out dma_resv ww locking utilities to separate files
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915
Hi Thomas,
On 09/15, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in vkms.
>
> Signed-off-by: Thomas Zimmermann
Thanks! Looks fine.
Reviewed-by: M
On Wed, Sep 16, 2020 at 09:45:28PM +0530, Vandita Kulkarni wrote:
> In TE Gate mode or TE NO_GATE mode on every flip
> we need to set the frame update request bit.
> After this bit is set transcoder hardware will
> automatically send the frame data to the panel
> in case of TE NO_GATE mode, where
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, September 17, 2020 5:01 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; B
> S,
> Karthik
> Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode
>
> On Wed, Sep 16, 2020 at 09
On Tue, Sep 15, 2020 at 04:03:45PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:47:56PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:38:57PM -0700, Navare, Manasi wrote:
> > > On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 14, 2020 at 1
On Tue, Sep 15, 2020 at 07:44:10PM -0700, José Roberto de Souza wrote:
> Due to the debugfs flag, has_psr2 in CRTC state could have a different
> value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
> and selective fetch) to be set to not a expected state.
>
> So here only taking
On Thu, Sep 17, 2020 at 11:56:44AM +, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Thursday, September 17, 2020 5:01 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> > B S,
> > Karthik
> > Subject: Re: [V12 4
On Tue, Sep 08, 2020 at 02:04:56PM -0400, Lyude Paul wrote:
> On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add helpers to get the TMDS clock limits for HDMI/DVI downstream
> > facing ports.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, September 17, 2020 6:08 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; B
> S,
> Karthik
> Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode
>
> On Thu, Sep 17, 2020 at 11
On Thu, Jul 30, 2020 at 06:45:14PM +0200, Thomas Hellström (Intel) wrote:
>
> On 7/30/20 3:17 PM, Daniel Vetter wrote:
> > On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
> > wrote:
> > >
> > > On 7/28/20 3:58 PM, Daniel Vetter wrote:
> > > > GPU drivers need this in their shrinkers, to
Hi Thomas,
On 09/15, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in vgem. The only exception is gem_prime_mmap,
> which is non-trivial to convert.
>
On Tue, 2020-09-15 at 12:57 -0700, Souza, Jose wrote:
> On Tue, 2020-09-15 at 20:28 +0100, Mun, Gwan-gyeong wrote:
> > On Mon, 2020-09-14 at 13:15 -0700, Souza, Jose wrote:
> > > On Mon, 2020-09-14 at 17:28 +0300, Ville Syrjälä wrote:
> > > > On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto d
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.9, v5.4.65, v4.19.145, v4.14.198,
v4.9.236, v4.4.236.
v5.8.9: Build OK!
v5.4.6
On Tue, Sep 08, 2020 at 02:34:24PM -0400, Lyude Paul wrote:
> With the nitpicks addressed (note there were a couple of other spots where we
> wanted to use Return: in the kdocs, but I didn't bother pointing all of them
> out), all but patch 07 is:
>
> Reviewed-by: Lyude Paul
Thanks for the revie
On Wed, Aug 26, 2020 at 02:24:50PM -0400, Lyude Paul wrote:
> This adds support for querying the maximum clock rate of a downstream
> port on a DisplayPort connection. Generally, downstream ports refer to
> active dongles which can have their own pixel clock limits.
>
> Note as well, we also start
The GuC communication enabled/disabled messages are too noisy in info
level. Convert them from info to debug level, and switch to device based
logging while at it.
Reported-by: Karol Herbst
Cc: Karol Herbst
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 --
1 file
On Thu, Sep 17, 2020 at 07:50:56PM +0300, Jani Nikula wrote:
> The GuC communication enabled/disabled messages are too noisy in info
> level. Convert them from info to debug level, and switch to device based
> logging while at it.
>
> Reported-by: Karol Herbst
> Cc: Karol Herbst
> Signed-off-by:
We have observed that Google Pixelbook's backlight hardware is
interpretting these backlight bits from the most-significant side of the
16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
assumes the peripheral cares about the least-significant bits.
Testing was done from within
Just an FYI, my plan for some of this eDP backlight code is to move as much of
it into helpers as possible since we need to implement the same interface in
nouveau. We probably can figure out some other solution for handling this quirk
if this isn't possible, but could we maybe use the panel's OUI
On Thu, Sep 17, 2020 at 11:09:06AM -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the periphera
On Thu, 17 Sep 2020, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the le
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify before
falling down the wrong hole: are you suggesting that I move
the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
the drm_dp_helper.c file?
On Thu, Sep 17, 2020 at
(resending as plain-text, my last mail was rejected by lots of
addresses for some reason)
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify
before falling down the wrong hole: are you suggesting that I move the
intel_dp_aux_set_backlight
== Series Details ==
Series: drm/i915/uc: tune down GuC communication enabled/disabled messages
URL : https://patchwork.freedesktop.org/series/81808/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9022 -> Patchwork_18520
Sum
Apologies for being too vague. To be as precise I can be, here is the
specific code delta I tested: https://crrev.com/c/2406616 . To answer
your other question, the code I tested against is indeed including the
fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
message): our current top
== Series Details ==
Series: i915: Introduce quirk for shifting eDP brightness.
URL : https://patchwork.freedesktop.org/series/81809/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8c6e983afa60 i915: Introduce quirk for shifting eDP brightness.
-:34: CHECK:PARENTHESIS_ALIGNMENT:
The Lyude fde7266fb2f6 change is actually based on Chromium change
(https://crrev.com/c/1650325) that fixes the brightness for Samsung
Galaxy Chromebook. So currently we have 2 examples that use LSB
interpretation and 1 that use MSB.
On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
>
> Apol
On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> The Lyude fde7266fb2f6 change is actually based on Chromium change
> (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> Galaxy Chromebook. So currently we have 2 examples that use LSB
> interpretation and 1
== Series Details ==
Series: i915: Introduce quirk for shifting eDP brightness.
URL : https://patchwork.freedesktop.org/series/81809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9022 -> Patchwork_18521
Summary
---
On Thu, 2020-09-17 at 21:25 +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So
On Thu, 2020-09-17 at 11:31 -0600, Kevin Chowski wrote:
> Thanks very much for the quick reply, Lyude!
>
> I'm happy to make the requested changes, but I wanted to clarify before
> falling down the wrong hole: are you suggesting that I move
> the intel_dp_aux_set_backlight/intel_dp_aux_get_backlig
== Series Details ==
Series: drm/i915/uc: tune down GuC communication enabled/disabled messages
URL : https://patchwork.freedesktop.org/series/81808/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9022_full -> Patchwork_18520_full
===
From: Thomas Hellström
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm
A ww transaction utility intended to help removing the
obj->mm.lock from the driver and introduce ww transactions
in a robust way.
Patch 1/2 breaks the current i915 utilities out to separate files
Patch 2/2 introduces the ww transaction utility
A similar utility could easily be introduced in the
From: Thomas Hellström
With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function prototypes become
bloated passing the ww_acquire_ctx around. Furthermore it's not
always easy to get
== Series Details ==
Series: Introduce a ww transaction utility (rev2)
URL : https://patchwork.freedesktop.org/series/81787/
State : failure
== Summary ==
Applying: drm/i915: Break out dma_resv ww locking utilities to separate files
error: sha1 information is lacking or useless
(drivers/gpu/d
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 01/20] drm/i915: Fix state checker
> hw.active/hw.enable readout
>
> From: Ville Syrjälä
>
> Previously intel
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/20] drm/i915: Move MST master transcoder dump
> earlier
>
> From: Ville Syrjälä
>
> Move the MST master tr
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/20] drm/i915: Include the LUT sizes in the
> state
> dump
>
> From: Ville Syrjälä
>
> Dump the sizes of t
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/20] drm/i915:
> s/glk_read_lut_10/bdw_read_lut_10/
>
> From: Ville Syrjälä
>
> glk_read_lut_10() works jus
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/20] drm/i915: Reset glk degamma index after
> programming/readout
>
> From: Ville Syrjälä
>
> Just for som
On 9/9/2020 1:55 PM, Keith Busch wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index eea0f453cfb6..8aac5bc60f4c 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -2464,7 +2464,7 @@ static int do_test(const
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/20] drm/i915: Shuffle chv_cgm_gamma_pack()
> around a bit
>
> From: Ville Syrjälä
>
> Move chv_cgm_gamma_p
== Series Details ==
Series: i915: Introduce quirk for shifting eDP brightness.
URL : https://patchwork.freedesktop.org/series/81809/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9022_full -> Patchwork_18521_full
Summary
-
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 07/20] drm/i915: Relocate CHV CGM gamma masks
>
> From: Ville Syrjälä
>
> CGM_PIPE_GAMMA_RED_MASK & co. are m
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/20] drm/i915: Add glk+ degamma readout
>
> From: Ville Syrjälä
>
> Read out the degamma LUT on glk+. No st
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 09/20] drm/i915: Read out CHV CGM degamma
>
> From: Ville Syrjälä
>
> Since CHV has the dedicate CGM degamma
On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebo
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 10/20] drm/i915: Add gamma/degamma readout for
> bdw+
>
> From: Ville Syrjälä
>
> Read out the gamme/degamma
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 11/20] drm/i915: Do degamma+gamma readout in
> bdw+ split gamma mode
>
> From: Ville Syrjälä
>
> Read out bot
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 14/20] drm/i915: Replace some gamma_mode ifs with
> switches
>
> From: Ville Syrjälä
>
> Since gamma_mode can
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 15/20] drm/i915: Make ilk_load_luts() deal with
> degamma
>
> From: Ville Syrjälä
>
> Make ilk_load_luts() re
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 16/20] drm/i915: Make ilk_read_luts() capable of
> degamma readout
>
> From: Ville Syrjälä
>
> Just like ivb+
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 12/20] drm/i915: Polish bdw_read_lut_10() a bit
>
> From: Ville Syrjälä
>
> Since bdw_read_lut_10() uses the
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 18/20] drm/i915: Extract ilk_crtc_has_gamma() &
> co.
>
> From: Ville Syrjälä
>
> Extract a few helpers to c
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 13/20] drm/i915: Add gamma/degamm readout for
Typo in degamma.
With this fixed,
Reviewed-by: Uma Shankar
> iv
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 17/20] drm/i915: Make .read_luts() mandatory
>
> From: Ville Syrjälä
>
> Every platform now implemnts .read_l
From: Ville Syrjälä
When validating a "YCbCr 4:2:0 only" mode we must take into
account the fact that we're going to be outputting YCbCr
4:2:0 or 4:4:4 (when a DP->HDMI protocol converter is doing
the 4:2:0 downsampling). For YCbCr 4:4:4 the minimum output
bpc is 8, for YCbCr 4:2:0 it'll be half
From: Ville Syrjälä
Refactor the output_format calculation into a helper so that
we can reuse it for mode validation as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 32 +++--
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a
From: Ville Syrjälä
Pass the output_format directly to intel_dp_{min,output}_bpp()
rather than passing in the crtc_state and digging out the
output_format inside the functions. This will allow us to reuse
the functions for mode validation purposes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/
== Series Details ==
Series: series starting with [1/3] drm/i915: Extract intel_dp_output_format()
URL : https://patchwork.freedesktop.org/series/81815/
State : failure
== Summary ==
Applying: drm/i915: Extract intel_dp_output_format()
error: sha1 information is lacking or useless
(drivers/gp
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 19/20] drm/i915: Complete the gamma/degamma
> state checking
>
> From: Ville Syrjälä
>
> Add new .gamma_equal
On Fri, Sep 18, 2020 at 12:43:33AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Refactor the output_format calculation into a helper so that
> we can reuse it for mode validation as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 32 +++
On Fri, Sep 18, 2020 at 12:43:34AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pass the output_format directly to intel_dp_{min,output}_bpp()
> rather than passing in the crtc_state and digging out the
> output_format inside the functions. This will allow us to reuse
> the functions for
On Fri, Sep 18, 2020 at 12:43:35AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When validating a "YCbCr 4:2:0 only" mode we must take into
> account the fact that we're going to be outputting YCbCr
> 4:2:0 or 4:4:4 (when a DP->HDMI protocol converter is doing
> the 4:2:0 downsampling).
From: Sean Paul
In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
DPCD control mode"), we fixed the brightness level when DPCD control was
not active to max brightness. This is as good as we can guess since most
backlights go on full when uncontrolled.
However in doing so we
Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.
v2:
- removed warn on when no plane is visibl
For platforms without selective fetch this register is reserved so
do not write 0 to it.
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
Due to the debugfs flag, has_psr2 in CRTC state could have a different
value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
and selective fetch) to be set to not a expected state.
So here only taking in consideration the parameter and debugfs flag
when computing PSR state, this wa
== Series Details ==
Series: drm/i915/dp: Tweak initial dpcd backlight.enabled value
URL : https://patchwork.freedesktop.org/series/81821/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9023 -> Patchwork_18524
Summary
--
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Ignore
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL : https://patchwork.freedesktop.org/series/81824/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9023 -> Patchwork_18525
== Series Details ==
Series: drm/i915/dp: Tweak initial dpcd backlight.enabled value
URL : https://patchwork.freedesktop.org/series/81821/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9023_full -> Patchwork_18524_full
Summ
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Ignore
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL : https://patchwork.freedesktop.org/series/81824/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9023_full -> Patchwork_18525_full
==
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/3] drm/i915: Extract intel_dp_output_format()
>
> From: Ville Syrjälä
>
> Refactor the output_format calcu
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Decouple intel_dp_{min,
> output}_bpp() from crtc_state
>
> From: Ville Syrjälä
>
> Pass the
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915: Use the correct bpp when
> validating "4:2:0 only" modes
>
> From: Ville Syrjälä
>
> When val
Hello Thomas,
On Mon, 14 Sep 2020 at 16:55, Thomas Zimmermann wrote:
>
> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
> of dma-buf memory in kernel address space. The functions operate with plain
> addresses and the assumption is that the memory can be accessed with
87 matches
Mail list logo
