Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
and narrow") started to optize the eDP 1.4+ link config, both per spec
and as preparation for display stream compression support.
Sadly, we again face panels that flat out fail with parameters they
claim to support. Revert, and
From: Janusz Krzysztofik
The driver does not currently support unbinding from a device which is
in use. Since open file descriptors may still be pointing into kernel
memory where the device structures used to be, entirely correct kernel
panics protect the driver from being unbound as we should n
Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> From: Janusz Krzysztofik
>
> The driver does not currently support unbinding from a device which is
> in use. Since open file descriptors may still be pointing into kernel
> memory where the device structures used to be, entirely correct kernel
On Fri, 05 Apr 2019, Jani Nikula wrote:
> Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
> and narrow") started to optize the eDP 1.4+ link config, both per spec
> and as preparation for display stream compression support.
>
> Sadly, we again face panels that flat out fail w
Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
and narrow") started to optize the eDP 1.4+ link config, both per spec
and as preparation for display stream compression support.
Sadly, we again face panels that flat out fail with parameters they
claim to support. Revert, and
Quoting Chris Wilson (2019-04-05 00:32:13)
> Quoting Jani Nikula (2019-04-04 22:14:24)
> > intel_drv.h has grown out of proportions, and turned into a dumping
> > ground. Way back when it was useful to have only a handful of headers,
> > but we're long past that.
> >
> > Start splitting off per-mo
On Fri, 2019-04-05 at 08:41 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> > From: Janusz Krzysztofik
> >
> > The driver does not currently support unbinding from a device which
> > is
> > in use. Since open file descriptors may still be pointing into
> > kernel
== Series Details ==
Series: drm/i915: Use drm_dev_unplug()
URL : https://patchwork.freedesktop.org/series/59041/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5877 -> Patchwork_12691
Summary
---
**FAILURE**
Serio
Quoting Janusz Krzysztofik (2019-04-05 09:11:54)
> On Fri, 2019-04-05 at 08:41 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> > > From: Janusz Krzysztofik
> > >
> > > The driver does not currently support unbinding from a device which
> > > is
> > > in use. Sin
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, April 5, 2019 2:00 AM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix pipe config timing mismatch
> warnings
>
> On Thu, Apr 04, 2019 at 01:36:25
In order to run as a standalone test (i.e. immediately after booting a
device), we need to explicitly probe the connectors.
Signed-off-by: Chris Wilson
---
tests/i915/i915_pm_rpm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected dis
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
A common binary sysfs called "hdcp_srm" is created at /sys/class/drm
with only write permission.
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and 2
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git
HDCP2.2 phase-II introduces below features:
Addition of two connector properties
HDCP Content Type
HDCP Topology
Addition of binary sysfs "hdcp_srm" at drm subsystem
Parsing for HDCP1.4 and 2.2 SRM table
Once HDCP1.4/2.2 authentication
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ram
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_hdcp.c | 13 +
include/drm/drm_hdcp.h | 2 ++
2 files changed, 15 insertions(+)
diff --git
Functions to create and remove the binary sysfs for class are added.
These are getting introduced as DRM wants to create the common binary
sysfs across the drm subsystem to handle hdcp srm.
Signed-off-by: Ramalingam C
cc: Greg Kroah-Hartman
cc: Daniel Vetter
---
drivers/base/class.c | 19 ++
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 78 ---
drivers/gpu/drm/drm_hdcp.c
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 13 +++--
include/drm/drm_connector.h | 6 --
This patch adds a optional CP downstream info blob property to the
connectors. This enables the Userspace to read the information of HDCP
authenticated downstream topology.
Driver will update this blob with all downstream information at the
end of the authentication.
In case userspace configures
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
v2:
Minor fixes at KDoc comments [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_sysfs.c | 31 +
Implements drm blob property content_protection_downstream_info
property on HDCP capable connectors.
Downstream topology info is gathered across authentication stages
and stored in intel_hdcp. When HDCP authentication is complete,
new blob with latest downstream topology information is updated to
On 03/04/2019 09:21, Chris Wilson wrote:
During request construction, we take the timeline->mutex to ensure
exclusive access to the ringbuffer (for command emission) and the
timeline itself (for command ordering). The timeline->mutex should not
be dropped by callers until we release it in i915_r
On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> Functions to create and remove the binary sysfs for class are added.
>
> These are getting introduced as DRM wants to create the common binary
> sysfs across the drm subsystem to handle hdcp srm.
Why do you need individual files? Th
== Series Details ==
Series: drm/i915: Be precise in types for i915_gem_busy (rev2)
URL : https://patchwork.freedesktop.org/series/58993/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5871_full -> Patchwork_12682_full
Summa
On 29/03/2019 13:40, Chris Wilson wrote:
When we introduced preemption, we chose to keep it disabled for gen8 as
supporting preemption inside GPGPU user batches required various w/a in
userspace. Since then, the desire to preempt long queues of requests
between batches (e.g. within busywaiting s
Quoting Tvrtko Ursulin (2019-04-05 10:46:19)
>
> On 29/03/2019 13:40, Chris Wilson wrote:
> > +static int gen9_emit_bb_start(struct i915_request *rq,
> > + u64 offset, u32 len,
> > + const unsigned int flags)
> > +{
> > + u32 *cs;
> > +
> > +
00
On 05/04/2019 10:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-05 10:46:19)
On 29/03/2019 13:40, Chris Wilson wrote:
+static int gen9_emit_bb_start(struct i915_request *rq,
+ u64 offset, u32 len,
+ const unsigned int flags)
+{
+
On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > Functions to create and remove the binary sysfs for class are added.
> >
> > These are getting introduced as DRM wants to create the common binary
> > sysfs across the drm
This will be helpful in the follow-up work. No functional changes.
Reviewed-by: Chris Wilson
Acked-by: Joonas Lahtinen
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile.header-test | 1 +
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
drivers/gpu/drm/i915/intel_frontbu
v2 of [1] with:
- each foo.c now includes the corresponding new foo.h to avoid sparse warnings
- minor sparse/checkpatch/whitespace fixes
- commit message tab screwup fixed
I didn't add changelog to each patch for the first two.
Took the liberty of adding Chris' r-b despite the changes.
BR,
J
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
While transitioning to having better clarity between the modules, it's
desirable to have the function name prefixes reflect the
module. Functions in intel_foo.c should be prefixed intel_foo_.
Expose only one CDCLK init/uninit function from intel_cdclk.c instead of
one per platform. Obviously this
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minim
== Series Details ==
Series: HDCP2.2 Phase II (rev5)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
932360ca743e drm: move content protection property to mode_config
1e7b8941c421 drm/i915: debugfs: HDCP2.2 capability read
6d5
Quelch a sparse warning:
drivers/gpu/drm/i915/gt/selftest_lrc.c:119:54: warning: Using plain integer as
NULL pointer
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
== Series Details ==
Series: drm/i915/dp: revert back to max link rate and lane count on eDP (rev2)
URL : https://patchwork.freedesktop.org/series/59039/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5878 -> Patchwork_12692
== Series Details ==
Series: HDCP2.2 Phase II (rev5)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm: move content protection property to mode_config
Okay!
Commit: drm/i915: debugfs: HDCP2.2 cap
On 05/04/2019 12:14, Chris Wilson wrote:
Quelch a sparse warning:
drivers/gpu/drm/i915/gt/selftest_lrc.c:119:54: warning: Using plain integer as
NULL pointer
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 2 +-
1 file chan
On Fri, 2019-04-05 at 09:24 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-04-05 09:11:54)
> > On Fri, 2019-04-05 at 08:41 +0100, Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> > > > From: Janusz Krzysztofik
> > > >
> > > > The driver does not currentl
As soon as a device is considered unplugged, not only prevent pending
users from accessing the device structures but also cancel all their
pending requests so all consumed resources can be cleaned up as soon
as possible.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Chris Wilson
---
drivers/gp
== Series Details ==
Series: HDCP2.2 Phase II (rev5)
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5878 -> Patchwork_12693
Summary
---
**SUCCESS**
No regressio
== Series Details ==
Series: drm/i915: the great header refactoring, part one (rev2)
URL : https://patchwork.freedesktop.org/series/59022/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7dd28bb15c13 drm/i915: make intel_frontbuffer.h self-contained
1c4845705dd7 drm/i915: extract
== Series Details ==
Series: drm/i915: the great header refactoring, part one (rev2)
URL : https://patchwork.freedesktop.org/series/59022/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: make intel_frontbuffer.h self-contained
-drivers/gpu/drm
On 2019-04-05 at 14:13:02 +0530, Ramalingam C wrote:
> Implements drm blob property content_protection_downstream_info
> property on HDCP capable connectors.
>
> Downstream topology info is gathered across authentication stages
> and stored in intel_hdcp. When HDCP authentication is complete,
> ne
== Series Details ==
Series: drm/i915/selftests: Fix plain use of integer 0 as NULL
URL : https://patchwork.freedesktop.org/series/59053/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/selftests: Fix plain use of integer 0 as NULL
-O:drivers/g
From: Janusz Krzysztofik
If there are active users of a device during driver unbind, the driver
now panics on non-empty list of free cachelines.
By design, chachelines which are not in use are kept on a list of free
chachelines associated with a timeline and rmoved from that list either
when in
== Series Details ==
Series: drm/i915: the great header refactoring, part one (rev2)
URL : https://patchwork.freedesktop.org/series/59022/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5878 -> Patchwork_12694
Summary
--
Quoting Janusz Krzysztofik (2019-04-05 13:13:31)
> From: Janusz Krzysztofik
>
> If there are active users of a device during driver unbind, the driver
> now panics on non-empty list of free cachelines.
This panic is there to say that fini is being called with active
contexts, that it is being ca
== Series Details ==
Series: drm/i915: Mark GEM wedged right after marking device unplugged
URL : https://patchwork.freedesktop.org/series/59054/
State : failure
== Summary ==
Applying: drm/i915: Mark GEM wedged right after marking device unplugged
error: sha1 information is lacking or useless
== Series Details ==
Series: drm/i915/selftests: Fix plain use of integer 0 as NULL
URL : https://patchwork.freedesktop.org/series/59053/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5878 -> Patchwork_12695
Summary
---
On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > Functions to create and remove the binary sysfs for class are added.
> > >
> > > These are getting intr
The PDP registers are an oddity inside the set of context saved
registers in that they take the engine as a parameter to the macro and
not the mmio_base as the others do. Make it accept the engine->mmio_base
for consistency in programming the context registers.
add/remove: 0/0 grow/shrink: 2/1 up/
On Fri, 2019-04-05 at 13:20 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-04-05 13:13:31)
> > From: Janusz Krzysztofik
> >
> > If there are active users of a device during driver unbind, the
> > driver
> > now panics on non-empty list of free cachelines.
>
> This panic is there t
== Series Details ==
Series: drm/i915/dp: On link train failure on eDP, retry with max params first
(rev2)
URL : https://patchwork.freedesktop.org/series/58975/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5874_full -> Patchwork_12685_full
===
== Series Details ==
Series: drm/i915: Don't panic on non-empty list of free cachelines
URL : https://patchwork.freedesktop.org/series/59056/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5878 -> Patchwork_12697
Summary
---
From: Janusz Krzysztofik
The driver does not currently support unbinding from a device which is
in use. Since open file descriptors may still be pointing into kernel
memory where the device structures used to be, entirely correct kernel
panics protect the driver from being unbound as we should n
Use drm_dev_unplug() to have device resources protected from user access
by DRM layer as soon as the driver is going to be unbound. Also, cancel
all pending work so associated resources can be quickly released.
Janusz Krzysztofik (2):
drm/i915: Use drm_dev_unplug()
drm/i915: Mark GEM wedged r
As soon as a device is considered unplugged, not only prevent pending
users from accessing the device structures but also cancel all their
pending requests so all consumed resources can be cleaned up as soon
as possible.
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
Reviewed-by: C
On 05/04/2019 13:38, Chris Wilson wrote:
The PDP registers are an oddity inside the set of context saved
registers in that they take the engine as a parameter to the macro and
not the mmio_base as the others do. Make it accept the engine->mmio_base
for consistency in programming the context regi
From: Janusz Krzysztofik
If there are active users of a device during driver unbind, the driver
now panics on non-empty list of free cachelines.
By design, cachelines which are not in use are kept on a list of free
cachelines associated with a timeline and removed from that list either
when in u
From: Ville Syrjälä
The only bpc information in pipe registers for BXT/GLK DSI
is the PIPEMISC dither bpc. Let's try to use that to read
out pipe_bpp on these platforms. However, I'm not sure if
this will be correctly populated by the GOP since bspec
suggests it's only needed if dithering is actu
== Series Details ==
Series: drm/i915: Make RING_PDP relative to engine->mmio_base
URL : https://patchwork.freedesktop.org/series/59060/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5880 -> Patchwork_12698
Summary
---
Reviewed-by: Caz Yokoyama
On Fri, 2019-04-05 at 12:38 +0100, Tvrtko Ursulin wrote:
> i915_vma_instance
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Mar 29, 2019 at 06:19:21PM -0700, Radhakrishna Sripada wrote:
> Fixes the clock-gating issue when pipe scaling is enabled.
> (Lineage #2006604312)
>
> V2: Fix typo in headline(Chris)
> Handle the non double buffered nature of the register(Ville)
> V3: Fix checkpatch warning. BAT failur
Push getting the reference for the encoders' power domains into the
encoder get_power_domain() hook instead of doing this from the caller.
This way the encoder can store away the corresponding wakerefs.
This fixes the DSI encoder disabling, which didn't release these
power references it acquired d
We can unconditionally release the power references during encoder
disabling. The references for each port used by the encoder are
guaranteed to be enabled at this point.
Cc: Vandita Kulkarni
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/icl_dsi.c | 12 +---
1 file changed, 5 insert
Dear Sir/Madam:
I am having an issue with intel Baytrail GPU DRM driver.
Description:
Linux kernel version 3.10.61:
Afer calling function
properties = drmModeObjectGetProperties(drmfd, plane_id, DRM_MODE_OBJECT_PLANE);
it only returns only one property:
property->name = "rotation", property->p
On Mon, Apr 01, 2019 at 11:00:04PM +0530, Uma Shankar wrote:
> This series adds support for programmable gamma modes and
> exposes a property interface for the same. Also added,
> support for multi segment gamma mode introduced in ICL+
>
> It creates 2 property interfaces :
> 1. GAMMA_MODE_CAPS: T
== Series Details ==
Series: Stop users from using the device on driver unbind
URL : https://patchwork.freedesktop.org/series/59064/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5881 -> Patchwork_12699
Summary
---
*
On Fri, Apr 05, 2019 at 05:13:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The only bpc information in pipe registers for BXT/GLK DSI
> is the PIPEMISC dither bpc. Let's try to use that to read
> out pipe_bpp on these platforms. However, I'm not sure if
> this will be correctly popu
Quoting Patchwork (2019-04-05 17:20:39)
> == Series Details ==
>
> Series: Stop users from using the device on driver unbind
> URL : https://patchwork.freedesktop.org/series/59064/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5881 -> Patchwork_12699
> ==
The engine has a direct link to the intel_uncore mmio handler, so make
use of it rather than going indirectly via &engine->i915->uncore.
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reset.c | 9 +
1 file changed, 5 insertions(+),
== Series Details ==
Series: series starting with [1/7] drm/i915/psr: Update PSR2 SU corruption
workaround comment (rev2)
URL : https://patchwork.freedesktop.org/series/58974/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5875_full -> Patchwork_12686_full
== Series Details ==
Series: tests/i915/gem_madvise.c: Add more mappings
URL : https://patchwork.freedesktop.org/series/59021/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5875_full -> IGTPW_2790_full
Summary
---
**
== Series Details ==
Series: drm/i915: Don't panic on non-empty list of free cachelines (rev2)
URL : https://patchwork.freedesktop.org/series/59056/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5881 -> Patchwork_12700
Summ
1 - 100 of 157 matches
Mail list logo
