Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: Change KVMGT as self load module
Zhenyu,
Overall I think the impact to AcrnGT is not big, we can modify our code to adapt
to the new interfaces.
But I have some comments embedded.
> -Original Message-
> From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
> Sent: Thursday, December 6, 2018 12:28 PM
> To: Yuan, Hang ; Wang, Zhi A
> ; Zhang, Xiong Y ; He,
> Min
> Cc: intel-gfx@lists.freedesktop.org; Alex Williamson
> ; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [PATCH v4] drm/i915/gvt: Change KVMGT as self load module
>
>
> Ping for any more comments? Or ack?
>
> Adding Min, for head-up notify, I've moved 'kvmgt' into self load
> module instead of loaded by i915/gvt, in order to clean up the
> dependence, so need to load 'kvmgt.ko' to enable GVT through
> VFIO/mdev. Hypervisor module needs to call new register/unregister
> function to initialize hypervisor specific interface for GVT. If
> AcrnGT rebase on this, it may need to change initial setup too, so
> could you double check?
>
> thanks
>
> On 2018.12.04 10:40:28 +0800, Zhenyu Wang wrote:
> > This trys to make 'kvmgt' module as self loadable instead of loading
> > by i915/gvt device model. So hypervisor specific module could be
> > stand-alone, e.g only after loading hypervisor specific module, GVT
> > feature could be enabled via specific hypervisor interface, e.g VFIO/mdev.
> >
> > So this trys to use hypervisor module register/unregister interface
> > for that. Hypervisor module needs to take care of module reference
> > itself when working for hypervisor interface, e.g for VFIO/mdev,
> > hypervisor module would reference counting mdev when open and release.
> >
> > This makes 'kvmgt' module really split from GVT device model. User
> > needs to load 'kvmgt' to enable VFIO/mdev interface.
> >
> > v4:
> > - fix checkpatch warning
> >
> > v3:
> > - Fix module reference handling for device open and release. Unused
> > mdev devices would be cleaned up in device unregister when module
> unload.
> >
> > v2:
> > - Fix kvmgt order after i915 for built-in case
> >
> > Cc: Alex Williamson
> > Signed-off-by: Zhenyu Wang
> > ---
> > drivers/gpu/drm/i915/Makefile| 1 +
> > drivers/gpu/drm/i915/gvt/Makefile| 1 -
> > drivers/gpu/drm/i915/gvt/gvt.c | 107 +++
> > drivers/gpu/drm/i915/gvt/gvt.h | 6 +-
> > drivers/gpu/drm/i915/gvt/hypercall.h | 7 +-
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 21 +-
> > drivers/gpu/drm/i915/gvt/mpt.h | 3 +
> > drivers/gpu/drm/i915/intel_gvt.c | 9 ---
> > 8 files changed, 72 insertions(+), 83 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> > index 0ff878c994e2..ae0d975a6f34 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -195,3 +195,4 @@ endif
> > i915-y += intel_lpe_audio.o
> >
> > obj-$(CONFIG_DRM_I915) += i915.o
> > +obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
> > diff --git a/drivers/gpu/drm/i915/gvt/Makefile
> b/drivers/gpu/drm/i915/gvt/Makefile
> > index b016dc753db9..271fb46d4dd0 100644
> > --- a/drivers/gpu/drm/i915/gvt/Makefile
> > +++ b/drivers/gpu/drm/i915/gvt/Makefile
> > @@ -7,4 +7,3 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
> trace_points.o firmware.o \
> >
> > ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
> > i915-y += $(addprefix $(GVT_DIR)/,
> $(GVT_SOURCE))
> > -obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
> > diff --git a/drivers/gpu/drm/i915/gvt/gvt.c
> b/drivers/gpu/drm/i915/gvt/gvt.c
> > index a5b760b7bc10..e1c9c20918af 100644
> > --- a/drivers/gpu/drm/i915/gvt/gvt.c
> > +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> > @@ -187,52 +187,6 @@ static const struct intel_gvt_ops intel_gvt_ops = {
> > .write_protect_handler = intel_vgpu_page_track_handler,
> > };
> >
> > -/**
> > - * intel_gvt_init_host - Load MPT modules and detect if we're running in
> host
> > - *
> > - * This function is called at the driver loading stage. If failed to find a
> > - * loadable MPT module or detect currently we're running in a VM, then
> GVT-g
> > - * will be disabled
> > - *
> > - * Returns:
> > - * Zero on success, negative error code if failed.
> > - *
> > - */
> > -int intel_gvt_init_host(void)
> > -{
> > - if (intel_gvt_host.initialized)
> > - return 0;
> > -
> > - /* Xen DOM U */
> > - if (xen_domain() && !xen_initial_domain())
> > - return -ENODEV;
> > -
> > - /* Try to load MPT modules for hypervisors */
> > - if (xen_initial_domain()) {
> > - /* In Xen dom0 */
> > - intel_gvt_host.mpt = try_then_request_module(
> > - symbol_get(xengt_mpt), "xengt");
> > - intel_gvt_host.hypervisor_type =
> INTEL_GVT_HYPERVISOR_XEN;
> > - } else {
> > -#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
> > - /* not in Xen. Try KVMGT */
> > - intel_gvt_host.mpt = try_then_request_module(
> > -
Re: [Intel-gfx] [PATCH v8 33/35] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
On 12/6/2018 7:50 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:31PM +0530, Ramalingam C wrote:
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 9f4056e156ec..654a076c58e4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -24,6 +25,27 @@
__p == PORT_A ? MEI_DDI_A : (enum mei_hdcp_ddi)__p;\
})
+static void kbl_repositioning_enc_en_signal(struct intel_connector *connector)
Is there a Bspec WA number/label so I can more easily find this?
Referenced in WAs #0889 and #0890
--Ram
-Daniel
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ struct drm_crtc *crtc = connector->base.state->crtc;
+ struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+ u32 scanline;
+
+ for (;;) {
+ scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+ if (scanline > 100 && scanline < 200)
+ break;
+ usleep_range(25, 50);
+ }
+
+ hdcp->shim->toggle_signalling(intel_dig_port, false);
+ hdcp->shim->toggle_signalling(intel_dig_port, true);
+}
+
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
{
@@ -1527,6 +1549,13 @@ static int hdcp2_enable_encryption(struct
intel_connector *connector)
}
if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+ /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+ if (IS_KABYLAKE(dev_priv) && hdcp->shim->toggle_signalling)
+ kbl_repositioning_enc_en_signal(connector);
+
/* Link is Authenticated. Now set for Encryption */
I915_WRITE(HDCP2_CTL_DDI(port),
I915_READ(HDCP2_CTL_DDI(port)) |
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 09/35] drm/i915: Implement HDCP2.2 link integrity check
On 12/6/2018 6:57 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the HDCP Receiver must assert
the corresponding bits of the RxStatus register. The Transmitter polls
the RxStatus register and it may initiate re-authentication.
v2:
Rebased.
v3:
No Changes.
v4:
enum check_link_response is used check the link status [Uma]
v5:
Rebased as part of patch reordering.
v6:
Required members of intel_hdcp is defined [Sean Paul]
v7:
hdcp2_check_link is cancelled at required places.
v8:
Rebased for the component i/f changes.
Errors due to the sinks are reported as DEBUG logs.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_display.c | 11 +++--
drivers/gpu/drm/i915/intel_drv.h | 5 +++
drivers/gpu/drm/i915/intel_hdcp.c| 83 +++-
include/drm/drm_hdcp.h | 8
4 files changed, 103 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e9f4e22b2a4e..fc63babce165 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15833,15 +15833,20 @@ static void intel_hpd_poll_fini(struct drm_device
*dev)
{
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+ struct intel_hdcp *hdcp;
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
+ hdcp = &connector->hdcp;
+
if (connector->modeset_retry_work.func)
cancel_work_sync(&connector->modeset_retry_work);
- if (connector->hdcp.shim) {
- cancel_delayed_work_sync(&connector->hdcp.check_work);
- cancel_work_sync(&connector->hdcp.prop_work);
+ if (hdcp->shim) {
+ cancel_delayed_work_sync(&hdcp->check_work);
+ cancel_work_sync(&hdcp->prop_work);
+ if (hdcp->hdcp2_supported)
+
cancel_delayed_work_sync(&hdcp->hdcp2_check_work);
Locking of these workers is always tricky ... why can't we use the same
worker for both checking hdcp2 and hdcp1 link status?
Doable similar to how we are doing hdcp_enable. Needs the tracking of the spec
in
use to pick proper timeout and functions.
I will look into it.
Of course need to use the right timeout and call the right functions, but
I think gives us less duplication in the complicated code.
}
}
drm_connector_list_iter_end(&conn_iter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 24d258488efe..e6e32bf52568 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -403,6 +403,9 @@ struct intel_hdcp_shim {
*/
int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
void *buf, size_t size);
+
+ /* HDCP2.2 Link Integrity Check */
+ int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
};
struct intel_hdcp {
@@ -445,6 +448,8 @@ struct intel_hdcp {
* over re-Auth has to be triggered.
*/
u32 seq_num_m;
+
+ struct delayed_work hdcp2_check_work;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 679f3c164582..98b112395a5a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1626,6 +1626,81 @@ static int _intel_hdcp2_disable(struct intel_connector
*connector)
return ret;
}
+/* Implements the Link Integrity Check for HDCP2.2 */
+static int intel_hdcp2_check_link(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum port port = connector->encoder->port;
+
+ int ret = 0;
+
+ if (!hdcp->shim)
+ return -ENOENT;
Why is this possible? Should we wrap it into at least a WARN_ON?
we could land here from CP_IRQ, with hdcp_exit called for shim removal.
But could avoid if we assert on the HDCP auth/encrypt status of the port
before check_link.
+
+ mutex_lock(&hdcp->mutex);
+
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+
+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) & L
Re: [Intel-gfx] [PATCH v8 06/35] drm/i915: Enable and Disable of HDCP2.2
On 12/6/2018 4:00 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:04PM +0530, Ramalingam C wrote:
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
This change implements a sequence of enabling and disabling of
HDCP2.2 authentication and HDCP2.2 port encryption.
Patch series suggestion for next time around: First build out the helper
functions, then time them into the big picture like here. Personally I
think that makes it easier to understand, but it's kinda personal choice.
Tried that already. But bisecting will give warnings as "defined but
unused functions"
Hence moved to this approach.
I guess this here works too.
v2:
Included few optimization suggestions [Chris Wilson]
Commit message is updated as per the rebased version.
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
No changes.
v4:
Extra comment added and Style issue fixed [Uma]
v5:
Rebased as part of patch reordering.
HDCP2 encryption status is tracked.
HW state check is moved into WARN_ON [Daniel]
v6:
Redefined the mei service functions as per comp redesign.
Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
Required shim functionality is defined [Sean Paul]
v7:
Return values are handles [Uma]
Realigned the code.
Check for comp_master is removed.
v8:
HDCP2.2 is attempted only if mei interface is up.
Adjust to the new interface
Avoid bool usage in struct [Tomas]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_hdcp.c | 223 +++---
2 files changed, 214 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bde82f3ada85..3e9f21d23442 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -383,6 +383,10 @@ struct intel_hdcp_shim {
/* Detects the HDCP protocol(DP/HDMI) required on the port */
enum mei_hdcp_wired_protocol (*hdcp_protocol)(void);
+
+ /* Detects whether Panel is HDCP2.2 capable */
+ int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
+ bool *capable);
};
struct intel_hdcp {
@@ -396,6 +400,7 @@ struct intel_hdcp {
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
u8 hdcp2_supported;
+ u8 hdcp2_in_use;
/*
* Content Stream Type defined by content owner. TYPE0(0x0) content can
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 760780f1105c..c1bd1ccd47cd 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -79,6 +79,43 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
}
+/* At present whether mei_hdcp component is binded with i915 master component */
+static bool intel_hdcp2_mei_binded(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_hdcp_component_master *comp = dev_priv->hdcp_comp;
+
+ mutex_lock(&comp->mutex);
+ if (!comp->ops || !comp->dev) {
+ mutex_unlock(&comp->mutex);
+ return false;
+ }
+ mutex_unlock(&comp->mutex);
+
+ return true;
+}
+
+/* Is HDCP2.2 capable on Platform and Sink */
+static bool intel_hdcp2_capable(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ bool capable = false;
+
+ /* I915 support for HDCP2.2 */
+ if (!hdcp->hdcp2_supported)
+ return false;
+
+ /* MEI services for HDCP2.2 */
+ if (!intel_hdcp2_mei_binded(connector))
+ return false;
Why do we still need this with component? Driver load should be stalled
out until it's all there, that was kinda the entire point of component,
so we don't have to recheck all the time whether hdcp2 is still there or
not.
We discussed this in previous patches. Lets decide whether this approach
is good enough or not.
--Ram
+
+ /* Sink's capability for HDCP2.2 */
+ hdcp->shim->hdcp_2_2_capable(intel_dig_port, &capable);
+
+ return capable;
+}
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
{
@@ -1114,8 +1151,7 @@ int hdcp2_authenticate_port(struct intel_connector
*connector)
return ret;
}
-static __attribute__((unused))
-int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_mei_session(struct intel_connector *connector)
{
struct mei_hdcp_dat
Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
Signed-off-by: Ramalingam C
Signed-off-by: Tomas Winkler
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_drv.h | 7 +
drivers/gpu/drm/i915/intel_hdcp.c | 442 +-
include/drm/i915_component.h | 71 ++
4 files changed, 521 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f763b30f98d9..b68bc980b7cd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2015,6 +2015,8 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ struct i915_hdcp_component_master *hdcp_comp;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85a526598096..bde82f3ada85 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include "i915_drv.h"
#include
@@ -379,6 +380,9 @@ struct intel_hdcp_shim {
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
bool *hdcp_capable);
+
+ /* Detects the HDCP protocol(DP/HDMI) required on the port */
+ enum mei_hdcp_wired_protocol (*hdcp_protocol)(void);
Looking ahead, this seems hardwired to constant return value? Or why do we
need a function here?
This is hardwired based on the connector type(DP/HDMI).
Since we have the shim for hdcp's connector based work, I have added this
function.
Could have done this just with connector_type check, but in that way whole
hdcp_shim
can be done in that way. So going with the larger design here.
};
struct intel_hdcp {
@@ -399,6 +403,9 @@ struct intel_hdcp {
* content can flow only through a link protected by HDCP2.2.
*/
u8 content_type;
+
+ /* mei interface related information */
+ struct mei_hdcp_data mei_data;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 99dddb540958..760780f1105c 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -8,14 +8,20 @@
#include
#include
+#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
#define KEY_LOAD_TRIES 5
#define TIME_FOR_ENCRYPT_STATUS_CHANGE50
+#define GET_MEI_DDI_INDEX(p) ({\
+ typeof(p) __p = (p); \
+ __p == PORT_A ? MEI_DDI_A : (enum mei_hdcp_ddi)__p;\
+})
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -833,6 +839,417 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
!IS_CHERRYVIEW(dev_priv) && port < PORT_E);
}
+static __attribute__((unused)) int
+hdcp2_prepare_ake_init(struct intel_connector *connector,
+ struct hdcp2_ake_init *ake_data)
+{
+ struct mei_hdcp_data *data = &connector->hdcp.mei_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_hdcp_component_master *comp = dev_priv->hdcp_comp;
+ int ret;
+
+ if (!comp)
+ return -EINVAL;
+
+ mutex_lock(&comp->mutex);
+ if (!comp->ops || !comp->dev) {
+ mutex_unlock(&comp->mutex);
+ return -EINVAL;
+ }
+
+ if (data->port == MEI_DDI_INVALID_PORT && connector->encoder)
+ data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
+
+ /* Clear ME FW instance for the port, just incase */
+ comp->ops->close_hdcp_session(comp->dev, data);
Sounds like a bug somewhere if we need this? I'd put this code into the
->initiate_hdcp2_session, with a big WARN_ON if it's actually needed.
Not really. Lets say you have progressed beyond the first step of HDCP2.2 auth
along with ME FW.
Now if authentication failed due to some reason, then the HDCP2.2 season
created with
ME FW for that port is not closed yet.
So we need to call close_hdcp_session() explicitly on authentication failures.
Session has to be closed before restarting the auth on that port with
initialite_hdcp_session.
If we are closing the hdcp session of the port on all auth errors, we dont need
this just before
start of the hdcp session.
"Just in case" papering over programming bugs of our own just makes
debugging harder.
+
+ ret = comp->ops->initiate_hdcp2_session(comp->dev,
+ data, ake_data);
We should set the port only afte
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable Y210, Y212, Y216 formats for ICL (rev4)
== Series Details ==
Series: Enable Y210, Y212, Y216 formats for ICL (rev4)
URL : https://patchwork.freedesktop.org/series/48729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5274_full -> Patchwork_11033_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11033_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_cpu_reloc@full:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108248]
* igt@gem_exec_schedule@pi-ringfull-render:
- {shard-iclb}: NOTRUN -> FAIL [fdo#103158]
* igt@i915_suspend@shrink:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#106886] / [fdo#107773]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107956]
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-primary-basic:
- {shard-iclb}: NOTRUN -> FAIL [fdo#107725]
* igt@kms_chv_cursor_fail@pipe-b-256x256-bottom-edge:
- shard-skl: PASS -> FAIL [fdo#104671]
* igt@kms_color@pipe-b-degamma:
- shard-skl: NOTRUN -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-256x256-offscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x85-sliding:
- {shard-iclb}: NOTRUN -> FAIL [fdo#103232] +4
- shard-glk: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-64x21-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_fbcon_fbt@psr:
- {shard-iclb}: NOTRUN -> FAIL [fdo#107882]
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: NOTRUN -> FAIL [fdo#107882]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-skl: NOTRUN -> FAIL [fdo#105683]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +1
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_plane@pixel-format-pipe-c-planes:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-glk: PASS -> FAIL [fdo#108948]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- {shard-iclb}: PASS -> FAIL [fdo#103166] +1
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665]
* igt@pm_backlight@fade_with_suspend:
- {shard-iclb}: NOTRUN -> FAIL [fdo#107847]
Possible fixes
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-xtiled:
- {shard-iclb}: WARN [fdo#108336] -> PASS +1
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: FAIL [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- {shard-iclb}: DMESG-FAIL [fdo#107724] -> PASS +5
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-move:
- {shard-iclb}: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt:
- {shard-iclb}: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +8
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- shard-apl: FAIL [fdo#108948] -> PASS
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- {shard-iclb}: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-a
Re: [Intel-gfx] [PATCH v8 04/35] drm/i915: Initialize HDCP2.2
On 12/6/2018 3:33 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote:
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
With the comments below addressed the commit message is a bit untrue,
since this just wires up a basic hdcp2_supported flag in a few places.
Please make that clear.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma]
v5:
Rebase as Part of reordering.
Component is used for the I915 and MEI_HDCP interface [Daniel]
v6:
HDCP2.2 uses the I915 component master to communicate with mei_hdcp
- [Daniel]
Required HDCP2.2 variables defined [Sean Paul]
v7:
intel_hdcp2.2_init returns void [Uma]
Realigning the codes.
v8:
Avoid using bool structure members.
MEI interface related changes are moved into separate patch.
Commit msg is updated accordingly.
intel_hdcp_exit is defined and used from i915_unload
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/intel_dp.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 16 +++-
drivers/gpu/drm/i915/intel_hdcp.c | 172 --
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
5 files changed, 130 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b1d23c73c147..fbedd5024afe 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1755,6 +1755,8 @@ void i915_driver_unload(struct drm_device *dev)
disable_rpm_wakeref_asserts(dev_priv);
+ intel_hdcp_exit(dev_priv);
This smells like a separate patch. Needs to be split out. Looking at the
implementation of intel_hdcp_exit I think it's papering over some unload
trouble. We should be shutting down all the outputs on driver unload,
which mei should be triggering (with the component stuff), which means
this code should be unecessary. But I'm not sure.
Either way needs to be split out, but I think proper solution is to drop
it.
As we discussed, during v7-->v8 i changed the component usage such that it wont
affect i915 load/unload.
During the first connector init, component master will be added. And during the
mei_client dev and driver binding,
component will be added hence the binding will happen with interface
initialization from mei.
Upon HDCP2.2 request, component binding will be checked before attempting for
HDCP2.2 auth.
So component master unbind triggered due to mei component_del, will teardown
the HDCP2.2 capability of the I915.
So in case of I915 unload trigger, from whatsoever reason, we need to clear the
HDCP activities and bring down
the i915_hdcp_component_master and the interface with mei. For this purpose
only intel_hdcp_exit is written here.
+
i915_driver_unregister(dev_priv);
if (i915_gem_suspend(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 18e3a5a3d873..ac62af073688 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6675,7 +6675,8 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp_add_properties(intel_dp, connector);
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
- int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
+ int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim,
+ false);
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a62d77b76291..85a526598096 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -388,6 +388,17 @@ struct intel_hdcp {
u64 value;
struct delayed_work check_work;
struct work_struct prop_work;
+
+ /* HDCP2.2 related definitions */
+ /* Flag indicates whether this connector supports HDCP2.2 or not. */
+ u8 hdcp2_supported;
+
+ /*
+* Content Stream Type defined by content owner. TYPE0(0x0) content can
+* flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
+* content can flow only through a link protected by HDCP2.2.
+*/
+ u8 content_type;
};
struct intel_connector {
@@ -2016,12 +2027,15 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *hdcp_shim);
+ const struct intel_hdcp_shim *hdcp_shim,
+
[Intel-gfx] [PULL] gvt-next for 4.21
Hi, As I was hoping to possibly merge more new stuff for next kernel e.g CFL support, etc, but seems those're still not stable enough so better wait for next cycle, so sorry for the late. This includes mostly one regression fix for drm-intel-next when we introduced during previous shadow ctx ppgtt failure fix patch, and one update on force-to-nonpriv register list. There're also three typo fixes we received, I think they're trivial so should be no harm to include. Thanks -- The following changes since commit 4377d4e0d3d511986033ba7b4182d5a80b7f9ea2: drm/i915: Update DRIVER_DATE to 20181204 (2018-12-04 19:26:17 +0200) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-next-2018-12-07 for you to fetch changes up to d1810909d841314ba94b14dc3de9e9fbc13b046a: drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts" (2018-12-07 12:01:09 +0800) gvt-next-2018-12-07 - Fix -next regression on shadow ctx's ppgtt destroy (Xiong) - Update force-to-nonpriv register list (Yan) - three typo fixes Colin Ian King (1): drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts" Peng Hao (1): drm/i915/gvt: fix a typo: "registeration" -> "registration". Xinyun Liu (1): drm/i915/gvt: fix typo in two MI cmd annotation Xiong Zhang (1): drm/i915/gvt: Fix shadow ctx ppgtt destroy function Zhao Yan (1): drm/i915/gvt: update force-to-nonpriv register whitelist drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 +++--- drivers/gpu/drm/i915/gvt/gvt.c| 2 +- drivers/gpu/drm/i915/gvt/gvt.h| 4 drivers/gpu/drm/i915/gvt/handlers.c | 1 + drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- drivers/gpu/drm/i915/gvt/scheduler.c | 33 + 6 files changed, 43 insertions(+), 5 deletions(-) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
== Series Details ==
Series: drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
URL : https://patchwork.freedesktop.org/series/53629/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11032_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11032_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11032_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11032_full:
### IGT changes ###
Possible regressions
* igt@kms_color@pipe-b-gamma:
- {shard-iclb}: SKIP -> FAIL +29
* igt@kms_color@pipe-c-degamma:
- shard-glk: SKIP -> FAIL +4
Warnings
* igt@kms_color@pipe-a-legacy-gamma-reset:
- {shard-iclb}: SKIP -> PASS +5
* igt@kms_color@pipe-b-ctm-green-to-red:
- shard-glk: SKIP -> PASS +28
Known issues
Here are the changes found in Patchwork_11032_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108039]
* igt@gem_workarounds@suspend-resume-context:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#107713]
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-c-bad-pixel-format:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +7
* igt@kms_chv_cursor_fail@pipe-c-128x128-left-edge:
- shard-skl: NOTRUN -> FAIL [fdo#104671]
* igt@kms_color@pipe-a-degamma:
- shard-glk: SKIP -> FAIL [fdo#108145]
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: PASS -> FAIL [fdo#105767]
* igt@kms_draw_crc@draw-method-rgb565-blt-untiled:
- {shard-iclb}: PASS -> WARN [fdo#108336]
* igt@kms_draw_crc@draw-method-xrgb-render-untiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107720] / [fdo#107724]
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-wc:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +4
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- {shard-iclb}: PASS -> FAIL [fdo#103167]
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +3
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- {shard-iclb}: PASS -> FAIL [fdo#103166]
* igt@pm_rpm@gem-pread:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]
* igt@prime_busy@hang-vebox:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@sw_sync@sync_busy_fork:
- shard-hsw: PASS -> INCOMPLETE [fdo#103540]
Possible fixes
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- {shard-iclb}: DMESG-WARN [fdo#107724] -> PASS +4
* igt@kms_color@pipe-b-degamma:
- shard-skl: FAIL [fdo#104782] -> PASS
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_legacy@all-pipes-single-move:
- shard-hsw: DMESG-WARN [fdo#102614] -> PASS
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-skl: FAIL [fdo#108472] -> PASS
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
- shard-hsw: DMESG-FAIL [fdo#102614] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_frontbuffe
[Intel-gfx] ✓ Fi.CI.BAT: success for Use intel_* types more consistently
== Series Details ==
Series: Use intel_* types more consistently
URL : https://patchwork.freedesktop.org/series/53705/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5279 -> Patchwork_11042
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53705/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11042:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- {fi-kbl-7567u}: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11042 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: PASS -> FAIL [fdo#108656]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: FAIL [fdo#108880] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
Participating hosts (46 -> 41)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3
Build changes
-
* Linux: CI_DRM_5279 -> Patchwork_11042
CI_DRM_5279: 8c3dbdac21ef5357bfa9b11da9b2bd1baedc4962 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11042: 3c31c0ac3fda554cb4383098e3f8ee4611720567 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3c31c0ac3fda drm/i915: Use intel_ types more consistently for color management
code
3b3378ade6f9 drm/i915: Use intel_ types more consistently for watermark code
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11042/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Use intel_* types more consistently
== Series Details == Series: Use intel_* types more consistently URL : https://patchwork.freedesktop.org/series/53705/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Use intel_ types more consistently for watermark code -drivers/gpu/drm/i915/selftests/../i915_drv.h:3563:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3562:16: warning: expression using sizeof(void) Commit: drm/i915: Use intel_ types more consistently for color management code Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Use intel_* types more consistently
== Series Details ==
Series: Use intel_* types more consistently
URL : https://patchwork.freedesktop.org/series/53705/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3b3378ade6f9 drm/i915: Use intel_ types more consistently for watermark code
3c31c0ac3fda drm/i915: Use intel_ types more consistently for color management
code
-:209: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'state->gamma_mode == GAMMA_MODE_MODE_SPLIT'
#209: FILE: drivers/gpu/drm/i915/intel_color.c:367:
+ if (IS_HASWELL(dev_priv) && state->ips_enabled &&
+ (state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
total: 0 errors, 0 warnings, 1 checks, 511 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Use intel_ types more consistently for color management code
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions. While we're at it, let's also be more
consistent with state variable naming (half of the platforms use the
name 'state' whereas the other half used 'crtc_state').
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_color.c | 207 ---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
drivers/gpu/drm/i915/intel_drv.h | 8 +-
4 files changed, 112 insertions(+), 127 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7469a7785253..48fb5e9bd08b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -321,8 +321,8 @@ struct drm_i915_display_funcs {
/* display clock increase/decrease */
/* pll clock increase/decrease */
- void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
- void (*load_luts)(struct drm_crtc_state *crtc_state);
+ void (*load_csc_matrix)(struct intel_crtc_state *state);
+ void (*load_luts)(struct intel_crtc_state *state);
};
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 5127da286a2b..335c4702fcfb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -74,12 +74,12 @@
#define ILK_CSC_COEFF_1_0 \
((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
-static bool crtc_state_is_legacy_gamma(struct drm_crtc_state *state)
+static bool crtc_state_is_legacy_gamma(struct intel_crtc_state *state)
{
- return !state->degamma_lut &&
- !state->ctm &&
- state->gamma_lut &&
- drm_color_lut_size(state->gamma_lut) == LEGACY_LUT_LENGTH;
+ return !state->base.degamma_lut &&
+ !state->base.ctm &&
+ state->base.gamma_lut &&
+ drm_color_lut_size(state->base.gamma_lut) == LEGACY_LUT_LENGTH;
}
/*
@@ -108,10 +108,10 @@ static u64 *ctm_mult_by_limited(u64 *result, const u64
*input)
return result;
}
-static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *crtc)
{
- int pipe = intel_crtc->pipe;
- struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ int pipe = crtc->pipe;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
@@ -132,14 +132,12 @@ static void ilk_load_ycbcr_conversion_matrix(struct
intel_crtc *intel_crtc)
I915_WRITE(PIPE_CSC_MODE(pipe), 0);
}
-static void ilk_load_csc_matrix(struct drm_crtc_state *crtc_state)
+static void ilk_load_csc_matrix(struct intel_crtc_state *state)
{
- struct drm_crtc *crtc = crtc_state->crtc;
- struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int i, pipe = intel_crtc->pipe;
+ struct intel_crtc *crtc = to_intel_crtc(state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int i, pipe = crtc->pipe;
uint16_t coeffs[9] = { 0, };
- struct intel_crtc_state *intel_crtc_state =
to_intel_crtc_state(crtc_state);
bool limited_color_range = false;
/*
@@ -147,14 +145,14 @@ static void ilk_load_csc_matrix(struct drm_crtc_state
*crtc_state)
* do the range compression using the gamma LUT instead.
*/
if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
- limited_color_range = intel_crtc_state->limited_color_range;
+ limited_color_range = state->limited_color_range;
- if (intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
- intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
- ilk_load_ycbcr_conversion_matrix(intel_crtc);
+ if (state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
+ state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
+ ilk_load_ycbcr_conversion_matrix(crtc);
return;
- } else if (crtc_state->ctm) {
- struct drm_color_ctm *ctm = crtc_state->ctm->data;
+ } else if (state->base.ctm) {
+ struct drm_color_ctm *ctm = state->base.ctm->data;
const u64 *input;
u64 temp[9];
@@ -253,16 +251,15 @@ static void ilk_load_csc_matrix(struct drm_crtc_state
*crtc_state)
/*
* Set up the pipe CSC unit on CherryView.
*/
-static void cherryview_load_csc_matrix(struct drm_crtc_state *state)
+static void cherryview_load_csc_matrix(struct intel_crtc_state *state)
{
- struct drm_crtc *crtc = state->crtc;
- struct drm_device *dev = crtc->dev;
+ s
[Intel-gfx] [PATCH 1/2] drm/i915: Use intel_ types more consistently for watermark code
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/intel_display.c | 32 ++---
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_pm.c | 250 ---
4 files changed, 134 insertions(+), 163 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0689e67c966e..7469a7785253 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -281,8 +281,7 @@ struct drm_i915_display_funcs {
int (*get_fifo_size)(struct drm_i915_private *dev_priv,
enum i9xx_plane_id i9xx_plane);
int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
- int (*compute_intermediate_wm)(struct drm_device *dev,
- struct intel_crtc *intel_crtc,
+ int (*compute_intermediate_wm)(struct intel_crtc *intel_crtc,
struct intel_crtc_state *newstate);
void (*initial_watermarks)(struct intel_atomic_state *state,
struct intel_crtc_state *cstate);
@@ -290,7 +289,7 @@ struct drm_i915_display_funcs {
struct intel_crtc_state *cstate);
void (*optimize_watermarks)(struct intel_atomic_state *state,
struct intel_crtc_state *cstate);
- int (*compute_global_watermarks)(struct drm_atomic_state *state);
+ int (*compute_global_watermarks)(struct intel_atomic_state *state);
void (*update_wm)(struct intel_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
/* Returns the active state of the crtc, and if the crtc is active,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 07c861884c70..db6004a883c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10661,12 +10661,9 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
*
* Returns true or false.
*/
-static bool intel_wm_need_update(struct drm_plane *plane,
-struct drm_plane_state *state)
+static bool intel_wm_need_update(struct intel_plane_state *cur,
+struct intel_plane_state *new)
{
- struct intel_plane_state *new = to_intel_plane_state(state);
- struct intel_plane_state *cur = to_intel_plane_state(plane->state);
-
/* Update watermarks on tiling or size changes. */
if (new->base.visible != cur->base.visible)
return true;
@@ -10775,7 +10772,8 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
/* must disable cxsr around plane enable/disable */
if (plane->id != PLANE_CURSOR)
pipe_config->disable_cxsr = true;
- } else if (intel_wm_need_update(&plane->base, plane_state)) {
+ } else if (intel_wm_need_update(to_intel_plane_state(plane->base.state),
+ to_intel_plane_state(plane_state))) {
if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
/* FIXME bollocks */
pipe_config->update_wm_pre = true;
@@ -10954,8 +10952,7 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
static int intel_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
@@ -11004,8 +11001,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
* old state and the new state. We can program these
* immediately.
*/
- ret = dev_priv->display.compute_intermediate_wm(dev,
- intel_crtc,
+ ret = dev_priv->display.compute_intermediate_wm(intel_crtc,
pipe_config);
if (ret) {
DRM_DEBUG_KMS("No valid intermediate pipe watermarks
are possible\n");
@@ -11964,7 +11960,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
if (INTEL_GEN(dev_priv) < 9 || !new_state->active)
return;
- skl_pipe_wm_get_hw_state(crtc, &hw_wm);
+ skl_pipe_wm_get_hw_state(intel_crtc, &hw_wm);
sw_wm = &to_intel_crtc_state(new_state)->wm.skl.optimal;
skl_pipe_ddb_get_hw_state(intel_crtc, hw_ddb_y, hw_d
[Intel-gfx] [PATCH 0/2] Use intel_* types more consistently
The i915 codebase usually tries to use intel_* types rather than drm_* types as parameters for internal driver functions that are only called by other i915 code. However I've noticed that the watermark code and the color management code are two places where we haven't been as careful about following that convention. Let's try to be more consistent about using the intel_* types. Matt Roper (2): drm/i915: Use intel_ types more consistently for watermark code drm/i915: Use intel_ types more consistently for color management code drivers/gpu/drm/i915/i915_drv.h | 9 +- drivers/gpu/drm/i915/intel_color.c | 207 ++--- drivers/gpu/drm/i915/intel_display.c | 52 drivers/gpu/drm/i915/intel_drv.h | 18 +-- drivers/gpu/drm/i915/intel_pm.c | 250 --- 5 files changed, 246 insertions(+), 290 deletions(-) -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Skip the ERR_PTR error state
== Series Details ==
Series: series starting with [1/3] drm/i915: Skip the ERR_PTR error state
URL : https://patchwork.freedesktop.org/series/53625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11031_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11031_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108039]
* igt@i915_suspend@debugfs-reader:
- shard-skl: PASS -> INCOMPLETE [fdo#104108]
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-skl: PASS -> FAIL [fdo#100368]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +2
* igt@kms_rmfb@close-fd:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +1
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-kbl: PASS -> DMESG-FAIL [fdo#108950]
* igt@pm_rpm@modeset-non-lpsp-stress-no-wait:
- {shard-iclb}: SKIP -> INCOMPLETE [fdo#108840]
* igt@pm_rpm@system-suspend-execbuf:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107807]
Possible fixes
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- {shard-iclb}: DMESG-WARN [fdo#107724] -> PASS +4
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_legacy@all-pipes-single-move:
- shard-hsw: DMESG-WARN [fdo#102614] -> PASS
* igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled:
- shard-skl: FAIL [fdo#103184] -> PASS
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-skl: FAIL [fdo#108472] -> PASS
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
- shard-hsw: DMESG-FAIL [fdo#102614] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- {shard-iclb}: FAIL [fdo#105683] / [fdo#108040] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite:
- {shard-iclb}: DMESG-FAIL [fdo#107724] -> PASS +3
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-render:
- shard-skl: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-wc:
- {shard-iclb}: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +5
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
- {shard-iclb}: FAIL [fdo#103167] -> PASS +4
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: FAIL [fdo#107815] / [fdo#108145] -> PASS
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: FAIL [fdo#107815] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
* igt@pm_rpm@gem-pread:
- shard-skl: INCOMPLETE [fdo#107807] -> PASS +1
* igt@pm_rpm@legacy-planes:
- {shard-iclb}: DMESG-WARN -> PASS
* igt@pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-skl: INCOMPLETE [fdo#107807] -> SKIP
Warnings
* igt@kms_content_protection@legacy:
- shard-apl: INCOMPLETE [fdo#103927] -> FAIL [fdo#108597]
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- {shard-iclb}: DMESG-WARN [fdo#107724] / [fdo#108336] -> FAIL
[fdo#108948]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- {shard-iclb}: FAIL [fdo#103375] -> INCOMPLETE [fdo#107713]
{name}: This ele
[Intel-gfx] ✓ Fi.CI.BAT: success for New DDB allocation algorithm (rev2)
== Series Details ==
Series: New DDB allocation algorithm (rev2)
URL : https://patchwork.freedesktop.org/series/53682/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5279 -> Patchwork_11041
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53682/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11041:
### IGT changes ###
Possible regressions
* {igt@runner@aborted}:
- fi-cfl-8109u: NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_11041 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: PASS -> FAIL [fdo#108656]
* igt@i915_module_load@reload:
- fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718]
* {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
Participating hosts (46 -> 42)
--
Additional (1): fi-icl-y
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3
Build changes
-
* Linux: CI_DRM_5279 -> Patchwork_11041
CI_DRM_5279: 8c3dbdac21ef5357bfa9b11da9b2bd1baedc4962 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11041: 0df16827bdf5f904893def72fcd9f2aab3f7fec0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0df16827bdf5 drm/i915: Switch to level-based DDB allocation algorithm (v2)
c26e16a3f466 drm/i915: Don't use DDB allocation when choosing gen9 watermark
method
041050b5e617 drm/i915: Remove a very stale FIXME
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11041/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for New DDB allocation algorithm (rev2)
== Series Details == Series: New DDB allocation algorithm (rev2) URL : https://patchwork.freedesktop.org/series/53682/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Remove a very stale FIXME Okay! Commit: drm/i915: Don't use DDB allocation when choosing gen9 watermark method -drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:6752:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:6752:35: warning: expression using sizeof(void) Commit: drm/i915: Switch to level-based DDB allocation algorithm (v2) Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Skip DSI path in DDI vswing programming.
== Series Details == Series: drm/i915/icl: Skip DSI path in DDI vswing programming. URL : https://patchwork.freedesktop.org/series/53703/ State : success == Summary == CI Bug Log - changes from CI_DRM_5279 -> Patchwork_11040 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/53703/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_11040 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094] * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341] * igt@gem_ctx_create@basic-files: - fi-bsw-kefka: PASS -> FAIL [fdo#108656] Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: DMESG-WARN -> PASS [fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341 [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094 [fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656 Participating hosts (46 -> 41) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3 Build changes - * Linux: CI_DRM_5279 -> Patchwork_11040 CI_DRM_5279: 8c3dbdac21ef5357bfa9b11da9b2bd1baedc4962 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11040: b5376994d2435d80bf43b696070164c4cb00417e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b5376994d243 drm/i915/icl: Skip DSI path in DDI vswing programming. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11040/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
On Thu, Dec 06, 2018 at 02:48:36PM +0530, Swati Sharma wrote:
> Fix the skip for kms_color/gamma subtest
>
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
> Test requirement: igt_pipe_obj_has_prop(&data->display.pipes[p],
> IGT_CRTC_DEGAMMA_LUT_SIZE)
> Subtest pipe-A-gamma: SKIP
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
> Test requirement: igt_pipe_obj_has_prop(&data->display.pipes[p],
> IGT_CRTC_DEGAMMA_LUT_SIZE)
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
> Test requirement: igt_pipe_obj_has_prop(&data->display.pipes[p],
> IGT_CRTC_DEGAMMA_LUT_SIZE)
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:847:
> Test requirement: p < data->display.n_pipes
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:847:
> Test requirement: p < data->display.n_pipes
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:847:
> Test requirement: p < data->display.n_pipes
>
> [Why]
> degamma_lut_size assigned 0
> [How]
> degamma_lut_size should be 35
> BSpec:18433
> Testcase:igt/kms_color/pipe-A-gamma
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 6350db5..a1e900b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -69,7 +69,7 @@
> #define CHV_COLORS \
> .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> #define GLK_COLORS \
> - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> + .color = { .degamma_lut_size = 35, .gamma_lut_size = 1024 }
Although the hardware has a degamma table, I believe leaving it disabled
for now was intended by the original author of that code since the
hardware degamma table doesn't work the same way as our other platforms
and doesn't exactly align with our driver ABI. I.e., GLK (and gen11 now
as well) just take a single value that it uses for the red, green, and
blue channels, whereas userspace expects to be able to upload a table
with different values for each.
I think to enable degamma we need to do the following:
* Add some checks that get run during the atomic check phase that test
to see whether r=g=b for each LUT entry. If userspace tried to
upload a table that we can't express to our hardware, we need to
reject the atomic transaction. While we're adding this function, we
should also probably check that other hardware requirements are
satisfied, such as that the table entries are always flat/increasing,
never decreasing.
* Update glk_load_degamma_lut() to actually make use of the
userspace-provided table. Right now that function is simply slamming
a linear table into the hardware rather than using whatever would
be uploaded from userspace via property blob.
* Finally, expose degamma to userspace by setting the table size as
you've done in this patch.
Also, I believe 35 entries isn't exactly right for GLK. While the
hardware table does have 35 slots, only the first 33 represent the usual
0-1.0 gamma range that our current driver ABI is exposing. Slots #34
and #35 are for "extended range" values which we don't currently have a
way of expressing through our ABI (we need to be able to express
non-uniform ranges and also values outside the usual 0-1.0 range). I
believe Uma is working on coming up with a way to expose this to
userspace, but it isn't ready just yet, so I think you'd want to just
set .degamma_lut_size to 33 for now and put a hardcoded 1.0 value into
the last two entries.
Matt
>
> /* Keep in gen based order, and chronological order within a gen */
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Switch to level-based DDB allocation algorithm (v2)
The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up. It turns out that this proportional
allocation approach is overly-generous with the larger planes and can
leave very small planes wthout a big enough allocation to even hit their
level 0 watermark requirements (especially on APL, which has a smaller
DDB in general than other gen9 platforms). Or there can be situations
where the smallest planes hit a lower watermark level than they should
have been able to hit with a more equitable division of DDB blocks, thus
limiting the overall system sleep state that can be achieved.
The bspec now describes an alternate algorithm that can be used to
overcome these types of issues. With the new algorithm, we calculate
all plane watermark values for all wm levels first, then go back and
partition a pipe's DDB space second. The DDB allocation will calculate
what the highest watermark level that can be achieved on *all* active
planes, and then grant the blocks necessary to hit that level to each
plane. Any remaining blocks are then divided up proportionally
according to data rate, similar to the old algorithm.
There was a previous attempt to implement this algorithm a couple years
ago in bb9d85f6e9d ("drm/i915/skl: New ddb allocation algorithm"), but
some regressions were reported, the patch was reverted, and nobody
ever got around to figuring out exactly where the bug was in that
version. Our watermark code has evolved significantly in the meantime,
but we're still getting bug reports caused by the unfair proportional
algorithm, so let's give this another shot.
v2:
- Make sure cursor allocation stays constant and fixed at the end of
the pipe allocation.
- Fix some watermark level iterators that weren't handling the max
level.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 350 +++-
1 file changed, 129 insertions(+), 221 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b09c2a257ff1..6db2bf7b037c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4306,102 +4306,6 @@ icl_get_total_relative_data_rate(struct
intel_crtc_state *intel_cstate,
return total_data_rate;
}
-static uint16_t
-skl_ddb_min_alloc(const struct drm_plane_state *pstate, const int plane)
-{
- struct drm_framebuffer *fb = pstate->fb;
- struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
- uint32_t src_w, src_h;
- uint32_t min_scanlines = 8;
- uint8_t plane_bpp;
-
- if (WARN_ON(!fb))
- return 0;
-
- /* For packed formats, and uv-plane, return 0 */
- if (plane == 1 && fb->format->format != DRM_FORMAT_NV12)
- return 0;
-
- /* For Non Y-tile return 8-blocks */
- if (fb->modifier != I915_FORMAT_MOD_Y_TILED &&
- fb->modifier != I915_FORMAT_MOD_Yf_TILED &&
- fb->modifier != I915_FORMAT_MOD_Y_TILED_CCS &&
- fb->modifier != I915_FORMAT_MOD_Yf_TILED_CCS)
- return 8;
-
- /*
-* Src coordinates are already rotated by 270 degrees for
-* the 90/270 degree plane rotation cases (to match the
-* GTT mapping), hence no need to account for rotation here.
-*/
- src_w = drm_rect_width(&intel_pstate->base.src) >> 16;
- src_h = drm_rect_height(&intel_pstate->base.src) >> 16;
-
- /* Halve UV plane width and height for NV12 */
- if (plane == 1) {
- src_w /= 2;
- src_h /= 2;
- }
-
- plane_bpp = fb->format->cpp[plane];
-
- if (drm_rotation_90_or_270(pstate->rotation)) {
- switch (plane_bpp) {
- case 1:
- min_scanlines = 32;
- break;
- case 2:
- min_scanlines = 16;
- break;
- case 4:
- min_scanlines = 8;
- break;
- case 8:
- min_scanlines = 4;
- break;
- default:
- WARN(1, "Unsupported pixel depth %u for rotation",
-plane_bpp);
- min_scanlines = 32;
- }
- }
-
- return DIV_ROUND_UP((4 * src_w * plane_bpp), 512) * min_scanlines/4 + 3;
-}
-
-static void
-skl_ddb_calc_min(const struct intel_crtc_state *cstate, int num_active,
-uint16_t *minimum, uint16_t *uv_minimum)
-{
- const struct drm_plane_state *pstate;
- struct drm_plane *plane;
-
- drm_atomic_crtc_state_for_each_plane_state(plane, pstate,
&cstate->base) {
- enum plane_
[Intel-gfx] [ANNOUNCE] xf86-video-i740 1.4.0
This is a maintenance release of Intel740 DDX. For those who do not know what Intel740 is (was), as of now, it is the only Intel discrete graphics chip to officially ship ever since Intel got deeply involved in the x86 PC system business with the likes of PCI bus and USB. And yes, that was almost 21 years ago. There was one patch that has been languishing over at Patchwork X.org website (https://patchwork.freedesktop.org/patch/122823/) for more than 2 years, so I decided to apply it, and release a new version. With that patch applied and one more small patch I authored, the DDX compiles cleanly without compilation warnings. Kevin Brace Brace Computer Laboratory https://bracecomputerlab.com --- Alan Coopersmith (3): configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Update configure.ac bug URL for gitlab migration Emil Velikov (1): autogen.sh: use quoted string variables Kevin Brace (2): Declare a variable only when XSERVER_LIBPCIACCESS is defined Version bumped to Version 1.4.0 Laurent Carlier (1): Stop using deprecated xf86PciInfo.h Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: xf86-video-i740-1.4.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-i740-1.4.0.tar.bz2 MD5: 34495b1e8f81507d8d5d38777f2e24ac xf86-video-i740-1.4.0.tar.bz2 SHA1: acbbc042f18d796b39588516b6cbb03684d99cd6 xf86-video-i740-1.4.0.tar.bz2 SHA256: 46e401219f8ceea1faa58efd46d05a5c3f85f08d789014e7234fb755520d7a50 xf86-video-i740-1.4.0.tar.bz2 SHA512: d34bcd1084de3173b65b9da4afc88435b153979ed4748cfa715d39f28fb238a21bbca7190a9091cdd9c67f55f98e4ae57980ef4dd7ca3dcfda373712f6bd0568 xf86-video-i740-1.4.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-i740-1.4.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-i740-1.4.0.tar.gz MD5: 2d0fa9b90b64642f245b4827a8a0decb xf86-video-i740-1.4.0.tar.gz SHA1: 4decbc535dd06063e59ad3600b93fdced14985fb xf86-video-i740-1.4.0.tar.gz SHA256: 956e3718b181602d7cf44a9fb00e9d07dca0ded78ce5db1c3115ce8ee57fc367 xf86-video-i740-1.4.0.tar.gz SHA512: 36e4be6a85ead6affa185d86e2548fe31b4e038bbdd9d80f3016a1888f7c9e74a991ce2c1874a27280cd63abb8bec4961d1fe9606484f7856f4d96615c146749 xf86-video-i740-1.4.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-i740-1.4.0.tar.gz.sig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl: Skip DSI path in DDI vswing programming.
DSI implements it's own pre_enable hook, encoder output type is never
DSI.
Cc: Manasi Navare
Cc: Paulo Zanoni
Cc: James Ausmus
Fixes: fb5c8e9d4350 ("drm/i915/icl: Implement voltage swing programming
sequence for Combo PHY DDI")
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_ddi.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f3e1d6a0b7dd..5792632fa6a3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2489,13 +2489,8 @@ static void icl_ddi_combo_vswing_program(struct
drm_i915_private *dev_priv,
/* Set DisableTap2 and DisableTap3 if MIPI DSI
* Clear DisableTap2 and DisableTap3 for all other Ports
*/
- if (type == INTEL_OUTPUT_DSI) {
- val |= TAP2_DISABLE;
- val |= TAP3_DISABLE;
- } else {
- val &= ~TAP2_DISABLE;
- val &= ~TAP3_DISABLE;
- }
+ val &= ~TAP2_DISABLE;
+ val &= ~TAP3_DISABLE;
I915_WRITE(ICL_PORT_TX_DW5_GRP(port), val);
/* Program PORT_TX_DW2 */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Change KVMGT into self loadable module (rev3)
== Series Details ==
Series: Change KVMGT into self loadable module (rev3)
URL : https://patchwork.freedesktop.org/series/53379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11030_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11030_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_read@short-buffer-nonblock:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614] +1
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108039]
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_chv_cursor_fail@pipe-c-128x128-left-edge:
- shard-skl: NOTRUN -> FAIL [fdo#104671]
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-xtiled:
- {shard-iclb}: PASS -> WARN [fdo#108336]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724]
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-apl: PASS -> FAIL [fdo#108948]
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +3
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- {shard-iclb}: PASS -> FAIL [fdo#103166] +1
* igt@kms_vblank@pipe-b-ts-continuation-idle-hang:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +5
* igt@pm_rpm@basic-pci-d3-state:
- shard-skl: PASS -> INCOMPLETE [fdo#107807]
* igt@pm_rpm@legacy-planes-dpms:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#108840]
Possible fixes
* igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
- shard-skl: FAIL [fdo#107815] / [fdo#108470] -> PASS
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- {shard-iclb}: DMESG-WARN [fdo#107724] -> PASS +5
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-256x85-offscreen:
- shard-skl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_legacy@all-pipes-single-move:
- shard-hsw: DMESG-WARN [fdo#102614] -> PASS
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
- shard-hsw: DMESG-FAIL [fdo#102614] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- {shard-iclb}: FAIL [fdo#105683] / [fdo#108040] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite:
- {shard-iclb}: DMESG-FAIL [fdo#107724] -> PASS +3
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-wc:
- {shard-iclb}: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +5
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
- {shard-iclb}: FAIL [fdo#103167] -> PASS +4
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-glk: FAIL [fdo#108948] -> PASS
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl: FAIL [fdo#108145] -> PASS
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- {shard-iclb}: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- {shard-iclb}: FAIL [fdo#103375] -> PASS +1
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
* igt@pm_rpm@gem-pread:
- shard-skl: INCOMPLETE [fdo#107807] -> PASS +1
* igt@pm_rpm@legacy-planes:
- {shard-iclb}: DMESG-WARN -> PASS
* igt@pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-skl:
[Intel-gfx] [PATCH xf86-video-i740] Declare a variable only when XSERVER_LIBPCIACCESS is defined
This is to suppress a compilation warning when compiling against
newer X Servers.
Signed-off-by: Kevin Brace
---
src/i740_driver.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/i740_driver.c b/src/i740_driver.c
index 7c1051d..a3675b6 100644
--- a/src/i740_driver.c
+++ b/src/i740_driver.c
@@ -780,7 +780,9 @@ I740PreInit(ScrnInfoPtr pScrn, int flags) {
static Bool I740MapMem(ScrnInfoPtr pScrn)
{
+#ifndef XSERVER_LIBPCIACCESS
int mmioFlags;
+#endif
I740Ptr pI740;
pI740 = I740PTR(pScrn);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Return immediately if trylock fails for direct-reclaim
Quoting Tvrtko Ursulin (2018-12-06 15:18:13)
>
> On 04/12/2018 14:15, Chris Wilson wrote:
> > Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
> > in the shrinker while performing direct-reclaim. The trade-off being
> > (much) lower latency for non-i915 clients at an increased risk of being
> > unable to obtain a page from direct-reclaim without hitting the
> > oom-notifier. The proviso being that we still keep trying to hard
> > obtain the lock for oom so that we can reap under heavy memory pressure.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> > drivers/gpu/drm/i915/i915_gem_shrinker.c | 24 +++-
> > 2 files changed, 13 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c5f01964f0fb..1cad218b71d3 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2916,9 +2916,9 @@ i915_gem_object_unpin_pages(struct
> > drm_i915_gem_object *obj)
> > __i915_gem_object_unpin_pages(obj);
> > }
> >
> > -enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
> > +enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex
> > */
> > I915_MM_NORMAL = 0,
> > - I915_MM_SHRINKER
> > + I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
> > };
> >
> > void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
> > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > index ea90d3a0d511..d461f458f4af 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > @@ -36,7 +36,9 @@
> > #include "i915_drv.h"
> > #include "i915_trace.h"
> >
> > -static bool shrinker_lock(struct drm_i915_private *i915, bool *unlock)
> > +static bool shrinker_lock(struct drm_i915_private *i915,
> > + unsigned int flags,
> > + bool *unlock)
> > {
> > switch (mutex_trylock_recursive(&i915->drm.struct_mutex)) {
> > case MUTEX_TRYLOCK_RECURSIVE:
> > @@ -45,15 +47,11 @@ static bool shrinker_lock(struct drm_i915_private
> > *i915, bool *unlock)
> >
> > case MUTEX_TRYLOCK_FAILED:
> > *unlock = false;
> > - preempt_disable();
> > - do {
> > - cpu_relax();
> > - if (mutex_trylock(&i915->drm.struct_mutex)) {
> > - *unlock = true;
> > - break;
> > - }
> > - } while (!need_resched());
> > - preempt_enable();
> > + if (flags & I915_SHRINK_ACTIVE) {
> > + mutex_lock_nested(&i915->drm.struct_mutex,
> > + I915_MM_SHRINKER);
> > + *unlock = true;
> > + }
>
> I just realized once oddity in the shrinker code which escaped me
> before. It is the fact the call paths will call the shrinker_lock twice.
> For instance i915_gem_shrinker_vmap and i915_gem_shrinker_scan. They
> both first take lock with flags of zero, and then they call
> i915_gem_shrink which takes the lock again, which obviously always
> results in the recursive path to be taken.
>
> I think we need to clean this up so it is easier to understand the code
> before further tweaking, even if in this patch. For instance adding
> I915_SHRINK_LOCKED would solve it.
>
> shrinker_lock_uninterruptible is also funky in that it doesn't respect
> the timeout in the waiting for idle phase.
>
> Sounds reasonable?
My alternate code for this avoids struct_mutex here, but the compromise
is that we can't process active requests here, and can't reap pages from
zombie objects (objects that are still waiting for the RCU release).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Apply a full mb before execution for Braswell
Quoting Tvrtko Ursulin (2018-12-06 13:12:35)
>
> On 06/12/2018 08:44, Chris Wilson wrote:
> > Braswell is really picky about having our writes posted to memory before
> > we execute or else the GPU may see stale values. A wmb() is insufficient
> > as it only ensures the writes are visible to other cores, we need a full
> > mb() to ensure the writes are in memory and visible to the GPU.
> >
> > The most frequent failure in flushing before execution is that we see
> > stale PTE values and execute the wrong pages.
> >
> > References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation
> > into context image vs execution")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Tvrtko Ursulin
> > Cc: Joonas Lahtinen
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index de1e9dc6aec0..e6a86fa4502d 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -379,8 +379,13 @@ static u64 execlists_update_context(struct
> > i915_request *rq)
> >* may not be visible to the HW prior to the completion of the UC
> >* register write and that we may begin execution from the context
> >* before its image is complete leading to invalid PD chasing.
> > + *
> > + * Furthermore, Braswell, at least, wants a full mb to be sure that
> > + * the writes are coherent in memory (visible to the GPU) prior to
> > + * execution, and not just visible to other CPUs (as is the result of
> > + * wmb).
> >*/
> > - wmb();
> > + mb();
> > return ce->lrc_desc;
> > }
> >
> >
>
> Too low level for me to really know what happens under the hood, but at
> least I know it can't break anything.
The alternative I'm considering is using a mmio read instead. However,
the improvement in stability from switching to mb() here is already
enough to proceed without necessarily finding the ideal solution.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Skip the ERR_PTR error state
Quoting Tvrtko Ursulin (2018-12-06 12:57:23)
>
> On 06/12/2018 08:44, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 07465123c166..7ca6f3f31d41 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -1907,6 +1907,11 @@ i915_capture_gpu_state(struct drm_i915_private *i915)
> > {
> > struct i915_gpu_state *error;
> >
> > + /* Check if GPU capture has been disabled */
> > + error = READ_ONCE(i915->gpu_error.first_error);
> > + if (IS_ERR(error))
> > + return error;
> > +
> > error = kzalloc(sizeof(*error), GFP_ATOMIC);
> > if (!error)
> > return NULL;
>
> Looks like it would be cleaner to return ERR_PTR(-ENOMEM) here. At least
> the i915_gpu_info_open hunk would be.
>
> Then in drm-tip I see i915_capture_error_state as a caller which needs
> to handle ERR_PTR now as well, no?
It shouldn't due to the earlier check, but it would work better if it
tool the ERR_PTR pointer from here.
> > @@ -1987,7 +1992,7 @@ i915_first_error_state(struct drm_i915_private *i915)
> >
> > spin_lock_irq(&i915->gpu_error.lock);
> > error = i915->gpu_error.first_error;
> > - if (error)
> > + if (!IS_ERR_OR_NULL(error))
> > i915_gpu_state_get(error);
> > spin_unlock_irq(&i915->gpu_error.lock);
> >
> > @@ -2000,10 +2005,11 @@ void i915_reset_error_state(struct drm_i915_private
> > *i915)
> >
> > spin_lock_irq(&i915->gpu_error.lock);
> > error = i915->gpu_error.first_error;
> > - i915->gpu_error.first_error = NULL;
> > + if (!IS_ERR_OR_NULL(error)) /* once disabled, always disabled */
>
> Hm, this will apply on transient -ENOMEM as well.
Yeah. The best compromise is to say only ENODEV is special.
> > + i915->gpu_error.first_error = NULL;
> > spin_unlock_irq(&i915->gpu_error.lock);
> >
> > - if (!IS_ERR(error))
> > + if (!IS_ERR_OR_NULL(error))
> > i915_gpu_state_put(error);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> > b/drivers/gpu/drm/i915/i915_sysfs.c
> > index 535caebd9813..370b7497e9df 100644
> > --- a/drivers/gpu/drm/i915/i915_sysfs.c
> > +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> > @@ -521,6 +521,9 @@ static ssize_t error_state_read(struct file *filp,
> > struct kobject *kobj,
> > ssize_t ret;
> >
> > gpu = i915_first_error_state(i915);
> > + if (IS_ERR(gpu))
> > + return PTR_ERR(gpu);
> > +
> > if (gpu) {
> > ret = i915_gpu_state_copy_to_buffer(gpu, buf, off, count);
> > i915_gpu_state_put(gpu);#
> >
>
> A single control block:
>
> if (!IS_ERR_OR_NULL) {
> ...
> } else {
> ...
> }
>
> seems like it would do the trick.
Not quite unless you were thinking of if { } else if { } else { };
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Make GEN macros more similar (rev3)
== Series Details ==
Series: Make GEN macros more similar (rev3)
URL : https://patchwork.freedesktop.org/series/51860/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11029_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11029_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108039]
* igt@gem_softpin@noreloc-s3:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_busy@basic-modeset-a:
- shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +8
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_chv_cursor_fail@pipe-a-256x256-left-edge:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +3
* igt@kms_chv_cursor_fail@pipe-b-256x256-bottom-edge:
- shard-skl: PASS -> FAIL [fdo#104671]
* igt@kms_chv_cursor_fail@pipe-c-128x128-left-edge:
- shard-skl: NOTRUN -> FAIL [fdo#104671]
* igt@kms_color@pipe-b-ctm-green-to-red:
- shard-skl: PASS -> FAIL [fdo#107201]
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108]
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
- shard-kbl: PASS -> DMESG-WARN [fdo#108566]
* igt@kms_draw_crc@draw-method-xrgb-render-ytiled:
- {shard-iclb}: PASS -> WARN [fdo#108336] +2
* igt@kms_flip@basic-flip-vs-wf_vblank:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +14
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: NOTRUN -> FAIL [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107720] / [fdo#107724] +1
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt:
- {shard-iclb}: PASS -> FAIL [fdo#103167]
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- shard-apl: PASS -> FAIL [fdo#108948] +1
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +2
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724] +5
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- {shard-iclb}: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166]
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538]
* igt@kms_universal_plane@universal-plane-pipe-b-functional:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724]
* igt@pm_rpm@cursor-dpms:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#108654]
* igt@pm_rpm@dpms-mode-unset-lpsp:
- shard-skl: PASS -> INCOMPLETE [fdo#107807]
* igt@pm_rpm@gem-execbuf-stress-pc8:
- {shard-iclb}: SKIP -> INCOMPLETE [fdo#107713] / [fdo#108840]
Possible fixes
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- {shard-iclb}: DMESG-WARN [fdo#107724] -> PASS +6
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_legacy@all-pipes-single-move:
- shard-hsw: DMESG-WARN [fdo#102614] -> PASS
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
- shard-hsw: DMESG-FAIL [fdo#102614] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- {shard-iclb}: FAIL [fdo#105683] / [fdo#108040] -> PASS
* igt@kms_frontbuffer_trackin
Re: [Intel-gfx] drm tip conflict in intel_workarounds.c
On Thu, Dec 06, 2018 at 12:25:48PM +1000, Dave Airlie wrote: > I merged the i915 tree into drm-next this morning, but got a major > conflict on the drm-tip rebuild in intel_workarounds.c. > > I'm not sure if I did wrong thing, but there were a couple of places > where the code seemed inconsistent and I couldn't track down what was > actually wanted. I'd appreciate someone checking my work on what is in > current drm-tip, what is currently on drm-tip looks sane to me. > > /* Wa_1604302699:icl */ > + wa_write_or(wal, > + GEN10_L3_CHICKEN_MODE_REGISTER, > + GEN11_I2M_WRITE_DISABLE); > > and > > - > - /* Wa_1406609255:icl (pre-prod) */ > - if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_B0)) > - wa_write_or(wal, > - GEN7_SARCHKMD, > - GEN7_DISABLE_DEMAND_PREFETCH | > - GEN7_DISABLE_SAMPLER_PREFETCH); > > were the two problems I was seeing. > > Dave. > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/selftests: verify_gt_engine_wa()
needs rpm wakeref
URL : https://patchwork.freedesktop.org/series/53687/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5277 -> Patchwork_11039
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53687/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11039:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- {fi-kbl-7567u}: SKIP -> PASS +33
Known issues
Here are the changes found in Patchwork_11039 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN -> PASS
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@gem_mmap_gtt@basic-small-copy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (48 -> 41)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks
fi-bsw-cyan fi-gdg-551 fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5277 -> Patchwork_11039
CI_DRM_5277: 13e7a0e59420cbdafca1cedbe2d9c136180aa689 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11039: 6fe6cf6ba62eff3e69185819a6a8ae6953901136 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6fe6cf6ba62e drm/i915/execlists: Move RCS mmio workaround to new common wa_list
422c46d9ff54 drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11039/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/execlists: Move RCS mmio workaround to new common wa_list
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
v2: INSTPM_FORCE_ORDERING is already part of gen8_ctx_workarounds, and
as confirmed by the mmio verification is a part of the context image!
v3: MI_MODE is already part of gen_ctx_workarounds...
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 42 +---
drivers/gpu/drm/i915/intel_workarounds.c | 1 +
2 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d7fa301b5ec7..dc8981be22cf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1628,6 +1628,7 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
intel_engine_apply_workarounds(engine);
+ intel_engine_apply_whitelist(engine);
intel_mocs_init_engine(engine);
@@ -1644,43 +1645,6 @@ static int gen8_init_common_ring(struct intel_engine_cs
*engine)
return 0;
}
-static int gen8_init_render_ring(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- /* We need to disable the AsyncFlip performance optimisations in order
-* to use MI_WAIT_FOR_EVENT within the CS. It should already be
-* programmed to '1' on all products.
-*
-* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
-*/
- I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));
-
- I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
-
- return 0;
-}
-
-static int gen9_init_render_ring(struct intel_engine_cs *engine)
-{
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- return 0;
-}
-
static struct i915_request *
execlists_reset_prepare(struct intel_engine_cs *engine)
{
@@ -2280,10 +2244,6 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
engine->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
/* Override some for render ring. */
- if (INTEL_GEN(dev_priv) >= 9)
- engine->init_hw = gen9_init_render_ring;
- else
- engine->init_hw = gen8_init_render_ring;
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 6bcac78a9c36..d02f7e6c0051 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1231,6 +1231,7 @@ static void rcs_engine_wa_init(struct intel_engine_cs
*engine)
GEN8_L3SQCREG4,
GEN8_LQSC_FLUSH_COHERENT_LINES);
}
+
}
static void xcs_engine_wa_init(struct intel_engine_cs *engine)
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers retain their magic values across rpm suspend/resume.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/intel_workarounds.c| 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index 67017d5175b8..c2b3cd8fcc34 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -333,7 +333,6 @@ static bool verify_gt_engine_wa(struct drm_i915_private
*i915, const char *str)
bool ok = true;
ok &= intel_gt_verify_workarounds(i915, str);
-
for_each_engine(engine, i915, id)
ok &= intel_engine_verify_workarounds(engine, str);
@@ -353,19 +352,19 @@ live_gpu_reset_gt_engine_workarounds(void *arg)
pr_info("Verifying after GPU reset...\n");
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
ok = verify_gt_engine_wa(i915, "before reset");
if (!ok)
goto out;
- intel_runtime_pm_get(i915);
set_bit(I915_RESET_HANDOFF, &error->flags);
i915_reset(i915, ALL_ENGINES, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after reset");
out:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
return ok ? 0 : -ESRCH;
@@ -390,6 +389,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
return PTR_ERR(ctx);
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
for_each_engine(engine, i915, id) {
bool ok;
@@ -402,9 +402,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
goto err;
}
- intel_runtime_pm_get(i915);
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after idle reset");
if (!ok) {
@@ -416,13 +414,10 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (ret)
goto err;
- intel_runtime_pm_get(i915);
-
rq = igt_spinner_create_request(&spin, ctx, engine, MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
goto err;
}
@@ -431,15 +426,12 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (!igt_wait_for_spinner(&spin, rq)) {
pr_err("Spinner failed to start\n");
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
ret = -ETIMEDOUT;
goto err;
}
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
-
igt_spinner_end(&spin);
igt_spinner_fini(&spin);
@@ -451,6 +443,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
}
err:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
kernel_context_close(ctx);
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for New DDB allocation algorithm
== Series Details ==
Series: New DDB allocation algorithm
URL : https://patchwork.freedesktop.org/series/53682/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5277 -> Patchwork_11038
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11038 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11038, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53682/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11038:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005: PASS -> DMESG-FAIL +1
- fi-skl-iommu: PASS -> DMESG-FAIL +1
- fi-whl-u: PASS -> DMESG-FAIL +1
- fi-skl-6700hq: PASS -> FAIL +2
- fi-kbl-7560u: PASS -> DMESG-FAIL +1
- fi-cfl-8109u: PASS -> DMESG-FAIL +1
- fi-cfl-guc: PASS -> DMESG-FAIL +1
- fi-skl-6260u: PASS -> DMESG-FAIL +1
- fi-bxt-j4205: PASS -> DMESG-FAIL +1
- {fi-icl-u3}:PASS -> DMESG-FAIL +1
- fi-skl-6770hq: PASS -> DMESG-FAIL
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: PASS -> DMESG-FAIL +1
- fi-cfl-8700k: PASS -> DMESG-FAIL +1
- fi-apl-guc: PASS -> DMESG-FAIL +1
- fi-glk-dsi: NOTRUN -> DMESG-FAIL +1
- fi-skl-6700hq: PASS -> DMESG-FAIL
- fi-skl-gvtdvm: PASS -> DMESG-FAIL +1
- fi-bxt-dsi: PASS -> DMESG-FAIL +1
- {fi-kbl-7567u}: SKIP -> DMESG-FAIL +1
- fi-kbl-r: PASS -> DMESG-FAIL +1
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-bxt-j4205: PASS -> FAIL +1
- fi-glk-j4005: PASS -> FAIL +1
- fi-cfl-8109u: PASS -> FAIL +1
- fi-whl-u: PASS -> FAIL +1
- fi-bxt-dsi: PASS -> FAIL +1
- fi-cfl-8700k: PASS -> FAIL +1
- fi-skl-iommu: PASS -> FAIL +1
- fi-kbl-x1275: PASS -> FAIL +1
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-cfl-guc: PASS -> FAIL +1
- fi-glk-dsi: NOTRUN -> FAIL +1
- {fi-kbl-7567u}: SKIP -> FAIL +1
- fi-apl-guc: PASS -> FAIL +1
- fi-kbl-7560u: PASS -> FAIL +1
- fi-skl-6770hq: PASS -> FAIL +2
- fi-skl-6260u: PASS -> FAIL +1
- fi-skl-gvtdvm: PASS -> FAIL +1
- fi-kbl-r: PASS -> FAIL +1
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- {fi-kbl-7567u}: SKIP -> PASS +29
Known issues
Here are the changes found in Patchwork_11038 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2: PASS -> INCOMPLETE [fdo#104108] / [fdo#105524] /
[k.org#199541]
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- {fi-icl-u3}:PASS -> FAIL [fdo#107736] +1
* {igt@runner@aborted}:
- {fi-icl-u3}:NOTRUN -> FAIL [fdo#108315]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN -> PASS
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@gem_mmap_gtt@basic-small-copy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: DMESG-WARN [fdo#102614] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108315]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#105524]: https://bugs.freedesktop.org/show_bug.cgi?id=105524
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107736]: https://bugs.freedesktop.org/show_bug.cgi?id=107736
[fdo#1
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/selftests: verify_gt_engine_wa()
needs rpm wakeref
URL : https://patchwork.freedesktop.org/series/53673/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5277 -> Patchwork_11037
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11037 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11037, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53673/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11037:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_workarounds:
- fi-bsw-n3050: PASS -> DMESG-FAIL
- fi-bdw-5557u: PASS -> DMESG-FAIL
- fi-bdw-gvtdvm: PASS -> DMESG-FAIL
Warnings
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: PASS -> SKIP +36
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- {fi-kbl-7567u}: SKIP -> PASS +33
Known issues
Here are the changes found in Patchwork_11037 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* {igt@runner@aborted}:
- fi-bsw-kefka: NOTRUN -> FAIL [fdo#108656]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN -> PASS
* igt@gem_mmap_gtt@basic-small-copy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS
Warnings
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> DMESG-FAIL [fdo#108656]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (48 -> 43)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks
fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5277 -> Patchwork_11037
CI_DRM_5277: 13e7a0e59420cbdafca1cedbe2d9c136180aa689 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11037: 54b6bc238fb73fa1e5e5186ac82aa21e87509e83 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
54b6bc238fb7 drm/i915/execlists: Move RCS mmio workaround to new common wa_list
79bdd5a7a0d4 drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11037/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for New DDB allocation algorithm
== Series Details == Series: New DDB allocation algorithm URL : https://patchwork.freedesktop.org/series/53682/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Remove a very stale FIXME Okay! Commit: drm/i915: Don't use DDB allocation when choosing gen9 watermark method -drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:6752:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:6752:35: warning: expression using sizeof(void) Commit: drm/i915: Switch to level-based DDB allocation algorithm Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for New DDB allocation algorithm
== Series Details == Series: New DDB allocation algorithm URL : https://patchwork.freedesktop.org/series/53682/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2a7cd471873a drm/i915: Remove a very stale FIXME e52095e73e0d drm/i915: Don't use DDB allocation when choosing gen9 watermark method 193e7356179f drm/i915: Switch to level-based DDB allocation algorithm -:537: CHECK:LINE_SPACING: Please don't use multiple blank lines #537: FILE: drivers/gpu/drm/i915/intel_pm.c:5467: + + total: 0 errors, 0 warnings, 1 checks, 486 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Switch to level-based DDB allocation algorithm
The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up. It turns out that this proportional
allocation approach is overly-generous with the larger planes and can
leave very small planes wthout a big enough allocation to even hit their
level 0 watermark requirements (especially on APL, which has a smaller
DDB in general than other gen9 platforms). Or there can be situations
where the smallest planes hit a lower watermark level than they should
have been able to hit with a more equitable division of DDB blocks, thus
limiting the overall system sleep state that can be achieved.
The bspec now describes an alternate algorithm that can be used to
overcome these types of issues. With the new algorithm, we calculate
all plane watermark values for all wm levels first, then go back and
partition a pipe's DDB space second. The DDB allocation will calculate
what the highest watermark level that can be achieved on *all* active
planes, and then grant the blocks necessary to hit that level to each
plane. Any remaining blocks are then divided up proportionally
according to data rate, similar to the old algorithm.
There was a previous attempt to implement this algorithm a couple years
ago in bb9d85f6e9d ("drm/i915/skl: New ddb allocation algorithm"), but
some regressions were reported, the patch was reverted, and nobody
ever got around to figuring out exactly where the bug was in that
version. Our watermark code has evolved significantly in the meantime,
but we're still getting bug reports caused by the unfair proportional
algorithm, so let's give this another shot.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 345 ++--
1 file changed, 121 insertions(+), 224 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b09c2a257ff1..6c60a668c383 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4306,102 +4306,6 @@ icl_get_total_relative_data_rate(struct
intel_crtc_state *intel_cstate,
return total_data_rate;
}
-static uint16_t
-skl_ddb_min_alloc(const struct drm_plane_state *pstate, const int plane)
-{
- struct drm_framebuffer *fb = pstate->fb;
- struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
- uint32_t src_w, src_h;
- uint32_t min_scanlines = 8;
- uint8_t plane_bpp;
-
- if (WARN_ON(!fb))
- return 0;
-
- /* For packed formats, and uv-plane, return 0 */
- if (plane == 1 && fb->format->format != DRM_FORMAT_NV12)
- return 0;
-
- /* For Non Y-tile return 8-blocks */
- if (fb->modifier != I915_FORMAT_MOD_Y_TILED &&
- fb->modifier != I915_FORMAT_MOD_Yf_TILED &&
- fb->modifier != I915_FORMAT_MOD_Y_TILED_CCS &&
- fb->modifier != I915_FORMAT_MOD_Yf_TILED_CCS)
- return 8;
-
- /*
-* Src coordinates are already rotated by 270 degrees for
-* the 90/270 degree plane rotation cases (to match the
-* GTT mapping), hence no need to account for rotation here.
-*/
- src_w = drm_rect_width(&intel_pstate->base.src) >> 16;
- src_h = drm_rect_height(&intel_pstate->base.src) >> 16;
-
- /* Halve UV plane width and height for NV12 */
- if (plane == 1) {
- src_w /= 2;
- src_h /= 2;
- }
-
- plane_bpp = fb->format->cpp[plane];
-
- if (drm_rotation_90_or_270(pstate->rotation)) {
- switch (plane_bpp) {
- case 1:
- min_scanlines = 32;
- break;
- case 2:
- min_scanlines = 16;
- break;
- case 4:
- min_scanlines = 8;
- break;
- case 8:
- min_scanlines = 4;
- break;
- default:
- WARN(1, "Unsupported pixel depth %u for rotation",
-plane_bpp);
- min_scanlines = 32;
- }
- }
-
- return DIV_ROUND_UP((4 * src_w * plane_bpp), 512) * min_scanlines/4 + 3;
-}
-
-static void
-skl_ddb_calc_min(const struct intel_crtc_state *cstate, int num_active,
-uint16_t *minimum, uint16_t *uv_minimum)
-{
- const struct drm_plane_state *pstate;
- struct drm_plane *plane;
-
- drm_atomic_crtc_state_for_each_plane_state(plane, pstate,
&cstate->base) {
- enum plane_id plane_id = to_intel_plane(plane)->id;
- struct intel_plane_state *plane_state =
to_intel_plane_state(pstate);
-
- if (plane_id == PLANE_CURSOR)
-
[Intel-gfx] [PATCH 2/3] drm/i915: Don't use DDB allocation when choosing gen9 watermark method
The bspec gives an if/else chain for choosing whether to use "method 1"
or "method 2" for calculating the watermark "Selected Result Blocks"
value for a plane. One of the branches of the if chain is:
"Else If ('plane buffer allocation' is known and (plane buffer
allocation / plane blocks per line) >=1)"
Since our driver currently calculates DDB allocations first and the
actual watermark values second, the plane buffer allocation is known at
this point in our code and we include this test in our driver's logic.
However we plan to soon move to a "watermarks first, ddb allocation
second" sequence where we won't know the DDB allocation at this point.
Let's drop this arm of the if/else statement (effectively considering
the DDB allocation unknown) as an independent patch so that any
regressions can be more accurately bisected to either the different
watermark value (in this patch) or the new DDB allocation (in the next
patch).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9500bda64f26..b09c2a257ff1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4766,13 +4766,6 @@ static int skl_compute_plane_wm(const struct
intel_crtc_state *cstate,
wp->dbuf_block_size < 1) &&
(wp->plane_bytes_per_line / wp->dbuf_block_size < 1)) {
selected_result = method2;
- } else if (ddb_allocation >=
-fixed16_to_u32_round_up(wp->plane_blocks_per_line)) {
- if (IS_GEN9(dev_priv) &&
- !IS_GEMINILAKE(dev_priv))
- selected_result = min_fixed16(method1, method2);
- else
- selected_result = method2;
} else if (latency >= wp->linetime_us) {
if (IS_GEN9(dev_priv) &&
!IS_GEMINILAKE(dev_priv))
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Remove a very stale FIXME
SKL watermark calculations can and do trigger atomic transaction
rejection if no valid set of watermarks can be found. This FIXME
comment in the code hasn't been relevant for a very long time.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a26b4eddda25..9500bda64f26 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5548,10 +5548,6 @@ skl_compute_wm(struct drm_atomic_state *state)
* Note that the DDB allocation above may have added more CRTC's that
* weren't otherwise being modified (and set bits in dirty_pipes) if
* pipe allocations had to change.
-*
-* FIXME: Now that we're doing this in the atomic check phase, we
-* should allow skl_update_pipe_wm() to return failure in cases where
-* no suitable watermark values can be found.
*/
for_each_new_crtc_in_state(state, crtc, cstate, i) {
struct intel_crtc_state *intel_cstate =
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] New DDB allocation algorithm
Our current algorithm for partitioning a pipe's DDB allocation bases plane allocations exclusively on the proportion of the pipe's data rate that the plane contributes. This is a simple heuristic that works pretty well in a lot of cases, but it breaks down when there's a large difference in plane sizes (e.g., one full-screen plane and another 100x100 plane). When sizes are very different, using proportional data rate can leave the smaller planes without enough DDB allocation to even hit their level 0 watermarks (which means the whole configuration becomes impossible), or can artificially limit how high of a watermark level the smaller planes can achieve. These problems are most visible on APL (due to the platform's smaller DDB in general). A better algorithm is to calculate watermarks first, DDB second, and use the block counts from the watermark calculation to give planes exactly the allocation they need to hit the highest possible global watermark level. Mahesh took a stab at implementing this algorithm about 1.5 years ago, but there were some bugs that led to regressions and nobody had time to track them down. Our watermark code has evolved significantly since that time, but the problems with the original datarate-proportional algorithm remain. Matt Roper (3): drm/i915: Remove a very stale FIXME drm/i915: Don't use DDB allocation when choosing gen9 watermark method drm/i915: Switch to level-based DDB allocation algorithm drivers/gpu/drm/i915/intel_pm.c | 356 ++-- 1 file changed, 121 insertions(+), 235 deletions(-) -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/execlists: Move RCS mmio workaround to new common wa_list
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
v2: INSTPM_FORCE_ORDERING is already part of gen8_ctx_workarounds, and
as confirmed by the mmio verification is a part of the context image!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 42 +---
drivers/gpu/drm/i915/intel_workarounds.c | 11 +++
2 files changed, 12 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e6a86fa4502d..e8d52c1fe278 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1671,6 +1671,7 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
intel_engine_apply_workarounds(engine);
+ intel_engine_apply_whitelist(engine);
intel_mocs_init_engine(engine);
@@ -1687,43 +1688,6 @@ static int gen8_init_common_ring(struct intel_engine_cs
*engine)
return 0;
}
-static int gen8_init_render_ring(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- /* We need to disable the AsyncFlip performance optimisations in order
-* to use MI_WAIT_FOR_EVENT within the CS. It should already be
-* programmed to '1' on all products.
-*
-* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
-*/
- I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));
-
- I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
-
- return 0;
-}
-
-static int gen9_init_render_ring(struct intel_engine_cs *engine)
-{
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- return 0;
-}
-
static struct i915_request *
execlists_reset_prepare(struct intel_engine_cs *engine)
{
@@ -2279,10 +2243,6 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
engine->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
/* Override some for render ring. */
- if (INTEL_GEN(dev_priv) >= 9)
- engine->init_hw = gen9_init_render_ring;
- else
- engine->init_hw = gen8_init_render_ring;
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 6bcac78a9c36..de5b9555936b 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1231,6 +1231,17 @@ static void rcs_engine_wa_init(struct intel_engine_cs
*engine)
GEN8_L3SQCREG4,
GEN8_LQSC_FLUSH_COHERENT_LINES);
}
+
+ if (IS_GEN8(i915)) {
+ /*
+* We need to disable the AsyncFlip performance optimisations
+* in order to use MI_WAIT_FOR_EVENT within the CS. It should
+* already be programmed to '1' on all products.
+*
+* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
+*/
+ wa_masked_en(wal, MI_MODE, ASYNC_FLIP_PERF_DISABLE);
+ }
}
static void xcs_engine_wa_init(struct intel_engine_cs *engine)
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers retain their magic values across rpm suspend/resume.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/intel_workarounds.c| 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index 67017d5175b8..c2b3cd8fcc34 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -333,7 +333,6 @@ static bool verify_gt_engine_wa(struct drm_i915_private
*i915, const char *str)
bool ok = true;
ok &= intel_gt_verify_workarounds(i915, str);
-
for_each_engine(engine, i915, id)
ok &= intel_engine_verify_workarounds(engine, str);
@@ -353,19 +352,19 @@ live_gpu_reset_gt_engine_workarounds(void *arg)
pr_info("Verifying after GPU reset...\n");
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
ok = verify_gt_engine_wa(i915, "before reset");
if (!ok)
goto out;
- intel_runtime_pm_get(i915);
set_bit(I915_RESET_HANDOFF, &error->flags);
i915_reset(i915, ALL_ENGINES, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after reset");
out:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
return ok ? 0 : -ESRCH;
@@ -390,6 +389,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
return PTR_ERR(ctx);
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
for_each_engine(engine, i915, id) {
bool ok;
@@ -402,9 +402,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
goto err;
}
- intel_runtime_pm_get(i915);
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after idle reset");
if (!ok) {
@@ -416,13 +414,10 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (ret)
goto err;
- intel_runtime_pm_get(i915);
-
rq = igt_spinner_create_request(&spin, ctx, engine, MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
goto err;
}
@@ -431,15 +426,12 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (!igt_wait_for_spinner(&spin, rq)) {
pr_err("Spinner failed to start\n");
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
ret = -ETIMEDOUT;
goto err;
}
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
-
igt_spinner_end(&spin);
igt_spinner_fini(&spin);
@@ -451,6 +443,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
}
err:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
kernel_context_close(ctx);
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
Thanks for the patch and the review, pushed to dinq
Manasi`
On Thu, Nov 29, 2018 at 02:00:58PM -0800, Manasi Navare wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
>
> Read from DPCD once for all 3 values as this is an expensive operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
>
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh.
>
> This patch helps with backward compatibility for devices pre DP1.3.
>
> v2: read only dpcd values which can be affected, remove incorrect check,
> split into drm include changes into separate patch, commit message,
> verbose debugging statements during overwrite.
> v3: white space fixes
> v4: make path dependent on DPCD revision > 1.2
> v5: split into function, removed DPCD rev check
> v6: add debugging prints for early exit conditions
> v7 (From Manasi):
> * Memcpy, memcmp and debig logging based on sizeof(dpcd_ext) (Jani N)
> * Exit early (Jani N)
> v8 (From Manasi):
> * Get rid of superfluous debug prints (Jani N)
> * Print entire base DPCD before memcpy (Jani N)
> v9 (From Manasi):
> * Add uniform newlines (Rodrigo)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Signed-off-by: Matt Atwood
> Signed-off-by: Manasi Navare
> Tested-by: Manasi Navare
> Acked-by: Manasi Navare
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 38 +
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 38a6e82153fd..b7c4d38089b5 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3991,6 +3991,42 @@ intel_dp_link_down(struct intel_encoder *encoder,
> }
> }
>
> +static void
> +intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
> +{
> + u8 dpcd_ext[6];
> +
> + /*
> + * Prior to DP1.3 the bit represented by
> + * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> + * if it is set DP_DPCD_REV at h could be at a value less than
> + * the true capability of the panel. The only way to check is to
> + * then compare h and 2200h.
> + */
> + if (!(intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
> + return;
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DP13_DPCD_REV,
> + &dpcd_ext, sizeof(dpcd_ext)) != sizeof(dpcd_ext)) {
> + DRM_ERROR("DPCD failed read at extended capabilities\n");
> + return;
> + }
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
> + DRM_DEBUG_KMS("DPCD extended DPCD rev less than base DPCD
> rev\n");
> + return;
> + }
> +
> + if (!memcmp(intel_dp->dpcd, dpcd_ext, sizeof(dpcd_ext)))
> + return;
> +
> + DRM_DEBUG_KMS("Base DPCD: %*ph\n",
> + (int)sizeof(intel_dp->dpcd), intel_dp->dpcd);
> +
> + memcpy(intel_dp->dpcd, dpcd_ext, sizeof(dpcd_ext));
> +}
> +
> bool
> intel_dp_read_dpcd(struct intel_dp *intel_dp)
> {
> @@ -3998,6 +4034,8 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>sizeof(intel_dp->dpcd)) < 0)
> return false; /* aux transfer failed */
>
> + intel_dp_extended_receiver_capabilities(intel_dp);
> +
> DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> intel_dp->dpcd);
>
> return intel_dp->dpcd[DP_DPCD_REV] != 0;
> --
> 2.19.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Return immediately if trylock fails for direct-reclaim
On 04/12/2018 14:15, Chris Wilson wrote:
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The proviso being that we still keep trying to hard
obtain the lock for oom so that we can reap under heavy memory pressure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gem_shrinker.c | 24 +++-
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c5f01964f0fb..1cad218b71d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2916,9 +2916,9 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
__i915_gem_object_unpin_pages(obj);
}
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
+enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER
+ I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index ea90d3a0d511..d461f458f4af 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -36,7 +36,9 @@
#include "i915_drv.h"
#include "i915_trace.h"
-static bool shrinker_lock(struct drm_i915_private *i915, bool *unlock)
+static bool shrinker_lock(struct drm_i915_private *i915,
+ unsigned int flags,
+ bool *unlock)
{
switch (mutex_trylock_recursive(&i915->drm.struct_mutex)) {
case MUTEX_TRYLOCK_RECURSIVE:
@@ -45,15 +47,11 @@ static bool shrinker_lock(struct drm_i915_private *i915,
bool *unlock)
case MUTEX_TRYLOCK_FAILED:
*unlock = false;
- preempt_disable();
- do {
- cpu_relax();
- if (mutex_trylock(&i915->drm.struct_mutex)) {
- *unlock = true;
- break;
- }
- } while (!need_resched());
- preempt_enable();
+ if (flags & I915_SHRINK_ACTIVE) {
+ mutex_lock_nested(&i915->drm.struct_mutex,
+ I915_MM_SHRINKER);
+ *unlock = true;
+ }
I just realized once oddity in the shrinker code which escaped me
before. It is the fact the call paths will call the shrinker_lock twice.
For instance i915_gem_shrinker_vmap and i915_gem_shrinker_scan. They
both first take lock with flags of zero, and then they call
i915_gem_shrink which takes the lock again, which obviously always
results in the recursive path to be taken.
I think we need to clean this up so it is easier to understand the code
before further tweaking, even if in this patch. For instance adding
I915_SHRINK_LOCKED would solve it.
shrinker_lock_uninterruptible is also funky in that it doesn't respect
the timeout in the waiting for idle phase.
Sounds reasonable?
Regards,
Tvrtko
return *unlock;
case MUTEX_TRYLOCK_SUCCESS:
@@ -160,7 +158,7 @@ i915_gem_shrink(struct drm_i915_private *i915,
unsigned long scanned = 0;
bool unlock;
- if (!shrinker_lock(i915, &unlock))
+ if (!shrinker_lock(i915, flags, &unlock))
return 0;
/*
@@ -357,7 +355,7 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
sc->nr_scanned = 0;
- if (!shrinker_lock(i915, &unlock))
+ if (!shrinker_lock(i915, 0, &unlock))
return SHRINK_STOP;
freed = i915_gem_shrink(i915,
@@ -397,7 +395,7 @@ shrinker_lock_uninterruptible(struct drm_i915_private
*i915, bool *unlock,
do {
if (i915_gem_wait_for_idle(i915,
0, MAX_SCHEDULE_TIMEOUT) == 0 &&
- shrinker_lock(i915, unlock))
+ shrinker_lock(i915, 0, unlock))
break;
schedule_timeout_killable(1);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: verify_gt_engine_wa()
needs rpm wakeref
URL : https://patchwork.freedesktop.org/series/53666/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5275 -> Patchwork_11036
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11036 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11036, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53666/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11036:
### IGT changes ###
Possible regressions
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN
* igt@i915_selftest@live_workarounds:
- fi-bsw-n3050: PASS -> DMESG-FAIL
- fi-bsw-kefka: PASS -> DMESG-FAIL
- fi-bdw-5557u: PASS -> DMESG-FAIL
- fi-bdw-gvtdvm: PASS -> DMESG-FAIL
Known issues
Here are the changes found in Patchwork_11036 that come from known issues:
### IGT changes ###
Issues hit
* {igt@runner@aborted}:
- {fi-icl-u3}:NOTRUN -> FAIL [fdo#108315]
Warnings
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108315]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
Participating hosts (48 -> 43)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
Build changes
-
* Linux: CI_DRM_5275 -> Patchwork_11036
CI_DRM_5275: 95dba5a17f86524f31cdc13af7d3238351db9a9c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11036: 7b0ea48ff157b9f357769f113638718c09b5ae97 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7b0ea48ff157 drm/i915/execlists: Move RCS mmio workaround to new common wa_list
e56b100f62b3 drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11036/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Series Details == Series: series starting with [v2,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements URL : https://patchwork.freedesktop.org/series/53662/ State : success == Summary == CI Bug Log - changes from CI_DRM_5275 -> Patchwork_11035 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/53662/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_11035 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-read: - fi-glk-dsi: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (48 -> 44) -- Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u Build changes - * Linux: CI_DRM_5275 -> Patchwork_11035 CI_DRM_5275: 95dba5a17f86524f31cdc13af7d3238351db9a9c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11035: 7d47b33cf34569f5768f221174c90ff218af8d2b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7d47b33cf345 drm/i915/intel_dsi_vbt: Add support for PMIC mipi sequences fab666073ace ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC 8a78de6f985d ACPI / PMIC: Add support for executing PMIC MIPI sequence elements == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11035/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
On 06/12/2018 14:18, Chris Wilson wrote:
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers retain their magic values across rpm suspend/resume.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/intel_workarounds.c| 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index 67017d5175b8..c2b3cd8fcc34 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -333,7 +333,6 @@ static bool verify_gt_engine_wa(struct drm_i915_private
*i915, const char *str)
bool ok = true;
ok &= intel_gt_verify_workarounds(i915, str);
-
for_each_engine(engine, i915, id)
ok &= intel_engine_verify_workarounds(engine, str);
@@ -353,19 +352,19 @@ live_gpu_reset_gt_engine_workarounds(void *arg)
pr_info("Verifying after GPU reset...\n");
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
ok = verify_gt_engine_wa(i915, "before reset");
if (!ok)
goto out;
- intel_runtime_pm_get(i915);
set_bit(I915_RESET_HANDOFF, &error->flags);
i915_reset(i915, ALL_ENGINES, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after reset");
out:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
return ok ? 0 : -ESRCH;
@@ -390,6 +389,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
return PTR_ERR(ctx);
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
for_each_engine(engine, i915, id) {
bool ok;
@@ -402,9 +402,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
goto err;
}
- intel_runtime_pm_get(i915);
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after idle reset");
if (!ok) {
@@ -416,13 +414,10 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (ret)
goto err;
- intel_runtime_pm_get(i915);
-
rq = igt_spinner_create_request(&spin, ctx, engine, MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
goto err;
}
@@ -431,15 +426,12 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (!igt_wait_for_spinner(&spin, rq)) {
pr_err("Spinner failed to start\n");
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
ret = -ETIMEDOUT;
goto err;
}
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
-
igt_spinner_end(&spin);
igt_spinner_fini(&spin);
@@ -451,6 +443,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
}
err:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
kernel_context_close(ctx);
Hm yeah, for some reason I thought I915_READ would get it on it's own.
Oh well.. when in doubt use a bigger hammer.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 00/35] drm/i915: Implement HDCP2.2
On Tue, Nov 27, 2018 at 04:12:58PM +0530, Ramalingam C wrote: > This series enables the HDCP2.2 for I915. The sequence for HDCP2.2 > authentication and encryption is implemented as a generic flow > between HDMI and DP. Encoder specific implementations are moved > into hdcp_shim. > > Intel HWs supports HDCP2.2 through ME FW. Hence this series > introduces a client driver for mei bus, so that for HDCP2.2 > authentication, HDCP2.2 stack in I915 can avail the services from > ME FW. To enable this client driver set the config variable > CONFIG_INTEL_MEI_HDCP. > > Userspace interface remains unchanged as version agnostic. When > userspace request for HDCP enable, Kernel will detect the HDCP source > and sink's HDCP version(1.4/2.2)capability and enable the best capable > version for that combination. > > This series enables the HDCP2.2 for Type0 content strams. > > Major changes in v8: > - Mei_hdcp component binding status will impact HDCP2.2 alone. Oh now I see why component side looked so totally different than the old series. That's not how component works, and essentially we're back to rolling all the synchronization ourselves. If you have an optional component, you need to decide whether you want it at component_match_add time: Either add the component as a match, or not. All the other stuff needs to stay the same. That also explains why I didn't find the special audio component registration hack anymore. I think for the unload side we need to make the symmetrical hack, i.e. unregister the audio component from the pci unload function, not from component_master_unbind. To avoid the locking recursion. The proper fix for the recursion should be easy, we just need to add _locked version of component functions called for the audio component, which check that the component lock is already taken (like component_bind_all and friends already do to break the recursion in other places). -Daniel > - hdcp2_check_work is cancelled only when hdcp2 is supported. > - Errors due to sinks are reported as DEBUG logs. > - HDCP2.2 auth will be attempted only if the mei_hdcp interface is up. > - Maintainability ease MEI i/f changes are gathered in single patch. > - intel_hdcp_exit is defined and used. > > To ease the review process, series is hosted at > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v8 > > Ramalingam C (33): > drm/i915: debug log for REPLY_ACK missing > drm/i915: Increase timeout for Encrypt status change > linux/mei: Header for mei_hdcp driver interface > drm/i915: Initialize HDCP2.2 > drm/i915: MEI interface definition > drm/i915: Enable and Disable of HDCP2.2 > drm/i915: Implement HDCP2.2 receiver authentication > drm/i915: Implement HDCP2.2 repeater authentication > drm/i915: Implement HDCP2.2 link integrity check > drm/i915: Handle HDCP2.2 downstream topology change > drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ > drm/i915: Implement the HDCP2.2 support for DP > drm/i915: Implement the HDCP2.2 support for HDMI > drm/i915: Add HDCP2.2 support for DP connectors > drm/i915: Add HDCP2.2 support for HDMI connectors > misc/mei/hdcp: Client driver for HDCP application > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > misc/mei/hdcp: Verify Receiver Cert and prepare km > misc/mei/hdcp: Verify H_prime > misc/mei/hdcp: Store the HDCP Pairing info > misc/mei/hdcp: Initiate Locality check > misc/mei/hdcp: Verify L_prime > misc/mei/hdcp: Prepare Session Key > misc/mei/hdcp: Repeater topology verification and ack > misc/mei/hdcp: Verify M_prime > misc/mei/hdcp: Enabling the HDCP authentication > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > misc/mei/hdcp: Component framework for I915 Interface > drm/i915: Commit CP without modeset > drm/i915: Fix KBL HDCP2.2 encrypt status signalling > FOR_TEST: i915/Kconfig: Select mei_hdcp by I915 > FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4 > > Tomas Winkler (2): > mei: bus: whitelist hdcp client > mei: bus: export to_mei_cl_device for mei client device drivers > > MAINTAINERS |1 + > drivers/gpu/drm/i915/i915_debugfs.c | 10 +- > drivers/gpu/drm/i915/i915_drv.c |2 + > drivers/gpu/drm/i915/i915_drv.h |2 + > drivers/gpu/drm/i915/intel_ddi.c |7 - > drivers/gpu/drm/i915/intel_display.c | 21 +- > drivers/gpu/drm/i915/intel_dp.c | 349 - > drivers/gpu/drm/i915/intel_drv.h | 81 +- > drivers/gpu/drm/i915/intel_hdcp.c| 1390 > +++--- > drivers/gpu/drm/i915/intel_hdmi.c| 193 - > drivers/misc/mei/Kconfig |8 + > drivers/misc/mei/Makefile|2 + > drivers/misc/mei/bus-fixup.c | 16 + > drivers/misc/mei/bus.c |1 - > drivers/misc/mei/hdcp/Makefile |7 + > drivers/misc/mei/hdcp/mei_hdcp.c | 825 > dr
Re: [Intel-gfx] [PATCH v8 33/35] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
On Tue, Nov 27, 2018 at 04:13:31PM +0530, Ramalingam C wrote:
> Implement the required WA sequence for KBL to fix the
> incorrect positioning of the window of oppurtunity and enc_en
> signalling.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 9f4056e156ec..654a076c58e4 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
> @@ -24,6 +25,27 @@
> __p == PORT_A ? MEI_DDI_A : (enum mei_hdcp_ddi)__p;\
> })
>
> +static void kbl_repositioning_enc_en_signal(struct intel_connector
> *connector)
Is there a Bspec WA number/label so I can more easily find this?
-Daniel
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + struct drm_crtc *crtc = connector->base.state->crtc;
> + struct intel_crtc *intel_crtc = container_of(crtc,
> + struct intel_crtc, base);
> + u32 scanline;
> +
> + for (;;) {
> + scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
> + if (scanline > 100 && scanline < 200)
> + break;
> + usleep_range(25, 50);
> + }
> +
> + hdcp->shim->toggle_signalling(intel_dig_port, false);
> + hdcp->shim->toggle_signalling(intel_dig_port, true);
> +}
> +
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> {
> @@ -1527,6 +1549,13 @@ static int hdcp2_enable_encryption(struct
> intel_connector *connector)
> }
>
> if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
> + /*
> + * WA: To fix incorrect positioning of the window of
> + * opportunity and enc_en signalling in KABYLAKE.
> + */
> + if (IS_KABYLAKE(dev_priv) && hdcp->shim->toggle_signalling)
> + kbl_repositioning_enc_en_signal(connector);
> +
> /* Link is Authenticated. Now set for Encryption */
> I915_WRITE(HDCP2_CTL_DDI(port),
> I915_READ(HDCP2_CTL_DDI(port)) |
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 32/35] drm/i915: Commit CP without modeset
On Tue, Nov 27, 2018 at 04:13:30PM +0530, Ramalingam C wrote:
> Commits the content protection change of a connector,
> without crtc modeset. This improves the user experience.
>
> Originally proposed by Sean Paul at v3 of HDCP1.4 framework
> https://patchwork.freedesktop.org/patch/191759/. For some
> reason this was dropped, but needed for the proper functionality
> of HDCP encryption.
>
> Signed-off-by: Ramalingam C
> Suggested-by: Sean Paul
I think best to split this out from this series, since it's a separate
concern really.
Wrt implementation, this problem here is pretty similar to other sink
setup stuff like infoframes, where atm we also require a full modeset. The
idea that iirc Ville&me toyed around with is a kind of
per-encoder/connector fixup function, where all this stuff could be set if
we did _not_ do a full modeset. For a full modeset I think it's best to
still keep all this in connectors.
Plus for anything where we do this kind of fast-modeset trick we need to
lock down the state tracking using the state readout code. Otherwise this
is very hard to validate properly.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 7 ---
> drivers/gpu/drm/i915/intel_display.c | 10 ++
> drivers/gpu/drm/i915/intel_drv.h | 5 +
> drivers/gpu/drm/i915/intel_hdcp.c| 32
> 4 files changed, 43 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ad11540ac436..128cc558d75f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3469,11 +3469,6 @@ static void intel_enable_ddi(struct intel_encoder
> *encoder,
> intel_enable_ddi_hdmi(encoder, crtc_state, conn_state);
> else
> intel_enable_ddi_dp(encoder, crtc_state, conn_state);
> -
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> }
>
> static void intel_disable_ddi_dp(struct intel_encoder *encoder,
> @@ -3513,8 +3508,6 @@ static void intel_disable_ddi(struct intel_encoder
> *encoder,
> const struct intel_crtc_state *old_crtc_state,
> const struct drm_connector_state *old_conn_state)
> {
> - intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
> -
> if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
> intel_disable_ddi_hdmi(encoder, old_crtc_state, old_conn_state);
> else
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fc63babce165..98aaf536146f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12854,6 +12854,8 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
> + struct drm_connector_state *old_conn_state, *new_conn_state;
> + struct drm_connector *connector;
> struct drm_crtc *crtc;
> struct intel_crtc *intel_crtc;
> u64 put_domains[I915_MAX_PIPES] = {};
> @@ -12947,9 +12949,17 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
> }
> }
>
> + for_each_oldnew_connector_in_state(state, connector, old_conn_state,
> +new_conn_state, i)
> + intel_hdcp_atomic_pre_commit(connector, old_conn_state,
> + new_conn_state);
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.update_crtcs(state);
>
> + for_each_new_connector_in_state(state, connector, new_conn_state, i)
> + intel_hdcp_atomic_commit(connector, new_conn_state);
> +
> /* FIXME: We should call drm_atomic_helper_commit_hw_done() here
>* already, but still need the state for the delayed optimization. To
>* fix this:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 2b7181b76475..68eae1e569e4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -2084,6 +2084,11 @@ static inline void
> intel_backlight_device_unregister(struct intel_connector *con
> void intel_hdcp_atomic_check(struct drm_connector *connector,
>struct drm_connector_state *old_state,
>struct drm_connector_state *new_state);
> +void intel_hdcp_atomic_pre_commit(struct drm_connector *connector,
> + struct drm_connector_state *old_state,
> + struct drm_connector_state *new_sta
[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Move RCS mmio workaround to new common wa_list
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 42 +---
drivers/gpu/drm/i915/intel_workarounds.c | 14
2 files changed, 15 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e6a86fa4502d..e8d52c1fe278 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1671,6 +1671,7 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
intel_engine_apply_workarounds(engine);
+ intel_engine_apply_whitelist(engine);
intel_mocs_init_engine(engine);
@@ -1687,43 +1688,6 @@ static int gen8_init_common_ring(struct intel_engine_cs
*engine)
return 0;
}
-static int gen8_init_render_ring(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- /* We need to disable the AsyncFlip performance optimisations in order
-* to use MI_WAIT_FOR_EVENT within the CS. It should already be
-* programmed to '1' on all products.
-*
-* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
-*/
- I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));
-
- I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
-
- return 0;
-}
-
-static int gen9_init_render_ring(struct intel_engine_cs *engine)
-{
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- return 0;
-}
-
static struct i915_request *
execlists_reset_prepare(struct intel_engine_cs *engine)
{
@@ -2279,10 +2243,6 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
engine->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
/* Override some for render ring. */
- if (INTEL_GEN(dev_priv) >= 9)
- engine->init_hw = gen9_init_render_ring;
- else
- engine->init_hw = gen8_init_render_ring;
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index a4ab78bdcbbf..50229eb1eb08 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1229,6 +1229,20 @@ static void rcs_engine_wa_init(struct intel_engine_cs
*engine)
GEN8_L3SQCREG4,
GEN8_LQSC_FLUSH_COHERENT_LINES);
}
+
+ if (IS_GEN8(i915)) {
+ /*
+* We need to disable the AsyncFlip performance optimisations
+* in order to use MI_WAIT_FOR_EVENT within the CS. It should
+* already be programmed to '1' on all products.
+*
+* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
+*/
+ wa_masked_en(wal, MI_MODE, ASYNC_FLIP_PERF_DISABLE);
+
+ /* XXX Is not INSTPM per-context + non-priv for gen6+? */
+ wa_masked_en(wal, INSTPM, INSTPM_FORCE_ORDERING);
+ }
}
static void xcs_engine_wa_init(struct intel_engine_cs *engine)
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/selftests: verify_gt_engine_wa() needs rpm wakeref
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers retain their magic values across rpm suspend/resume.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/intel_workarounds.c| 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
index 67017d5175b8..c2b3cd8fcc34 100644
--- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
@@ -333,7 +333,6 @@ static bool verify_gt_engine_wa(struct drm_i915_private
*i915, const char *str)
bool ok = true;
ok &= intel_gt_verify_workarounds(i915, str);
-
for_each_engine(engine, i915, id)
ok &= intel_engine_verify_workarounds(engine, str);
@@ -353,19 +352,19 @@ live_gpu_reset_gt_engine_workarounds(void *arg)
pr_info("Verifying after GPU reset...\n");
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
ok = verify_gt_engine_wa(i915, "before reset");
if (!ok)
goto out;
- intel_runtime_pm_get(i915);
set_bit(I915_RESET_HANDOFF, &error->flags);
i915_reset(i915, ALL_ENGINES, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after reset");
out:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
return ok ? 0 : -ESRCH;
@@ -390,6 +389,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
return PTR_ERR(ctx);
igt_global_reset_lock(i915);
+ intel_runtime_pm_get(i915);
for_each_engine(engine, i915, id) {
bool ok;
@@ -402,9 +402,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
goto err;
}
- intel_runtime_pm_get(i915);
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
ok = verify_gt_engine_wa(i915, "after idle reset");
if (!ok) {
@@ -416,13 +414,10 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (ret)
goto err;
- intel_runtime_pm_get(i915);
-
rq = igt_spinner_create_request(&spin, ctx, engine, MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
goto err;
}
@@ -431,15 +426,12 @@ live_engine_reset_gt_engine_workarounds(void *arg)
if (!igt_wait_for_spinner(&spin, rq)) {
pr_err("Spinner failed to start\n");
igt_spinner_fini(&spin);
- intel_runtime_pm_put(i915);
ret = -ETIMEDOUT;
goto err;
}
i915_reset_engine(engine, "live_workarounds");
- intel_runtime_pm_put(i915);
-
igt_spinner_end(&spin);
igt_spinner_fini(&spin);
@@ -451,6 +443,7 @@ live_engine_reset_gt_engine_workarounds(void *arg)
}
err:
+ intel_runtime_pm_put(i915);
igt_global_reset_unlock(i915);
kernel_context_close(ctx);
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 13/35] drm/i915: Implement the HDCP2.2 support for HDMI
On Tue, Nov 27, 2018 at 04:13:11PM +0530, Ramalingam C wrote:
> Implements the HDMI adaptation specific HDCP2.2 operations.
>
> Basically these are DDC read and write for authenticating through
> HDCP2.2 messages.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> No more special handling of Gmbus burst read for AKE_SEND_CERT.
> Style fixed with few naming. [Uma]
> %s/PARING/PAIRING
> v5:
> msg_sz is initialized at definition.
> Lookup table is defined for HDMI HDCP2.2 msgs [Daniel].
> v6:
> Rebased.
> v7:
> Make a function as inline [Uma]
> %s/uintxx_t/uxx
> v8:
> Errors due to sinks are reported as DEBUG logs.
> Adjust to the new mei interface.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 190
> ++
> 1 file changed, 190 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e755a3370bca..912f50133645 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1117,6 +1118,190 @@ bool intel_hdmi_hdcp_check_link(struct
> intel_digital_port *intel_dig_port)
> return true;
> }
>
> +static struct hdcp2_hdmi_msg_data {
> + u8 msg_id;
> + u32 timeout;
> + u32 timeout2;
> + } hdcp2_msg_data[] = {
> + {HDCP_2_2_AKE_INIT, 0, 0},
> + {HDCP_2_2_AKE_SEND_CERT, HDCP_2_2_CERT_TIMEOUT_MS, 0},
> + {HDCP_2_2_AKE_NO_STORED_KM, 0, 0},
> + {HDCP_2_2_AKE_STORED_KM, 0, 0},
> + {HDCP_2_2_AKE_SEND_HPRIME, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
> + HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
> + {HDCP_2_2_AKE_SEND_PAIRING_INFO, HDCP_2_2_PAIRING_TIMEOUT_MS,
> + 0},
> + {HDCP_2_2_LC_INIT, 0, 0},
> + {HDCP_2_2_LC_SEND_LPRIME, HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS, 0},
> + {HDCP_2_2_SKE_SEND_EKS, 0, 0},
> + {HDCP_2_2_REP_SEND_RECVID_LIST,
> + HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
> + {HDCP_2_2_REP_SEND_ACK, 0, 0},
> + {HDCP_2_2_REP_STREAM_MANAGE, 0, 0},
> + {HDCP_2_2_REP_STREAM_READY, HDCP_2_2_STREAM_READY_TIMEOUT_MS,
> + 0},
> + };
> +
> +static
> +int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port
> *intel_dig_port,
> + uint8_t *rx_status)
> +{
> + return intel_hdmi_hdcp_read(intel_dig_port,
> + HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
> + rx_status,
> + HDCP_2_2_HDMI_RXSTATUS_LEN);
> +}
> +
> +static int get_hdcp2_msg_timeout(u8 msg_id, bool is_paired)
> +{
> + int i;
> +
> + for (i = 0; i < sizeof(hdcp2_msg_data); i++)
> + if (hdcp2_msg_data[i].msg_id == msg_id &&
> + (msg_id != HDCP_2_2_AKE_SEND_HPRIME || is_paired))
> + return hdcp2_msg_data[i].timeout;
> + else if (hdcp2_msg_data[i].msg_id == msg_id)
> + return hdcp2_msg_data[i].timeout2;
> +
> + return -EINVAL;
> +}
> +
> +static inline
> +int hdcp2_detect_msg_availability(struct intel_digital_port
> *intel_digital_port,
> + u8 msg_id, bool *msg_ready,
> + ssize_t *msg_sz)
> +{
> + u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
> + int ret;
> +
> + ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
> + if (ret < 0) {
> + DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
> + return ret;
> + }
> +
> + *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
> + rx_status[0]);
> +
> + if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
> + *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
> + *msg_sz);
> + else
> + *msg_ready = *msg_sz;
> +
> + return 0;
> +}
> +
> +static ssize_t
> +intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
> + u8 msg_id, bool paired)
> +{
> + bool msg_ready = false;
> + int timeout, ret;
> + ssize_t msg_sz = 0;
> +
> + timeout = get_hdcp2_msg_timeout(msg_id, paired);
> + if (timeout < 0)
> + return timeout;
> +
> + ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
> + msg_id, &msg_ready,
> + &msg_sz),
> + !ret && msg_ready && msg_sz, timeout * 1000,
> + 1000, 5 * 1000);
Yeah, doing this also for DP is imo much simpler.
lgtm.
-Daniel
> + if (ret)
> +
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Move RCS mmio workaround to new common wa_list
== Series Details ==
Series: drm/i915/execlists: Move RCS mmio workaround to new common wa_list
URL : https://patchwork.freedesktop.org/series/53656/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5275 -> Patchwork_11034
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11034 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11034, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53656/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11034:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_workarounds:
- fi-bsw-n3050: PASS -> DMESG-FAIL
- fi-bsw-kefka: PASS -> DMESG-FAIL
- fi-bdw-5557u: PASS -> DMESG-FAIL
- fi-bdw-gvtdvm: PASS -> DMESG-FAIL
* {igt@runner@aborted}:
- fi-bdw-gvtdvm: NOTRUN -> FAIL
- fi-bsw-n3050: NOTRUN -> FAIL
- fi-bsw-kefka: NOTRUN -> FAIL
- fi-bdw-5557u: NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_11034 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: PASS -> FAIL [fdo#108880]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
Participating hosts (48 -> 43)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-glk-j4005
Build changes
-
* Linux: CI_DRM_5275 -> Patchwork_11034
CI_DRM_5275: 95dba5a17f86524f31cdc13af7d3238351db9a9c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11034: 01e3692245d777c44640736d9f257d88cb2095d2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
01e3692245d7 drm/i915/execlists: Move RCS mmio workaround to new common wa_list
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11034/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 12/35] drm/i915: Implement the HDCP2.2 support for DP
On Tue, Nov 27, 2018 at 04:13:10PM +0530, Ramalingam C wrote:
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> v2:
> wait for cp_irq is merged with this patch. Rebased.
> v3:
> wait_queue is used for wait for cp_irq [Chris Wilson]
> v4:
> Style fixed.
> %s/PARING/PAIRING
> Few style fixes [Uma]
> v5:
> Lookup table for DP HDCP2.2 msg details [Daniel].
> Extra lines are removed.
> v6:
> Rebased.
> v7:
> Fixed some regression introduced at v5. [Ankit]
> Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
> Converted a function to inline [Uma]
> %s/uintxx_t/uxx
> v8:
> Error due to the sinks are reported as DEBUG logs.
> Adjust to the new mei interface.
>
> Signed-off-by: Ramalingam C
> Signed-off-by: Ankit K Nautiyal
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_dp.c | 338
> ++
> drivers/gpu/drm/i915/intel_drv.h | 7 +
> drivers/gpu/drm/i915/intel_hdcp.c | 6 +
> 3 files changed, 351 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ecc4706db7dc..1cc82e490999 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -5347,6 +5348,27 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> pps_unlock(intel_dp);
> }
>
> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> + int timeout)
> +{
> + long ret;
> +
> + /* Reinit */
> + atomic_set(&hdcp->cp_irq_recved, 0);
This here doesn't fix any race here, you might as well use
#define C true
here (Except of course it rechecks that).
> +
> +#define C (atomic_read(&hdcp->cp_irq_recved) > 0)
> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> +msecs_to_jiffies(timeout));
What you really need/want to do to check whether the wait succeeded is
call hdcp2_detect_msg_availability(). Might be better to open-code the
wait_event for clarity.
Also debug ouptut to complain when we timed out here would be good (since
you ignore the error later on)
> +
> + if (ret > 0) {
> + atomic_set(&hdcp->cp_irq_recved, 0);
> + return 0;
> + } else if (!ret) {
> + return -ETIMEDOUT;
> + }
> + return (int)ret;
> +}
> +
> static
> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> u8 *an)
> @@ -5570,6 +5592,316 @@ int intel_dp_hdcp_capable(struct intel_digital_port
> *intel_dig_port,
> return 0;
> }
>
> +static struct hdcp2_dp_msg_data {
> + u8 msg_id;
> + u32 offset;
> + bool msg_detectable;
> + u32 timeout;
> + u32 timeout2; /* Added for non_paired situation */
> + } hdcp2_msg_data[] = {
> + {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
> + {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
> + false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
> + {HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
> + false, 0, 0},
> + {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
> + false, 0, 0},
> + {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
> + true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
> + HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
> + {HDCP_2_2_AKE_SEND_PAIRING_INFO,
> + DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
> + HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
> + {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
> + {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
> + false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
> + {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
> + 0, 0},
> + {HDCP_2_2_REP_SEND_RECVID_LIST,
> + DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
> + HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
> + {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
> + 0, 0},
> + {HDCP_2_2_REP_STREAM_MANAGE,
> + DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
> + 0, 0},
> + {HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
> + false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
> + {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
> +
[Intel-gfx] [PATCH v2 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to have support for these PMIC specific MIPI
sequence elements somwhere. Since we already instantiate a special platform
device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
with PMIC specific implementations of the OpRegion, the handling of MIPI
sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
function, which is to be backed by a PMIC specific
exec_mipi_pmic_seq_element callback. This function will be called by the
i915 code to execture MIPI sequence PMIC elements.
Signed-off-by: Hans de Goede
---
drivers/acpi/pmic/intel_pmic.c | 25 +
drivers/acpi/pmic/intel_pmic.h | 1 +
include/linux/mfd/intel_soc_pmic.h | 2 ++
3 files changed, 28 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index ca18e0d23df9..0d96ca08bb79 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include "intel_pmic.h"
@@ -36,6 +37,8 @@ struct intel_pmic_opregion {
struct intel_pmic_regs_handler_ctx ctx;
};
+static struct intel_pmic_opregion *intel_pmic_opregion;
+
static int pmic_get_reg_bit(int address, struct pmic_table *table,
int count, int *reg, int *bit)
{
@@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device *dev,
acpi_handle handle,
}
opregion->data = d;
+ intel_pmic_opregion = opregion;
return 0;
out_remove_thermal_handler:
@@ -319,3 +323,24 @@ int intel_pmic_install_opregion_handler(struct device
*dev, acpi_handle handle,
return ret;
}
EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
+
+void intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data)
+{
+ struct intel_pmic_opregion_data *d;
+
+ if (!intel_pmic_opregion) {
+ pr_warn("%s: No PMIC registered\n", __func__);
+ return;
+ }
+
+ d = intel_pmic_opregion->data;
+ if (!d->exec_mipi_pmic_seq_element) {
+ pr_warn("%s: Not implemented\n", __func__);
+ return;
+ }
+
+ mutex_lock(&intel_pmic_opregion->lock);
+ d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap, data);
+ mutex_unlock(&intel_pmic_opregion->lock);
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 095afc96952e..5a7bb33d046a 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -15,6 +15,7 @@ struct intel_pmic_opregion_data {
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
+ void (*exec_mipi_pmic_seq_element)(struct regmap *r, const u8 *data);
struct pmic_table *power_table;
int power_table_count;
struct pmic_table *thermal_table;
diff --git a/include/linux/mfd/intel_soc_pmic.h
b/include/linux/mfd/intel_soc_pmic.h
index ed1dfba5e5f9..ce04ad7d4b6c 100644
--- a/include/linux/mfd/intel_soc_pmic.h
+++ b/include/linux/mfd/intel_soc_pmic.h
@@ -26,4 +26,6 @@ struct intel_soc_pmic {
struct device *dev;
};
+void intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data);
+
#endif /* __INTEL_SOC_PMIC_H__ */
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Interpret data passed to the PMIC MIPI elements according to the docs
instead of my own reverse engineered interpretation
---
drivers/acpi/pmic/intel_pmic_chtwc.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..049c0cf3b9ed 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "intel_pmic.h"
#define CHT_WC_V1P05A_CTRL 0x6e3b
@@ -231,6 +232,28 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
}
+static void intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ const u8 *data)
+{
+ u32 value, mask, reg_address, address;
+ u16 i2c_client_address;
+
+ /* byte 0 aka PMIC Flag is reserved */
+ i2c_client_address = get_unaligned_le16(data + 1);
+ reg_address = get_unaligned_le32(data + 3);
+ value = get_unaligned_le32(data + 7);
+ mask= get_unaligned_le32(data + 11);
+
+ if (i2c_client_address > 255 || reg_address > 255) {
+ pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+ __func__, i2c_client_address, reg_address);
+ return;
+ }
+
+ address = (i2c_client_address << 8) | reg_address;
+ regmap_update_bits(regmap, address, mask, value);
+}
+
/*
* The thermal table and ops are empty, we do not support the Thermal opregion
* (DPTF) due to lacking documentation.
@@ -238,6 +261,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
.get_power = intel_cht_wc_pmic_get_power,
.update_power = intel_cht_wc_pmic_update_power,
+ .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
.power_table= power_table,
.power_table_count = ARRAY_SIZE(power_table),
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC mipi sequences
Add support for PMIC mipi sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index f27af47c6e49..6a2ed1ca72e0 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -371,7 +372,11 @@ static const u8 *mipi_exec_spi(struct intel_dsi
*intel_dsi, const u8 *data)
static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
{
+#ifdef CONFIG_PMIC_OPREGION
+ intel_soc_pmic_exec_mipi_pmic_seq_element(data);
+#else
DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+#endif
return data + 15;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 11/35] drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ
On Tue, Nov 27, 2018 at 04:13:09PM +0530, Ramalingam C wrote:
> On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
> integrity check for the HDCP version that is enabled.
>
> v2:
> Rebased. Function name is changed.
> v3:
> No Changes.
> v4:
> No Changes.
> v5:
> No Changes.
> v6:
> %s/_in_force/_in_use [Sean Paul]
> v7:
> Rebased.
> v8:
> Rebased.
>
> Signed-off-by: Ramalingam C
> cc: Sean Paul
> Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_hdcp.c | 29 +
> 3 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ac62af073688..ecc4706db7dc 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4532,7 +4532,7 @@ static void intel_dp_check_service_irq(struct intel_dp
> *intel_dp)
> intel_dp_handle_test_request(intel_dp);
>
> if (val & DP_CP_IRQ)
> - intel_hdcp_check_link(intel_dp->attached_connector);
> + intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
>
> if (val & DP_SINK_SPECIFIC_IRQ)
> DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e6e32bf52568..d5ab1ff9cc69 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -2082,11 +2082,11 @@ int intel_hdcp_init(struct intel_connector *connector,
> bool hdcp2_supported);
> int intel_hdcp_enable(struct intel_connector *connector);
> int intel_hdcp_disable(struct intel_connector *connector);
> -int intel_hdcp_check_link(struct intel_connector *connector);
> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
> bool intel_hdcp_capable(struct intel_connector *connector);
> bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
> void intel_hdcp_exit(struct drm_i915_private *dev_priv);
> +void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
Renaming doesn't seem to gain us anything, pls drop.
>
> /* intel_psr.c */
> #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index df0fb6d9200b..b9e5f73c640d 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -117,6 +117,26 @@ static bool intel_hdcp2_capable(struct intel_connector
> *connector)
> return capable;
> }
>
> +static inline bool intel_hdcp_in_use(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + enum port port = connector->encoder->port;
> + u32 reg;
> +
> + reg = I915_READ(PORT_HDCP_STATUS(port));
> + return reg & (HDCP_STATUS_AUTH | HDCP_STATUS_ENC);
> +}
> +
> +static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + enum port port = connector->encoder->port;
> + u32 reg;
> +
> + reg = I915_READ(HDCP2_STATUS_DDI(port));
> + return reg & (LINK_ENCRYPTION_STATUS | LINK_AUTH_STATUS);
> +}
> +
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
> {
> @@ -2008,3 +2028,12 @@ void intel_hdcp_atomic_check(struct drm_connector
> *connector,
> new_state->crtc);
> crtc_state->mode_changed = true;
> }
> +
> +/* Handles the CP_IRQ raised from the DP HDCP sink */
> +void intel_hdcp_handle_cp_irq(struct intel_connector *connector)
> +{
> + if (intel_hdcp_in_use(connector))
Reading registers to figure out what we're doing is bad style. I think
reading register to double-check that our sw-side tracking is correct is
good, so maybe put these checks into hdcp1/2_check_link in a WARN_ON. But
here we should take the hdcp mutex and look at the sw state.
This will naturally fall out of the check_link worker merging in the
earlier patch I think.
-Daniel
> + intel_hdcp_check_link(connector);
> + else if (intel_hdcp2_in_use(connector))
> + intel_hdcp2_check_link(connector);
> +}
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 10/35] drm/i915: Handle HDCP2.2 downstream topology change
On Tue, Nov 27, 2018 at 04:13:08PM +0530, Ramalingam C wrote:
> When repeater notifies a downstream topology change, this patch
> reauthenticate the repeater alone without disabling the hdcp
> encryption. If that fails then complete reauthentication is executed.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> Typo in commit msg is fixed [Uma]
> v5:
> Rebased as part of patch reordering.
> Minor style fixes.
> v6:
> Rebased.
> v7:
> Rebased.
> v8:
> Errors due to sinks are reported as DEBUG logs.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Trusting Uma's hdcp knowledge here.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 98b112395a5a..df0fb6d9200b 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -1662,8 +1662,24 @@ static int intel_hdcp2_check_link(struct
> intel_connector *connector)
> goto out;
> }
>
> - DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
> - connector->base.name, connector->base.base.id);
> + if (ret == DRM_HDCP_TOPOLOGY_CHANGE) {
> + if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + goto out;
> +
> + DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
> + ret = hdcp2_authenticate_repeater_topology(connector);
> + if (!ret) {
> + hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
> + schedule_work(&hdcp->prop_work);
> + goto out;
> + }
> + DRM_DEBUG_KMS("[%s:%d] Repeater topology auth failed.(%d)\n",
> + connector->base.name, connector->base.base.id,
> + ret);
> + } else {
> + DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
> + connector->base.name, connector->base.base.id);
> + }
>
> ret = _intel_hdcp2_disable(connector);
> if (ret) {
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 09/35] drm/i915: Implement HDCP2.2 link integrity check
On Thu, Dec 06, 2018 at 02:27:21PM +0100, Daniel Vetter wrote:
> On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
> > Implements the link integrity check once in 500mSec.
> >
> > Once encryption is enabled, an ongoing Link Integrity Check is
> > performed by the HDCP Receiver to check that cipher synchronization
> > is maintained between the HDCP Transmitter and the HDCP Receiver.
> >
> > On the detection of synchronization lost, the HDCP Receiver must assert
> > the corresponding bits of the RxStatus register. The Transmitter polls
> > the RxStatus register and it may initiate re-authentication.
> >
> > v2:
> > Rebased.
> > v3:
> > No Changes.
> > v4:
> > enum check_link_response is used check the link status [Uma]
> > v5:
> > Rebased as part of patch reordering.
> > v6:
> > Required members of intel_hdcp is defined [Sean Paul]
> > v7:
> > hdcp2_check_link is cancelled at required places.
> > v8:
> > Rebased for the component i/f changes.
> > Errors due to the sinks are reported as DEBUG logs.
> >
> > Signed-off-by: Ramalingam C
> > Reviewed-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 11 +++--
> > drivers/gpu/drm/i915/intel_drv.h | 5 +++
> > drivers/gpu/drm/i915/intel_hdcp.c| 83
> > +++-
> > include/drm/drm_hdcp.h | 8
> > 4 files changed, 103 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index e9f4e22b2a4e..fc63babce165 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15833,15 +15833,20 @@ static void intel_hpd_poll_fini(struct drm_device
> > *dev)
> > {
> > struct intel_connector *connector;
> > struct drm_connector_list_iter conn_iter;
> > + struct intel_hdcp *hdcp;
> >
> > /* Kill all the work that may have been queued by hpd. */
> > drm_connector_list_iter_begin(dev, &conn_iter);
> > for_each_intel_connector_iter(connector, &conn_iter) {
> > + hdcp = &connector->hdcp;
> > +
> > if (connector->modeset_retry_work.func)
> > cancel_work_sync(&connector->modeset_retry_work);
> > - if (connector->hdcp.shim) {
> > - cancel_delayed_work_sync(&connector->hdcp.check_work);
> > - cancel_work_sync(&connector->hdcp.prop_work);
> > + if (hdcp->shim) {
> > + cancel_delayed_work_sync(&hdcp->check_work);
> > + cancel_work_sync(&hdcp->prop_work);
> > + if (hdcp->hdcp2_supported)
> > +
> > cancel_delayed_work_sync(&hdcp->hdcp2_check_work);
>
> Locking of these workers is always tricky ... why can't we use the same
> worker for both checking hdcp2 and hdcp1 link status?
>
> Of course need to use the right timeout and call the right functions, but
> I think gives us less duplication in the complicated code.
Locking and also the logic to update the content protection property. I
think sharing the entire main function, and splitting to hdcp1 vs. hdcp2
in the check/enable/disable functions would be neat.
-Daniel
>
>
> > }
> > }
> > drm_connector_list_iter_end(&conn_iter);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 24d258488efe..e6e32bf52568 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -403,6 +403,9 @@ struct intel_hdcp_shim {
> > */
> > int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
> > void *buf, size_t size);
> > +
> > + /* HDCP2.2 Link Integrity Check */
> > + int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
> > };
> >
> > struct intel_hdcp {
> > @@ -445,6 +448,8 @@ struct intel_hdcp {
> > * over re-Auth has to be triggered.
> > */
> > u32 seq_num_m;
> > +
> > + struct delayed_work hdcp2_check_work;
> > };
> >
> > struct intel_connector {
> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > b/drivers/gpu/drm/i915/intel_hdcp.c
> > index 679f3c164582..98b112395a5a 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -1626,6 +1626,81 @@ static int _intel_hdcp2_disable(struct
> > intel_connector *connector)
> > return ret;
> > }
> >
> > +/* Implements the Link Integrity Check for HDCP2.2 */
> > +static int intel_hdcp2_check_link(struct intel_connector *connector)
> > +{
> > + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > + enum port port = connector->encoder->port;
> > +
> > + int ret = 0;
> > +
> > + if (!hdcp->shim)
> > + return -ENOENT;
>
> Why is this possible? Should we wrap it
Re: [Intel-gfx] [PATCH v8 09/35] drm/i915: Implement HDCP2.2 link integrity check
On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
> Implements the link integrity check once in 500mSec.
>
> Once encryption is enabled, an ongoing Link Integrity Check is
> performed by the HDCP Receiver to check that cipher synchronization
> is maintained between the HDCP Transmitter and the HDCP Receiver.
>
> On the detection of synchronization lost, the HDCP Receiver must assert
> the corresponding bits of the RxStatus register. The Transmitter polls
> the RxStatus register and it may initiate re-authentication.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> enum check_link_response is used check the link status [Uma]
> v5:
> Rebased as part of patch reordering.
> v6:
> Required members of intel_hdcp is defined [Sean Paul]
> v7:
> hdcp2_check_link is cancelled at required places.
> v8:
> Rebased for the component i/f changes.
> Errors due to the sinks are reported as DEBUG logs.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_drv.h | 5 +++
> drivers/gpu/drm/i915/intel_hdcp.c| 83
> +++-
> include/drm/drm_hdcp.h | 8
> 4 files changed, 103 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e9f4e22b2a4e..fc63babce165 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15833,15 +15833,20 @@ static void intel_hpd_poll_fini(struct drm_device
> *dev)
> {
> struct intel_connector *connector;
> struct drm_connector_list_iter conn_iter;
> + struct intel_hdcp *hdcp;
>
> /* Kill all the work that may have been queued by hpd. */
> drm_connector_list_iter_begin(dev, &conn_iter);
> for_each_intel_connector_iter(connector, &conn_iter) {
> + hdcp = &connector->hdcp;
> +
> if (connector->modeset_retry_work.func)
> cancel_work_sync(&connector->modeset_retry_work);
> - if (connector->hdcp.shim) {
> - cancel_delayed_work_sync(&connector->hdcp.check_work);
> - cancel_work_sync(&connector->hdcp.prop_work);
> + if (hdcp->shim) {
> + cancel_delayed_work_sync(&hdcp->check_work);
> + cancel_work_sync(&hdcp->prop_work);
> + if (hdcp->hdcp2_supported)
> +
> cancel_delayed_work_sync(&hdcp->hdcp2_check_work);
Locking of these workers is always tricky ... why can't we use the same
worker for both checking hdcp2 and hdcp1 link status?
Of course need to use the right timeout and call the right functions, but
I think gives us less duplication in the complicated code.
> }
> }
> drm_connector_list_iter_end(&conn_iter);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 24d258488efe..e6e32bf52568 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -403,6 +403,9 @@ struct intel_hdcp_shim {
>*/
> int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
> void *buf, size_t size);
> +
> + /* HDCP2.2 Link Integrity Check */
> + int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
> };
>
> struct intel_hdcp {
> @@ -445,6 +448,8 @@ struct intel_hdcp {
>* over re-Auth has to be triggered.
>*/
> u32 seq_num_m;
> +
> + struct delayed_work hdcp2_check_work;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 679f3c164582..98b112395a5a 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -1626,6 +1626,81 @@ static int _intel_hdcp2_disable(struct intel_connector
> *connector)
> return ret;
> }
>
> +/* Implements the Link Integrity Check for HDCP2.2 */
> +static int intel_hdcp2_check_link(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + enum port port = connector->encoder->port;
> +
> + int ret = 0;
> +
> + if (!hdcp->shim)
> + return -ENOENT;
Why is this possible? Should we wrap it into at least a WARN_ON?
> +
> + mutex_lock(&hdcp->mutex);
> +
> + if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + goto out;
> +
> + if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)) {
> + DRM_ERROR("HDCP2.2 check failed: link is not encrypted, %x\n",
> + I915_READ(HDCP2_STATUS_DDI(port)));
> + ret = -ENXIO;
> + hdcp->value = DRM
Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Apply a full mb before execution for Braswell
On 06/12/2018 08:44, Chris Wilson wrote:
Braswell is really picky about having our writes posted to memory before
we execute or else the GPU may see stale values. A wmb() is insufficient
as it only ensures the writes are visible to other cores, we need a full
mb() to ensure the writes are in memory and visible to the GPU.
The most frequent failure in flushing before execution is that we see
stale PTE values and execute the wrong pages.
References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into
context image vs execution")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index de1e9dc6aec0..e6a86fa4502d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -379,8 +379,13 @@ static u64 execlists_update_context(struct i915_request
*rq)
* may not be visible to the HW prior to the completion of the UC
* register write and that we may begin execution from the context
* before its image is complete leading to invalid PD chasing.
+*
+* Furthermore, Braswell, at least, wants a full mb to be sure that
+* the writes are coherent in memory (visible to the GPU) prior to
+* execution, and not just visible to other CPUs (as is the result of
+* wmb).
*/
- wmb();
+ mb();
return ce->lrc_desc;
}
Too low level for me to really know what happens under the hood, but at
least I know it can't break anything.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Pipeline PDP updates for Braswell
On 06/12/2018 08:44, Chris Wilson wrote:
Currently we face a severe problem on Braswell that manifests as invalid
ppGTT accesses. The code tries to maintain the PDP (page directory
pointers) inside the context in two ways, direct write into the context
and a pipelined LRI update. The direct write into the context is
fundamentally racy as it is unserialised with any access (read or write)
the GPU is doing. By asserting that Braswell is not used with vGPU
(currently an unsupported platform) we can eliminate the dangerous
direct write into the context image and solely use the pipelined update.
However, the LRI of the PDP fouls up the GPU, causing it to freeze and
take out the machine with "forcewake ack timeouts". This seems possible
to workaround by preventing the GPU from sleeping (via means of
disabling the power-state management interface, i.e. forcing each ring
to remain awake) around the update.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
References: https://bugs.freedesktop.org/show_bug.cgi?id=108714
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 -
drivers/gpu/drm/i915/i915_request.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c| 143
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +-
4 files changed, 74 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index add1fe7aeb93..62bde517d383 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1423,8 +1423,6 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space
*vm,
gen8_initialize_pd(vm, pd);
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
GEM_BUG_ON(pdp->used_pdpes > i915_pdpes_per_pdp(vm));
-
- mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
}
ret = gen8_ppgtt_alloc_pd(vm, pd, start, length);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ca95ab2f4cfa..8ab8e8e6a086 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -719,11 +719,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
- /* Unconditionally invalidate GPU caches and TLBs. */
- ret = engine->emit_flush(rq, EMIT_INVALIDATE);
- if (ret)
- goto err_unwind;
-
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d7fa301b5ec7..de1e9dc6aec0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -363,31 +363,12 @@ execlists_context_schedule_out(struct i915_request *rq,
unsigned long status)
trace_i915_request_out(rq);
}
-static void
-execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
-{
- ASSIGN_CTX_PDP(ppgtt, reg_state, 3);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 2);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 1);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 0);
-}
-
static u64 execlists_update_context(struct i915_request *rq)
{
- struct i915_hw_ppgtt *ppgtt = rq->gem_context->ppgtt;
struct intel_context *ce = rq->hw_context;
- u32 *reg_state = ce->lrc_reg_state;
-
- reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring, rq->tail);
- /*
-* True 32b PPGTT with dynamic page allocation: update PDP
-* registers and point the unallocated PDPs to scratch page.
-* PML4 is allocated during ppgtt init, so this is not needed
-* in 48-bit mode.
-*/
- if (!i915_vm_is_48bit(&ppgtt->vm))
- execlists_update_context_pdps(ppgtt, reg_state);
+ ce->lrc_reg_state[CTX_RING_TAIL + 1] =
+ intel_ring_set_tail(rq->ring, rq->tail);
/*
* Make sure the context image is complete before we submit it to HW.
@@ -1242,29 +1223,86 @@ execlists_context_pin(struct intel_engine_cs *engine,
return __execlists_context_pin(engine, ctx, ce);
}
+static int emit_pdps(struct i915_request *rq)
+{
+ const struct intel_engine_cs * const engine = rq->engine;
+ struct i915_hw_ppgtt * const ppgtt = rq->gem_context->ppgtt;
+ int err, i;
+ u32 *cs;
+
+ /*
+* Beware ye of the dragons, this sequence is magic!
+*
+* Small changes to this sequence can cause anything from
+* GPU hangs to forcewake errors and machine lockups!
+*/
+
+ err = engine->emit_flush(rq, EMIT_FLUSH);
+ if (err)
+ return err;
+
+ err = engine->emit_flush(rq, EMIT_INVALIDATE);
+ if (err)
+ return err;
+
+ cs = intel_ring_begin(rq, 4 * GEN8_3LVL_PDPES + 2);
+ if (IS_ERR(cs))
+ re
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move RCS mmio workaround to new common wa_list
On 06/12/2018 12:56, Chris Wilson wrote:
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 42 +---
drivers/gpu/drm/i915/intel_workarounds.c | 14
2 files changed, 15 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0b64bc38f66f..31f378cf5525 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1671,6 +1671,7 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
intel_engine_apply_workarounds(engine);
+ intel_engine_apply_whitelist(engine);
intel_mocs_init_engine(engine);
@@ -1687,43 +1688,6 @@ static int gen8_init_common_ring(struct intel_engine_cs *engine)
return 0;
}
-static int gen8_init_render_ring(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- /* We need to disable the AsyncFlip performance optimisations in order
-* to use MI_WAIT_FOR_EVENT within the CS. It should already be
-* programmed to '1' on all products.
-*
-* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
-*/
- I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));
-
- I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
-
- return 0;
-}
-
-static int gen9_init_render_ring(struct intel_engine_cs *engine)
-{
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- return 0;
-}
-
static struct i915_request *
execlists_reset_prepare(struct intel_engine_cs *engine)
{
@@ -2286,10 +2250,6 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
engine->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
/* Override some for render ring. */
- if (INTEL_GEN(dev_priv) >= 9)
- engine->init_hw = gen9_init_render_ring;
- else
- engine->init_hw = gen8_init_render_ring;
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index a4ab78bdcbbf..50229eb1eb08 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1229,6 +1229,20 @@ static void rcs_engine_wa_init(struct intel_engine_cs
*engine)
GEN8_L3SQCREG4,
GEN8_LQSC_FLUSH_COHERENT_LINES);
}
+
+ if (IS_GEN8(i915)) {
+ /*
+* We need to disable the AsyncFlip performance optimisations
+* in order to use MI_WAIT_FOR_EVENT within the CS. It should
+* already be programmed to '1' on all products.
+*
+* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
+*/
+ wa_masked_en(wal, MI_MODE, ASYNC_FLIP_PERF_DISABLE);
+
+ /* XXX Is not INSTPM per-context + non-priv for gen6+? */
+ wa_masked_en(wal, INSTPM, INSTPM_FORCE_ORDERING);
+ }
}
static void xcs_engine_wa_init(struct intel_engine_cs *engine)
Simples!
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Skip the ERR_PTR error state
On 06/12/2018 08:44, Chris Wilson wrote:
Although commit fb6f0b64e455 ("drm/i915: Prevent machine hang from
Broxton's vtd w/a and error capture") applied cleanly after a 24 month
hiatus, the code had moved on with new methods for peeking and fetching
the captured gpu info. Make sure we catch all uses of the stashed error
state and avoid dereferencing the error pointer.
Fixes: fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and
error capture")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 12 +---
drivers/gpu/drm/i915/i915_sysfs.c | 3 +++
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 38dcee1ca062..f8aa8586c9a6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -984,6 +984,9 @@ static int i915_gpu_info_open(struct inode *inode, struct
file *file)
intel_runtime_pm_get(i915);
gpu = i915_capture_gpu_state(i915);
intel_runtime_pm_put(i915);
+
+ if (IS_ERR(gpu))
+ return PTR_ERR(gpu);
if (!gpu)
return -ENOMEM;
@@ -1018,7 +1021,13 @@ i915_error_state_write(struct file *filp,
static int i915_error_state_open(struct inode *inode, struct file *file)
{
- file->private_data = i915_first_error_state(inode->i_private);
+ struct i915_gpu_state *error;
+
+ error = i915_first_error_state(inode->i_private);
+ if (IS_ERR(error))
+ return PTR_ERR(error);
+
+ file->private_data = error;
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
index 07465123c166..7ca6f3f31d41 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1907,6 +1907,11 @@ i915_capture_gpu_state(struct drm_i915_private *i915)
{
struct i915_gpu_state *error;
+ /* Check if GPU capture has been disabled */
+ error = READ_ONCE(i915->gpu_error.first_error);
+ if (IS_ERR(error))
+ return error;
+
error = kzalloc(sizeof(*error), GFP_ATOMIC);
if (!error)
return NULL;
Looks like it would be cleaner to return ERR_PTR(-ENOMEM) here. At least
the i915_gpu_info_open hunk would be.
Then in drm-tip I see i915_capture_error_state as a caller which needs
to handle ERR_PTR now as well, no?
@@ -1987,7 +1992,7 @@ i915_first_error_state(struct drm_i915_private *i915)
spin_lock_irq(&i915->gpu_error.lock);
error = i915->gpu_error.first_error;
- if (error)
+ if (!IS_ERR_OR_NULL(error))
i915_gpu_state_get(error);
spin_unlock_irq(&i915->gpu_error.lock);
@@ -2000,10 +2005,11 @@ void i915_reset_error_state(struct drm_i915_private *i915)
spin_lock_irq(&i915->gpu_error.lock);
error = i915->gpu_error.first_error;
- i915->gpu_error.first_error = NULL;
+ if (!IS_ERR_OR_NULL(error)) /* once disabled, always disabled */
Hm, this will apply on transient -ENOMEM as well.
+ i915->gpu_error.first_error = NULL;
spin_unlock_irq(&i915->gpu_error.lock);
- if (!IS_ERR(error))
+ if (!IS_ERR_OR_NULL(error))
i915_gpu_state_put(error);
}
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c b/drivers/gpu/drm/i915/i915_sysfs.c
index 535caebd9813..370b7497e9df 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -521,6 +521,9 @@ static ssize_t error_state_read(struct file *filp, struct
kobject *kobj,
ssize_t ret;
gpu = i915_first_error_state(i915);
+ if (IS_ERR(gpu))
+ return PTR_ERR(gpu);
+
if (gpu) {
ret = i915_gpu_state_copy_to_buffer(gpu, buf, off, count);
i915_gpu_state_put(gpu);#
A single control block:
if (!IS_ERR_OR_NULL) {
...
} else {
...
}
seems like it would do the trick.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Move RCS mmio workaround to new common wa_list
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 42 +---
drivers/gpu/drm/i915/intel_workarounds.c | 14
2 files changed, 15 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0b64bc38f66f..31f378cf5525 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1671,6 +1671,7 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
intel_engine_apply_workarounds(engine);
+ intel_engine_apply_whitelist(engine);
intel_mocs_init_engine(engine);
@@ -1687,43 +1688,6 @@ static int gen8_init_common_ring(struct intel_engine_cs
*engine)
return 0;
}
-static int gen8_init_render_ring(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- /* We need to disable the AsyncFlip performance optimisations in order
-* to use MI_WAIT_FOR_EVENT within the CS. It should already be
-* programmed to '1' on all products.
-*
-* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
-*/
- I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));
-
- I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
-
- return 0;
-}
-
-static int gen9_init_render_ring(struct intel_engine_cs *engine)
-{
- int ret;
-
- ret = gen8_init_common_ring(engine);
- if (ret)
- return ret;
-
- intel_engine_apply_whitelist(engine);
-
- return 0;
-}
-
static struct i915_request *
execlists_reset_prepare(struct intel_engine_cs *engine)
{
@@ -2286,10 +2250,6 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
engine->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
/* Override some for render ring. */
- if (INTEL_GEN(dev_priv) >= 9)
- engine->init_hw = gen9_init_render_ring;
- else
- engine->init_hw = gen8_init_render_ring;
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index a4ab78bdcbbf..50229eb1eb08 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1229,6 +1229,20 @@ static void rcs_engine_wa_init(struct intel_engine_cs
*engine)
GEN8_L3SQCREG4,
GEN8_LQSC_FLUSH_COHERENT_LINES);
}
+
+ if (IS_GEN8(i915)) {
+ /*
+* We need to disable the AsyncFlip performance optimisations
+* in order to use MI_WAIT_FOR_EVENT within the CS. It should
+* already be programmed to '1' on all products.
+*
+* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
+*/
+ wa_masked_en(wal, MI_MODE, ASYNC_FLIP_PERF_DISABLE);
+
+ /* XXX Is not INSTPM per-context + non-priv for gen6+? */
+ wa_masked_en(wal, INSTPM, INSTPM_FORCE_ORDERING);
+ }
}
static void xcs_engine_wa_init(struct intel_engine_cs *engine)
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear bogus DMC BIOS/debug power well requests
On Thu, Dec 06, 2018 at 02:23:00PM +0200, Imre Deak wrote:
> On Wed, Dec 05, 2018 at 10:20:23PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The DMC firmware is confused and forces on the BIOS and debug
> > power well requests for PW1 and MISC IO on some platforms. On
> > BXT I measured this to waste about 10mW in the freeze system
> > suspend state with the SoC in s0. I didn't get conclusive
> > numbers for s0ix on account of the power consumption being
> > much more noisy than in s0.
> >
> > This is pretty much undoing part of commit 42d9366d41a9
> > ("drm/i915/gen9+: Don't remove secondary power well requests")
> > where we stopped sanitizing the DMCs bogus request bits.
> >
> > Cc: Imre Deak
> > Cc: Rodrigo Vivi
> > Signed-off-by: Ville Syrjälä
>
> Thanks for the effort for clarifying this.
>
> The justification in 42d9366d41a9 for not removing the PW#1 and MISC_IO driver
> request bits is not too solid, I admit. Bspec 4230 has this to say about them
> (for SKL, but same in practice for the rest):
>
> """
> 4. Disable Power Well 1 (PG1) and Misc IO Power
>
> Clear PWR_WELL_CTL Power Well 1 Request to 0b. Do not clear Misc IO Power
> Request.
> Wait for 10us. Do not poll for the power well to disable. Other clients
> may be keeping it enabled.
> """
>
> With MISC_IO we would clearly do the opposite in this patch wrt. the spec.
Actually we don't disable MISC_IO during SKL display core uninit, so
we'd still follow the spec regarding this.
>
> With PW#1 it's unclear if the spec means only the driver's request bit or all
> of them, but "other clients may be keeping it enabled" suggests to me it means
> only the driver's request bit. OTOH removing only the driver's request bit
> alone doesn't make sense due to DMC forcing on the BIOS (and debug) request
> bits anyway.
>
> I opened a BSpec update request to clarify this, I suggest waiting for an
> update there before going ahead with this change.
>
> > ---
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 35 +++--
> > 1 file changed, 33 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 4350a5270423..6e349181dd1c 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -336,10 +336,17 @@ static void hsw_wait_for_power_well_disable(struct
> > drm_i915_private *dev_priv,
> > * Bspec doesn't require waiting for PWs to get disabled, but still do
> > * this for paranoia. The known cases where a PW will be forced on:
> > * - a KVMR request on any power well via the KVMR request register
> > -* - a DMC request on PW1 and MISC_IO power wells via the BIOS and
> > -* DEBUG request registers
> > +* - a debug request on any power well via the DEBUG request register
> > * Skip the wait in case any of the request bits are set and print a
> > * diagnostic message.
> > +*
> > +* Note that DMC firmware will also force on the PW1 BIOS request
> > +* on SKL-CNL, MISC_IO BIOS request on SKL-GLK (although MISC_IO
> > +* does not even exits on BXT/GLK so the bit doesn't stick),
> > +* and the PW1/MISC_IO debug request on BXT. We simply clear
> > +* those spurious requests in hsw_power_well_disable() to make
> > +* sure they don't waste power. Starting from ICL the DMC firmware
> > +* has been fixed to only force on the PW1 driver request bit.
> > */
> > wait_for((disabled = !(I915_READ(regs->driver) &
> >HSW_PWR_WELL_CTL_STATE(pw_idx))) ||
> > @@ -347,6 +354,11 @@ static void hsw_wait_for_power_well_disable(struct
> > drm_i915_private *dev_priv,
> > if (disabled)
> > return;
> >
> > + WARN(reqs & 3,
> > +"%s left on (bios:%d driver:%d kvmr:%d debug:%d)\n",
> > +power_well->desc->name,
> > +!!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
> > +
> > DRM_DEBUG_KMS("%s forced on (bios:%d driver:%d kvmr:%d debug:%d)\n",
> > power_well->desc->name,
> > !!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
> > @@ -409,6 +421,7 @@ static void hsw_power_well_disable(struct
> > drm_i915_private *dev_priv,
> >struct i915_power_well *power_well)
> > {
> > const struct i915_power_well_regs *regs = power_well->desc->hsw.regs;
> > + enum i915_power_well_id id = power_well->desc->id;
> > int pw_idx = power_well->desc->hsw.idx;
> > u32 val;
> >
> > @@ -417,6 +430,24 @@ static void hsw_power_well_disable(struct
> > drm_i915_private *dev_priv,
> >
> > val = I915_READ(regs->driver);
> > I915_WRITE(regs->driver, val & ~HSW_PWR_WELL_CTL_REQ(pw_idx));
> > + /*
> > +* On SKL-CNL DMC firmware forces on the BIOS request.
> > +* This wastes a bit of power so clear it.
> > +*/
> > + if (INTEL_GEN(dev_priv) < 11 &&
> > +
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: replace IS_GEN with IS_GEN(..., N)
On 06/12/2018 06:11, Lucas De Marchi wrote:
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
Since you are calling it out here, I assume there is some good reason to
replace gen_mask with gen?
Regards,
Tvrtko
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/vgpu.c| 4 +-
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c| 16 ++---
drivers/gpu/drm/i915/i915_drv.c| 18 +++---
drivers/gpu/drm/i915/i915_drv.h| 29 +++--
drivers/gpu/drm/i915/i915_gem.c| 14 ++--
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 10 +--
drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +-
drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +-
drivers/gpu/drm/i915/i915_gem_tiling.c | 4 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 18 +++---
drivers/gpu/drm/i915/i915_irq.c| 24 +++
drivers/gpu/drm/i915/i915_perf.c | 4 +-
drivers/gpu/drm/i915/i915_suspend.c| 12 ++--
drivers/gpu/drm/i915/intel_atomic.c| 2 +-
drivers/gpu/drm/i915/intel_audio.c | 2 +-
drivers/gpu/drm/i915/intel_cdclk.c | 10 +--
drivers/gpu/drm/i915/intel_crt.c | 6 +-
drivers/gpu/drm/i915/intel_device_info.c | 16 ++---
drivers/gpu/drm/i915/intel_display.c | 74 +++---
drivers/gpu/drm/i915/intel_dp.c| 24 +++
drivers/gpu/drm/i915/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/intel_fbc.c | 22 +++
drivers/gpu/drm/i915/intel_fifo_underrun.c | 6 +-
drivers/gpu/drm/i915/intel_guc_fw.c| 2 +-
drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/intel_lvds.c | 4 +-
drivers/gpu/drm/i915/intel_mocs.c | 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 10 +--
drivers/gpu/drm/i915/intel_panel.c | 8 +--
drivers/gpu/drm/i915/intel_pipe_crc.c | 8 +--
drivers/gpu/drm/i915/intel_pm.c| 60 +-
drivers/gpu/drm/i915/intel_psr.c | 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c| 28
drivers/gpu/drm/i915/intel_ringbuffer.h| 4 +-
drivers/gpu/drm/i915/intel_runtime_pm.c| 4 +-
drivers/gpu/drm/i915/intel_sprite.c| 6 +-
drivers/gpu/drm/i915/intel_uc.c| 2 +-
drivers/gpu/drm/i915/intel_uncore.c| 18 +++---
drivers/gpu/drm/i915/intel_wopcm.c | 4 +-
drivers/gpu/drm/i915/intel_workarounds.c | 4 +-
44 files changed, 251 insertions(+), 263 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index c628be05fbfe..e1c860f80eb0 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -148,10 +148,10 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
gvt->types[i].avail_instance = min(low_avail /
vgpu_types[i].low_mm,
high_avail /
vgpu_types[i].high_mm);
- if (IS_GEN8(gvt->dev_priv))
+ if (IS_GEN(gvt->dev_priv, 8))
sprintf(gvt->types[i].name, "GVTg_V4_%s",
vgpu_types[i].name);
- else if (IS_GEN9(gvt->dev_priv))
+ else if (IS_GEN(gvt->dev_priv, 9))
sprintf(gvt->types[i].name, "GVTg_V5_%s",
vgpu_types[i].name);
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 95478db9998b..33e8eed64423 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -865,7 +865,7 @@ void intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
int cmd_table_count;
int ret;
- if (!IS_GEN7(engine->i915))
+ if (!IS_GEN(engine->i915, 7))
return;
switch (engine->id) {
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 38dcee1ca062..53e3f57a13f3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1064,7 +1064,7 @@ static int i9
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Rename IS_GEN to IS_GEN_RANGE
On 06/12/2018 06:11, Lucas De Marchi wrote:
RANGE makes it longer, but clearer. We are also going to add a macro to
check an individual gen, so add the _RANGE prefix here.
Diff generated with:
sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i
v2: use IS_GEN rather than GT_GEN
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_perf.c| 4 ++--
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/intel_fbc.c| 2 +-
drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
drivers/gpu/drm/i915/intel_uncore.c | 12 ++--
8 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0689e67c966e..affcb028ff8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2213,7 +2213,7 @@ intel_info(const struct drm_i915_private *dev_priv)
GENMASK((e) - 1, (s) - 1))
/* Returns true if Gen is in inclusive range [Start, End] */
-#define IS_GEN(dev_priv, s, e) \
+#define IS_GEN_RANGE(dev_priv, s, e) \
(!!((dev_priv)->info.gen_mask & INTEL_GEN_MASK((s), (e
/*
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4529edfdcfc8..ad0095be435d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1796,7 +1796,7 @@ static int gen8_enable_metric_set(struct i915_perf_stream
*stream)
* be read back from automatically triggered reports, as part of the
* RPT_ID field.
*/
- if (IS_GEN(dev_priv, 9, 11)) {
+ if (IS_GEN_RANGE(dev_priv, 9, 11)) {
I915_WRITE(GEN8_OA_DEBUG,
_MASKED_BIT_ENABLE(GEN9_OA_DEBUG_DISABLE_CLK_RATIO_REPORTS |
GEN9_OA_DEBUG_INCLUDE_CLK_RATIO));
@@ -3442,7 +3442,7 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
}
- } else if (IS_GEN(dev_priv, 10, 11)) {
+ } else if (IS_GEN_RANGE(dev_priv, 10, 11)) {
dev_priv->perf.oa.ops.is_valid_b_counter_reg =
gen7_is_valid_b_counter_addr;
dev_priv->perf.oa.ops.is_valid_mux_reg =
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 6d3e0260d49c..7b7e7abfa259 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -453,7 +453,7 @@ parse_sdvo_device_mapping(struct drm_i915_private
*dev_priv, u8 bdb_version)
* Only parse SDVO mappings on gens that could have SDVO. This isn't
* accurate and doesn't have to be, as long as it's not too strict.
*/
- if (!IS_GEN(dev_priv, 3, 7)) {
+ if (!IS_GEN_RANGE(dev_priv, 3, 7)) {
DRM_DEBUG_KMS("Skipping SDVO device mapping\n");
return;
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index af2873403009..fe5e87b6e1af 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1248,7 +1248,7 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
&engine->execlists;
u64 addr;
- if (engine->id == RCS && IS_GEN(dev_priv, 4, 7))
+ if (engine->id == RCS && IS_GEN_RANGE(dev_priv, 4, 7))
drm_printf(m, "\tCCID: 0x%08x\n", I915_READ(CCID));
drm_printf(m, "\tRING_START: 0x%08x\n",
I915_READ(RING_START(engine->mmio_base)));
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 78dbacdeaece..b57e31fc0f1e 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -787,7 +787,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
* having a Y offset that isn't divisible by 4 causes FIFO underrun
* and screen flicker.
*/
- if (IS_GEN(dev_priv, 9, 10) &&
+ if (IS_GEN_RANGE(dev_priv, 9, 10) &&
(fbc->state_cache.plane.adjusted_y & 3)) {
fbc->no_fbc_reason = "plane Y offset is misaligned";
return false;
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
b/drivers/gpu/drm/i915/intel_hangcheck.c
index e26d05a46451..41921a843d42 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -252,7 +252,7 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
return ENGINE_WAIT_KICK;
}
- if (IS_GEN(dev_priv, 6, 7) && tmp & RING_WAIT_SEMAPHORE) {
+ if (IS_GEN_RANGE(dev_priv, 6, 7) && tmp & RING_WAIT_SEMAPHORE) {
switch (semaphore_passed(e
Re: [Intel-gfx] [PATCH] drm/i915: Clear bogus DMC BIOS/debug power well requests
On Wed, Dec 05, 2018 at 10:20:23PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The DMC firmware is confused and forces on the BIOS and debug
> power well requests for PW1 and MISC IO on some platforms. On
> BXT I measured this to waste about 10mW in the freeze system
> suspend state with the SoC in s0. I didn't get conclusive
> numbers for s0ix on account of the power consumption being
> much more noisy than in s0.
>
> This is pretty much undoing part of commit 42d9366d41a9
> ("drm/i915/gen9+: Don't remove secondary power well requests")
> where we stopped sanitizing the DMCs bogus request bits.
>
> Cc: Imre Deak
> Cc: Rodrigo Vivi
> Signed-off-by: Ville Syrjälä
Thanks for the effort for clarifying this.
The justification in 42d9366d41a9 for not removing the PW#1 and MISC_IO driver
request bits is not too solid, I admit. Bspec 4230 has this to say about them
(for SKL, but same in practice for the rest):
"""
4. Disable Power Well 1 (PG1) and Misc IO Power
Clear PWR_WELL_CTL Power Well 1 Request to 0b. Do not clear Misc IO Power
Request.
Wait for 10us. Do not poll for the power well to disable. Other clients may
be keeping it enabled.
"""
With MISC_IO we would clearly do the opposite in this patch wrt. the spec.
With PW#1 it's unclear if the spec means only the driver's request bit or all
of them, but "other clients may be keeping it enabled" suggests to me it means
only the driver's request bit. OTOH removing only the driver's request bit
alone doesn't make sense due to DMC forcing on the BIOS (and debug) request
bits anyway.
I opened a BSpec update request to clarify this, I suggest waiting for an
update there before going ahead with this change.
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 35 +++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 4350a5270423..6e349181dd1c 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -336,10 +336,17 @@ static void hsw_wait_for_power_well_disable(struct
> drm_i915_private *dev_priv,
>* Bspec doesn't require waiting for PWs to get disabled, but still do
>* this for paranoia. The known cases where a PW will be forced on:
>* - a KVMR request on any power well via the KVMR request register
> - * - a DMC request on PW1 and MISC_IO power wells via the BIOS and
> - * DEBUG request registers
> + * - a debug request on any power well via the DEBUG request register
>* Skip the wait in case any of the request bits are set and print a
>* diagnostic message.
> + *
> + * Note that DMC firmware will also force on the PW1 BIOS request
> + * on SKL-CNL, MISC_IO BIOS request on SKL-GLK (although MISC_IO
> + * does not even exits on BXT/GLK so the bit doesn't stick),
> + * and the PW1/MISC_IO debug request on BXT. We simply clear
> + * those spurious requests in hsw_power_well_disable() to make
> + * sure they don't waste power. Starting from ICL the DMC firmware
> + * has been fixed to only force on the PW1 driver request bit.
>*/
> wait_for((disabled = !(I915_READ(regs->driver) &
> HSW_PWR_WELL_CTL_STATE(pw_idx))) ||
> @@ -347,6 +354,11 @@ static void hsw_wait_for_power_well_disable(struct
> drm_i915_private *dev_priv,
> if (disabled)
> return;
>
> + WARN(reqs & 3,
> + "%s left on (bios:%d driver:%d kvmr:%d debug:%d)\n",
> + power_well->desc->name,
> + !!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
> +
> DRM_DEBUG_KMS("%s forced on (bios:%d driver:%d kvmr:%d debug:%d)\n",
> power_well->desc->name,
> !!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
> @@ -409,6 +421,7 @@ static void hsw_power_well_disable(struct
> drm_i915_private *dev_priv,
> struct i915_power_well *power_well)
> {
> const struct i915_power_well_regs *regs = power_well->desc->hsw.regs;
> + enum i915_power_well_id id = power_well->desc->id;
> int pw_idx = power_well->desc->hsw.idx;
> u32 val;
>
> @@ -417,6 +430,24 @@ static void hsw_power_well_disable(struct
> drm_i915_private *dev_priv,
>
> val = I915_READ(regs->driver);
> I915_WRITE(regs->driver, val & ~HSW_PWR_WELL_CTL_REQ(pw_idx));
> + /*
> + * On SKL-CNL DMC firmware forces on the BIOS request.
> + * This wastes a bit of power so clear it.
> + */
> + if (INTEL_GEN(dev_priv) < 11 &&
> + (id == SKL_DISP_PW_1 || id == SKL_DISP_PW_MISC_IO)) {
> + val = I915_READ(regs->bios);
> + I915_WRITE(regs->bios, val & ~HSW_PWR_WELL_CTL_REQ(pw_idx));
> + }
> + /*
> + * On BXT DMC firmware forces on the debug request.
> + * This wastes a bit of power so c
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsc: Add Per connector debugfs node for DSC support/enable (rev4)
== Series Details ==
Series: drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
(rev4)
URL : https://patchwork.freedesktop.org/series/53449/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5269_full -> Patchwork_11028_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11028_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11028_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11028_full:
### IGT changes ###
Warnings
* igt@kms_draw_crc@draw-method-xrgb-blt-xtiled:
- shard-snb: PASS -> SKIP
* igt@tools_test@sysfs_l3_parity:
- shard-hsw: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11028_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@debugfs-reader:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#103375]
* igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108470]
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-primary-rotation-180:
- {shard-iclb}: NOTRUN -> FAIL [fdo#107725]
* igt@kms_chv_cursor_fail@pipe-c-128x128-left-edge:
- shard-skl: NOTRUN -> FAIL [fdo#104671]
* igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-skl: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x85-offscreen:
- shard-skl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled:
- {shard-iclb}: PASS -> WARN [fdo#108336] +1
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-skl: PASS -> FAIL [fdo#108472]
* igt@kms_flip@dpms-off-confusion:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +13
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-indfb-scaledprimary:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724] +7
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-render:
- shard-skl: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +9
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@pixel-format-pipe-c-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166]
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-glk: PASS -> DMESG-WARN [fdo#105763] / [fdo#106538]
* igt@perf@polling:
- shard-hsw: PASS -> FAIL [fdo#102252]
* igt@pm_rpm@modeset-non-lpsp-stress:
- shard-skl: SKIP -> INCOMPLETE [fdo#107807]
Possible fixes
* igt@gem_exec_create@forked:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable Y210, Y212, Y216 formats for ICL (rev4)
== Series Details ==
Series: Enable Y210, Y212, Y216 formats for ICL (rev4)
URL : https://patchwork.freedesktop.org/series/48729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5274 -> Patchwork_11033
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48729/revisions/4/mbox/
Known issues
Here are the changes found in Patchwork_11033 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-bsw-kefka: PASS -> FAIL [fdo#108656]
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: PASS -> DMESG-FAIL [fdo#108656]
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: NOTRUN -> FAIL [fdo#108880]
* igt@i915_module_load@reload:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@i915_selftest@live_hangcheck:
- fi-skl-guc: NOTRUN -> DMESG-FAIL [fdo#108593]
* igt@i915_selftest@live_workarounds:
- {fi-icl-u3}:NOTRUN -> DMESG-FAIL [fdo#108954]
* igt@kms_chamelium@common-hpd-after-suspend:
- {fi-kbl-7567u}: NOTRUN -> DMESG-WARN [fdo#108473]
* igt@kms_chamelium@dp-crc-fast:
- {fi-kbl-7500u}: NOTRUN -> FAIL [fdo#103841] +8
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:NOTRUN -> FAIL [fdo#103167]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
* {igt@runner@aborted}:
- fi-bsw-kefka: NOTRUN -> FAIL [fdo#108656]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#108622] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108593]: https://bugs.freedesktop.org/show_bug.cgi?id=108593
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
[fdo#108954]: https://bugs.freedesktop.org/show_bug.cgi?id=108954
Participating hosts (26 -> 43)
--
Additional (20): fi-hsw-4770r fi-kbl-7567u fi-bdw-5557u fi-skl-6770hq
fi-bdw-gvtdvm fi-glk-dsi fi-skl-guc fi-skl-6260u fi-cfl-8700k fi-kbl-7500u
fi-cfl-guc fi-kbl-guc fi-glk-j4005 fi-cfl-8109u fi-icl-u3 fi-skl-iommu
fi-ivb-3520m fi-kbl-r fi-skl-6600u fi-snb-2600
Missing(3): fi-byt-squawks fi-bsw-cyan fi-skl-6700hq
Build changes
-
* Linux: CI_DRM_5274 -> Patchwork_11033
CI_DRM_5274: 3117375b77ec896e358afaff7c307bfad01d0de7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11033: 0f855b9a747aad4f0d7319a4b975fd0ec5ce1470 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0f855b9a747a drm/i915/icl: Enable Y210, Y212, Y216 format for primary and
sprite planes
1d7136c40bbd drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats
7d0f6917f175 drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
7ad9e3b1affc drm: Add Y210, Y212, Y216 format definitions and fourcc
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11033/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFT i-g-t v2] tests/gem_shrink: Background, direct and OOM shrinker plus userptr tests
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915/gem_shrink.c | 213
1 file changed, 213 insertions(+)
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..acc12efed15e 100644
--- a/tests/i915/gem_shrink.c
+++ b/tests/i915/gem_shrink.c
@@ -26,6 +26,9 @@
*
* Exercise the shrinker by overallocating GEM objects
*/
+#include
+#include
+#include
#include "igt.h"
#include "igt_gt.h"
@@ -366,6 +369,210 @@ static void reclaim(unsigned engine, int timeout)
close(fd);
}
+static unsigned long get_meminfo(const char *info, const char *tag)
+{
+ const char *str;
+ unsigned long val;
+
+ str = strstr(info, tag);
+ if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
+ return val >> 10;
+
+ igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
+ return 0;
+}
+
+static unsigned long get_avail_ram_mb(void)
+{
+ int fd;
+ int ret;
+ char buf[4096];
+ unsigned long ram;
+
+ fd = open("/proc/meminfo", O_RDONLY);
+ igt_assert_fd(fd);
+
+ ret = read(fd, buf, sizeof(buf));
+ igt_assert(ret >= 0);
+
+ close(fd);
+
+ ram = get_meminfo(buf, "MemAvailable:");
+ ram += get_meminfo(buf, "Buffers:");
+ ram += get_meminfo(buf, "Cached:");
+ ram += get_meminfo(buf, "SwapCached:");
+
+ return ram;
+}
+
+struct test {
+#define TEST_BO(1)
+#define TEST_USERPTR (2)
+ unsigned int flags;
+ int fd;
+};
+
+static uint32_t __get_pages(int fd, unsigned long alloc)
+{
+ uint32_t handle = gem_create(fd, alloc);
+
+ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, handle, I915_MADV_DONTNEED);
+
+ return handle;
+}
+
+struct test_obj {
+ void *ptr;
+ uint32_t handle;
+};
+
+static void
+__get_userptr(int fd, struct test_obj *obj, unsigned long sz)
+{
+ struct local_i915_gem_userptr userptr = { };
+ void *ptr;
+
+ igt_assert_eq(sz & 4095, 0);
+
+ ptr = mmap(NULL, sz, PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ assert(ptr != MAP_FAILED);
+
+ userptr.user_size = sz;
+ userptr.user_ptr = to_user_pointer(ptr);
+ do_ioctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
+
+ gem_set_domain(fd, userptr.handle, I915_GEM_DOMAIN_GTT, 0);
+
+ obj->ptr = ptr;
+ obj->handle = userptr.handle;
+}
+
+#define PAGE_SIZE 4096
+static void *mempressure(void *arg)
+{
+ struct test_obj *list = NULL;
+ struct test *test = arg;
+ const unsigned int sz_mb = 2;
+ const unsigned int sz = sz_mb << 20;
+ unsigned int n = 0, max = 0;
+ unsigned int blocks;
+
+ while (true) {
+ unsigned long ram_mb = get_avail_ram_mb();
+
+ if (!list) {
+ blocks = ram_mb / sz_mb;
+ list = calloc(blocks, sizeof(*list));
+ igt_assert(list);
+ } else if (ram_mb < 256) {
+ blocks = max + 1;
+ }
+
+ if (list[n].ptr || list[n].handle) {
+ if (test->flags & TEST_BO)
+ gem_close(test->fd, list[n].handle);
+ else
+ munmap(list[n].ptr, sz);
+ }
+
+ if (test->flags & TEST_BO) {
+ list[n].handle = __get_pages(test->fd, sz);
+ } else if (test->flags & TEST_USERPTR) {
+ __get_userptr(test->fd, &list[n], sz);
+ } else {
+ list[n].ptr = mmap(NULL, sz, PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ assert(list[n].ptr != MAP_FAILED);
+
+ madvise(list[n].ptr, sz, MADV_HUGEPAGE);
+
+ for (size_t page = 0; page < sz; page += PAGE_SIZE)
+ *(volatile uint32_t *)((unsigned char
*)list[n].ptr + page) = 0;
+ }
+
+ if (n > max)
+ max = n;
+
+ n++;
+
+ if (n >= blocks)
+ n = 0;
+ }
+
+ return NULL;
+}
+
+static void oom_adjust(const char *score)
+{
+int fd;
+
+fd = open("/proc/self/oom_score_adj", O_WRONLY);
+igt_assert_fd(fd);
+igt_assert(write(fd, score, sizeof(score)) == sizeof(score));
+close(fd);
+}
+
+static void trigger_oom(void)
+{
+ const char *cmd = "f";
+int fd;
+
+fd = open("/proc/sysrq-trigger", O_WRONLY);
+igt_assert_fd(fd);
+igt_assert(write(fd, cmd, sizeof(cmd)) == sizeof(cmd));
+close(fd);
+}
+
+static void reclaim_oom(unsigned int flags)
+{
+ unsigned int count = 0;
+
+ igt_assert_eq(__builtin_popcount(flags), 1);
+
+ oom_ad
[Intel-gfx] [RFT i-g-t] tests/gem_shrink: Background, direct and OOM shrinker plus userptr tests
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915/gem_shrink.c | 213
1 file changed, 213 insertions(+)
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..d838a750fe68 100644
--- a/tests/i915/gem_shrink.c
+++ b/tests/i915/gem_shrink.c
@@ -26,6 +26,9 @@
*
* Exercise the shrinker by overallocating GEM objects
*/
+#include
+#include
+#include
#include "igt.h"
#include "igt_gt.h"
@@ -366,6 +369,210 @@ static void reclaim(unsigned engine, int timeout)
close(fd);
}
+static unsigned long get_meminfo(const char *info, const char *tag)
+{
+ const char *str;
+ unsigned long val;
+
+ str = strstr(info, tag);
+ if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
+ return val >> 10;
+
+ igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
+ return 0;
+}
+
+static unsigned long get_avail_ram_mb(void)
+{
+ int fd;
+ int ret;
+ char buf[4096];
+ unsigned long ram;
+
+ fd = open("/proc/meminfo", O_RDONLY);
+ igt_assert_fd(fd);
+
+ ret = read(fd, buf, sizeof(buf));
+ igt_assert(ret >= 0);
+
+ close(fd);
+
+ ram = get_meminfo(buf, "MemAvailable:");
+ ram += get_meminfo(buf, "Buffers:");
+ ram += get_meminfo(buf, "Cached:");
+ ram += get_meminfo(buf, "SwapCached:");
+
+ return ram;
+}
+
+struct test {
+#define TEST_BO(1)
+#define TEST_USERPTR (2)
+ unsigned int flags;
+ int fd;
+};
+
+static uint32_t __get_pages(int fd, unsigned long alloc)
+{
+ uint32_t handle = gem_create(fd, alloc);
+
+ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, handle, I915_MADV_DONTNEED);
+
+ return handle;
+}
+
+struct test_obj {
+ void *ptr;
+ uint32_t handle;
+};
+
+static void
+__get_userptr(int fd, struct test_obj *obj, unsigned long sz)
+{
+ struct local_i915_gem_userptr userptr = { };
+ void *ptr;
+
+ igt_assert_eq(sz & 4095, 0);
+
+ ptr = mmap(NULL, sz, PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ assert(ptr != MAP_FAILED);
+
+ userptr.user_size = sz;
+ userptr.user_ptr = to_user_pointer(ptr);
+ do_ioctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
+
+ gem_set_domain(fd, userptr.handle, I915_GEM_DOMAIN_GTT, 0);
+
+ obj->ptr = ptr;
+ obj->handle = userptr.handle;
+}
+
+#define PAGE_SIZE 4096
+static void *mempressure(void *arg)
+{
+ struct test_obj *list = NULL;
+ struct test *test = arg;
+ const unsigned int sz_mb = 2;
+ const unsigned int sz = sz_mb << 20;
+ unsigned int n = 0, max = 0;
+ unsigned int blocks;
+
+ while (true) {
+ unsigned long ram_mb = get_avail_ram_mb();
+
+ if (!list) {
+ blocks = ram_mb / sz_mb;
+ list = calloc(blocks, sizeof(*list));
+ igt_assert(list);
+ } else if (ram_mb < 256) {
+ blocks = max + 1;
+ }
+
+ if (list[n].ptr || list[n].handle) {
+ if (test->flags & TEST_BO)
+ gem_close(test->fd, list[n].handle);
+ else
+ munmap(list[n].ptr, sz);
+ }
+
+ if (test->flags & TEST_BO) {
+ list[n].handle = __get_pages(test->fd, sz);
+ } else if (test->flags & TEST_USERPTR) {
+ __get_userptr(test->fd, &list[n], sz);
+ } else {
+ list[n].ptr = mmap(NULL, sz, PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ assert(list[n].ptr != MAP_FAILED);
+
+ madvise(list[n].ptr, sz, MADV_HUGEPAGE);
+
+ for (size_t page = 0; page < sz; page += PAGE_SIZE)
+ *(volatile uint32_t *)((unsigned char
*)list[n].ptr + page) = 0;
+ }
+
+ if (n > max)
+ max = n;
+
+ n++;
+
+ if (n >= blocks)
+ n = 0;
+ }
+
+ return NULL;
+}
+
+static void oom_adjust(const char *score)
+{
+int fd;
+
+fd = open("/proc/self/oom_score_adj", O_WRONLY);
+igt_assert_fd(fd);
+igt_assert(write(fd, score, sizeof(score)) == sizeof(score));
+close(fd);
+}
+
+static void trigger_oom(void)
+{
+ const char *cmd = "f";
+int fd;
+
+fd = open("/proc/sysrq-trigger", O_WRONLY);
+igt_assert_fd(fd);
+igt_assert(write(fd, cmd, sizeof(cmd)) == sizeof(cmd));
+close(fd);
+}
+
+static void reclaim_oom(unsigned int flags)
+{
+ unsigned int count = 0;
+
+ igt_assert_eq(__builtin_popcount(flags), 1);
+
+ oom_ad
Re: [Intel-gfx] [PATCH v8 08/35] drm/i915: Implement HDCP2.2 repeater authentication
On Tue, Nov 27, 2018 at 04:13:06PM +0530, Ramalingam C wrote:
> Implements the HDCP2.2 repeaters authentication steps such as verifying
> the downstream topology and sending stream management information.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> -EINVAL is returned for topology error and rollover scenario.
> Endianness conversion func from drm_hdcp.h is used [Uma]
> v5:
> Rebased as part of patches reordering.
> Defined the mei service functions [Daniel]
> v6:
> Redefined the mei service functions as per comp redesign.
> v7:
> %s/uintxx_t/uxx
> Check for comp_master is removed.
> v8:
> Adjust to the new mei interface.
> style issue fixed.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 125
> +-
> include/drm/drm_hdcp.h| 15 +
> 2 files changed, 138 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 0d7fea9c9bb1..679f3c164582 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -1069,7 +1069,7 @@ static int hdcp2_prepare_skey(struct intel_connector
> *connector,
> return ret;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
> struct hdcp2_rep_send_receiverid_list
> *rep_topology,
> @@ -1099,7 +1099,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct
> intel_connector *connector,
> return ret;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_verify_mprime(struct intel_connector *connector,
> struct hdcp2_rep_stream_ready *stream_ready)
> {
> @@ -1315,6 +1315,121 @@ static int hdcp2_session_key_exchange(struct
> intel_connector *connector)
> return 0;
> }
>
> +static
> +int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + union {
> + struct hdcp2_rep_stream_manage stream_manage;
> + struct hdcp2_rep_stream_ready stream_ready;
> + } msgs;
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> + int ret;
> +
> + /* Prepare RepeaterAuth_Stream_Manage msg */
> + msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
> + reverse_endianness(msgs.stream_manage.seq_num_m, HDCP_2_2_SEQ_NUM_LEN,
> +(u8 *)&hdcp->seq_num_m);
> +
> + /* K no of streams is fixed as 1. Stored as big-endian. */
> + msgs.stream_manage.k = __swab16(1);
> +
> + /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
> + msgs.stream_manage.streams[0].stream_id = 0;
> + msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
> +
> + /* Send it to Repeater */
> + ret = shim->write_2_2_msg(intel_dig_port, &msgs.stream_manage,
> + sizeof(msgs.stream_manage));
> + if (ret < 0)
> + return ret;
> +
> + ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
> + &msgs.stream_ready, sizeof(msgs.stream_ready));
> + if (ret < 0)
> + return ret;
> +
> + hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
> + hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
> +
> + ret = hdcp2_verify_mprime(connector, &msgs.stream_ready);
> + if (ret < 0)
> + return ret;
> +
> + hdcp->seq_num_m++;
> +
> + if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
> + DRM_DEBUG_KMS("seq_num_m roll over.\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static
> +int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + union {
> + struct hdcp2_rep_send_receiverid_list recvid_list;
> + struct hdcp2_rep_send_ack rep_ack;
> + } msgs;
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> + u8 *rx_info;
> + u32 seq_num_v;
> + int ret;
> +
> + ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
> + &msgs.recvid_list, sizeof(msgs.recvid_list));
> + if (ret < 0)
> + return ret;
> +
> + rx_info = msgs.recvid_list.rx_info;
> +
> + if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
> + HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
> + DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
> + return -EINVAL;
> + }
> +
> + /* Converting and Storing the seq_num_v to local variable as DWORD */
> + reverse_endianness((u8 *)&seq_num_v, HDCP_2_2_SEQ_NU
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable Y210, Y212, Y216 formats for ICL (rev4)
== Series Details ==
Series: Enable Y210, Y212, Y216 formats for ICL (rev4)
URL : https://patchwork.freedesktop.org/series/48729/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7ad9e3b1affc drm: Add Y210, Y212, Y216 format definitions and fourcc
-:46: WARNING:LONG_LINE: line over 100 characters
#46: FILE: drivers/gpu/drm/drm_fourcc.c:229:
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:47: WARNING:LONG_LINE: line over 100 characters
#47: FILE: drivers/gpu/drm/drm_fourcc.c:230:
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:48: WARNING:LONG_LINE: line over 100 characters
#48: FILE: drivers/gpu/drm/drm_fourcc.c:231:
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:64: WARNING:LONG_LINE_COMMENT: line over 100 characters
#64: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
-:65: WARNING:LONG_LINE_COMMENT: line over 100 characters
#65: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian */
-:66: WARNING:LONG_LINE_COMMENT: line over 100 characters
#66: FILE: include/uapi/drm/drm_fourcc.h:162:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
total: 0 errors, 6 warnings, 0 checks, 23 lines checked
7d0f6917f175 drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
1d7136c40bbd drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats
0f855b9a747a drm/i915/icl: Enable Y210, Y212, Y216 format for primary and
sprite planes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 06/35] drm/i915: Enable and Disable of HDCP2.2
On Tue, Nov 27, 2018 at 04:13:04PM +0530, Ramalingam C wrote:
> Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
> supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
>
> When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
> enabled.
>
> This change implements a sequence of enabling and disabling of
> HDCP2.2 authentication and HDCP2.2 port encryption.
Patch series suggestion for next time around: First build out the helper
functions, then time them into the big picture like here. Personally I
think that makes it easier to understand, but it's kinda personal choice.
I guess this here works too.
>
> v2:
> Included few optimization suggestions [Chris Wilson]
> Commit message is updated as per the rebased version.
> intel_wait_for_register is used instead of wait_for. [Chris Wilson]
> v3:
> No changes.
> v4:
> Extra comment added and Style issue fixed [Uma]
> v5:
> Rebased as part of patch reordering.
> HDCP2 encryption status is tracked.
> HW state check is moved into WARN_ON [Daniel]
> v6:
> Redefined the mei service functions as per comp redesign.
> Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
> Required shim functionality is defined [Sean Paul]
> v7:
> Return values are handles [Uma]
> Realigned the code.
> Check for comp_master is removed.
> v8:
> HDCP2.2 is attempted only if mei interface is up.
> Adjust to the new interface
> Avoid bool usage in struct [Tomas]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_drv.h | 5 +
> drivers/gpu/drm/i915/intel_hdcp.c | 223
> +++---
> 2 files changed, 214 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index bde82f3ada85..3e9f21d23442 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -383,6 +383,10 @@ struct intel_hdcp_shim {
>
> /* Detects the HDCP protocol(DP/HDMI) required on the port */
> enum mei_hdcp_wired_protocol (*hdcp_protocol)(void);
> +
> + /* Detects whether Panel is HDCP2.2 capable */
> + int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
> + bool *capable);
> };
>
> struct intel_hdcp {
> @@ -396,6 +400,7 @@ struct intel_hdcp {
> /* HDCP2.2 related definitions */
> /* Flag indicates whether this connector supports HDCP2.2 or not. */
> u8 hdcp2_supported;
> + u8 hdcp2_in_use;
>
> /*
>* Content Stream Type defined by content owner. TYPE0(0x0) content can
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 760780f1105c..c1bd1ccd47cd 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -79,6 +79,43 @@ bool intel_hdcp_capable(struct intel_connector *connector)
> return capable;
> }
>
> +/* At present whether mei_hdcp component is binded with i915 master
> component */
> +static bool intel_hdcp2_mei_binded(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct i915_hdcp_component_master *comp = dev_priv->hdcp_comp;
> +
> + mutex_lock(&comp->mutex);
> + if (!comp->ops || !comp->dev) {
> + mutex_unlock(&comp->mutex);
> + return false;
> + }
> + mutex_unlock(&comp->mutex);
> +
> + return true;
> +}
> +
> +/* Is HDCP2.2 capable on Platform and Sink */
> +static bool intel_hdcp2_capable(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + bool capable = false;
> +
> + /* I915 support for HDCP2.2 */
> + if (!hdcp->hdcp2_supported)
> + return false;
> +
> + /* MEI services for HDCP2.2 */
> + if (!intel_hdcp2_mei_binded(connector))
> + return false;
Why do we still need this with component? Driver load should be stalled
out until it's all there, that was kinda the entire point of component,
so we don't have to recheck all the time whether hdcp2 is still there or
not.
> +
> + /* Sink's capability for HDCP2.2 */
> + hdcp->shim->hdcp_2_2_capable(intel_dig_port, &capable);
> +
> + return capable;
> +}
> +
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
> {
> @@ -1114,8 +1151,7 @@ int hdcp2_authenticate_port(struct intel_connector
> *connector)
> return ret;
> }
>
> -static __attribute__((unused))
> -int hdcp2_close_mei_session(struct intel_connector *connector)
> +static int hdcp2_close_mei_session(struct intel_connector *connector)
> {
> struct mei_hdcp_data *data = &connector->hdcp.mei_data;
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -1137,12
Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> Signed-off-by: Ramalingam C
> Signed-off-by: Tomas Winkler
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_drv.h | 7 +
> drivers/gpu/drm/i915/intel_hdcp.c | 442
> +-
> include/drm/i915_component.h | 71 ++
> 4 files changed, 521 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f763b30f98d9..b68bc980b7cd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2015,6 +2015,8 @@ struct drm_i915_private {
>
> struct i915_pmu pmu;
>
> + struct i915_hdcp_component_master *hdcp_comp;
> +
> /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 85a526598096..bde82f3ada85 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "i915_drv.h"
> #include
> @@ -379,6 +380,9 @@ struct intel_hdcp_shim {
> /* Detects panel's hdcp capability. This is optional for HDMI. */
> int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> bool *hdcp_capable);
> +
> + /* Detects the HDCP protocol(DP/HDMI) required on the port */
> + enum mei_hdcp_wired_protocol (*hdcp_protocol)(void);
Looking ahead, this seems hardwired to constant return value? Or why do we
need a function here?
> };
>
> struct intel_hdcp {
> @@ -399,6 +403,9 @@ struct intel_hdcp {
>* content can flow only through a link protected by HDCP2.2.
>*/
> u8 content_type;
> +
> + /* mei interface related information */
> + struct mei_hdcp_data mei_data;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 99dddb540958..760780f1105c 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -8,14 +8,20 @@
>
> #include
> #include
> +#include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
>
> #define KEY_LOAD_TRIES 5
> #define TIME_FOR_ENCRYPT_STATUS_CHANGE 50
> +#define GET_MEI_DDI_INDEX(p) ({\
> + typeof(p) __p = (p); \
> + __p == PORT_A ? MEI_DDI_A : (enum mei_hdcp_ddi)__p;\
> +})
>
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> @@ -833,6 +839,417 @@ bool is_hdcp_supported(struct drm_i915_private
> *dev_priv, enum port port)
> !IS_CHERRYVIEW(dev_priv) && port < PORT_E);
> }
>
> +static __attribute__((unused)) int
> +hdcp2_prepare_ake_init(struct intel_connector *connector,
> +struct hdcp2_ake_init *ake_data)
> +{
> + struct mei_hdcp_data *data = &connector->hdcp.mei_data;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct i915_hdcp_component_master *comp = dev_priv->hdcp_comp;
> + int ret;
> +
> + if (!comp)
> + return -EINVAL;
> +
> + mutex_lock(&comp->mutex);
> + if (!comp->ops || !comp->dev) {
> + mutex_unlock(&comp->mutex);
> + return -EINVAL;
> + }
> +
> + if (data->port == MEI_DDI_INVALID_PORT && connector->encoder)
> + data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
> +
> + /* Clear ME FW instance for the port, just incase */
> + comp->ops->close_hdcp_session(comp->dev, data);
Sounds like a bug somewhere if we need this? I'd put this code into the
->initiate_hdcp2_session, with a big WARN_ON if it's actually needed.
"Just in case" papering over programming bugs of our own just makes
debugging harder.
> +
> + ret = comp->ops->initiate_hdcp2_session(comp->dev,
> + data, ake_data);
We should set the port only after successfully initializing this.
> + mutex_unlock(&comp->mutex);
> +
> + return ret;
> +}
> +
> +static __attribute__((unused)) int
> +hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
> + struct hdcp2_ake_send_cert *rx_cert,
> + bool *paired,
> + struct hdcp2_ake_no_stored_km *ek_pub_km,
> + size_t *msg_sz)
> +{
> + struct mei_hdcp_data *data = &connector->hdcp.mei_data;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct i915_hdcp_component_master *comp = dev_priv->hdcp_comp;
> + int ret;
> +
> + if (!comp)
> + return -EINVAL;
> +
Re: [Intel-gfx] [PATCH v8 04/35] drm/i915: Initialize HDCP2.2
On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote:
> Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
With the comments below addressed the commit message is a bit untrue,
since this just wires up a basic hdcp2_supported flag in a few places.
Please make that clear.
>
> v2:
> mei interface handle is protected with mutex. [Chris Wilson]
> v3:
> Notifiers are used for the mei interface state.
> v4:
> Poll for mei client device state
> Error msg for out of mem [Uma]
> Inline req for init function removed [Uma]
> v5:
> Rebase as Part of reordering.
> Component is used for the I915 and MEI_HDCP interface [Daniel]
> v6:
> HDCP2.2 uses the I915 component master to communicate with mei_hdcp
> - [Daniel]
> Required HDCP2.2 variables defined [Sean Paul]
> v7:
> intel_hdcp2.2_init returns void [Uma]
> Realigning the codes.
> v8:
> Avoid using bool structure members.
> MEI interface related changes are moved into separate patch.
> Commit msg is updated accordingly.
> intel_hdcp_exit is defined and used from i915_unload
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +
> drivers/gpu/drm/i915/intel_dp.c | 3 +-
> drivers/gpu/drm/i915/intel_drv.h | 16 +++-
> drivers/gpu/drm/i915/intel_hdcp.c | 172
> --
> drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> 5 files changed, 130 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b1d23c73c147..fbedd5024afe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1755,6 +1755,8 @@ void i915_driver_unload(struct drm_device *dev)
>
> disable_rpm_wakeref_asserts(dev_priv);
>
> + intel_hdcp_exit(dev_priv);
This smells like a separate patch. Needs to be split out. Looking at the
implementation of intel_hdcp_exit I think it's papering over some unload
trouble. We should be shutting down all the outputs on driver unload,
which mei should be triggering (with the component stuff), which means
this code should be unecessary. But I'm not sure.
Either way needs to be split out, but I think proper solution is to drop
it.
> +
> i915_driver_unregister(dev_priv);
>
> if (i915_gem_suspend(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 18e3a5a3d873..ac62af073688 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6675,7 +6675,8 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> intel_dp_add_properties(intel_dp, connector);
>
> if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
> - int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
> + int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim,
> + false);
> if (ret)
> DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index a62d77b76291..85a526598096 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -388,6 +388,17 @@ struct intel_hdcp {
> u64 value;
> struct delayed_work check_work;
> struct work_struct prop_work;
> +
> + /* HDCP2.2 related definitions */
> + /* Flag indicates whether this connector supports HDCP2.2 or not. */
> + u8 hdcp2_supported;
> +
> + /*
> + * Content Stream Type defined by content owner. TYPE0(0x0) content can
> + * flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
> + * content can flow only through a link protected by HDCP2.2.
> + */
> + u8 content_type;
> };
>
> struct intel_connector {
> @@ -2016,12 +2027,15 @@ void intel_hdcp_atomic_check(struct drm_connector
> *connector,
>struct drm_connector_state *old_state,
>struct drm_connector_state *new_state);
> int intel_hdcp_init(struct intel_connector *connector,
> - const struct intel_hdcp_shim *hdcp_shim);
> + const struct intel_hdcp_shim *hdcp_shim,
> + bool hdcp2_supported);
> int intel_hdcp_enable(struct intel_connector *connector);
> int intel_hdcp_disable(struct intel_connector *connector);
> int intel_hdcp_check_link(struct intel_connector *connector);
> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
> bool intel_hdcp_capable(struct intel_connector *connector);
> +bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
> +void intel_hdcp_exit(struct drm_i915_private *dev_priv);
>
> /* intel_psr.c */
> #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> i
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
== Series Details ==
Series: drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
URL : https://patchwork.freedesktop.org/series/53629/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272 -> Patchwork_11032
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53629/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11032 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108566]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: FAIL [fdo#108880] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108315]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
Participating hosts (48 -> 45)
--
Additional (1): fi-skl-guc
Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_5272 -> Patchwork_11032
CI_DRM_5272: 4bb8baa3a7b836ce18e1b27ba12bae2130ee38cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11032: 8664eef5c26ac67fcc7c23c12151bcda8f254cd6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8664eef5c26a drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11032/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Final pull request for -next targeting v4.21. Most of the changes are small and all over the place, so I didn't enumerate them all. drm-misc-next-2018-12-06: Final changes to drm-misc-next for v4.21: UAPI Changes: Core Changes: - Add dma_fence_get_stub to dma-buf, and use it in drm/syncobj. - Add and use DRM_MODESET_LOCK_BEGIN/END helpers. - Small fixes to drm_atomic_helper_resume(), drm_mode_setcrtc() and drm_atomic_helper_commit_duplicated_state() - Fix drm_atomic_state_helper.[c] extraction. Driver Changes: - Small fixes to tinydrm, vkms, meson, rcar-du, virtio, vkms, v3d, and pl111. - vc4: Allow scaling and YUV formats on cursor planes. - v3d: Enable use of the Texture Formatting Unit, and fix prime imports of buffers from other drivers. - Add support for the AUO G101EVN010 panel. - sun4i: Enable support for the H6 display engine. The following changes since commit 167bfe534dc2de680ef706dbb903c9a7bfcb2dd8: Documentation: drm: Remove dangling pointer from drm-mm.rst (2018-11-30 08:55:37 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-12-06 for you to fetch changes up to 0b258ed1a219a9776e8f6967eb34837ae0332e64: drm: revert "expand replace_fence to support timeline point v2" (2018-12-05 11:01:11 +0100) Final changes to drm-misc-next for v4.21: UAPI Changes: Core Changes: - Add dma_fence_get_stub to dma-buf, and use it in drm/syncobj. - Add and use DRM_MODESET_LOCK_BEGIN/END helpers. - Small fixes to drm_atomic_helper_resume(), drm_mode_setcrtc() and drm_atomic_helper_commit_duplicated_state() - Fix drm_atomic_state_helper.[c] extraction. Driver Changes: - Small fixes to tinydrm, vkms, meson, rcar-du, virtio, vkms, v3d, and pl111. - vc4: Allow scaling and YUV formats on cursor planes. - v3d: Enable use of the Texture Formatting Unit, and fix prime imports of buffers from other drivers. - Add support for the AUO G101EVN010 panel. - sun4i: Enable support for the H6 display engine. Alex Gonzalez (1): drm/panel: simple: Add AUO G101EVN010 panel support Boris Brezillon (6): drm/vc4: Make vc4_lbm_size() return 0 when vertical scaling is disabled drm/vc4: Move LBM creation out of vc4_plane_mode_set() drm/vc4: Don't check plane state more than once drm/vc4: Rework the async update logic drm/vc4: Allow scaling on cursor plane drm/vc4: Allow YUV formats on cursor planes Christian König (3): dma-buf: add dma_fence_get_stub drm/syncobj: use dma_fence_get_stub drm: revert "expand replace_fence to support timeline point v2" Daniel Vetter (2): drm/vkms: Fix plane duplicate_state drm: Fix up drm_atomic_state_helper.[hc] extraction Eric Anholt (5): drm/v3d: Add support for submitting jobs to the TFU. drm/v3d: Drop the "dev" argument to lock/unlock of BO reservations. drm/v3d: Fix prime imports of buffers from other drivers. drm/v3d: Add missing fence timeline name for TFU. drm/v3d: Add more tracepoints for V3D GPU rendering. Gerd Hoffmann (2): drm/virtio: fence: pass plain pointer drm/virtio: virtio_gpu_cmd_resource_create_3d: drop unused fence arg Jernej Skrabec (1): drm/sun4i: Add compatible for H6 display engine Maarten Lankhorst (1): Merge remote-tracking branch 'drm/drm-next' into drm-misc-next Neil Armstrong (1): drm/meson: Fix an Alpha Primary Plane bug on Meson GXL/GXM SoCs Noralf Trønnes (1): drm/rcar-du: Use drm_fbdev_generic_setup() Sean Paul (7): drm: Clear state->acquire_ctx before leaving drm_atomic_helper_commit_duplicated_state() drm: Move drm_mode_setcrtc() local re-init to failure path drm: Move atomic_state_put after locks are dropped drm: Add DRM_MODESET_LOCK_BEGIN/END helpers drm: TODO: Add DRM_MODESET_LOCK_ALL* conversion to todo.rst Merge drm/drm-next into drm-misc-next drm: Fix compiler warning in drm_atomic_helper.c Yangtao Li (1): drm/pl111: add of_node_put() YueHaibing (2): drm/vkms: Remove set but not used variable 'vkms_obj' drm/tinydrm: Use kmemdup rather than duplicating its implementation in repaper_spi_transfer() .../bindings/display/panel/auo,g101evn010 | 12 ++ Documentation/gpu/todo.rst | 15 ++ drivers/dma-buf/dma-fence.c| 36 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/drm_atomic_helper.c| 217 drivers/gpu/drm/drm_atomic_state_helper.c | 157 --- drivers/gpu/drm/drm_color_mgmt.c | 14 +- drivers/gpu/drm/drm_crtc.c | 31 ++- drivers/gpu/drm/drm_modeset_lock.c | 6 + drivers/gpu/drm/drm_plane.c| 16 +-
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
== Series Details == Series: drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK URL : https://patchwork.freedesktop.org/series/53629/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8664eef5c26a drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK -:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #8: Test requirement not met in function run_tests_for_pipe, file kms_color.c:858: total: 0 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/4] drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
Added needed plane control flag definitions for Y210, Y212 and
Y216 formats.
v3: no change
v4: rebase
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a7d605..ad5cee1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6522,6 +6522,9 @@ enum {
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
#define PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define PLANE_CTL_FORMAT_Y210(1 << 23)
+#define PLANE_CTL_FORMAT_Y212(3 << 23)
+#define PLANE_CTL_FORMAT_Y216(5 << 23)
#define PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
#define PLANE_CTL_KEY_ENABLE_SOURCE (1 << 21)
#define PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.
Y210: Valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212: Valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216: Valid data occupies 16 bits,
doesn't require any padding bits.
First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.
v2: is_yuv setted to true (mahesh)
different order of yuv samples (mahesh): still update from
hardware team pending
change in comment (alexandru)
v3: change in patch comment (juha)
change in fourcc_code comment (juha)
different order of yuv samples needs to be defined for Y210/
Y212/Y216 (update from h/w folks): not including in this patch,
will do in other patch series (if reqd)
v4: rebase
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d90ee03..fd011f6 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -226,6 +226,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0b44260..d46a8e1 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -154,6 +154,14 @@
#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /*
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
/*
+ * packed Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
+
+/*
* packed YCbCr420 2x2 tiled formats
* first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
*/
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/4] drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats
v3: case handling checking INTEL_GEN(dev_priv) < 11 added for these 3
new pixel formats (juha)
v4: rebase
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/gpu/drm/i915/intel_sprite.c | 3 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a2584f9..86d6613 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3530,6 +3530,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_Y210:
+ return PLANE_CTL_FORMAT_Y210;
+ case DRM_FORMAT_Y212:
+ return PLANE_CTL_FORMAT_Y212;
+ case DRM_FORMAT_Y216:
+ return PLANE_CTL_FORMAT_Y216;
default:
MISSING_CASE(pixel_format);
}
@@ -5023,6 +5029,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index d2e003d..a41d1af 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1905,6 +1905,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/4] Enable Y210, Y212, Y216 formats for ICL
These patches enable packed format YUV422-Y210, Y212 and Y216 for 10, 12 and 16 bit respectively for ICL. For user space component IGT IGT needs libraries for Pixman and Cairo to support more than 8bpc. Work going on from Maarten Lankhorst. v2: addressed review comments of mahesh and alexandru hdr handling of these 64 bit pixel format not inscope of this series v3: addressed review comments of Juha-pekka(JP) v4: rebase Swati Sharma (4): drm: Add Y210, Y212, Y216 format definitions and fourcc drm/i915/icl: Add Y210, Y212, Y216 plane control definitions drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes drivers/gpu/drm/drm_fourcc.c | 3 +++ drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_display.c | 9 +++ drivers/gpu/drm/i915/intel_sprite.c | 52 ++-- include/uapi/drm/drm_fourcc.h| 8 ++ 5 files changed, 73 insertions(+), 2 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/4] drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes
In this patch, a list for icl specific pixel formats is created
in which Y210, Y212 and Y216 pixel formats are added along with
legacy pixel formats for primary and sprite plane.
v3: since support for planar formats on ICL was getting totally
skipped, added support for the same in intel_display.c and
intel_sprite.c. (juha)
v4: rebase
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_sprite.c | 49 +++--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index a41d1af..fa6b59a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1767,6 +1767,43 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_NV12,
};
+static const uint32_t icl_plane_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
+static const uint32_t icl_planar_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -2049,8 +2086,16 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
- formats = skl_planar_formats;
- num_formats = ARRAY_SIZE(skl_planar_formats);
+ if (INTEL_GEN(dev_priv) >= 11) {
+ formats = icl_planar_formats;
+ num_formats = ARRAY_SIZE(icl_planar_formats);
+ } else {
+ formats = skl_planar_formats;
+ num_formats = ARRAY_SIZE(skl_planar_formats);
+ }
+ } else if (INTEL_GEN(dev_priv) >= 11) {
+ formats = icl_plane_formats;
+ num_formats = ARRAY_SIZE(icl_plane_formats);
} else {
formats = skl_plane_formats;
num_formats = ARRAY_SIZE(skl_plane_formats);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Fix the formulae for register offsets (rev3)
== Series Details ==
Series: drm/i915/cnl: Fix the formulae for register offsets (rev3)
URL : https://patchwork.freedesktop.org/series/52960/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5267_full -> Patchwork_11027_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11027_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-bsd:
- shard-skl: NOTRUN -> FAIL [fdo#103158]
* igt@gem_workarounds@suspend-resume-context:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_atomic@test_only:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +26
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-skl: NOTRUN -> FAIL [fdo#106641]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-hang-newfb-render-b:
- shard-apl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_chv_cursor_fail@pipe-c-128x128-left-edge:
- shard-skl: NOTRUN -> FAIL [fdo#104671]
* igt@kms_color@pipe-b-ctm-green-to-red:
- shard-skl: PASS -> FAIL [fdo#107201]
* igt@kms_color@pipe-b-degamma:
- shard-skl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-random:
- {shard-iclb}: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +14
* igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-ytiled:
- {shard-iclb}: PASS -> WARN [fdo#108336]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite:
- shard-skl: PASS -> FAIL [fdo#103167] / [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724] +11
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-render:
- shard-skl: PASS -> FAIL [fdo#103167] +2
* igt@kms_plane@pixel-format-pipe-a-planes:
- shard-skl: NOTRUN -> FAIL [fdo#103166]
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#107713]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +3
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_properties@connector-properties-atomic:
- shard-skl: NOTRUN -> FAIL [fdo#108642]
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-glk: PASS -> DMESG-WARN [fdo#105763] / [fdo#106538]
* igt@kms_setmode@basic:
- {shard-iclb}: NOTRUN -> FAIL [fdo#99912]
* igt@kms_universal_plane@universal-plane-pipe-a-functional:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@pm_rpm@legacy-planes:
- shard-skl: PASS -> INCOMPLETE [fdo#105959] / [fdo#107807]
* igt@pm_rpm@universal-planes-dpms:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840] +1
* igt@pm_rps@waitboost:
- {shard-iclb}: NOTRUN -> FAIL [fdo#102250] / [fdo#108059]
Possible fixes
* igt@gem_exec_nop@signal-all:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@basic-modeset-a:
- shard-apl: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS
Re: [Intel-gfx] [PATCH v5] drm/i915/gvt: Change KVMGT as self load module
Looks good to me. Thanks.
Reviewed-by: Yuan, Hang
> -Original Message-
> From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
> Sent: Thursday, December 6, 2018 4:03 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org; Yuan, Hang ;
> Alex Williamson
> Subject: [PATCH v5] drm/i915/gvt: Change KVMGT as self load module
>
> This trys to make 'kvmgt' module as self loadable instead of loading by
> i915/gvt device model. So hypervisor specific module could be stand-alone,
> e.g only after loading hypervisor specific module, GVT feature could be
> enabled via specific hypervisor interface, e.g VFIO/mdev.
>
> So this trys to use hypervisor module register/unregister interface for that.
> Hypervisor module needs to take care of module reference itself when
> working for hypervisor interface, e.g for VFIO/mdev, hypervisor module
> would reference counting mdev when open and release.
>
> This makes 'kvmgt' module really split from GVT device model. User needs to
> load 'kvmgt' to enable VFIO/mdev interface.
>
> v5:
> - put module reference in register error path
>
> v4:
> - fix checkpatch warning
>
> v3:
> - Fix module reference handling for device open and release. Unused
> mdev devices would be cleaned up in device unregister when module
> unload.
>
> v2:
> - Fix kvmgt order after i915 for built-in case
>
> Cc: "Yuan, Hang"
> Cc: Alex Williamson
> Signed-off-by: Zhenyu Wang
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/gvt/Makefile| 1 -
> drivers/gpu/drm/i915/gvt/gvt.c | 108 +++
> drivers/gpu/drm/i915/gvt/gvt.h | 6 +-
> drivers/gpu/drm/i915/gvt/hypercall.h | 7 +-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 21 +-
> drivers/gpu/drm/i915/gvt/mpt.h | 3 +
> drivers/gpu/drm/i915/intel_gvt.c | 9 ---
> 8 files changed, 73 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0ff878c994e2..ae0d975a6f34 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -195,3 +195,4 @@ endif
> i915-y += intel_lpe_audio.o
>
> obj-$(CONFIG_DRM_I915) += i915.o
> +obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile
> b/drivers/gpu/drm/i915/gvt/Makefile
> index b016dc753db9..271fb46d4dd0 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -7,4 +7,3 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
> trace_points.o firmware.o \
>
> ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR)
> i915-y += $(addprefix $(GVT_DIR)/,
> $(GVT_SOURCE))
> -obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index a5b760b7bc10..4e8947f33bd0 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -187,52 +187,6 @@ static const struct intel_gvt_ops intel_gvt_ops = {
> .write_protect_handler = intel_vgpu_page_track_handler, };
>
> -/**
> - * intel_gvt_init_host - Load MPT modules and detect if we're running in
> host
> - *
> - * This function is called at the driver loading stage. If failed to find a
> - * loadable MPT module or detect currently we're running in a VM, then
> GVT-g
> - * will be disabled
> - *
> - * Returns:
> - * Zero on success, negative error code if failed.
> - *
> - */
> -int intel_gvt_init_host(void)
> -{
> - if (intel_gvt_host.initialized)
> - return 0;
> -
> - /* Xen DOM U */
> - if (xen_domain() && !xen_initial_domain())
> - return -ENODEV;
> -
> - /* Try to load MPT modules for hypervisors */
> - if (xen_initial_domain()) {
> - /* In Xen dom0 */
> - intel_gvt_host.mpt = try_then_request_module(
> - symbol_get(xengt_mpt), "xengt");
> - intel_gvt_host.hypervisor_type =
> INTEL_GVT_HYPERVISOR_XEN;
> - } else {
> -#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
> - /* not in Xen. Try KVMGT */
> - intel_gvt_host.mpt = try_then_request_module(
> - symbol_get(kvmgt_mpt), "kvmgt");
> - intel_gvt_host.hypervisor_type =
> INTEL_GVT_HYPERVISOR_KVM;
> -#endif
> - }
> -
> - /* Fail to load MPT modules - bail out */
> - if (!intel_gvt_host.mpt)
> - return -EINVAL;
> -
> - gvt_dbg_core("Running with hypervisor %s in host mode\n",
> -
> supported_hypervisors[intel_gvt_host.hypervisor_type]);
> -
> - intel_gvt_host.initialized = true;
> - return 0;
> -}
> -
> static void init_device_info(struct intel_gvt *gvt) {
> struct intel_gvt_device_info *info = &gvt->device_info; @@ -316,7
> +270,6 @@ void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
> return;
>
> intel_gvt_destroy_idle_v
[Intel-gfx] [PATCH] drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
Fix the skip for kms_color/gamma subtest
Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
Test requirement: igt_pipe_obj_has_prop(&data->display.pipes[p],
IGT_CRTC_DEGAMMA_LUT_SIZE)
Subtest pipe-A-gamma: SKIP
Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
Test requirement: igt_pipe_obj_has_prop(&data->display.pipes[p],
IGT_CRTC_DEGAMMA_LUT_SIZE)
Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
Test requirement: igt_pipe_obj_has_prop(&data->display.pipes[p],
IGT_CRTC_DEGAMMA_LUT_SIZE)
Test requirement not met in function run_tests_for_pipe, file kms_color.c:847:
Test requirement: p < data->display.n_pipes
Test requirement not met in function run_tests_for_pipe, file kms_color.c:847:
Test requirement: p < data->display.n_pipes
Test requirement not met in function run_tests_for_pipe, file kms_color.c:847:
Test requirement: p < data->display.n_pipes
[Why]
degamma_lut_size assigned 0
[How]
degamma_lut_size should be 35
BSpec:18433
Testcase:igt/kms_color/pipe-A-gamma
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6350db5..a1e900b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -69,7 +69,7 @@
#define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
#define GLK_COLORS \
- .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 35, .gamma_lut_size = 1024 }
/* Keep in gen based order, and chronological order within a gen */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Skip the ERR_PTR error state
== Series Details == Series: series starting with [1/3] drm/i915: Skip the ERR_PTR error state URL : https://patchwork.freedesktop.org/series/53625/ State : success == Summary == CI Bug Log - changes from CI_DRM_5272 -> Patchwork_11031 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/53625/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_11031 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_ctx_create@basic-files: - fi-bsw-kefka: FAIL [fdo#108656] -> PASS [fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656 Participating hosts (48 -> 44) -- Additional (1): fi-skl-guc Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-apl-guc Build changes - * Linux: CI_DRM_5272 -> Patchwork_11031 CI_DRM_5272: 4bb8baa3a7b836ce18e1b27ba12bae2130ee38cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11031: e14c4601fdfcd633dea62087b23987e029194d1f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e14c4601fdfc drm/i915/execlists: Apply a full mb before execution for Braswell 26553eeb0969 drm/i915: Pipeline PDP updates for Braswell 47d5e8ffa422 drm/i915: Skip the ERR_PTR error state == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11031/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Skip the ERR_PTR error state
== Series Details ==
Series: series starting with [1/3] drm/i915: Skip the ERR_PTR error state
URL : https://patchwork.freedesktop.org/series/53625/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
47d5e8ffa422 drm/i915: Skip the ERR_PTR error state
26553eeb0969 drm/i915: Pipeline PDP updates for Braswell
e14c4601fdfc drm/i915/execlists: Apply a full mb before execution for Braswell
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into
context image vs execution")
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 987abd5c62f9
("drm/i915/execlists: Force write serialisation into context image vs
execution")'
#15:
References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into
context image vs execution")
-:37: WARNING:MEMORY_BARRIER: memory barrier without comment
#37: FILE: drivers/gpu/drm/i915/intel_lrc.c:388:
+ mb();
total: 1 errors, 2 warnings, 0 checks, 14 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Change KVMGT into self loadable module (rev3)
== Series Details ==
Series: Change KVMGT into self loadable module (rev3)
URL : https://patchwork.freedesktop.org/series/53379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272 -> Patchwork_11030
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53379/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_11030 that come from known issues:
### IGT changes ###
Issues hit
* {igt@runner@aborted}:
- {fi-icl-u3}:NOTRUN -> FAIL [fdo#108315]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: FAIL [fdo#108880] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108315]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
Participating hosts (48 -> 45)
--
Additional (1): fi-skl-guc
Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_5272 -> Patchwork_11030
CI_DRM_5272: 4bb8baa3a7b836ce18e1b27ba12bae2130ee38cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4743: edb2db2cf2b6665d7ba3fa9117263302f6307a4f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11030: 66ee14434e7534c0aa38e16f08a89d910461716d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
66ee14434e75 drm/i915/gvt: Change KVMGT as self load module
d5d9d337bd09 drm/i915/gvt: remove unused parameter for hypervisor's host_exit
call
e4458706d879 drm/i915/gvt: mandatory require hypervisor's host_init
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11030/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Hi Ville,
Thank you for the review.
On 05-12-18 22:25, Ville Syrjälä wrote:
On Wed, Dec 05, 2018 at 10:03:09PM +0100, Hans de Goede wrote:
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Signed-off-by: Hans de Goede
---
drivers/acpi/pmic/intel_pmic_chtwc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..d035541f0ed2 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "intel_pmic.h"
#define CHT_WC_V1P05A_CTRL 0x6e3b
@@ -231,6 +232,27 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
}
+static void intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ const u8 *data)
+{
+ u16 i2c_client_address, reg_address, address;
+ u32 value, mask;
+
+ i2c_client_address = get_unaligned_be16(data);
+ reg_address = get_unaligned_be16(data + 2);
+ value = get_unaligned_be32(data + 4);
+ mask= get_unaligned_be32(data + 8);
This doesn't match the docs:
Well I didn't have access to the docs, I just looked at the
data and interpreted that, the first byte being reserved
for future use tripped me up.
"Byte0 – PMIC Flag
Bits 7:0 = Reserved for future use
Byte2,1 – PMIC Slave Address
Bits 15:0 = Slave address for PMIC access
Each slave can address 256byte register space in general
Bytes 6,5,4,3 – DWORD 0
Bits 31:0 = PMIC Register Address
Bytes 10,9,8,7 – DWORD 1
Bits 31:0 = PMIC Register Data
Bytes 14,13,12,11 – DWORD 2
Bits 31:0 = PMIC Register DataMask"
Though I wouldn't be entirely surprised if the docs are simply
wrong.
I think the docs are probably right, of the 2 sequences I'm seeing
the OFF sequence has more 00 bytes, so the ON sequence is the most
interesting, this is:
00 6e 00 3c 00 00 00 01 00 00 00 01 00 00 00
With my (big endian) interpretation that gives:
PMIC Slave Address 00 6e
PMIC Register Address00 3c
PMIC Register Data 00 00 00 01
PMIC Register Mask 00 00 00 01
With the docs slightly shifted (little endian) interpretation that gives:
Reserverd00
PMIC Slave Address 00 6e
PMIC Register Address00 00 00 3c
PMIC Register Data 00 00 00 01
PMIC Register Mask 00 00 00 01
So the 2 interpretation agree for the data which I'm actually
seeing used and the docs interpretation actually consumes all bytes.
I'll prepare a v2 of this patch-set using the docs interpretation
of the bytes.
Regards,
Hans
+
+ if ((i2c_client_address & 0xff00) || (reg_address & 0xff00)) {
+ pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+ __func__, i2c_client_address, reg_address);
+ return;
+ }
+
+ address = (i2c_client_address << 8) | reg_address;
+ regmap_update_bits(regmap, address, mask, value);
+}
+
/*
* The thermal table and ops are empty, we do not support the Thermal opregion
* (DPTF) due to lacking documentation.
@@ -238,6 +260,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
.get_power = intel_cht_wc_pmic_get_power,
.update_power = intel_cht_wc_pmic_update_power,
+ .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
.power_table= power_table,
.power_table_count = ARRAY_SIZE(power_table),
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Skip the ERR_PTR error state
Although commit fb6f0b64e455 ("drm/i915: Prevent machine hang from
Broxton's vtd w/a and error capture") applied cleanly after a 24 month
hiatus, the code had moved on with new methods for peeking and fetching
the captured gpu info. Make sure we catch all uses of the stashed error
state and avoid dereferencing the error pointer.
Fixes: fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and
error capture")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 12 +---
drivers/gpu/drm/i915/i915_sysfs.c | 3 +++
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 38dcee1ca062..f8aa8586c9a6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -984,6 +984,9 @@ static int i915_gpu_info_open(struct inode *inode, struct
file *file)
intel_runtime_pm_get(i915);
gpu = i915_capture_gpu_state(i915);
intel_runtime_pm_put(i915);
+
+ if (IS_ERR(gpu))
+ return PTR_ERR(gpu);
if (!gpu)
return -ENOMEM;
@@ -1018,7 +1021,13 @@ i915_error_state_write(struct file *filp,
static int i915_error_state_open(struct inode *inode, struct file *file)
{
- file->private_data = i915_first_error_state(inode->i_private);
+ struct i915_gpu_state *error;
+
+ error = i915_first_error_state(inode->i_private);
+ if (IS_ERR(error))
+ return PTR_ERR(error);
+
+ file->private_data = error;
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 07465123c166..7ca6f3f31d41 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1907,6 +1907,11 @@ i915_capture_gpu_state(struct drm_i915_private *i915)
{
struct i915_gpu_state *error;
+ /* Check if GPU capture has been disabled */
+ error = READ_ONCE(i915->gpu_error.first_error);
+ if (IS_ERR(error))
+ return error;
+
error = kzalloc(sizeof(*error), GFP_ATOMIC);
if (!error)
return NULL;
@@ -1987,7 +1992,7 @@ i915_first_error_state(struct drm_i915_private *i915)
spin_lock_irq(&i915->gpu_error.lock);
error = i915->gpu_error.first_error;
- if (error)
+ if (!IS_ERR_OR_NULL(error))
i915_gpu_state_get(error);
spin_unlock_irq(&i915->gpu_error.lock);
@@ -2000,10 +2005,11 @@ void i915_reset_error_state(struct drm_i915_private
*i915)
spin_lock_irq(&i915->gpu_error.lock);
error = i915->gpu_error.first_error;
- i915->gpu_error.first_error = NULL;
+ if (!IS_ERR_OR_NULL(error)) /* once disabled, always disabled */
+ i915->gpu_error.first_error = NULL;
spin_unlock_irq(&i915->gpu_error.lock);
- if (!IS_ERR(error))
+ if (!IS_ERR_OR_NULL(error))
i915_gpu_state_put(error);
}
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 535caebd9813..370b7497e9df 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -521,6 +521,9 @@ static ssize_t error_state_read(struct file *filp, struct
kobject *kobj,
ssize_t ret;
gpu = i915_first_error_state(i915);
+ if (IS_ERR(gpu))
+ return PTR_ERR(gpu);
+
if (gpu) {
ret = i915_gpu_state_copy_to_buffer(gpu, buf, off, count);
i915_gpu_state_put(gpu);
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/execlists: Apply a full mb before execution for Braswell
Braswell is really picky about having our writes posted to memory before
we execute or else the GPU may see stale values. A wmb() is insufficient
as it only ensures the writes are visible to other cores, we need a full
mb() to ensure the writes are in memory and visible to the GPU.
The most frequent failure in flushing before execution is that we see
stale PTE values and execute the wrong pages.
References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into
context image vs execution")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index de1e9dc6aec0..e6a86fa4502d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -379,8 +379,13 @@ static u64 execlists_update_context(struct i915_request
*rq)
* may not be visible to the HW prior to the completion of the UC
* register write and that we may begin execution from the context
* before its image is complete leading to invalid PD chasing.
+*
+* Furthermore, Braswell, at least, wants a full mb to be sure that
+* the writes are coherent in memory (visible to the GPU) prior to
+* execution, and not just visible to other CPUs (as is the result of
+* wmb).
*/
- wmb();
+ mb();
return ce->lrc_desc;
}
--
2.20.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Pipeline PDP updates for Braswell
Currently we face a severe problem on Braswell that manifests as invalid
ppGTT accesses. The code tries to maintain the PDP (page directory
pointers) inside the context in two ways, direct write into the context
and a pipelined LRI update. The direct write into the context is
fundamentally racy as it is unserialised with any access (read or write)
the GPU is doing. By asserting that Braswell is not used with vGPU
(currently an unsupported platform) we can eliminate the dangerous
direct write into the context image and solely use the pipelined update.
However, the LRI of the PDP fouls up the GPU, causing it to freeze and
take out the machine with "forcewake ack timeouts". This seems possible
to workaround by preventing the GPU from sleeping (via means of
disabling the power-state management interface, i.e. forcing each ring
to remain awake) around the update.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
References: https://bugs.freedesktop.org/show_bug.cgi?id=108714
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 -
drivers/gpu/drm/i915/i915_request.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c| 143
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +-
4 files changed, 74 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index add1fe7aeb93..62bde517d383 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1423,8 +1423,6 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space
*vm,
gen8_initialize_pd(vm, pd);
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
GEM_BUG_ON(pdp->used_pdpes > i915_pdpes_per_pdp(vm));
-
- mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
}
ret = gen8_ppgtt_alloc_pd(vm, pd, start, length);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ca95ab2f4cfa..8ab8e8e6a086 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -719,11 +719,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
- /* Unconditionally invalidate GPU caches and TLBs. */
- ret = engine->emit_flush(rq, EMIT_INVALIDATE);
- if (ret)
- goto err_unwind;
-
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d7fa301b5ec7..de1e9dc6aec0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -363,31 +363,12 @@ execlists_context_schedule_out(struct i915_request *rq,
unsigned long status)
trace_i915_request_out(rq);
}
-static void
-execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
-{
- ASSIGN_CTX_PDP(ppgtt, reg_state, 3);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 2);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 1);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 0);
-}
-
static u64 execlists_update_context(struct i915_request *rq)
{
- struct i915_hw_ppgtt *ppgtt = rq->gem_context->ppgtt;
struct intel_context *ce = rq->hw_context;
- u32 *reg_state = ce->lrc_reg_state;
-
- reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring, rq->tail);
- /*
-* True 32b PPGTT with dynamic page allocation: update PDP
-* registers and point the unallocated PDPs to scratch page.
-* PML4 is allocated during ppgtt init, so this is not needed
-* in 48-bit mode.
-*/
- if (!i915_vm_is_48bit(&ppgtt->vm))
- execlists_update_context_pdps(ppgtt, reg_state);
+ ce->lrc_reg_state[CTX_RING_TAIL + 1] =
+ intel_ring_set_tail(rq->ring, rq->tail);
/*
* Make sure the context image is complete before we submit it to HW.
@@ -1242,29 +1223,86 @@ execlists_context_pin(struct intel_engine_cs *engine,
return __execlists_context_pin(engine, ctx, ce);
}
+static int emit_pdps(struct i915_request *rq)
+{
+ const struct intel_engine_cs * const engine = rq->engine;
+ struct i915_hw_ppgtt * const ppgtt = rq->gem_context->ppgtt;
+ int err, i;
+ u32 *cs;
+
+ /*
+* Beware ye of the dragons, this sequence is magic!
+*
+* Small changes to this sequence can cause anything from
+* GPU hangs to forcewake errors and machine lockups!
+*/
+
+ err = engine->emit_flush(rq, EMIT_FLUSH);
+ if (err)
+ return err;
+
+ err = engine->emit_flush(rq, EMIT_INVALIDATE);
+ if (err)
+ return err;
+
+ cs = intel_ring_begin(rq, 4 * GEN8_3LVL_PDPES + 2);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ /* Ensur
Re: [Intel-gfx] [PATCH v4 0/4] HDCP1.4 Fixes - II
On Wed, Dec 05, 2018 at 05:14:39PM +0530, Ramalingam C wrote: > Couple of more HDCP1.4 fixes on > - Key load process for CFL > - Encryption status change time > - debug log addition > - active platform coverage > > v1 and v2 went into old series https://patchwork.freedesktop.org/series/38978/ > as v8 and v9, due to the same series title. Now changed the title. > > v3-->v4: > Respining with minor fix on 2nd patch [Ville] All applied, thanks for patches&organizing the review too. -Daniel > > Thanks Sean Paul for the reviews. > > Ramalingam C (4): > drm/i915: Fix GEN9 HDCP1.4 key load process > drm/i915: Fix platform coverage for HDCP1.4 > drm/i915: debug log for REPLY_ACK missing > drm/i915: Increase timeout for Encrypt status change > > drivers/gpu/drm/i915/intel_dp.c | 7 ++- > drivers/gpu/drm/i915/intel_hdcp.c | 16 +--- > 2 files changed, 15 insertions(+), 8 deletions(-) > > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
