== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev12)
URL : https://patchwork.freedesktop.org/series/68081/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev12)
URL : https://patchwork.freedesktop.org/series/68081/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
07f151724145 drm/i915/display: Add HDR Capability detection for LSPCON
015b28ecdd00
On 11/26/2020 1:07 PM, Anshuman Gupta wrote:
This is v6 version to test with IGT
https://patchwork.freedesktop.org/series/82987/
This v6 has added a new patch to series to avoid a crash reported on Chrome-OS
and has addressed the few cosmetics review comments from Ram.
It has been also tested
On 11/27/2020 5:34 AM, Chris Wilson wrote:
Quoting Xing Zhengjun (2020-11-26 01:44:55)
On 11/25/2020 4:47 AM, Chris Wilson wrote:
Quoting Oliver Sang (2020-11-19 07:20:18)
On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
Hi,
Could you add intel-gfx@lists.freedesktop.org
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip v5.10-rc5 next-20201126]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.10-rc5 next-20201126]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Quoting Xing Zhengjun (2020-11-26 01:44:55)
>
>
> On 11/25/2020 4:47 AM, Chris Wilson wrote:
> > Quoting Oliver Sang (2020-11-19 07:20:18)
> >> On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> >>> Hi,
> >>>
> >>> Could you add intel-gfx@lists.freedesktop.org into reports going
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next
Implemented Infoframes enabled readback for LSPCON devices.
This will help align the implementation with state readback
infrastructure.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
v3: Added pcon specific infoframe types instead of using the HSW
one's, as
This patch fixes the quantization range for YCbCr output on
Lspcon based devices.
v2: Re-phrased the description and added Ville's Rb.
Signed-off-by: Uma Shankar
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +++--
1 file changed, 11
Implement Read back of HDR metadata infoframes i.e Dynamic Range
and Mastering Infoframe for LSPCON devices.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
v3: Dropped a redundant wrapper as per Ville's comment.
v4: Dropped a redundant print, added Ville's RB.
Blanking needs to be reduced to incorporate DP and HDMI timing/link
bandwidth limitations for CEA modes (4k@60 at 10 bpp). DP can drive
17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
This will cause mode to blank out. Reduced Htotal by shortening the
back porch and front porch
Non-HDMI sinks shouldn't be sent Dynamic Range and Mastering infoframes.
Check for that when using LSPCON.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
Lspcon has Infoframes as well as DIP for HDR metadata(DRM Infoframe).
Create a separate mechanism for lspcon compared to HDMI in order to
address the same and ensure future scalability.
v2: Streamlined this as per Ville's suggestions, making sure that
HDMI infoframe versions are directly returned
Enable HDR for LSPCON based on Parade along with MCA.
v2: Added a helper for status reg as suggested by Ville.
v3: Removed a redundant variable, added Ville's RB.
Signed-off-by: Uma Shankar
Signed-off-by: Vipin Anand
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_lspcon.c
Dropped a irrelevant lspcon check from intel_hdmi_add_properties
function.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git
Enable HDMI Colorspace for LSPCON based devices. Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.
v2: Dropped state managed in drm core as
From: Ville Syrjälä
With LSPCON we use the AVI infoframe to convey the colorimetry
information (as opposed to DP MSA/SDP), so the property we expose
should match the values we can stuff into the infoframe. Ie. we
must use the HDMI variant of the property, even though we drive
LSPCON in PCON
Add a WARN to rule out an invalid output range and format
combination. This is to align the lspcon code with
compute_avi_infoframes.
Signed-off-by: Uma Shankar
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 4
1 file changed, 4 insertions(+)
diff --git
Content type is supported on HDMI sink devices. Attached the
property for the same for LSPCON based devices.
v2: Added the content type programming when we are attaching
the property to connector, as suggested by Ville.
Signed-off-by: Uma Shankar
Reviewed-by: Ville Syrjälä
---
Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Mastering
Attach HDR property for Gen9 devices with MCA LSPCON
chips.
v2: Cleaned HDR property attachment logic based on capability
as per Jani Nikula's suggestion.
v3: Fixed the HDR property attachment logic as per the new changes
by Kai-Feng to align with lspcon detection failure on some devices.
v4:
Gen9 hardware supports HDMI2.0 through LSPCON chips. Extending HDR
support for MCA and Parade LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.
v2: Addressed Jani
> -Original Message-
> From: Ville Syrjala
> Sent: Thursday, November 26, 2020 10:41 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma
> Subject: [PATCH] drm/i915: Split intel_attach_colorspace_property() into HDMI
> vs. DP variants
>
> From: Ville Syrjälä
>
> With LSPCON
== Series Details ==
Series: drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking
URL : https://patchwork.freedesktop.org/series/84305/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9395_full -> Patchwork_18991_full
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, November 26, 2020 10:43 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [v11 07/13] i915/display: Enable BT2020 for HDR on LSPCON devices
>
> On Thu, Nov 26, 2020 at 01:44:39PM +0530, Uma Shankar
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, November 26, 2020 11:14 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [v11 09/13] drm/i915/display: Implement infoframes readback for
> LSPCON
>
> On Thu, Nov 26, 2020 at 06:32:02PM +0200, Ville
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, November 26, 2020 9:56 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [v11 01/13] drm/i915/display: Add HDR Capability detection for
> LSPCON
>
> On Thu, Nov 26, 2020 at 01:44:33PM +0530, Uma
Quoting Tvrtko Ursulin (2020-11-26 18:58:20)
>
> On 26/11/2020 16:56, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-11-26 16:47:03)
> >> -static unsigned int config_enabled_bit(u64 config)
> >> +static unsigned int is_tracked_config(const u64 config)
> >> {
> >> - if
== Series Details ==
Series: drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP
variants
URL : https://patchwork.freedesktop.org/series/84309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9395 -> Patchwork_18992
On 26/11/2020 16:56, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-26 16:47:03)
-static unsigned int config_enabled_bit(u64 config)
+static unsigned int is_tracked_config(const u64 config)
{
- if (is_engine_config(config))
+ unsigned int val;
+/**
+ * Non-engine events
== Series Details ==
Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)
URL : https://patchwork.freedesktop.org/series/84293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9394_full -> Patchwork_18990_full
== Series Details ==
Series: drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking
URL : https://patchwork.freedesktop.org/series/84305/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9395 -> Patchwork_18991
On Thu, Nov 26, 2020 at 06:32:02PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 26, 2020 at 01:44:41PM +0530, Uma Shankar wrote:
> > Implemented Infoframes enabled readback for LSPCON devices.
> > This will help align the implementation with state readback
> > infrastructure.
> >
> > v2: Added
== Series Details ==
Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/84301/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9394_full -> Patchwork_18989_full
On Thu, Nov 26, 2020 at 01:44:39PM +0530, Uma Shankar wrote:
> Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
> data for HDR using AVI infoframe. LSPCON firmware expects this and though
> SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
> which
From: Ville Syrjälä
With LSPCON we use the AVI infoframe to convey the colorimetry
information (as opposed to DP MSA/SDP), so the property we expose
should match the values we can stuff into the infoframe. Ie. we
must use the HDMI variant of the property, even though we drive
LSPCON in PCON
Quoting Tvrtko Ursulin (2020-11-26 16:47:03)
> -static unsigned int config_enabled_bit(u64 config)
> +static unsigned int is_tracked_config(const u64 config)
> {
> - if (is_engine_config(config))
> + unsigned int val;
> +/**
> + * Non-engine events that we need to track
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven wrote:
>
> Hi Miguel,
>
> On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
> wrote:
> > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
> > > To make the intent clear, you have to first be certain that you
> > > understand the intent;
From: Tvrtko Ursulin
Adding any kinds of "last" abi markers is usually a mistake which I
repeated when implementing the PMU because it felt convenient at the time.
This patch marks I915_PMU_LAST as deprecated and stops the internal
implementation using it for sizing the event status bitmask and
On Thu, Nov 26, 2020 at 01:44:41PM +0530, Uma Shankar wrote:
> Implemented Infoframes enabled readback for LSPCON devices.
> This will help align the implementation with state readback
> infrastructure.
>
> v2: Added proper bitmask of enabled infoframes as per Ville's
> recommendation.
>
> v3:
On Thu, Nov 26, 2020 at 01:44:37PM +0530, Uma Shankar wrote:
> Add a WARN to rule out an invalid output range and format
> combination. This is to align the lspcon code with
> compute_avi_infoframes.
>
> Signed-off-by: Uma Shankar
Reviewed-by: Ville Syrjälä
> ---
>
On Thu, Nov 26, 2020 at 01:44:38PM +0530, Uma Shankar wrote:
> Content type is supported on HDMI sink devices. Attached the
> property for the same for LSPCON based devices.
>
> v2: Added the content type programming when we are attaching
> the property to connector, as suggested by Ville.
>
>
On Thu, Nov 26, 2020 at 01:44:36PM +0530, Uma Shankar wrote:
> This patch handles the quantization range for Lspcon.
I would state it as "fixes quantization range for YCbCr output" or
something along those lins.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Uma Shankar
> ---
>
On Thu, Nov 26, 2020 at 01:44:33PM +0530, Uma Shankar wrote:
> LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
> DPCD register. LSPCON implementations capable of supporting
> HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
> reads the same, detects the HDR
On 26/11/2020 15:48, Chris Wilson wrote:
After combining rapl_parse and imc_parse into a single pmu_parse, I left
the "energy-" prefixes used by rapl (but not imc) in place. Lift the
prefix to rapl_open() so that pmu_parse() does work for both rapl and
imc!
Reported-by: Tvrtko Ursulin
Fixes:
On Thu, Nov 26, 2020 at 02:08:41PM +, Chris Wilson wrote:
> Ville noticed that the last mocs entry is used unconditionally by the HW
> when it performs cache evictions, and noted that while the value is not
> meant to be writable by the driver, we should program it to a reasonable
> value
After combining rapl_parse and imc_parse into a single pmu_parse, I left
the "energy-" prefixes used by rapl (but not imc) in place. Lift the
prefix to rapl_open() so that pmu_parse() does work for both rapl and
imc!
Reported-by: Tvrtko Ursulin
Fixes: d0b71b967ccd ("tools/intel_gpu_top:
== Series Details ==
Series: drm/i915/perf: also include Gen11 in OATAILPTR workaround
URL : https://patchwork.freedesktop.org/series/84292/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9393_full -> Patchwork_18987_full
== Series Details ==
Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)
URL : https://patchwork.freedesktop.org/series/84293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9394 -> Patchwork_18990
Hi Miguel,
On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
wrote:
> On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
> > To make the intent clear, you have to first be certain that you
> > understand the intent; otherwise by adding either a break or a
> > fallthrough to suppress the warning
== Series Details ==
Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)
URL : https://patchwork.freedesktop.org/series/84293/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2eb485b74704 drm/i915/gt: Program mocs:63 for cache eviction on gen9
-:26:
== Series Details ==
Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/84301/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9394 -> Patchwork_18989
== Series Details ==
Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/84301/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
== Series Details ==
Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/84301/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
61722d006160 drm/i915/gt: Decouple completed requests on unwind
Quoting Ville Syrjälä (2020-11-26 14:08:24)
> On Thu, Nov 26, 2020 at 10:55:39AM +, Chris Wilson wrote:
> > Ville noticed that the last mocs entry is used unconditionally by the HW
> > when it performs cache evictions, and noted that while the value is not
> > meant to be writable by the
On Wed, 25 Nov 2020, Imre Deak wrote:
> On Fri, Nov 20, 2020 at 11:57:48AM -0800, José Roberto de Souza wrote:
>> Right now we are only explicitly handling the backlight of types
>> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE, INTEL_BACKLIGHT_DSI_DCS and
>> INTEL_BACKLIGHT_DISPLAY_DDI all others are
Ville noticed that the last mocs entry is used unconditionally by the HW
when it performs cache evictions, and noted that while the value is not
meant to be writable by the driver, we should program it to a reasonable
value nevertheless.
As it turns out, we can change the value of mocs:63 and the
On Thu, Nov 26, 2020 at 10:55:39AM +, Chris Wilson wrote:
> Ville noticed that the last mocs entry is used unconditionally by the HW
> when it performs cache evictions, and noted that while the value is not
> meant to be writable by the driver, we should program it to a reasonable
> value
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any.
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
v2: Tweak reference counting so that we only acquire a new reference on
adding to a signal list, as opposed to a hidden i915_request_put of the
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
In doing so, we remove the tasklet kick, introduced with the completion
checks in commit 35f3fd8182ba ("drm/i915/execlists: Workaround switching
back
On Thu, Nov 26, 2020 at 03:09:50PM +0530, Anshuman Gupta wrote:
> On 2020-11-25 at 18:24:44 +0200, Imre Deak wrote:
> > +Ville.
> Hi Ville ,
> Let me provide you some context over the issue which requires your input.
> TGL on chorome OS has observed some display glitches when brightness is being
== Series Details ==
Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9
URL : https://patchwork.freedesktop.org/series/84293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9393 -> Patchwork_18988
Summary
== Series Details ==
Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL : https://patchwork.freedesktop.org/series/82998/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9392_full -> Patchwork_18986_full
Summary
== Series Details ==
Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9
URL : https://patchwork.freedesktop.org/series/84293/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eb703e13ad7c drm/i915/gt: Program mocs:63 for cache eviction on gen9
-:24:
== Series Details ==
Series: drm/i915/perf: also include Gen11 in OATAILPTR workaround
URL : https://patchwork.freedesktop.org/series/84292/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9393 -> Patchwork_18987
Summary
On Wed, 16 Sep 2020, Lyude Paul wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915, but the story ended
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL : https://patchwork.freedesktop.org/series/68081/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9392_full -> Patchwork_18985_full
Summary
On Thu, 26 Nov 2020, Dave Airlie wrote:
> On Thu, 17 Sept 2020 at 03:19, Lyude Paul wrote:
>>
>> Currently, every different type of backlight hook that i915 supports is
>> pretty straight forward - you have a backlight, probably through PWM
>> (but maybe DPCD), with a single set of
On 25/11/2020 19:56, Chris Wilson wrote:
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
v2: Tweak reference counting so that we only acquire a new reference on
adding to a signal list, as
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of
Ville noticed that the last mocs entry is used unconditionally by the HW
when it performs cache evictions, and noted that while the value is not
meant to be writable by the driver, we should program it to a reasonable
value nevertheless.
As it turns out, we can change the value of mocs:63 and the
On Wed, 16 Sep 2020, Lyude Paul wrote:
> Since we're going to need to add a set of lower-level PWM backlight
> control hooks to be shared by normal backlight controls and HDR
> backlight controls in SDR mode, let's add a prefix to the external PWM
> backlight functions so that the difference
CI shows this workaround is also needed on Gen11.
Signed-off-by: Lionel Landwerlin
Fixes: 059a0beb486344 ("drm/i915/perf: workaround register corruption in
OATAILPTR")
---
drivers/gpu/drm/i915/i915_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, 16 Sep 2020, Lyude Paul wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
>
>
== Series Details ==
Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL : https://patchwork.freedesktop.org/series/82998/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9392 -> Patchwork_18986
Summary
---
== Series Details ==
Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL : https://patchwork.freedesktop.org/series/82998/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL : https://patchwork.freedesktop.org/series/82998/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fede738db387 drm/i915/hdcp: Update CP property in update_pipe
-:24: WARNING:COMMIT_LOG_LONG_LINE:
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL : https://patchwork.freedesktop.org/series/68081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9392 -> Patchwork_18985
Summary
---
On Wed, 25 Nov 2020 at 19:30, Chris Wilson wrote:
>
> Prior to sanitizing the GGTT, the only operations around in
> intel_display_init_nogem() are those to reserve the preallocated (and
> active) regions in the GGTT leftover from the BIOS. Trying to allocate a
> GGTT vma (such as
On 2020-11-25 at 18:24:44 +0200, Imre Deak wrote:
> +Ville.
Hi Ville ,
Let me provide you some context over the issue which requires your input.
TGL on chorome OS has observed some display glitches when brightness is being
updated
at very fast rate. This has surfaced out two issue.
1. Getting the
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL : https://patchwork.freedesktop.org/series/68081/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL : https://patchwork.freedesktop.org/series/68081/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e7d69665cf73 drm/i915/display: Add HDR Capability detection for LSPCON
b5fa510007a1
== Series Details ==
Series: series starting with [1/2] drm/i915/tgl: Fix REVID macros for TGL to
fetch correct stepping
URL : https://patchwork.freedesktop.org/series/84285/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9390_full -> Patchwork_18984_full
Hi Dave, Daniel,
Here's this week round of fixes for drm-misc
Maxime
drm-misc-fixes-2020-11-26:
A bunch of fixes for vc4 fixing some coexistence issue between wifi and
HDMI, unsupported modes, and vblank timeouts, a fix for ast to reload
the gamma LUT after changing the plane format and a
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Monday, November 23, 2020 8:27 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chery, Nanley G ; Rafael Antognolli
> ; Pandiyan, Dhinakaran
> ; Kondapally, Kalyan
>
> Subject: [Intel-gfx] [PATCH 1/2] drm/framebuffer:
91 matches
Mail list logo
