== Series Details ==
Series: drm/i915/gem: conversion to new drm logging macros
URL : https://patchwork.freedesktop.org/series/72454/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7802_full -> Patchwork_16231_full
Summary
== Series Details ==
Series: conversion to struct drm_device logging macros. (rev2)
URL : https://patchwork.freedesktop.org/series/72349/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7802_full -> Patchwork_16230_full
== Series Details ==
Series: drm/i915/display: conversion to new struct drm_device logging macros.
URL : https://patchwork.freedesktop.org/series/72456/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7802_full -> Patchwork_16229_full
This Gem related failure is not relevant to this patch, but because of this it
doesn’t run full IGT, I want to make sure that the kms_flip tests are not
getting hung.
Or can we confirm this with manual testing?
Manasi
-Original Message-
From: Patchwork
Sent: Friday, January 24, 2020
== Series Details ==
Series: drm/i915/dp: Modeset only the tiled connectors with CRTC
URL : https://patchwork.freedesktop.org/series/72559/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16267
Summary
== Series Details ==
Series: Start separating GuC and execlists submission
URL : https://patchwork.freedesktop.org/series/72562/
State : failure
== Summary ==
Applying: drm/i915/guc: Add guc-specific breadcrumb functions
error: sha1 information is lacking or useless
On 24/01/2020 03:37, Umesh Nerlige Ramappa wrote:
Engine context pinned in perf OA was set to same context id as
the idle context. Set the context id to an unused value.
Clear the sw context id field in lrc descriptor before ORing with
ce->tag (Chris)
Fixes:
== Series Details ==
Series: drm/i915/gvt: fix high-order allocation failure on late load
URL : https://patchwork.freedesktop.org/series/72455/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7802_full -> Patchwork_16228_full
== Series Details ==
Series: drm/i915/dp: Modeset only the tiled connectors with CRTC
URL : https://patchwork.freedesktop.org/series/72559/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bb6a759231f4 drm/i915/dp: Modeset only the tiled connectors with CRTC
-:11:
== Series Details ==
Series: drm/i915: Remove 'prefault_disable' modparam
URL : https://patchwork.freedesktop.org/series/72557/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16266
Summary
---
The flush commands are independent from the submission method, so we can
re-use the same code.
RFC: I've kept the function in intel_lrc.c for now as my current plan is
to keep the common code there and split out execlists_submission out,
but maybe intel_gpu_commands.c would be a better location?
Similar to the execlists one, but we don't handle the STOP_RING (because
GuC owns the engine status) and we leave the CSB fifo at 6 deep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
Code is still very similar to the execlists side, with some
simplifications, but it will diverge soon once we start adding the async
communication with GuC.
Most of the code as been duplicated, with the exception of hw objects
(ce->state, ring) and lrc contents, because these map to HW
Copy the submit_request function (with a small simpliication) and set
the engine flags independently. No preemption or semaphore support yet
on the GuC side.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
Note: this applies on top of my series to commit early to GuC [1].
Picking up from the feedback from my RFC series about splitting
up intel_lrc.c [2], this series introduces GuC submission versions
of most of the engine and context functions. As a starting point,
the functions are still very
They're still mostly the same as the execlists ones, with the main
difference being that there is no busywait on the GuC side.
Since we now have multiple vfuncs set dutring setup, start compacting
them in their own helper.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal
A straight copy of the execlists one to begin with. Tweaks will come
later if needed.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 35 +++
1 file changed,
== Series Details ==
Series: drm/i915/tgl: Suppress DC5/DC6 around DSB usage (rev2)
URL : https://patchwork.freedesktop.org/series/72549/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16265
Summary
On Fri, Dec 20, 2019 at 12:03:53PM -0800, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use
== Series Details ==
Series: drm/i915: Check current i915_vma.pin_count status first on unbind (rev2)
URL : https://patchwork.freedesktop.org/series/72529/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16264
In case of tiled connectors if one of the tiled connectors in state
needs a full modeset we add other tiled connectors to the state. Make sure
that the connector has a CRTC before forcing a modeset on that else it fails
committing the state.
Cc: Ville Syrjälä
Fixes: a603f5bd1691 ("drm/i915/dp:
== Series Details ==
Series: drm/i915/tgl: Implement Wa_1606931601 (rev2)
URL : https://patchwork.freedesktop.org/series/72433/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16263
Summary
---
== Series Details ==
Series: series starting with [1/8] drm/edid: Check the number of detailed
timing descriptors in the CEA ext block
URL : https://patchwork.freedesktop.org/series/72550/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16262
The 'prefault_disable' modparam was used by IGT to prevent a few
prefaulting operations to make fault handling under struct_mutex more
prominent. With the removal of struct_mutex, this is not as important
any more and we have almost completely stopped using the parameter. The
remaining use in
There are reports of unexpected DSB busy/timeout happening after IGT
tests finish running that apparently go away when the DMC firmware isn't
loaded. The bspec doesn't say anything specific about DSB needing us to
exit DC5/DC6, but let's try adding DSB usage to the "DC off" list and
see if that
== Series Details ==
Series: series starting with [1/8] drm/edid: Check the number of detailed
timing descriptors in the CEA ext block
URL : https://patchwork.freedesktop.org/series/72550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3a501fdd02f1 drm/edid: Check the number
== Series Details ==
Series: drm/i915/tgl: Suppress DC5/DC6 around DSB usage
URL : https://patchwork.freedesktop.org/series/72549/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
== Series Details ==
Series: drm/i915: Stub out i915_gpu_coredump_put
URL : https://patchwork.freedesktop.org/series/72547/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16260
Summary
---
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is
currently pinned, without waiting to see if the inflight operations may
unpin it. We see this problem with the shrinker trying to unbind the
active vma from inside its bind worker:
<6> [472.618968] Workqueue: events_unbound
On Fri, Jan 24, 2020 at 01:54:58PM +, Chris Wilson wrote:
> Quoting Jani Nikula (2020-01-24 13:25:21)
> > Hey all,
> >
> > So I sent [1] to convert some forcewake register accessors... but what if we
> > just ripped off the bandage once and for all? It's going to hurt, a lot, but
> > we'd get
Disable Early Read and Src Swap by setting the bit 14
and 15 in the chicken register.
BSpec: 46045,52890
v2: Follow the Bspec implementation for the WA.
Cc: Matt Roper
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
drivers/gpu/drm/i915/i915_reg.h
If the HW min/max frequencies are the same, there is not much range to
deal with and a couple of our invalid tests become confused as they are
actually no-ops.
Error reporting in i915_pm_rps is rudimentary and we deserve better.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1008
On Fri, Jan 24, 2020 at 03:25:21PM +0200, Jani Nikula wrote:
> Hey all,
>
> So I sent [1] to convert some forcewake register accessors... but what if we
> just ripped off the bandage once and for all? It's going to hurt, a lot, but
> we'd get it done.
>
> This completely rids us of the
On Fri, Jan 24, 2020 at 03:25:26PM +0200, Jani Nikula wrote:
> The implicit "dev_priv" local variable use has been a long-standing pain
> point in the register access macros I915_READ(), I915_WRITE(),
> POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
>
> Replace them with the corresponding
On Thu, Jan 23, 2020 at 02:47:04PM -0800, Manasi Navare wrote:
> On Thu, Jan 23, 2020 at 08:27:12PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 22, 2020 at 04:24:15PM -0800, Manasi Navare wrote:
> >
> > Missing commit msg.
>
> Yes will add the commit message
>
Capturing an Ack from Ville from
== Series Details ==
Series: drm/i915: Fix inconsistance between pfit.enable and scaler freeing
(rev3)
URL : https://patchwork.freedesktop.org/series/72539/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7810 -> Patchwork_16259
On Thu, 2020-01-23 at 08:17 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/ehl: Ensure that the DDI selection MUX is programmed
> correctly
> URL : https://patchwork.freedesktop.org/series/72357/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from
== Series Details ==
Series: drm/i915/gt: Flush engine parking before release
URL : https://patchwork.freedesktop.org/series/72540/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7810 -> Patchwork_16257
Summary
---
== Series Details ==
Series: i915/tests/gem_exec_big: prefer PROT_WRITE
URL : https://patchwork.freedesktop.org/series/72544/
State : failure
== Summary ==
Applying: i915/tests/gem_exec_big: prefer PROT_WRITE
error: sha1 information is lacking or useless (tests/i915/gem_exec_big.c).
error:
On Fri, 2020-01-24 at 11:53 -0800, Matt Roper wrote:
> There are reports of unexpected DSB busy/timeout happening after IGT
> tests finish running that apparently go away when the DMC firmware
> isn't
> loaded. The bspec doesn't say anything specific about DSB needing us
> to
> exit DC5/DC6, but
On 1/24/20 7:39 PM, Chris Wilson wrote:
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47)
On 1/24/20 2:01 PM, Chris Wilson wrote:
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local
== Series Details ==
Series: drm/i915/vbt: Fix the timing parameters
URL : https://patchwork.freedesktop.org/series/72534/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7810 -> Patchwork_16256
Summary
---
From: Ville Syrjälä
CEA-861 says :
"d = offset for the byte following the reserved data block.
If no data is provided in the reserved data block, then d=4.
If no DTDs are provided, then d=0."
So let's not look for DTDs when d==0. In fact let's just make that
<4 since those values would just
From: Ville Syrjälä
Let's try to make a lot more stuff const in the edid parser.
The "downside" is that we can no longer mangle the EDID in the
middle of the parsing to apply quirks (drm_mode_detailed()).
I don't really think mangling the blob itself is such a great
idea anyway so I won't miss
From: Ville Syrjälä
I don't understand what the DispID CEA data block revision
means. The spec doesn't say. I guess some DispID must have
a value of >= 3 in there or else we generally wouldn't
even parse the CEA data blocks. Or does all this code
actually not do anything?
Cc: Andres Rodriguez
From: Ville Syrjälä
Nuke some whitespace that shouldn't be there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d6bce58b27ac..3df5744026b0
From: Ville Syrjälä
After much head scratching I managed to convince myself that
for_each_displayid_db() has already done the bounds checks for
the DispID CEA data block. Which is why we don't need to repeat
them in cea_db_offsets(). To avoid having to go through that
pain again in the future
From: Ville Syrjälä
Let's introduce is_detailed_timing_descritor() as the opposite
counterpart of is_display_descriptor().
Cc: Allen Chen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 42 ++
1 file changed, 24 insertions(+), 18 deletions(-)
From: Ville Syrjälä
Currently we assume any 18 byte descriptor to be a display descritor
if only the tag byte matches the expected value. But for detailed
timing descriptors that same byte is just the lower 8 bits of
hblank, and as such can match any display descriptor tag. To
properly validate
From: Ville Syrjälä
I'm curious if there are any bogus 18 byte descriptors around.
Let's dump them out if we encounter them.
Not sure we'd actually want this, but at least I get to see
if our CI has anything that hits this :)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 22
There are reports of unexpected DSB busy/timeout happening after IGT
tests finish running that apparently go away when the DMC firmware isn't
loaded. The bspec doesn't say anything specific about DSB needing us to
exit DC5/DC6, but let's try adding DSB usage to the "DC off" list and
see if that
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, January 23, 2020 9:50 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl: Implement Wa_1606931601
>
> On Wed, Jan 22, 2020 at 03:40:27PM -0800, Anusha Srivatsa
i915_gpu_coreddump_put is currently only defined if
CONFIG_DRM_I915_CAPTURE_ERROR is enabled, provide a stub otherwise.
Reported-by: Mike Lothian
Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capture")
Fixes: 748317386afb ("drm/i915/execlists: Offline error capture")
On Fri, Jan 24, 2020 at 12:53:54AM -0800, Niranjana Vishwanathapura wrote:
This patch series is WIP and not submission ready.
It needs more clarity on locking strategy, synchronization between
VM_BIND and execbuff paths, endless batch buffer support among other things.
This patch series is in
On Fri, 2020-01-24 at 08:04 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/2] drm/i915/dc3co: Do the full
> calculation of DC3CO exit only once (rev2)
> URL : https://patchwork.freedesktop.org/series/72416/
> State : failure
>
> == Summary ==
>
> CI Bug
== Series Details ==
Series: drm/i915/display: mass conversion to intel_de_*() register accessors
URL : https://patchwork.freedesktop.org/series/72533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7809 -> Patchwork_16255
Quoting Michal Wajdeczko (2020-01-20 19:18:17)
> We should never BUG_ON on any corruption in CTB descriptor as
> data there can be also modified by the GuC. Instead we can
> use flag "is_in_error" to indicate that we will not process
> any further messages over this CTB (until reset).
Like you
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47)
> On 1/24/20 2:01 PM, Chris Wilson wrote:
> > Since drm_global_mutex is a true global mutex across devices, we don't
> > want to acquire it unless absolutely necessary. For maintaining the
> > device local open_count, we can use atomic
== Series Details ==
Series: drm/i915/display: mass conversion to intel_de_*() register accessors
URL : https://patchwork.freedesktop.org/series/72533/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/icl_dsi: use intel_de_*() functions for
== Series Details ==
Series: drm/i915/display: mass conversion to intel_de_*() register accessors
URL : https://patchwork.freedesktop.org/series/72533/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c07095a827f3 drm/i915/icl_dsi: use intel_de_*() functions for register access
== Series Details ==
Series: series starting with [1/2] drm: Release filp before global lock (rev2)
URL : https://patchwork.freedesktop.org/series/72530/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7809 -> Patchwork_16254
On Fri, Jan 24, 2020 at 07:23:01PM +0200, Stanislav Lisovskiy wrote:
> Despite that during hw readout we seem to have scalers assigned
> to pipes, then call atomic_setup_scalers, at the commit stage in
> skl_update_scaler there is a check, that if we have fb src and
> dest of same size, we stage
On Fri, 24 Jan 2020 at 11:51, Chris Wilson wrote:
>
> Using a clear page for scratch means that we have relatively benign
> errors in case it is accidentally used, but that can be rather too
> benign for debugging. If we poison the scratch, ideally it quickly
> results in an obvious error.
>
>
Despite that during hw readout we seem to have scalers assigned
to pipes, then call atomic_setup_scalers, at the commit stage in
skl_update_scaler there is a check, that if we have fb src and
dest of same size, we stage freeing of that scaler.
However we don't update pfit.enabled flag then, which
Thanks.
Hopefully I'll a series soon getting rid of all this special case stuff.
Reviewed-by: Lionel Landwerlin
On 24/01/2020 19:03, Chris Wilson wrote:
The kernel doesn't differentiate between the Coffeelake and Cometlake
platforms, but igt does. Add the alias for perf to use the Coffeelake
Quoting Matthew Auld (2020-01-24 16:54:42)
> On 24/01/2020 16:46, Chris Wilson wrote:
> > Quoting Matthew Auld (2020-01-24 16:41:31)
> >> Technically mmap__cpu and mmap__wc just ignore the prot value, so it
> >> doesn't really matter, but the intention is to have write access to the
> >> ptr, so
The kernel doesn't differentiate between the Coffeelake and Cometlake
platforms, but igt does. Add the alias for perf to use the Coffeelake
register set for Cometlake.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
tests/perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Fri, 24 Jan 2020 at 14:33, Chris Wilson wrote:
>
> Due to the asynchronous nature of releasing our wakerefs, we can signal
> the main GT wakeref as complete before the individual engines have
> cleared their own wakerefs. During shutdown we assert that the engines
> are indeed parked before we
== Series Details ==
Series: drm/i915: Check current i915_vma.pin_count status first on unbind
URL : https://patchwork.freedesktop.org/series/72529/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7809 -> Patchwork_16253
On 24/01/2020 16:46, Chris Wilson wrote:
Quoting Matthew Auld (2020-01-24 16:41:31)
Technically mmap__cpu and mmap__wc just ignore the prot value, so it
doesn't really matter, but the intention is to have write access to the
ptr, so make that clear. Also if the underlying mmap__wc were to at
Quoting Matthew Auld (2020-01-24 16:41:31)
> Technically mmap__cpu and mmap__wc just ignore the prot value, so it
> doesn't really matter, but the intention is to have write access to the
> ptr, so make that clear. Also if the underlying mmap__wc were to at some
> point use mmap_offset where the
Technically mmap__cpu and mmap__wc just ignore the prot value, so it
doesn't really matter, but the intention is to have write access to the
ptr, so make that clear. Also if the underlying mmap__wc were to at some
point use mmap_offset where the prot is not ignored then we won't have
any
== Series Details ==
Series: drm/i915/gt: Poison GTT scratch pages (rev9)
URL : https://patchwork.freedesktop.org/series/72423/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7809 -> Patchwork_16252
Summary
---
On Mon, Jan 20, 2020 at 07:47:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move intel_atomic_state_free() next to its counterpart.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
Some exported functions in this file are missing documentation.
> ---
>
On Mon, Jan 20, 2020 at 07:47:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Give the cdclk init/uninit functions a _hw suffix to make
> it clear they are about initializing the actual hardware.
> I'll be wanting to to add a intel_cdclk_init() which is
> purely initializing software
On Mon, Jan 20, 2020 at 07:47:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make life less confusing let's swap() the entire cdclk state
> rather than swapping some parts, copying other parts, and leaving
> the rest just as is.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by:
On Fri, Jan 24, 2020 at 04:42:16PM +0200, Stanislav Lisovskiy wrote:
> Despite that during hw readout we seem to have scalers assigned
> to pipes, then call atomic_setup_scalers, at the commit stage in
> skl_update_scaler there is a check, that if we have fb src and
> dest of same size, we stage
Despite that during hw readout we seem to have scalers assigned
to pipes, then call atomic_setup_scalers, at the commit stage in
skl_update_scaler there is a check, that if we have fb src and
dest of same size, we stage freeing of that scaler.
However we don't update pfit.enabled flag then, which
Due to the asynchronous nature of releasing our wakerefs, we can signal
the main GT wakeref as complete before the individual engines have
cleared their own wakerefs. During shutdown we assert that the engines
are indeed parked before we release them, but for this to be always true
we need to
Despite that during hw readout we seem to have scalers assigned
to pipes, then call atomic_setup_scalers, at the commit stage in
skl_update_scaler there is a check, that if we have fb src and
dest of same size, we stage freeing of that scaler.
However we don't update pfit.enabled flag then, which
On Fri, 24 Jan 2020, Vandita Kulkarni wrote:
> Fix htotal and vtotal parameters derived from
> DTD block of VBT.
>
> Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
> Signed-off-by: Vandita Kulkarni
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 6
== Series Details ==
Series: series starting with [1/2] drm/i915: Tighten atomicity of
i915_active_acquire vs i915_active_release
URL : https://patchwork.freedesktop.org/series/72523/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7809 -> Patchwork_16251
Quoting Jani Nikula (2020-01-24 13:25:21)
> Hey all,
>
> So I sent [1] to convert some forcewake register accessors... but what if we
> just ripped off the bandage once and for all? It's going to hurt, a lot, but
> we'd get it done.
>
> This completely rids us of the "dev_priv" dependency in
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47)
> On 1/24/20 2:01 PM, Chris Wilson wrote:
> > Since drm_global_mutex is a true global mutex across devices, we don't
> > want to acquire it unless absolutely necessary. For maintaining the
> > device local open_count, we can use atomic
On 1/24/20 2:01 PM, Chris Wilson wrote:
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_count, we can use atomic operations on the counter
itself, except when making the transition
On Fri, 24 Jan 2020, Anshuman Gupta wrote:
> On 2020-01-24 at 14:15:30 +0200, Jani Nikula wrote:
>> On Fri, 24 Jan 2020, Anshuman Gupta wrote:
>> > On 2020-01-23 at 15:48:05 +0200, Jani Nikula wrote:
>> >> On Thu, 23 Jan 2020, Anshuman Gupta wrote:
>> >> > It should not be assumed that a
Fix htotal and vtotal parameters derived from
DTD block of VBT.
Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_bios.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
1 - 100 of 193 matches
Mail list logo
