[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 --- Comment #4 from Evan Goers --- I am using an RX580 and also have this issue. Forcing OpenGL 4.2(4.3 and above causes the issue) with the mesa environment variable allows the game to run without artifacts but some shaders do not work, such as ambient occlusion. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 = >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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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, _iter);
for_each_intel_connector_iter(connector, _iter) {
+ hdcp = >hdcp;
+
if (connector->modeset_retry_work.func)
cancel_work_sync(>modeset_retry_work);
- if (connector->hdcp.shim) {
- cancel_delayed_work_sync(>hdcp.check_work);
- cancel_work_sync(>hdcp.prop_work);
+ if (hdcp->shim) {
+ cancel_delayed_work_sync(>check_work);
+ cancel_work_sync(>prop_work);
+ if (hdcp->hdcp2_supported)
+
cancel_delayed_work_sync(>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(_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 = >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(>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
[Bug 201815] Mouse Pointer Disappears when touching top of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=201815 siyia (eutychio...@gmail.com) changed: What|Removed |Added Kernel Version|4.20rc3-rc4 |4.20rc3-rc5 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #26 from Shmerl --- And I don't see ERROR* REG_WAIT anymore. I'm using latest Vega firmware. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #25 from Shmerl --- Just built 4.20-rc5+. This is indeed fixed, and KWin Wayland session is finally working with DisplayPort 1.2 enabled! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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(>mutex);
+ if (!comp->ops || !comp->dev) {
+ mutex_unlock(>mutex);
+ return false;
+ }
+ mutex_unlock(>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 = >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, );
+
+ 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 = >hdcp.mei_data;
[Bug 201815] Mouse Pointer Disappears when touching top of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=201815 --- Comment #7 from siyia (eutychio...@gmail.com) --- A workaround that works is to enable software cursor in Xorg, i edited 10-amdgpu.conf and 10-radeon.conf and added: Option "SWCursor" "True" -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 = >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(>mutex);
+ if (!comp->ops || !comp->dev) {
+ mutex_unlock(>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 after successfully
[Bug 201815] Mouse Pointer Disappears when touching top of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=201815 --- Comment #6 from siyia (eutychio...@gmail.com) --- that was an issue with the kernel fedora mainline repo, kernel 4.20rc5 boots on my laptop on archlinux, but the mouse pointer issue remains -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108892] kernel BUG at kernel/time/timer.c:1137 in drm_sched_job_finish [gpu_sched]
https://bugs.freedesktop.org/show_bug.cgi?id=108892 --- Comment #6 from Zheng Luo --- (In reply to sunnanyong from comment #5) > Hi brother , does the kernel upgrade work？ I switched between 4.19 and 4.20rc4/5 these days. However with none of the two kernels I can reproduce this bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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, _dp_hdcp_shim);
+ int ret = intel_hdcp_init(intel_connector, _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,
+
RE: [PATCH 2/2] drm/sched: Rework HW fence processing.
> -Original Message-
> From: dri-devel On Behalf Of
> Andrey Grodzovsky
> Sent: Friday, December 07, 2018 1:41 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ckoenig.leichtzumer...@gmail.com; e...@anholt.net;
> etna...@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH 2/2] drm/sched: Rework HW fence processing.
>
> Expedite job deletion from ring mirror list to the HW fence signal callback
> instead from finish_work, together with waiting for all such fences to signal
> in
> drm_sched_stop we garantee that already signaled job will not be processed
> twice.
> Remove the sched finish fence callback and just submit finish_work directly
> from the HW fence callback.
>
> Suggested-by: Christian Koenig
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/scheduler/sched_fence.c | 4 +++-
> drivers/gpu/drm/scheduler/sched_main.c | 39 --
> ---
> include/drm/gpu_scheduler.h | 10 +++--
> 3 files changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
> b/drivers/gpu/drm/scheduler/sched_fence.c
> index d8d2dff..e62c239 100644
> --- a/drivers/gpu/drm/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> @@ -151,7 +151,8 @@ struct drm_sched_fence
> *to_drm_sched_fence(struct dma_fence *f)
> EXPORT_SYMBOL(to_drm_sched_fence);
>
> struct drm_sched_fence *drm_sched_fence_create(struct
> drm_sched_entity *entity,
> -void *owner)
> +void *owner,
> +struct drm_sched_job *s_job)
> {
> struct drm_sched_fence *fence = NULL;
> unsigned seq;
> @@ -163,6 +164,7 @@ struct drm_sched_fence
> *drm_sched_fence_create(struct drm_sched_entity *entity,
> fence->owner = owner;
> fence->sched = entity->rq->sched;
> spin_lock_init(>lock);
> + fence->s_job = s_job;
>
> seq = atomic_inc_return(>fence_seq);
> dma_fence_init(>scheduled,
> _sched_fence_ops_scheduled, diff --git
> a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 8fb7f86..2860037 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -284,31 +284,17 @@ static void drm_sched_job_finish(struct
> work_struct *work)
> cancel_delayed_work_sync(>work_tdr);
>
> spin_lock_irqsave(>job_list_lock, flags);
> - /* remove job from ring_mirror_list */
> - list_del_init(_job->node);
> - /* queue TDR for next job */
> drm_sched_start_timeout(sched);
> spin_unlock_irqrestore(>job_list_lock, flags);
>
> sched->ops->free_job(s_job);
> }
>
> -static void drm_sched_job_finish_cb(struct dma_fence *f,
> - struct dma_fence_cb *cb)
> -{
> - struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
> - finish_cb);
> - schedule_work(>finish_work);
> -}
> -
> static void drm_sched_job_begin(struct drm_sched_job *s_job) {
> struct drm_gpu_scheduler *sched = s_job->sched;
> unsigned long flags;
>
> - dma_fence_add_callback(_job->s_fence->finished, _job-
> >finish_cb,
> -drm_sched_job_finish_cb);
> -
> spin_lock_irqsave(>job_list_lock, flags);
> list_add_tail(_job->node, >ring_mirror_list);
> drm_sched_start_timeout(sched);
> @@ -418,13 +404,17 @@ void drm_sched_start(struct drm_gpu_scheduler
> *sched, bool unpark_only) {
> struct drm_sched_job *s_job, *tmp;
> bool found_guilty = false;
> - unsigned long flags;
> int r;
>
> if (unpark_only)
> goto unpark;
>
> - spin_lock_irqsave(>job_list_lock, flags);
> + /*
> + * Locking the list is not required here as the sched thread is parked
> + * so no new jobs are being pushed in to HW and in drm_sched_stop
> we
> + * flushed any in flight jobs who didn't signal yet. Also concurrent
> + * GPU recovers can't run in parallel.
> + */
> list_for_each_entry_safe(s_job, tmp, >ring_mirror_list,
> node) {
> struct drm_sched_fence *s_fence = s_job->s_fence;
> struct dma_fence *fence;
> @@ -453,7 +443,6 @@ void drm_sched_start(struct drm_gpu_scheduler
> *sched, bool unpark_only)
> }
>
> drm_sched_start_timeout(sched);
> - spin_unlock_irqrestore(>job_list_lock, flags);
>
> unpark:
> kthread_unpark(sched->thread);
> @@ -505,7 +494,7 @@ int drm_sched_job_init(struct drm_sched_job *job,
> job->sched = sched;
> job->entity = entity;
> job->s_priority = entity->rq - sched->sched_rq;
> - job->s_fence = drm_sched_fence_create(entity, owner);
> + job->s_fence = drm_sched_fence_create(entity, owner, job);
> if (!job->s_fence)
> return -ENOMEM;
> job->id =
[PATCH v4 5/5] drm/msm: subclass work object for vblank events
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this redundant list
and its protection mechanism, if we subclass the
work object to encapsulate vblank event parameters.
changes in v2:
- subclass optimization on system wq (Sean Paul)
changes in v3:
- none
changes in v4:
- move flush_workqueue before irq uninstall
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 71 ++-
drivers/gpu/drm/msm/msm_drv.h | 7 -
2 files changed, 22 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 1e9fec1..5f61fc4 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -206,61 +206,44 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
-struct vblank_event {
- struct list_head node;
+struct msm_vblank_work {
+ struct work_struct work;
int crtc_id;
bool enable;
+ struct msm_drm_private *priv;
};
static void vblank_ctrl_worker(struct work_struct *work)
{
- struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
- struct msm_vblank_ctrl, work);
- struct msm_drm_private *priv = container_of(vbl_ctrl,
- struct msm_drm_private, vblank_ctrl);
+ struct msm_vblank_work *vbl_work = container_of(work,
+ struct msm_vblank_work, work);
+ struct msm_drm_private *priv = vbl_work->priv;
struct msm_kms *kms = priv->kms;
- struct vblank_event *vbl_ev, *tmp;
- unsigned long flags;
-
- spin_lock_irqsave(_ctrl->lock, flags);
- list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
- list_del(_ev->node);
- spin_unlock_irqrestore(_ctrl->lock, flags);
-
- if (vbl_ev->enable)
- kms->funcs->enable_vblank(kms,
- priv->crtcs[vbl_ev->crtc_id]);
- else
- kms->funcs->disable_vblank(kms,
- priv->crtcs[vbl_ev->crtc_id]);
-
- kfree(vbl_ev);
- spin_lock_irqsave(_ctrl->lock, flags);
- }
+ if (vbl_work->enable)
+ kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+ else
+ kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
- spin_unlock_irqrestore(_ctrl->lock, flags);
+ kfree(vbl_work);
}
static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
int crtc_id, bool enable)
{
- struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
- struct vblank_event *vbl_ev;
- unsigned long flags;
+ struct msm_vblank_work *vbl_work;
- vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
- if (!vbl_ev)
+ vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
+ if (!vbl_work)
return -ENOMEM;
- vbl_ev->crtc_id = crtc_id;
- vbl_ev->enable = enable;
+ INIT_WORK(_work->work, vblank_ctrl_worker);
- spin_lock_irqsave(_ctrl->lock, flags);
- list_add_tail(_ev->node, _ctrl->event_list);
- spin_unlock_irqrestore(_ctrl->lock, flags);
+ vbl_work->crtc_id = crtc_id;
+ vbl_work->enable = enable;
+ vbl_work->priv = priv;
- queue_work(priv->wq, _ctrl->work);
+ queue_work(priv->wq, _work->work);
return 0;
}
@@ -272,19 +255,15 @@ static int msm_drm_uninit(struct device *dev)
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm_mdss *mdss = priv->mdss;
- struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
- struct vblank_event *vbl_ev, *tmp;
int i;
/* We must cancel and cleanup any pending vblank enable/disable
* work before drm_irq_uninstall() to avoid work re-enabling an
* irq after uninstall has disabled it.
*/
- flush_work(_ctrl->work);
- list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
- list_del(_ev->node);
- kfree(vbl_ev);
- }
+
+ flush_workqueue(priv->wq);
+ destroy_workqueue(priv->wq);
/* clean up event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
@@ -313,9 +292,6 @@ static int msm_drm_uninit(struct device *dev)
drm_irq_uninstall(ddev);
pm_runtime_put_sync(dev);
- flush_workqueue(priv->wq);
- destroy_workqueue(priv->wq);
-
if (kms && kms->funcs)
kms->funcs->destroy(kms);
@@ -472,9 +448,6 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
priv->wq = alloc_ordered_workqueue("msm", 0);
[PATCH v4 3/5] drm/msm/dpu: use msm wq for idle power collapse
msm is using msm wq for dispatching commit and vblank
events. Switch idle power collapse feature also to use
msm wq to handle delayed work handlers so that
msm can get rid of redundant display threads.
changes in v2:
- patch introduced in v2
changes in v3:
- none
changes in v4:
- use msm wq for delayed works
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 36158b7..3d1e1e4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -205,7 +205,7 @@ struct dpu_encoder_virt {
bool idle_pc_supported;
struct mutex rc_lock;
enum dpu_enc_rc_states rc_state;
- struct kthread_delayed_work delayed_off_work;
+ struct delayed_work delayed_off_work;
struct kthread_work vsync_event_work;
struct msm_display_topology topology;
bool mode_set_complete;
@@ -742,7 +742,6 @@ static int dpu_encoder_resource_control(struct drm_encoder
*drm_enc,
{
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
- struct msm_drm_thread *disp_thread;
bool is_vid_mode = false;
if (!drm_enc || !drm_enc->dev || !drm_enc->dev->dev_private ||
@@ -755,12 +754,6 @@ static int dpu_encoder_resource_control(struct drm_encoder
*drm_enc,
is_vid_mode = dpu_enc->disp_info.capabilities &
MSM_DISPLAY_CAP_VID_MODE;
- if (drm_enc->crtc->index >= ARRAY_SIZE(priv->disp_thread)) {
- DPU_ERROR("invalid crtc index\n");
- return -EINVAL;
- }
- disp_thread = >disp_thread[drm_enc->crtc->index];
-
/*
* when idle_pc is not supported, process only KICKOFF, STOP and MODESET
* events and return early for other events (ie wb display).
@@ -777,8 +770,7 @@ static int dpu_encoder_resource_control(struct drm_encoder
*drm_enc,
switch (sw_event) {
case DPU_ENC_RC_EVENT_KICKOFF:
/* cancel delayed off work, if any */
- if (kthread_cancel_delayed_work_sync(
- _enc->delayed_off_work))
+ if (cancel_delayed_work_sync(_enc->delayed_off_work))
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work cancelled\n",
sw_event);
@@ -837,10 +829,8 @@ static int dpu_encoder_resource_control(struct drm_encoder
*drm_enc,
return 0;
}
- kthread_queue_delayed_work(
- _thread->worker,
- _enc->delayed_off_work,
- msecs_to_jiffies(dpu_enc->idle_timeout));
+ queue_delayed_work(priv->wq, _enc->delayed_off_work,
+ msecs_to_jiffies(dpu_enc->idle_timeout));
trace_dpu_enc_rc(DRMID(drm_enc), sw_event,
dpu_enc->idle_pc_supported, dpu_enc->rc_state,
@@ -849,8 +839,7 @@ static int dpu_encoder_resource_control(struct drm_encoder
*drm_enc,
case DPU_ENC_RC_EVENT_PRE_STOP:
/* cancel delayed off work, if any */
- if (kthread_cancel_delayed_work_sync(
- _enc->delayed_off_work))
+ if (cancel_delayed_work_sync(_enc->delayed_off_work))
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work cancelled\n",
sw_event);
@@ -1368,7 +1357,7 @@ static void dpu_encoder_frame_done_callback(
}
}
-static void dpu_encoder_off_work(struct kthread_work *work)
+static void dpu_encoder_off_work(struct work_struct *work)
{
struct dpu_encoder_virt *dpu_enc = container_of(work,
struct dpu_encoder_virt, delayed_off_work.work);
@@ -2193,7 +2182,7 @@ int dpu_encoder_setup(struct drm_device *dev, struct
drm_encoder *enc,
mutex_init(_enc->rc_lock);
- kthread_init_delayed_work(_enc->delayed_off_work,
+ INIT_DELAYED_WORK(_enc->delayed_off_work,
dpu_encoder_off_work);
dpu_enc->idle_timeout = IDLE_TIMEOUT;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/msm/dpu: use kthread_destroy_worker to release msm workers
use kthread_destroy_worker to destroy workers and
release their associated kthreads.
changes in v3:
- introduced in the series
changes in v4:
- none
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7d168cf..956f0599 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -290,14 +290,12 @@ static int msm_drm_uninit(struct device *dev)
/* clean up display commit/event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
if (priv->disp_thread[i].thread) {
- kthread_flush_worker(>disp_thread[i].worker);
- kthread_stop(priv->disp_thread[i].thread);
+ kthread_destroy_worker(>disp_thread[i].worker);
priv->disp_thread[i].thread = NULL;
}
if (priv->event_thread[i].thread) {
- kthread_flush_worker(>event_thread[i].worker);
- kthread_stop(priv->event_thread[i].thread);
+ kthread_destroy_worker(>event_thread[i].worker);
priv->event_thread[i].thread = NULL;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] drm/msm: clean up display thread
Since there are no clients using these threads,
cleaning it up.
changes in v2:
- switch all the dependent clients to use system wq
before removing the disp_threads (Sean Paul)
changes in v3:
- none
changes in v4:
- none
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 35 +--
drivers/gpu/drm/msm/msm_drv.h | 1 -
2 files changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 37740b8..1e9fec1 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -286,13 +286,8 @@ static int msm_drm_uninit(struct device *dev)
kfree(vbl_ev);
}
- /* clean up display commit/event worker threads */
+ /* clean up event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
- if (priv->disp_thread[i].thread) {
- kthread_destroy_worker(>disp_thread[i].worker);
- priv->disp_thread[i].thread = NULL;
- }
-
if (priv->event_thread[i].thread) {
kthread_destroy_worker(>event_thread[i].worker);
priv->event_thread[i].thread = NULL;
@@ -545,27 +540,6 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
*/
param.sched_priority = 16;
for (i = 0; i < priv->num_crtcs; i++) {
-
- /* initialize display thread */
- priv->disp_thread[i].crtc_id = priv->crtcs[i]->base.id;
- kthread_init_worker(>disp_thread[i].worker);
- priv->disp_thread[i].dev = ddev;
- priv->disp_thread[i].thread =
- kthread_run(kthread_worker_fn,
- >disp_thread[i].worker,
- "crtc_commit:%d", priv->disp_thread[i].crtc_id);
- if (IS_ERR(priv->disp_thread[i].thread)) {
- DRM_DEV_ERROR(dev, "failed to create crtc_commit
kthread\n");
- priv->disp_thread[i].thread = NULL;
- goto err_msm_uninit;
- }
-
- ret = sched_setscheduler(priv->disp_thread[i].thread,
-SCHED_FIFO, );
- if (ret)
- dev_warn(dev, "disp_thread set priority failed: %d\n",
-ret);
-
/* initialize event thread */
priv->event_thread[i].crtc_id = priv->crtcs[i]->base.id;
kthread_init_worker(>event_thread[i].worker);
@@ -580,13 +554,6 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
goto err_msm_uninit;
}
- /**
-* event thread should also run at same priority as disp_thread
-* because it is handling frame_done events. A lower priority
-* event thread and higher priority disp_thread can causes
-* frame_pending counters beyond 2. This can lead to commit
-* failure at crtc commit level.
-*/
ret = sched_setscheduler(priv->event_thread[i].thread,
SCHED_FIFO, );
if (ret)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0298fa7..0307543 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -197,7 +197,6 @@ struct msm_drm_private {
unsigned int num_crtcs;
struct drm_crtc *crtcs[MAX_CRTCS];
- struct msm_drm_thread disp_thread[MAX_CRTCS];
struct msm_drm_thread event_thread[MAX_CRTCS];
unsigned int num_encoders;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/5] drm/msm/dpu: use msm wq for vblank events
DPU was using one thread per display to dispatch async commits and
vblank requests. Since clean up already happened in msm to use the
common thread for all the display commits, display threads are only
used to cater vblank requests. Since a single thread is sufficient
to do the job without any performance hits, use msm workqueue
to queue requests. A separate patch is submitted later in this
series to remove the display threads altogether.
changes in v2:
- switch to system wq before removing disp threads (Sean Paul)
changes in v3:
- none
changes in v4:
- use msm wq for vblank events
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 9 -
drivers/gpu/drm/msm/msm_drv.h | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 956f0599..37740b8 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -212,7 +212,7 @@ struct vblank_event {
bool enable;
};
-static void vblank_ctrl_worker(struct kthread_work *work)
+static void vblank_ctrl_worker(struct work_struct *work)
{
struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
struct msm_vblank_ctrl, work);
@@ -260,8 +260,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private
*priv,
list_add_tail(_ev->node, _ctrl->event_list);
spin_unlock_irqrestore(_ctrl->lock, flags);
- kthread_queue_work(>disp_thread[crtc_id].worker,
- _ctrl->work);
+ queue_work(priv->wq, _ctrl->work);
return 0;
}
@@ -281,7 +280,7 @@ static int msm_drm_uninit(struct device *dev)
* work before drm_irq_uninstall() to avoid work re-enabling an
* irq after uninstall has disabled it.
*/
- kthread_flush_work(_ctrl->work);
+ flush_work(_ctrl->work);
list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
list_del(_ev->node);
kfree(vbl_ev);
@@ -479,7 +478,7 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
INIT_LIST_HEAD(>inactive_list);
INIT_LIST_HEAD(>vblank_ctrl.event_list);
- kthread_init_work(>vblank_ctrl.work, vblank_ctrl_worker);
+ INIT_WORK(>vblank_ctrl.work, vblank_ctrl_worker);
spin_lock_init(>vblank_ctrl.lock);
drm_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 71a03ce..0298fa7 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -78,7 +78,7 @@ enum msm_mdp_plane_property {
};
struct msm_vblank_ctrl {
- struct kthread_work work;
+ struct work_struct work;
struct list_head event_list;
spinlock_t lock;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm tree with the drm-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
between commit:
c679fd55 ("drm/amd/display: Fix 6x4K displays light-up on Vega20 (v2)")
from the drm-fixes tree and commit:
24f7dd7ea98d ("drm/amd/display: move pplib/smu notification to dccg block")
from the drm tree.
I fixed it up (I am not sure how to fix this up, so I just dropped the
drm-fixes change) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpXr1Uw8L8GU.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2 5/5] drm/msm: subclass work object for vblank events
On 2018-12-06 10:56, Jeykumar Sankaran wrote:
On 2018-11-07 07:55, Sean Paul wrote:
On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this redundant list
and its protection mechanism, if we subclass the
work object to encapsulate vblank event parameters.
changes in v2:
- subclass optimization on system wq (Sean Paul)
I wouldn't do it like this, tbh. One problem is that you've lost your
flush() on
unbind, so there's no way to know if you have workers in the wild
waiting
to
enable/disable vblank.
I believe I didnt respond to this quesition of yours. This patch is
removing the flush on the work. But flush_workqueue before destroying
the WQ
will make sure all the queued work jobs are run to completion.
To honor the comment, I will fix the patch to move the flush/destroy
wq before the
irq_unininstall.
Above is possible if we use priv->wq for vblank requests. Posted v4 with
the above fixes.
Thanks,
Jeykumar S.
Another issues is that AFAICT, we don't need a queue of
enables/disables,
but
rather just the last requested state (ie: should we be on or off). So
things
don't need to be this complicated (and we're possibly thrashing vblank
on/off
for no reason).
I'm still of the mind that you should just make this synchronous and
be
done
with the threads (especially since we're still uncovering/introducing
races!).
Sean
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 67
+--
drivers/gpu/drm/msm/msm_drv.h | 7 -
2 files changed, 20 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c
b/drivers/gpu/drm/msm/msm_drv.c
index 6d6c73b..8da5be2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -203,61 +203,44 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
-struct vblank_event {
- struct list_head node;
+struct msm_vblank_work {
+ struct work_struct work;
int crtc_id;
bool enable;
+ struct msm_drm_private *priv;
};
static void vblank_ctrl_worker(struct work_struct *work)
{
- struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
- struct msm_vblank_ctrl,
work);
- struct msm_drm_private *priv = container_of(vbl_ctrl,
- struct msm_drm_private,
vblank_ctrl);
+ struct msm_vblank_work *vbl_work = container_of(work,
+ struct msm_vblank_work,
work);
+ struct msm_drm_private *priv = vbl_work->priv;
struct msm_kms *kms = priv->kms;
- struct vblank_event *vbl_ev, *tmp;
- unsigned long flags;
-
- spin_lock_irqsave(_ctrl->lock, flags);
- list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node)
{
- list_del(_ev->node);
- spin_unlock_irqrestore(_ctrl->lock, flags);
-
- if (vbl_ev->enable)
- kms->funcs->enable_vblank(kms,
-
priv->crtcs[vbl_ev->crtc_id]);
- else
- kms->funcs->disable_vblank(kms,
-
priv->crtcs[vbl_ev->crtc_id]);
- kfree(vbl_ev);
-
- spin_lock_irqsave(_ctrl->lock, flags);
- }
+ if (vbl_work->enable)
+ kms->funcs->enable_vblank(kms,
priv->crtcs[vbl_work->crtc_id]);
+ else
+ kms->funcs->disable_vblank(kms,
priv->crtcs[vbl_work->crtc_id]);
- spin_unlock_irqrestore(_ctrl->lock, flags);
+ kfree(vbl_work);
}
static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
int crtc_id, bool enable)
{
- struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
- struct vblank_event *vbl_ev;
- unsigned long flags;
+ struct msm_vblank_work *vbl_work;
- vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
- if (!vbl_ev)
+ vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
+ if (!vbl_work)
return -ENOMEM;
- vbl_ev->crtc_id = crtc_id;
- vbl_ev->enable = enable;
+ INIT_WORK(_work->work, vblank_ctrl_worker);
- spin_lock_irqsave(_ctrl->lock, flags);
- list_add_tail(_ev->node, _ctrl->event_list);
- spin_unlock_irqrestore(_ctrl->lock, flags);
+ vbl_work->crtc_id = crtc_id;
+ vbl_work->enable = enable;
+ vbl_work->priv = priv;
- schedule_work(_ctrl->work);
+ schedule_work(_work->work);
return 0;
}
@@ -269,14 +252,13 @@ static int msm_drm_uninit(struct device *dev)
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm_mdss *mdss = priv->mdss;
- struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
- struct vblank_event *vbl_ev, *tmp;
int i;
linux-next: manual merge of the drm tree with the drm-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
between commit:
49f1c44b581b ("rm/amd/display: Fix unintialized max_bpc state values")
from the drm-fixes tree and commits:
c1ee92f94ce3 ("drm/amd: Add abm level drm property")
bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR properties")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5a6edf65c9ea,32e791d9b9a8..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@@ -3063,8 -3234,7 +3235,8 @@@ amdgpu_dm_connector_atomic_duplicate_st
__drm_atomic_helper_connector_duplicate_state(connector,
_state->base);
new_state->freesync_capable = state->freesync_capable;
- new_state->freesync_enable = state->freesync_enable;
+ new_state->max_bpc = state->max_bpc;
+ new_state->abm_level = state->abm_level;
return _state->base;
}
pgp4ai2jQMX8m.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg*
On Fri, Nov 30, 2018 at 10:46:04AM +0100, Daniel Vetter wrote: > > Being able to dip into CMA and maybe iommu coalescing if we want to > > get fancy is indeed the only reason for this API. If we just wanted > > to map pages we could already do that now with just a little bit > > of boilerplate code (and quite a few drivers do - just adding this > > new API will remove tons of code). > > Sounds like the future is very bright indeed \o/ So, I spent some time with this and instead of a new API I think it makes sure we have DMA_ATTR_NON_CONSISTENT consistently available and with well defined semantics, that is virt_to_page on the return value works, it is contiguos and we can use dma_sync_single_for_cpu and dma_sync_single_for_device for ownership tranfers. Can you graphics folks check if this: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-noncoherent-allocator is something to work with? Especially to get rid of the horrible dma_get_sgtable hacks? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 4.20-rc6
Hi Linus, This is the regular fixes pull. I'm off on holidays for a few days but will likely still have access to stuff, just not doing much else, I should be back for 2 days at the end of next week to line up more fixes, and likely send you the -next pull request before going on holidays until after boxing day. There's a bit more in here than I'd like, and I'm hoping things calm down when I'm out. msm: a bunch of display fixes for the new DPU, and a couple of command submission fixes omap: some DSI fixes ast: driver unload crash fix core: fix the lease uevent so userspace can distinguish it amd: fix a bpc regression, lru handling regression, fixed firmware support for new GPUs, power management fixes for vega20. Thanks, Dave. drm-fixes-2018-12-07: ast, msm display fixes, amdgpu fixes, lease fix, omap fixes The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7: Linux 4.20-rc5 (2018-12-02 15:07:55 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-12-07 for you to fetch changes up to e594a5e349ddbfdaca1951bb3f8d72f3f1660d73: drm/ast: Fix connector leak during driver unload (2018-12-06 14:12:02 +1000) ast, msm display fixes, amdgpu fixes, lease fix, omap fixes Abhinav Kumar (1): drm/msm/dsi: configure VCO rate for 10nm PLL driver Alex Deucher (3): drm/amdgpu: add VCN JPEG support amdgpu_ctx_num_entities drm/amdgpu/gmc8: update MC firmware for polaris drm/amdgpu/gmc8: always load MC firmware in the driver Christian König (2): drm/ttm: fix LRU handling in ttm_buffer_object_transfer drm/amdgpu: wait for IB test on first device open Dan Carpenter (1): drm/msm/gpu: Fix a couple memory leaks in debugfs Daniel Vetter (1): drm/lease: Send a distinct uevent Dave Airlie (3): Merge tag 'msm-fixes-2018-12-04' of https://gitlab.freedesktop.org/seanpaul/dpu-staging into drm-fixes Merge branch 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2018-12-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Evan Quan (3): drm/amd/powerplay: support new pptable upload on Vega20 drm/amd/powerplay: issue pre-display settings for display change event drm/amd/powerplay: support SoftMin/Max setting for some specific DPM James Zhu (1): drm/amdgpu/vcn: Update vcn.cur_state during suspend Jayant Shekhar (1): drm/msm/dpu: Ignore alpha for XBGR format Jeykumar Sankaran (1): drm/msm: validate display and event threads Jordan Crouse (1): drm/msm/gpu: Don't map command buffers with nr_relocs equal to 0 Junwei Zhang (1): drm/amdgpu: update mc firmware image for polaris12 variants Nicholas Kazlauskas (2): drm/amd/display: Fix unintialized max_bpc state values drm/amd/display: Fix overflow/truncation from strncpy. Rob Clark (1): drm/msm: fix handling of cmdstream offset Robert Foss (1): drm/msm: Move fence put to where failure occurs Roman Li (1): drm/amd/display: Fix 6x4K displays light-up on Vega20 (v2) Sam Bobroff (1): drm/ast: Fix connector leak during driver unload Sandeep Panda (1): drm/bridge: fix AUX_CMD_SEND bit value for ti, sn65dsi86 bridge Sean Paul (2): drm/msm: Grab a vblank reference when waiting for commit_done drm/msm: dpu: Don't set legacy plane->crtc pointer Sebastian Reichel (2): drm/omap: populate DSI platform bus earlier drm/omap: fix incorrect union usage Sharat Masetty (2): drm/msm: Check if target supports crash dump capture drm/msm: Fix task dump in gpu recovery Todor Tomov (1): drm/msm/hdmi: Enable HPD after HDMI IRQ is set up Tomi Valkeinen (1): drm/omap: fix bus_flags for panel-dpi Wei Yongjun (1): drm/fb-helper: Fix typo in parameter description Wen Yang (1): drm/msm: Fix error return checking YueHaibing (2): drm/msm/hdmi: Drop pointless static qualifier in msm_hdmi_bind() drm/msm: dpu: Fix "WARNING: invalid free of devm_ allocated data" tianci yin (1): drm/amd/powerplay: improve OD code robustness wentalou (1): drm/amdgpu: enlarge maximum waiting time of KIQ drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 6 +-- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 44 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 3 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +-- .../amd/display/dc/dce110/dce110_hw_sequencer.c| 2 + .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 4 +- drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 3 ++ drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 2 -
Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD
Hi Andrzej, 18. 12. 6. 오후 8:06에 Andrzej Hajda 이(가) 쓴 글: > Hi Inki, > > On 06.12.2018 10:38, Andrzej Hajda wrote: >> Hi Inki, >> >> This small patchset adds dynamic zpos support for DECON and FIMD. >> It was tested on tm2 and trats2. > > > I have realized that this patchset interferes with Christoph's exynos > plane patches for fimd and decon, but in drm-exynos/exynos_drm_next I > have found only patches for decon. Do you plan to get Christpoph's > alpha/blending patches for fimd? > > Should I rebase my patches on current exynos-drm-next, or on all > Christoph's patches? I missed to merge Christoph's patches. Thanks for notice. Now you can rebase your patch on top of exynos-drm-next. Thanks, Inki Dae > > > Regards > > Andrzej > > >> >> Regards >> Andrzej >> >> >> Andrzej Hajda (3): >> drm/exynos/decon5433: add dynamic zpos support >> drm/exynos/fimd: create local helper for disabling hardware window >> drm/exynos/fimd: add dynamic zpos support >> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 23 +- >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 --- >> 2 files changed, 29 insertions(+), 36 deletions(-) >> > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel
On Thu, Dec 06, 2018 at 12:32:47PM +, Kieran Bingham wrote: > My main initial idea for a libumlinux is to provide infrastructure such > as our linked-lists and other kernel formatting so that we can take > kernel code directly to userspace for test and debug (assuming that > there are no hardware dependencies or things that we can't mock out) The tools/ directory already does this for a tons of things. Its where I ended up placing some API I tested a long time ago when I wanted to test it in userspace, and provide the unit test in userspace (for my linker table patches). > Now we just have to start the race to see who can tweak the kernel build > system to produce an output library first :) Should be relatively easy if the tools directory used. Yes, there is an inherent risk of duplication, but that was decided long ago. Luis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 17/19] of: unittest: migrate tests to run on KUnit
On Wed, Dec 5, 2018 at 5:43 PM Brendan Higgins wrote: > > On Tue, Dec 4, 2018 at 5:41 AM Rob Herring wrote: > > > > On Mon, Dec 3, 2018 at 6:14 PM Brendan Higgins > > wrote: > > > > > > On Thu, Nov 29, 2018 at 4:40 PM Randy Dunlap > > > wrote: > > > > > > > > On 11/28/18 12:56 PM, Rob Herring wrote: > > > > >> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > > > > >> index ad3fcad4d75b8..f309399deac20 100644 > > > > >> --- a/drivers/of/Kconfig > > > > >> +++ b/drivers/of/Kconfig > > > > >> @@ -15,6 +15,7 @@ if OF > > > > >> config OF_UNITTEST > > > > >> bool "Device Tree runtime unit tests" > > > > >> depends on !SPARC > > > > >> + depends on KUNIT > > > > > Unless KUNIT has depends, better to be a select here. > > > > > > > > That's just style or taste. I would prefer to use depends > > > > instead of select, but that's also just my preference. > > > > > > I prefer depends too, but Rob is the maintainer here. > > > > Well, we should be consistent, not the follow the whims of each maintainer. > > Sorry, I don't think that came out the way I meant it. I don't really > think we are consistent on this point across the kernel, and I don't > feel very strongly about the point, so I was just looking to follow > the path of least resistance. (I also just assumed Rob would keep us > consistent within drivers/of/.) I meant across unittests, we should be consistent. All unittests do either "depends on KUNIT" or "select KUNIT". The question I would ask is does KUNIT need to be user visible or is useful to enable without any unittests enabled? With depends, a user has 2 options to go enable vs. 1 with select. But if you want a global kill switch to turn off all unittests, then depends works better. > I figure if we are running unit tests from the test runner script or > from an automated system, you won't be hunting for dependencies for a > single test every time you want to run a test, so select doesn't make > it easier to configure in most imagined use cases. > > KUNIT hypothetically should not depend on anything, so select should > be safe to use. > > On the other hand, if we end up being wrong on this point and KUnit > gains widespread adoption, I would prefer not to be in a position > where I have to change a bunch of configs all over the kernel because > this example got copied and pasted. You'll be so happy that 100s of tests have been created using kunit, it won't be a big deal. :) In any case, I wouldn't spend more time on this. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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(>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(>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(>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-devel@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0
On Wed, Nov 21, 2018 at 08:48:00AM +, eugen.hris...@microchip.com wrote: > From: Cristian Birsan > > PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel. > This panel with backlight is found in PDA 5" LCD screen (TM5000 series or > AC320005-5). > Adding Device Tree bindings for this panel. > > Signed-off-by: Cristian Birsan > --- > .../devicetree/bindings/display/panel/pda,91-00156-a0.txt | 7 > +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt > b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt > new file mode 100644 > index 000..52f0da9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt > @@ -0,0 +1,7 @@ > +PDA 91-00156-A0 5.0" WVGA TFT LCD panel > + > +Required properties: > +- compatible: should be "pda,91-00156-a0" > + > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. You need to explicitly list what properties from this are used. Does this have a single supply or did you just forget to add supplies for example? I don't know. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc.
On Wed, 21 Nov 2018 08:47:57 +, wrote: > Precision Design Associates, Inc. (PDA) manufactures standard and custom > capacitive touch screens, LCD's embedded controllers and custom embedded > software. They specialize in industrial, rugged and outdoor applications. > Website: http://www.pdaatl.com/ > > Signed-off-by: Eugen Hristev > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #24 from Shmerl --- Does KWin Wayland session work for you now? It was crashing also because of this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #23 from Sibren Vasse --- Switching to tty now works for me , I still get the [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:944 message though -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] mm/mmu_notifier: contextual information for event triggering invalidation
Should be all fixed in v2 i built with and without mmu notifier and
did not had any issue in v2.
On Fri, Dec 07, 2018 at 05:19:21AM +0800, kbuild test robot wrote:
> Hi Jérôme,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc5]
> [cannot apply to next-20181206]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/jglisse-redhat-com/mmu-notifier-contextual-informations/20181207-031930
> config: x86_64-randconfig-x017-201848 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>fs///proc/task_mmu.c: In function 'clear_refs_write':
>fs///proc/task_mmu.c:1099:29: error: storage size of 'range' isn't known
> struct mmu_notifier_range range;
> ^
> >> fs///proc/task_mmu.c:1147:18: error: 'MMU_NOTIFY_SOFT_DIRTY' undeclared
> >> (first use in this function); did you mean 'CLEAR_REFS_SOFT_DIRTY'?
>range.event = MMU_NOTIFY_SOFT_DIRTY;
> ^
> CLEAR_REFS_SOFT_DIRTY
>fs///proc/task_mmu.c:1147:18: note: each undeclared identifier is reported
> only once for each function it appears in
>fs///proc/task_mmu.c:1099:29: warning: unused variable 'range'
> [-Wunused-variable]
> struct mmu_notifier_range range;
> ^
>
> vim +1147 fs///proc/task_mmu.c
>
> 1069
> 1070static ssize_t clear_refs_write(struct file *file, const char
> __user *buf,
> 1071size_t count, loff_t *ppos)
> 1072{
> 1073struct task_struct *task;
> 1074char buffer[PROC_NUMBUF];
> 1075struct mm_struct *mm;
> 1076struct vm_area_struct *vma;
> 1077enum clear_refs_types type;
> 1078struct mmu_gather tlb;
> 1079int itype;
> 1080int rv;
> 1081
> 1082memset(buffer, 0, sizeof(buffer));
> 1083if (count > sizeof(buffer) - 1)
> 1084count = sizeof(buffer) - 1;
> 1085if (copy_from_user(buffer, buf, count))
> 1086return -EFAULT;
> 1087rv = kstrtoint(strstrip(buffer), 10, );
> 1088if (rv < 0)
> 1089return rv;
> 1090type = (enum clear_refs_types)itype;
> 1091if (type < CLEAR_REFS_ALL || type >= CLEAR_REFS_LAST)
> 1092return -EINVAL;
> 1093
> 1094task = get_proc_task(file_inode(file));
> 1095if (!task)
> 1096return -ESRCH;
> 1097mm = get_task_mm(task);
> 1098if (mm) {
> > 1099struct mmu_notifier_range range;
> 1100struct clear_refs_private cp = {
> 1101.type = type,
> 1102};
> 1103struct mm_walk clear_refs_walk = {
> 1104.pmd_entry = clear_refs_pte_range,
> 1105.test_walk = clear_refs_test_walk,
> 1106.mm = mm,
> 1107.private = ,
> 1108};
> 1109
> 1110if (type == CLEAR_REFS_MM_HIWATER_RSS) {
> if (down_write_killable(>mmap_sem))
> {
> 1112count = -EINTR;
> 1113goto out_mm;
> 1114}
> 1115
> 1116/*
> 1117 * Writing 5 to /proc/pid/clear_refs
> resets the peak
> 1118 * resident set size to this mm's
> current rss value.
> 1119 */
> 1120reset_mm_hiwater_rss(mm);
> 1121up_write(>mmap_sem);
> 1122goto out_mm;
> 1123}
> 1124
> 1125down_read(>mmap_sem);
> 1126tlb_gathe
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #22 from Shmerl --- Great news! Debian didn't get 4.20 rc kernels yet, but I can try building one from source to test. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #21 from Sibren Vasse --- (In reply to Jerry Zuo from comment #20) > The fix is showing up since 4.20-rc5. Please give a try. 4.20-rc5 solves the problem for me! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/sched: Refactor ring mirror list handling.
On 12/06/2018 01:33 PM, Christian König wrote:
> Am 06.12.18 um 18:41 schrieb Andrey Grodzovsky:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from non signaled HW fenes wait for all signaled HW fences
>> to complete before rerunning the jobs.
>>
>> Suggested-by: Christian Koenig
>> Signed-off-by: Andrey Grodzovsky
>
> Just briefly skimmed over this, but it looks exactly like what I had
> in mind.
>
> Need to give that a more detailed thought tomorrow,
> Christian.
Please note I've already resent V2 after finding refactoring error.
Andrey
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++---
>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 8 +--
>> drivers/gpu/drm/scheduler/sched_main.c | 86
>> +++---
>> drivers/gpu/drm/v3d/v3d_sched.c | 11 ++--
>> include/drm/gpu_scheduler.h | 10 ++--
>> 5 files changed, 83 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index ef36cc5..42111d5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3292,17 +3292,16 @@ static int
>> amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>> /* block all schedulers and reset given job's ring */
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> struct amdgpu_ring *ring = adev->rings[i];
>> + bool park_only = job && job->base.sched != >sched;
>> if (!ring || !ring->sched.thread)
>> continue;
>> - kthread_park(ring->sched.thread);
>> + drm_sched_stop(>sched, job ? >base : NULL,
>> park_only);
>> - if (job && job->base.sched != >sched)
>> + if (park_only)
>> continue;
>> - drm_sched_hw_job_reset(>sched, job ? >base :
>> NULL);
>> -
>> /* after all hw jobs are reset, hw fence is meaningless, so
>> force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>> }
>> @@ -3445,6 +3444,7 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>> struct amdgpu_job *job)
>> {
>> int i;
>> + bool unpark_only;
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> struct amdgpu_ring *ring = adev->rings[i];
>> @@ -3456,10 +3456,13 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>> * or all rings (in the case @job is NULL)
>> * after above amdgpu_reset accomplished
>> */
>> - if ((!job || job->base.sched == >sched) &&
>> !adev->asic_reset_res)
>> - drm_sched_job_recovery(>sched);
>> + unpark_only = (job && job->base.sched != >sched) ||
>> + adev->asic_reset_res;
>> +
>> + if (!unpark_only)
>> + drm_sched_resubmit_jobs(>sched);
>> - kthread_unpark(ring->sched.thread);
>> + drm_sched_start(>sched, unpark_only);
>> }
>> if (!amdgpu_device_has_dc_support(adev)) {
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index 49a6763..fab3b51 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> @@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
>> drm_sched_job *sched_job)
>> }
>> /* block scheduler */
>> - kthread_park(gpu->sched.thread);
>> - drm_sched_hw_job_reset(>sched, sched_job);
>> + drm_sched_stop(>sched, sched_job, false);
>> /* get the GPU back into the init state */
>> etnaviv_core_dump(gpu);
>> etnaviv_gpu_recover_hang(gpu);
>> + drm_sched_resubmit_jobs(>sched);
>> +
>> /* restart scheduler after GPU is usable again */
>> - drm_sched_job_recovery(>sched);
>> - kthread_unpark(gpu->sched.thread);
>> + drm_sched_start(>sched);
>> }
>> static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>> b/drivers/gpu/drm/scheduler/sched_main.c
>> index dbb6906..8fb7f86 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -60,8 +60,6 @@
>> static void drm_sched_process_job(struct dma_fence *f, struct
>> dma_fence_cb *cb);
>> -static void drm_sched_expel_job_unlocked(struct drm_sched_job
>> *s_job);
>> -
>> /**
>> * drm_sched_rq_init - initialize a given run queue struct
>> *
>> @@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct
>> work_struct *work)
>> * @bad: bad scheduler job
>> *
>> */
>> -void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
>> drm_sched_job *bad)
>> +void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
>>
[PATCH v2 1/2] drm/sched: Refactor ring mirror list handling.
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
v2: Fix resubmission of guilty job into HW after refactoring.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 8 +--
drivers/gpu/drm/scheduler/sched_main.c | 110 ++---
drivers/gpu/drm/v3d/v3d_sched.c| 11 +--
include/drm/gpu_scheduler.h| 10 ++-
5 files changed, 95 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ef36cc5..42111d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3292,17 +3292,16 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
/* block all schedulers and reset given job's ring */
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
+ bool park_only = job && job->base.sched != >sched;
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_stop(>sched, job ? >base : NULL,
park_only);
- if (job && job->base.sched != >sched)
+ if (park_only)
continue;
- drm_sched_hw_job_reset(>sched, job ? >base : NULL);
-
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3445,6 +3444,7 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
struct amdgpu_job *job)
{
int i;
+ bool unpark_only;
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -3456,10 +3456,13 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
* or all rings (in the case @job is NULL)
* after above amdgpu_reset accomplished
*/
- if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+ unpark_only = (job && job->base.sched != >sched) ||
+ adev->asic_reset_res;
+
+ if (!unpark_only)
+ drm_sched_resubmit_jobs(>sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(>sched, unpark_only);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..fab3b51 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(>sched, sched_job);
+ drm_sched_stop(>sched, sched_job, false);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(>sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(>sched);
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..cdf95e2 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
*cb);
-static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct work_struct
*work)
* @bad: bad scheduler job
*
*/
-void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
+void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad,
+ bool park_only)
{
struct drm_sched_job *s_job;
struct drm_sched_entity *entity, *tmp;
unsigned long flags;
+ struct list_head wait_list;
int i;
+ kthread_park(sched->thread);
+ if (park_only)
+ return;
+
+ INIT_LIST_HEAD(_list);
+
spin_lock_irqsave(>job_list_lock,
[PATCH v2 2/2] drm/sched: Rework HW fence processing.
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit finish_work
directly from the HW fence callback.
v2: Fix comments.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_fence.c | 4 +++-
drivers/gpu/drm/scheduler/sched_main.c | 41 +
include/drm/gpu_scheduler.h | 10 ++--
3 files changed, 32 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
b/drivers/gpu/drm/scheduler/sched_fence.c
index d8d2dff..e62c239 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -151,7 +151,8 @@ struct drm_sched_fence *to_drm_sched_fence(struct dma_fence
*f)
EXPORT_SYMBOL(to_drm_sched_fence);
struct drm_sched_fence *drm_sched_fence_create(struct drm_sched_entity *entity,
- void *owner)
+ void *owner,
+ struct drm_sched_job *s_job)
{
struct drm_sched_fence *fence = NULL;
unsigned seq;
@@ -163,6 +164,7 @@ struct drm_sched_fence *drm_sched_fence_create(struct
drm_sched_entity *entity,
fence->owner = owner;
fence->sched = entity->rq->sched;
spin_lock_init(>lock);
+ fence->s_job = s_job;
seq = atomic_inc_return(>fence_seq);
dma_fence_init(>scheduled, _sched_fence_ops_scheduled,
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index cdf95e2..5359418 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -284,8 +284,6 @@ static void drm_sched_job_finish(struct work_struct *work)
cancel_delayed_work_sync(>work_tdr);
spin_lock_irqsave(>job_list_lock, flags);
- /* remove job from ring_mirror_list */
- list_del_init(_job->node);
/* queue TDR for next job */
drm_sched_start_timeout(sched);
spin_unlock_irqrestore(>job_list_lock, flags);
@@ -293,22 +291,11 @@ static void drm_sched_job_finish(struct work_struct *work)
sched->ops->free_job(s_job);
}
-static void drm_sched_job_finish_cb(struct dma_fence *f,
- struct dma_fence_cb *cb)
-{
- struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-finish_cb);
- schedule_work(>finish_work);
-}
-
static void drm_sched_job_begin(struct drm_sched_job *s_job)
{
struct drm_gpu_scheduler *sched = s_job->sched;
unsigned long flags;
- dma_fence_add_callback(_job->s_fence->finished, _job->finish_cb,
- drm_sched_job_finish_cb);
-
spin_lock_irqsave(>job_list_lock, flags);
list_add_tail(_job->node, >ring_mirror_list);
drm_sched_start_timeout(sched);
@@ -363,8 +350,7 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad,
dma_fence_put(s_job->s_fence->parent);
s_job->s_fence->parent = NULL;
atomic_dec(>hw_rq_count);
- }
- else {
+ } else {
/* TODO Is it get/put neccessey here ? */
dma_fence_get(_job->s_fence->finished);
list_add(_job->finish_node, _list);
@@ -423,7 +409,13 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool
unpark_only)
if (unpark_only)
goto unpark;
- spin_lock_irqsave(>job_list_lock, flags);
+ /*
+* Locking the list is not required here as the sched thread is parked
+* so no new jobs are being pushed in to HW and in drm_sched_stop we
+* flushed all the jobs who were still in mirror list but who already
+* signaled and removed them self from the list. Also concurrent
+* GPU recovers can't run in parallel.
+*/
list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
struct drm_sched_fence *s_fence = s_job->s_fence;
struct dma_fence *fence = s_job->s_fence->parent;
@@ -441,7 +433,6 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool
unpark_only)
}
drm_sched_start_timeout(sched);
- spin_unlock_irqrestore(>job_list_lock, flags);
unpark:
kthread_unpark(sched->thread);
@@ -505,7 +496,7 @@ int drm_sched_job_init(struct drm_sched_job *job,
job->sched = sched;
job->entity = entity;
job->s_priority = entity->rq - sched->sched_rq;
- job->s_fence = drm_sched_fence_create(entity, owner);
+ job->s_fence =
Re: [PATCH 3/3] mm/mmu_notifier: contextual information for event triggering invalidation
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/jglisse-redhat-com/mmu-notifier-contextual-informations/20181207-031930
config: x86_64-randconfig-x017-201848 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
fs///proc/task_mmu.c: In function 'clear_refs_write':
fs///proc/task_mmu.c:1099:29: error: storage size of 'range' isn't known
struct mmu_notifier_range range;
^
>> fs///proc/task_mmu.c:1147:18: error: 'MMU_NOTIFY_SOFT_DIRTY' undeclared
>> (first use in this function); did you mean 'CLEAR_REFS_SOFT_DIRTY'?
range.event = MMU_NOTIFY_SOFT_DIRTY;
^
CLEAR_REFS_SOFT_DIRTY
fs///proc/task_mmu.c:1147:18: note: each undeclared identifier is reported
only once for each function it appears in
fs///proc/task_mmu.c:1099:29: warning: unused variable 'range'
[-Wunused-variable]
struct mmu_notifier_range range;
^
vim +1147 fs///proc/task_mmu.c
1069
1070 static ssize_t clear_refs_write(struct file *file, const char __user
*buf,
1071 size_t count, loff_t *ppos)
1072 {
1073 struct task_struct *task;
1074 char buffer[PROC_NUMBUF];
1075 struct mm_struct *mm;
1076 struct vm_area_struct *vma;
1077 enum clear_refs_types type;
1078 struct mmu_gather tlb;
1079 int itype;
1080 int rv;
1081
1082 memset(buffer, 0, sizeof(buffer));
1083 if (count > sizeof(buffer) - 1)
1084 count = sizeof(buffer) - 1;
1085 if (copy_from_user(buffer, buf, count))
1086 return -EFAULT;
1087 rv = kstrtoint(strstrip(buffer), 10, );
1088 if (rv < 0)
1089 return rv;
1090 type = (enum clear_refs_types)itype;
1091 if (type < CLEAR_REFS_ALL || type >= CLEAR_REFS_LAST)
1092 return -EINVAL;
1093
1094 task = get_proc_task(file_inode(file));
1095 if (!task)
1096 return -ESRCH;
1097 mm = get_task_mm(task);
1098 if (mm) {
> 1099 struct mmu_notifier_range range;
1100 struct clear_refs_private cp = {
1101 .type = type,
1102 };
1103 struct mm_walk clear_refs_walk = {
1104 .pmd_entry = clear_refs_pte_range,
1105 .test_walk = clear_refs_test_walk,
1106 .mm = mm,
1107 .private = ,
1108 };
1109
1110 if (type == CLEAR_REFS_MM_HIWATER_RSS) {
if (down_write_killable(>mmap_sem)) {
1112 count = -EINTR;
1113 goto out_mm;
1114 }
1115
1116 /*
1117 * Writing 5 to /proc/pid/clear_refs resets the
peak
1118 * resident set size to this mm's current rss
value.
1119 */
1120 reset_mm_hiwater_rss(mm);
1121 up_write(>mmap_sem);
1122 goto out_mm;
1123 }
1124
1125 down_read(>mmap_sem);
1126 tlb_gather_mmu(, mm, 0, -1);
1127 if (type == CLEAR_REFS_SOFT_DIRTY) {
1128 for (vma = mm->mmap; vma; vma = vma->vm_next) {
1129 if (!(vma->vm_flags & VM_SOFTDIRTY))
1130 continue;
1131 up_read(>mmap_sem);
1132 if (down_write_killable(>mmap_sem))
{
1133 count = -EINTR;
1134 goto out_mm;
1135 }
1136 for (vma = mm->mmap; vma; vma =
vma->vm_next) {
1137 vma->vm_flags &= ~VM_SOFTDIRTY;
1138 vma_set_page_prot(vma);
1139 }
1140 downgrade_write(>mmap_sem);
1141
Re: [PATCH 3/3] mm/mmu_notifier: contextual information for event triggering invalidation
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/jglisse-redhat-com/mmu-notifier-contextual-informations/20181207-031930
config: i386-randconfig-x007-201848 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/events/uprobes.c: In function '__replace_page':
kernel/events/uprobes.c:174:28: error: storage size of 'range' isn't known
struct mmu_notifier_range range;
^
>> kernel/events/uprobes.c:177:16: error: 'MMU_NOTIFY_CLEAR' undeclared (first
>> use in this function); did you mean 'VM_ARCH_CLEAR'?
range.event = MMU_NOTIFY_CLEAR;
^~~~
VM_ARCH_CLEAR
kernel/events/uprobes.c:177:16: note: each undeclared identifier is reported
only once for each function it appears in
kernel/events/uprobes.c:174:28: warning: unused variable 'range'
[-Wunused-variable]
struct mmu_notifier_range range;
^
vim +177 kernel/events/uprobes.c
152
153 /**
154 * __replace_page - replace page in vma by new page.
155 * based on replace_page in mm/ksm.c
156 *
157 * @vma: vma that holds the pte pointing to page
158 * @addr: address the old @page is mapped at
159 * @page: the cowed page we are replacing by kpage
160 * @kpage:the modified page we replace page by
161 *
162 * Returns 0 on success, -EFAULT on failure.
163 */
164 static int __replace_page(struct vm_area_struct *vma, unsigned long
addr,
165 struct page *old_page, struct page
*new_page)
166 {
167 struct mm_struct *mm = vma->vm_mm;
168 struct page_vma_mapped_walk pvmw = {
169 .page = old_page,
170 .vma = vma,
171 .address = addr,
172 };
173 int err;
> 174 struct mmu_notifier_range range;
175 struct mem_cgroup *memcg;
176
> 177 range.event = MMU_NOTIFY_CLEAR;
178 range.start = addr;
179 range.end = addr + PAGE_SIZE;
180 range.mm = mm;
181
182 VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page);
183
184 err = mem_cgroup_try_charge(new_page, vma->vm_mm, GFP_KERNEL,
,
185 false);
186 if (err)
187 return err;
188
189 /* For try_to_free_swap() and munlock_vma_page() below */
190 lock_page(old_page);
191
192 mmu_notifier_invalidate_range_start();
193 err = -EAGAIN;
194 if (!page_vma_mapped_walk()) {
195 mem_cgroup_cancel_charge(new_page, memcg, false);
196 goto unlock;
197 }
198 VM_BUG_ON_PAGE(addr != pvmw.address, old_page);
199
200 get_page(new_page);
201 page_add_new_anon_rmap(new_page, vma, addr, false);
202 mem_cgroup_commit_charge(new_page, memcg, false, false);
203 lru_cache_add_active_or_unevictable(new_page, vma);
204
205 if (!PageAnon(old_page)) {
206 dec_mm_counter(mm, mm_counter_file(old_page));
207 inc_mm_counter(mm, MM_ANONPAGES);
208 }
209
210 flush_cache_page(vma, addr, pte_pfn(*pvmw.pte));
211 ptep_clear_flush_notify(vma, addr, pvmw.pte);
212 set_pte_at_notify(mm, addr, pvmw.pte,
213 mk_pte(new_page, vma->vm_page_prot));
214
215 page_remove_rmap(old_page, false);
216 if (!page_mapped(old_page))
217 try_to_free_swap(old_page);
218 page_vma_mapped_walk_done();
219
220 if (vma->vm_flags & VM_LOCKED)
221 munlock_vma_page(old_page);
222 put_page(old_page);
223
224 err = 0;
225 unlock:
226 mmu_notifier_invalidate_range_end();
227 unlock_page(old_page);
228 return err;
229 }
230
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] mm/mmu_notifier: use structure for invalidate_range_start/end calls
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/jglisse-redhat-com/mmu-notifier-contextual-informations/20181207-031930
config: i386-randconfig-x007-201848 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/events/uprobes.c: In function '__replace_page':
>> kernel/events/uprobes.c:174:28: error: storage size of 'range' isn't known
struct mmu_notifier_range range;
^
kernel/events/uprobes.c:174:28: warning: unused variable 'range'
[-Wunused-variable]
vim +174 kernel/events/uprobes.c
152
153 /**
154 * __replace_page - replace page in vma by new page.
155 * based on replace_page in mm/ksm.c
156 *
157 * @vma: vma that holds the pte pointing to page
158 * @addr: address the old @page is mapped at
159 * @page: the cowed page we are replacing by kpage
160 * @kpage:the modified page we replace page by
161 *
162 * Returns 0 on success, -EFAULT on failure.
163 */
164 static int __replace_page(struct vm_area_struct *vma, unsigned long
addr,
165 struct page *old_page, struct page
*new_page)
166 {
167 struct mm_struct *mm = vma->vm_mm;
168 struct page_vma_mapped_walk pvmw = {
169 .page = old_page,
170 .vma = vma,
171 .address = addr,
172 };
173 int err;
> 174 struct mmu_notifier_range range;
175 struct mem_cgroup *memcg;
176
177 range.start = addr;
178 range.end = addr + PAGE_SIZE;
179 range.mm = mm;
180
181 VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page);
182
183 err = mem_cgroup_try_charge(new_page, vma->vm_mm, GFP_KERNEL,
,
184 false);
185 if (err)
186 return err;
187
188 /* For try_to_free_swap() and munlock_vma_page() below */
189 lock_page(old_page);
190
191 mmu_notifier_invalidate_range_start();
192 err = -EAGAIN;
193 if (!page_vma_mapped_walk()) {
194 mem_cgroup_cancel_charge(new_page, memcg, false);
195 goto unlock;
196 }
197 VM_BUG_ON_PAGE(addr != pvmw.address, old_page);
198
199 get_page(new_page);
200 page_add_new_anon_rmap(new_page, vma, addr, false);
201 mem_cgroup_commit_charge(new_page, memcg, false, false);
202 lru_cache_add_active_or_unevictable(new_page, vma);
203
204 if (!PageAnon(old_page)) {
205 dec_mm_counter(mm, mm_counter_file(old_page));
206 inc_mm_counter(mm, MM_ANONPAGES);
207 }
208
209 flush_cache_page(vma, addr, pte_pfn(*pvmw.pte));
210 ptep_clear_flush_notify(vma, addr, pvmw.pte);
211 set_pte_at_notify(mm, addr, pvmw.pte,
212 mk_pte(new_page, vma->vm_page_prot));
213
214 page_remove_rmap(old_page, false);
215 if (!page_mapped(old_page))
216 try_to_free_swap(old_page);
217 page_vma_mapped_walk_done();
218
219 if (vma->vm_flags & VM_LOCKED)
220 munlock_vma_page(old_page);
221 put_page(old_page);
222
223 err = 0;
224 unlock:
225 mmu_notifier_invalidate_range_end();
226 unlock_page(old_page);
227 return err;
228 }
229
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #20 from Jerry Zuo --- The fix is showing up since 4.20-rc5. Please give a try. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] mm/mmu_notifier: use structure for invalidate_range_start/end calls
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/jglisse-redhat-com/mmu-notifier-contextual-informations/20181207-031930
config: x86_64-randconfig-x017-201848 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
fs//proc/task_mmu.c: In function 'clear_refs_write':
>> fs//proc/task_mmu.c:1099:29: error: storage size of 'range' isn't known
struct mmu_notifier_range range;
^
fs//proc/task_mmu.c:1099:29: warning: unused variable 'range'
[-Wunused-variable]
vim +1099 fs//proc/task_mmu.c
1069
1070 static ssize_t clear_refs_write(struct file *file, const char __user
*buf,
1071 size_t count, loff_t *ppos)
1072 {
1073 struct task_struct *task;
1074 char buffer[PROC_NUMBUF];
1075 struct mm_struct *mm;
1076 struct vm_area_struct *vma;
1077 enum clear_refs_types type;
1078 struct mmu_gather tlb;
1079 int itype;
1080 int rv;
1081
1082 memset(buffer, 0, sizeof(buffer));
1083 if (count > sizeof(buffer) - 1)
1084 count = sizeof(buffer) - 1;
1085 if (copy_from_user(buffer, buf, count))
1086 return -EFAULT;
1087 rv = kstrtoint(strstrip(buffer), 10, );
1088 if (rv < 0)
1089 return rv;
1090 type = (enum clear_refs_types)itype;
1091 if (type < CLEAR_REFS_ALL || type >= CLEAR_REFS_LAST)
1092 return -EINVAL;
1093
1094 task = get_proc_task(file_inode(file));
1095 if (!task)
1096 return -ESRCH;
1097 mm = get_task_mm(task);
1098 if (mm) {
> 1099 struct mmu_notifier_range range;
1100 struct clear_refs_private cp = {
1101 .type = type,
1102 };
1103 struct mm_walk clear_refs_walk = {
1104 .pmd_entry = clear_refs_pte_range,
1105 .test_walk = clear_refs_test_walk,
1106 .mm = mm,
1107 .private = ,
1108 };
1109
1110 if (type == CLEAR_REFS_MM_HIWATER_RSS) {
if (down_write_killable(>mmap_sem)) {
1112 count = -EINTR;
1113 goto out_mm;
1114 }
1115
1116 /*
1117 * Writing 5 to /proc/pid/clear_refs resets the
peak
1118 * resident set size to this mm's current rss
value.
1119 */
1120 reset_mm_hiwater_rss(mm);
1121 up_write(>mmap_sem);
1122 goto out_mm;
1123 }
1124
1125 down_read(>mmap_sem);
1126 tlb_gather_mmu(, mm, 0, -1);
1127 if (type == CLEAR_REFS_SOFT_DIRTY) {
1128 for (vma = mm->mmap; vma; vma = vma->vm_next) {
1129 if (!(vma->vm_flags & VM_SOFTDIRTY))
1130 continue;
1131 up_read(>mmap_sem);
1132 if (down_write_killable(>mmap_sem))
{
1133 count = -EINTR;
1134 goto out_mm;
1135 }
1136 for (vma = mm->mmap; vma; vma =
vma->vm_next) {
1137 vma->vm_flags &= ~VM_SOFTDIRTY;
1138 vma_set_page_prot(vma);
1139 }
1140 downgrade_write(>mmap_sem);
1141 break;
1142 }
1143
1144 range.start = 0;
1145 range.end = -1UL;
1146 range.mm = mm;
1147 mmu_notifier_invalidate_range_start();
1148 }
1149 walk_page_range(0, mm->highest_vm_end,
_refs_walk);
1150 if (type == CLEAR_REFS_SOFT_DIRTY)
1151 mmu_notif
[PATCH 5/5] drm/bridge: ti-tfp410: Report input bus config through bridge timings
The TFP410 supports configurable pixel clock sampling edge and data
de-skew adjustments. The configuration can be set through I2C or
dedicated chip pins.
Report the configuration through the drm_bridge timings. As the
ti-tftp410 driver doesn't support configuring the chip through I2C, we
simply use the default configuration in that case. When the chip is
configured through dedicated pins, we parse the configuration from DT.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 77 --
1 file changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index d25d23cfe3f5..48ec647a7526 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -34,6 +34,8 @@ struct tfp410 {
struct delayed_work hpd_work;
struct gpio_desc*powerdown;
+ struct drm_bridge_timings timings;
+
struct device *dev;
};
@@ -180,6 +182,70 @@ static irqreturn_t tfp410_hpd_irq_thread(int irq, void
*arg)
return IRQ_HANDLED;
}
+static const struct drm_bridge_timings tfp410_default_timings = {
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
+| DRM_BUS_FLAG_DE_HIGH,
+ .setup_time_ps = 1200,
+ .hold_time_ps = 1300,
+};
+
+static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
+{
+ struct drm_bridge_timings *timings = >timings;
+ struct device_node *ep;
+ u32 pclk_sample = 0;
+ s32 deskew = 0;
+
+ /* Start with defaults. */
+ *timings = tfp410_default_timings;
+
+ if (i2c)
+ /*
+* In I2C mode timings are configured through the I2C interface.
+* As the driver doesn't support I2C configuration yet, we just
+* go with the defaults (BSEL=1, DSEL=1, DKEN=0, EDGE=1).
+*/
+ return 0;
+
+ /*
+* In non-I2C mode, timings are configured through the BSEL, DSEL, DKEN
+* and EDGE pins. They are specified in DT through endpoint properties
+* and vendor-specific properties.
+*/
+ ep = of_graph_get_endpoint_by_regs(dvi->dev->of_node, 0, 0);
+ if (!ep)
+ return -EINVAL;
+
+ /* Get the sampling edge from the endpoint. */
+ of_property_read_u32(ep, "pclk-sample", _sample);
+ of_node_put(ep);
+
+ timings->input_bus_flags = DRM_BUS_FLAG_DE_HIGH;
+
+ switch (pclk_sample) {
+ case 0:
+ timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
+| DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE;
+ break;
+ case 1:
+ timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
+| DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* Get the setup and hold time from vendor-specific properties. */
+ of_property_read_u32(dvi->dev->of_node, "ti,deskew", (u32 *));
+ if (deskew < -4 || deskew > 3)
+ return -EINVAL;
+
+ timings->setup_time_ps = min(0, 1200 - 350 * deskew);
+ timings->hold_time_ps = min(0, 1300 + 350 * deskew);
+
+ return 0;
+}
+
static int tfp410_get_connector_properties(struct tfp410 *dvi)
{
struct device_node *connector_node, *ddc_phandle;
@@ -223,7 +289,7 @@ static int tfp410_get_connector_properties(struct tfp410
*dvi)
return ret;
}
-static int tfp410_init(struct device *dev)
+static int tfp410_init(struct device *dev, bool i2c)
{
struct tfp410 *dvi;
int ret;
@@ -240,8 +306,13 @@ static int tfp410_init(struct device *dev)
dvi->bridge.funcs = _bridge_funcs;
dvi->bridge.of_node = dev->of_node;
+ dvi->bridge.timings = >timings;
dvi->dev = dev;
+ ret = tfp410_parse_timings(dvi, i2c);
+ if (ret)
+ goto fail;
+
ret = tfp410_get_connector_properties(dvi);
if (ret)
goto fail;
@@ -294,7 +365,7 @@ static int tfp410_fini(struct device *dev)
static int tfp410_probe(struct platform_device *pdev)
{
- return tfp410_init(>dev);
+ return tfp410_init(>dev, false);
}
static int tfp410_remove(struct platform_device *pdev)
@@ -331,7 +402,7 @@ static int tfp410_i2c_probe(struct i2c_client *client,
return -ENXIO;
}
- return tfp410_init(>dev);
+ return tfp410_init(>dev, true);
}
static int tfp410_i2c_remove(struct i2c_client *client)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] dt-bindings: display: tfp410: Add bus parameters properties
The TFP410 supports configuration of several input bus parameters
through either the I2C port or chip pins. In the latter case, we need to
specify those parameters in DT.
Two new properties are added, ti,deskew to specify the data de-skew
configuration (as set through the DK[3:1] pins), and pclk-sample to
specify the pixel clock sampling edge (as set through the EDGE pin).
Signed-off-by: Laurent Pinchart
---
.../bindings/display/bridge/ti,tfp410.txt | 24 ++-
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
index 54d7e31525ec..3f903af93949 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
@@ -6,15 +6,25 @@ Required properties:
Optional properties:
- powerdown-gpios: power-down gpio
-- reg: I2C address. If and only if present the device node
- should be placed into the i2c controller node where the
- tfp410 i2c is connected to.
+- reg: I2C address. If and only if present the device node should be placed
+ into the I2C controller node where the TFP410 I2C is connected to.
+- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
+ through th DK[3:1] pins. This property shall be present only if the TFP410
+ is not connected through I2C.
Required nodes:
-- Video port 0 for DPI input [1].
-- Video port 1 for DVI output [1].
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in [1]. Each port node shall have a single endpoint.
+
+- Port 0 is the DPI input port. Its endpoint subnode shall contain a
+ pclk-sample property and a remote-endpoint property as specified in [1].
+
+- Port 1 is the DVI output port. Its endpoint subnode shall contain a
+ remote-endpoint property is specified in [1].
+
+[1] Documentation/devicetree/bindings/media/video-interfaces.txt
+
Example
---
@@ -22,6 +32,7 @@ Example
tfp410: encoder@0 {
compatible = "ti,tfp410";
powerdown-gpios = <_gpio 2 GPIO_ACTIVE_LOW>;
+ ti,deskew = <4>;
ports {
#address-cells = <1>;
@@ -31,6 +42,7 @@ tfp410: encoder@0 {
reg = <0>;
tfp410_in: endpoint@0 {
+ pclk-sample = <1>;
remote-endpoint = <_out>;
};
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm: ti-tfp410 improvements
Hello, This small patch series improves the ti-tfp410 driver with three new features, in patch 2/5 to 5/5. Patch 1/5 has been previously posted by Stefan, and I've included it here to support patch 5/5 that needs to store other polarity information in the bridge timings than the sampling edges. These changes are meant to support the missing tfp410 features currently implemented in the omapdrm custom tfp410 driver, in order to move to drm_bridge. The series is based on top of the "[PATCH v2 0/2] Clarify display info PIXDATA bus flags" series [1] previously posted on the mailing list. [1] https://lists.freedesktop.org/archives/dri-devel/2018-December/199204.html Laurent Pinchart (4): dt-bindings: display: tfp410: Add bus parameters properties drm/bridge: ti-tfp410: Set connector type based on DT connector node drm/bridge: ti-tfp410: Add support for the powerdown GPIO drm/bridge: ti-tfp410: Report input bus config through bridge timings Stefan Agner (1): drm/bridge: use bus flags in bridge timings .../bindings/display/bridge/ti,tfp410.txt | 24 +++- drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +- drivers/gpu/drm/bridge/ti-tfp410.c| 109 +- include/drm/drm_bridge.h | 12 +- 4 files changed, 131 insertions(+), 20 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/bridge: use bus flags in bridge timings
From: Stefan Agner
The DRM bus flags convey additional information on pixel data on
the bus. All current available bus flags might be of interest for
a bridge. Remove the sampling_edge field and use bus_flags.
In the case at hand a dumb VGA bridge needs a specific data enable
polarity (DRM_BUS_FLAG_DE_LOW).
Signed-off-by: Stefan Agner
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Renamed bus_flags to input_bus_flags
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +++---
include/drm/drm_bridge.h | 12 +---
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 7dc14c22f7db..191a4a6e624f 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -234,7 +234,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
*/
static const struct drm_bridge_timings default_dac_timings = {
/* Timing specifications, datasheet page 7 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
.setup_time_ps = 500,
.hold_time_ps = 1500,
};
@@ -245,7 +245,7 @@ static const struct drm_bridge_timings default_dac_timings
= {
*/
static const struct drm_bridge_timings ti_ths8134_dac_timings = {
/* From timing diagram, datasheet page 9 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
/* From datasheet, page 12 */
.setup_time_ps = 3000,
/* I guess this means latched input */
@@ -258,7 +258,7 @@ static const struct drm_bridge_timings
ti_ths8134_dac_timings = {
*/
static const struct drm_bridge_timings ti_ths8135_dac_timings = {
/* From timing diagram, datasheet page 14 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
/* From datasheet, page 16 */
.setup_time_ps = 2000,
.hold_time_ps = 500,
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index bf81fb573a5e..27c17706626c 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -244,15 +244,13 @@ struct drm_bridge_funcs {
*/
struct drm_bridge_timings {
/**
-* @sampling_edge:
+* @input_bus_flags:
*
-* Tells whether the bridge samples the digital input signals from the
-* display engine on the positive or negative edge of the clock. This
-* should use the DRM_BUS_FLAG_PIXDATA_SAMPLE_[POS|NEG]EDGE and
-* DRM_BUS_FLAG_SYNC_SAMPLE_[POS|NEG]EDGE bitwise flags from the DRM
-* connector (bit 2, 3, 6 and 7 valid).
+* Tells what additional settings for the pixel data on the bus
+* this bridge requires (like pixel signal polarity). See also
+* _display_info->bus_flags.
*/
- u32 sampling_edge;
+ u32 input_bus_flags;
/**
* @setup_time_ps:
*
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/bridge: ti-tfp410: Add support for the powerdown GPIO
The TFP410 has a powerdown pin that can be connected to a GPIO to
control power saving. The DT bindings define a corresponding property,
but the driver doesn't implement support for it. Fix that.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index e4280f5af9f5..d25d23cfe3f5 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -32,6 +32,7 @@ struct tfp410 {
struct i2c_adapter *ddc;
struct gpio_desc*hpd;
struct delayed_work hpd_work;
+ struct gpio_desc*powerdown;
struct device *dev;
};
@@ -139,8 +140,24 @@ static int tfp410_attach(struct drm_bridge *bridge)
return 0;
}
+static void tfp410_enable(struct drm_bridge *bridge)
+{
+ struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+
+ gpiod_set_value_cansleep(dvi->powerdown, 0);
+}
+
+static void tfp410_disable(struct drm_bridge *bridge)
+{
+ struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+
+ gpiod_set_value_cansleep(dvi->powerdown, 1);
+}
+
static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.attach = tfp410_attach,
+ .enable = tfp410_enable,
+ .disable= tfp410_disable,
};
static void tfp410_hpd_work_func(struct work_struct *work)
@@ -229,6 +246,13 @@ static int tfp410_init(struct device *dev)
if (ret)
goto fail;
+ dvi->powerdown = devm_gpiod_get_optional(dev, "powerdown",
+GPIOD_OUT_HIGH);
+ if (IS_ERR(dvi->powerdown)) {
+ dev_err(dev, "failed to parse powerdown gpio\n");
+ return PTR_ERR(dvi->powerdown);
+ }
+
if (dvi->hpd) {
INIT_DELAYED_WORK(>hpd_work, tfp410_hpd_work_func);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/bridge: ti-tfp410: Set connector type based on DT connector node
The TI TFP410 is a DVI encoder, not a full HDMI encoder. Its output can
be routed to a DVI-D connector, even if in many cases embedded systems
will use an HDMI connector to carry the DVI signals.
Instead of hardcoding the connector type to HDMI, retrieve the connector
type from its DT node.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index c3e32138c6bb..e4280f5af9f5 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -27,6 +27,7 @@
struct tfp410 {
struct drm_bridge bridge;
struct drm_connectorconnector;
+ unsigned intconnector_type;
struct i2c_adapter *ddc;
struct gpio_desc*hpd;
@@ -126,7 +127,7 @@ static int tfp410_attach(struct drm_bridge *bridge)
drm_connector_helper_add(>connector,
_con_helper_funcs);
ret = drm_connector_init(bridge->dev, >connector,
-_con_funcs, DRM_MODE_CONNECTOR_HDMIA);
+_con_funcs, dvi->connector_type);
if (ret) {
dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
return ret;
@@ -172,6 +173,11 @@ static int tfp410_get_connector_properties(struct tfp410
*dvi)
if (!connector_node)
return -ENODEV;
+ if (of_device_is_compatible(connector_node, "hdmi-connector"))
+ dvi->connector_type = DRM_MODE_CONNECTOR_HDMIA;
+ else
+ dvi->connector_type = DRM_MODE_CONNECTOR_DVID;
+
dvi->hpd = fwnode_get_named_gpiod(_node->fwnode,
"hpd-gpios", 0, GPIOD_IN, "hpd");
if (IS_ERR(dvi->hpd)) {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/vc4: Fix negative X/Y positioning on SAND planes
On Thu, 06 Dec 2018 10:59:17 -0800 Eric Anholt wrote: > > + > > + /* > > +* SCALER_PITCH0_SINK_PIX does not seem to work for SAND > > +* formats. Specify a negative START_X instead, even if it's > > +* less efficient. > > +*/ > > + if (x_off) > > + vc4_state->crtc_x = -x_off; > > Wait. If we were supposed to start at a nonzero x position within the > FB, then we instead put the image off the left hand side of the screen? > That seems wrong. Yep, I overlooked this case. > > Did you test if we can just vc4_state->offsets[i] += x_off * cpp? Yep, I tried, and it doesn't seem to work. We have to tell the HVS that some pixels must be skipped at the beginning of each line of the first tile. That's what SINK_PIX(x_off) is supposed to do, but it seems to be broken for 2 reasons: 1/ the max value of SINK_PIX is 63, but the HVS supports 128 and 256 bytes tiles. 2/ looks like the UV plane is truncated when we specify a SINK_PIX!=0. Don't know why exactly. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/5] vc4/hdmi: Support TV margin props
Boris Brezillon writes: > Hello, > > As suggested by Ville, this version uses the already available TV > margin props to define left/right/top/bottom margins insted of adding > new underscan props. > > This works pretty well for what we want to do in VC4: allow one to > define the visible area on a TV. > > The first 2 patches are fixing the existing doc, patch 3 is allowing > one to create and attach TV margins independently of the TV connector > props. Finally, patch 4 and 5 add support for those props to the VC4 > driver. This series is: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/vc4: Add support for X/Y reflection
Boris Brezillon writes: > Add support for X/Y reflection when the plane is using linear or T-tiled > formats. X/Y reflection hasn't been tested on SAND formats, so we reject > them until proper testing/debugging has been done. > > Signed-off-by: Boris Brezillon > --- > Eric, I dropped your Reviewed-by as this version also contains support > for rotation/reflection on SAND formats. > > Changes in v2: > - Use drm_rotation_simplify() to support ROTATE_180 > - Support rotation/reflection on SAND formats This one still looks good to me. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/vc4: Fix negative X/Y positioning on SAND planes
Boris Brezillon writes:
> Commit 3e407417b192 ("drm/vc4: Fix X/Y positioning of planes using
> T_TILES modifier") fixed the problem with T_TILES format, but left
> things in a non-working state for SAND formats. Address that now.
>
> Signed-off-by: Boris Brezillon
> ---
> Hi Eric,
>
> So, I finally spent time debugging my SANDXXX pattern generator and
> could validate that negative X/Y positioning does not work (which I
> was expecting :-)). The fix turns out to be simpler than I thought
> (much simpler than on T-tiles), and we now have negative X/Y
> positioning working on all kind of formats.
>
> Regards,
>
> Boris
>
> Changes in v2:
> - New patch
> ---
> drivers/gpu/drm/vc4/vc4_plane.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 75db62cbe468..3132f5e1d16a 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -595,6 +595,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> case DRM_FORMAT_MOD_BROADCOM_SAND128:
> case DRM_FORMAT_MOD_BROADCOM_SAND256: {
> uint32_t param = fourcc_mod_broadcom_param(fb->modifier);
> + u32 tile_w, tile, x_off, pix_per_tile;
>
> /* Column-based NV12 or RGBA.
>*/
> @@ -614,12 +615,15 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> switch (base_format_mod) {
> case DRM_FORMAT_MOD_BROADCOM_SAND64:
> tiling = SCALER_CTL0_TILING_64B;
> + tile_w = 64;
> break;
> case DRM_FORMAT_MOD_BROADCOM_SAND128:
> tiling = SCALER_CTL0_TILING_128B;
> + tile_w = 128;
> break;
> case DRM_FORMAT_MOD_BROADCOM_SAND256:
> tiling = SCALER_CTL0_TILING_256B_OR_T;
> + tile_w = 256;
> break;
> default:
> break;
> @@ -630,6 +634,28 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> return -EINVAL;
> }
>
> + pix_per_tile = tile_w / fb->format->cpp[0];
> + tile = vc4_state->src_x / pix_per_tile;
> + x_off = vc4_state->src_x % pix_per_tile;
> +
> + /* Adjust the base pointer to the first pixel to be scanned
> + * out.
> + */
> + for (i = 0; i < num_planes; i++) {
> + vc4_state->offsets[i] += param * tile_w * tile;
> + vc4_state->offsets[i] += (vc4_state->src_y /
> + (i ? v_subsample : 1)) *
> + tile_w;
> + }
> +
> + /*
> + * SCALER_PITCH0_SINK_PIX does not seem to work for SAND
> + * formats. Specify a negative START_X instead, even if it's
> + * less efficient.
> + */
> + if (x_off)
> + vc4_state->crtc_x = -x_off;
Wait. If we were supposed to start at a nonzero x position within the
FB, then we instead put the image off the left hand side of the screen?
That seems wrong.
Did you test if we can just vc4_state->offsets[i] += x_off * cpp?
> +
> pitch0 = VC4_SET_FIELD(param, SCALER_TILE_HEIGHT);
> break;
> }
> @@ -655,7 +681,8 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> vc4_state->pos0_offset = vc4_state->dlist_count;
> vc4_dlist_write(vc4_state,
> VC4_SET_FIELD(state->alpha >> 8,
> SCALER_POS0_FIXED_ALPHA) |
> - VC4_SET_FIELD(vc4_state->crtc_x, SCALER_POS0_START_X) |
> + VC4_SET_FIELD(vc4_state->crtc_x &
> SCALER_POS0_START_X_MASK,
> + SCALER_POS0_START_X) |
> VC4_SET_FIELD(vc4_state->crtc_y, SCALER_POS0_START_Y));
>
> /* Position Word 1: Scaled Image Dimensions. */
> --
> 2.17.1
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2 5/5] drm/msm: subclass work object for vblank events
On 2018-11-07 07:55, Sean Paul wrote:
On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this redundant list
and its protection mechanism, if we subclass the
work object to encapsulate vblank event parameters.
changes in v2:
- subclass optimization on system wq (Sean Paul)
I wouldn't do it like this, tbh. One problem is that you've lost your
flush() on
unbind, so there's no way to know if you have workers in the wild
waiting
to
enable/disable vblank.
I believe I didnt respond to this quesition of yours. This patch is
removing the flush on the work. But flush_workqueue before destroying
the WQ
will make sure all the queued work jobs are run to completion.
To honor the comment, I will fix the patch to move the flush/destroy wq
before the
irq_unininstall.
Thanks,
Jeykumar S.
Another issues is that AFAICT, we don't need a queue of
enables/disables,
but
rather just the last requested state (ie: should we be on or off). So
things
don't need to be this complicated (and we're possibly thrashing vblank
on/off
for no reason).
I'm still of the mind that you should just make this synchronous and be
done
with the threads (especially since we're still uncovering/introducing
races!).
Sean
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 67
+--
drivers/gpu/drm/msm/msm_drv.h | 7 -
2 files changed, 20 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c
b/drivers/gpu/drm/msm/msm_drv.c
index 6d6c73b..8da5be2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -203,61 +203,44 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
-struct vblank_event {
- struct list_head node;
+struct msm_vblank_work {
+ struct work_struct work;
int crtc_id;
bool enable;
+ struct msm_drm_private *priv;
};
static void vblank_ctrl_worker(struct work_struct *work)
{
- struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
- struct msm_vblank_ctrl,
work);
- struct msm_drm_private *priv = container_of(vbl_ctrl,
- struct msm_drm_private,
vblank_ctrl);
+ struct msm_vblank_work *vbl_work = container_of(work,
+ struct msm_vblank_work,
work);
+ struct msm_drm_private *priv = vbl_work->priv;
struct msm_kms *kms = priv->kms;
- struct vblank_event *vbl_ev, *tmp;
- unsigned long flags;
-
- spin_lock_irqsave(_ctrl->lock, flags);
- list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node)
{
- list_del(_ev->node);
- spin_unlock_irqrestore(_ctrl->lock, flags);
-
- if (vbl_ev->enable)
- kms->funcs->enable_vblank(kms,
-
priv->crtcs[vbl_ev->crtc_id]);
- else
- kms->funcs->disable_vblank(kms,
-
priv->crtcs[vbl_ev->crtc_id]);
- kfree(vbl_ev);
-
- spin_lock_irqsave(_ctrl->lock, flags);
- }
+ if (vbl_work->enable)
+ kms->funcs->enable_vblank(kms,
priv->crtcs[vbl_work->crtc_id]);
+ else
+ kms->funcs->disable_vblank(kms,
priv->crtcs[vbl_work->crtc_id]);
- spin_unlock_irqrestore(_ctrl->lock, flags);
+ kfree(vbl_work);
}
static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
int crtc_id, bool enable)
{
- struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
- struct vblank_event *vbl_ev;
- unsigned long flags;
+ struct msm_vblank_work *vbl_work;
- vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
- if (!vbl_ev)
+ vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
+ if (!vbl_work)
return -ENOMEM;
- vbl_ev->crtc_id = crtc_id;
- vbl_ev->enable = enable;
+ INIT_WORK(_work->work, vblank_ctrl_worker);
- spin_lock_irqsave(_ctrl->lock, flags);
- list_add_tail(_ev->node, _ctrl->event_list);
- spin_unlock_irqrestore(_ctrl->lock, flags);
+ vbl_work->crtc_id = crtc_id;
+ vbl_work->enable = enable;
+ vbl_work->priv = priv;
- schedule_work(_ctrl->work);
+ schedule_work(_work->work);
return 0;
}
@@ -269,14 +252,13 @@ static int msm_drm_uninit(struct device *dev)
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm_mdss *mdss = priv->mdss;
- struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
- struct vblank_event *vbl_ev, *tmp;
int i;
/* We must cancel and cleanup any pending vblank enable/disable
* work before drm_irq_uninstall() to avoid work re-enabling an
Re: [PATCH 1/2] drm/sched: Refactor ring mirror list handling.
Am 06.12.18 um 18:41 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
Just briefly skimmed over this, but it looks exactly like what I had in
mind.
Need to give that a more detailed thought tomorrow,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++---
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 8 +--
drivers/gpu/drm/scheduler/sched_main.c | 86 +++---
drivers/gpu/drm/v3d/v3d_sched.c| 11 ++--
include/drm/gpu_scheduler.h| 10 ++--
5 files changed, 83 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ef36cc5..42111d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3292,17 +3292,16 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
/* block all schedulers and reset given job's ring */
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
+ bool park_only = job && job->base.sched != >sched;
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_stop(>sched, job ? >base : NULL,
park_only);
- if (job && job->base.sched != >sched)
+ if (park_only)
continue;
- drm_sched_hw_job_reset(>sched, job ? >base : NULL);
-
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3445,6 +3444,7 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
struct amdgpu_job *job)
{
int i;
+ bool unpark_only;
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -3456,10 +3456,13 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
* or all rings (in the case @job is NULL)
* after above amdgpu_reset accomplished
*/
- if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+ unpark_only = (job && job->base.sched != >sched) ||
+ adev->asic_reset_res;
+
+ if (!unpark_only)
+ drm_sched_resubmit_jobs(>sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(>sched, unpark_only);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..fab3b51 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(>sched, sched_job);
+ drm_sched_stop(>sched, sched_job, false);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(>sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(>sched);
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..8fb7f86 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb);
-static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct work_struct
*work)
* @bad: bad scheduler job
*
*/
-void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
+void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad,
+ bool park_only)
{
struct drm_sched_job *s_job;
struct drm_sched_entity *entity, *tmp;
unsigned long flags;
+ struct list_head wait_list;
int i;
+ kthread_park(sched->thread);
+ if (park_only)
+ return;
Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2
Am 06.12.18 um 17:58 schrieb Chris Wilson: > Quoting jgli...@redhat.com (2018-12-06 15:47:04) >> From: Jérôme Glisse >> >> The debugfs take reference on fence without dropping them. Also the >> rcu section are not well balance. Fix all that ... > Wouldn't the code be a lot simpler (and a consistent snapshot) if it used > reservation_object_get_fences_rcu()? Yeah, thought about that as well. Or even better move that code into reservation_object.c as reservation_object_show_fences() or something like that. Christian. > -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: balance refcount inbalance
Am 06.12.18 um 17:18 schrieb jgli...@redhat.com: > From: Jérôme Glisse > > The debugfs take reference on fence without dropping them. > > Signed-off-by: Jérôme Glisse > Cc: Christian König > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: linux-me...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linaro-mm-...@lists.linaro.org > Cc: Stéphane Marchesin > Cc: sta...@vger.kernel.org Reviewed-by: Christian König > --- > drivers/dma-buf/dma-buf.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 13884474d158..69842145c223 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1069,6 +1069,7 @@ static int dma_buf_debug_show(struct seq_file *s, void > *unused) > fence->ops->get_driver_name(fence), > fence->ops->get_timeline_name(fence), > dma_fence_is_signaled(fence) ? "" : "un"); > + dma_fence_put(fence); > } > rcu_read_unlock(); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sched: Rework HW fence processing.
On 12/06/2018 12:41 PM, Andrey Grodzovsky wrote:
> Expedite job deletion from ring mirror list to the HW fence signal
> callback instead from finish_work, together with waiting for all
> such fences to signal in drm_sched_stop we garantee that
> already signaled job will not be processed twice.
> Remove the sched finish fence callback and just submit finish_work
> directly from the HW fence callback.
>
> Suggested-by: Christian Koenig
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/scheduler/sched_fence.c | 4 +++-
> drivers/gpu/drm/scheduler/sched_main.c | 39
> -
> include/drm/gpu_scheduler.h | 10 +++--
> 3 files changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
> b/drivers/gpu/drm/scheduler/sched_fence.c
> index d8d2dff..e62c239 100644
> --- a/drivers/gpu/drm/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> @@ -151,7 +151,8 @@ struct drm_sched_fence *to_drm_sched_fence(struct
> dma_fence *f)
> EXPORT_SYMBOL(to_drm_sched_fence);
>
> struct drm_sched_fence *drm_sched_fence_create(struct drm_sched_entity
> *entity,
> -void *owner)
> +void *owner,
> +struct drm_sched_job *s_job)
> {
> struct drm_sched_fence *fence = NULL;
> unsigned seq;
> @@ -163,6 +164,7 @@ struct drm_sched_fence *drm_sched_fence_create(struct
> drm_sched_entity *entity,
> fence->owner = owner;
> fence->sched = entity->rq->sched;
> spin_lock_init(>lock);
> + fence->s_job = s_job;
>
> seq = atomic_inc_return(>fence_seq);
> dma_fence_init(>scheduled, _sched_fence_ops_scheduled,
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 8fb7f86..2860037 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -284,31 +284,17 @@ static void drm_sched_job_finish(struct work_struct
> *work)
> cancel_delayed_work_sync(>work_tdr);
>
> spin_lock_irqsave(>job_list_lock, flags);
> - /* remove job from ring_mirror_list */
> - list_del_init(_job->node);
> - /* queue TDR for next job */
> drm_sched_start_timeout(sched);
> spin_unlock_irqrestore(>job_list_lock, flags);
>
> sched->ops->free_job(s_job);
> }
>
> -static void drm_sched_job_finish_cb(struct dma_fence *f,
> - struct dma_fence_cb *cb)
> -{
> - struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
> - finish_cb);
> - schedule_work(>finish_work);
> -}
> -
> static void drm_sched_job_begin(struct drm_sched_job *s_job)
> {
> struct drm_gpu_scheduler *sched = s_job->sched;
> unsigned long flags;
>
> - dma_fence_add_callback(_job->s_fence->finished, _job->finish_cb,
> -drm_sched_job_finish_cb);
> -
> spin_lock_irqsave(>job_list_lock, flags);
> list_add_tail(_job->node, >ring_mirror_list);
> drm_sched_start_timeout(sched);
> @@ -418,13 +404,17 @@ void drm_sched_start(struct drm_gpu_scheduler *sched,
> bool unpark_only)
> {
> struct drm_sched_job *s_job, *tmp;
> bool found_guilty = false;
> - unsigned long flags;
> int r;
>
> if (unpark_only)
> goto unpark;
>
> - spin_lock_irqsave(>job_list_lock, flags);
> + /*
> + * Locking the list is not required here as the sched thread is parked
> + * so no new jobs are being pushed in to HW and in drm_sched_stop we
> + * flushed any in flight jobs who didn't signal yet.
The comment is inaccurate here - it's supposed to be ' any in flight
jobs who already have their
sched finished signaled and they are removed from the mirror ring list
at that point already anyway'
I will fix this text later with other comments received on the patches.
Andrey
> Also concurrent
> + * GPU recovers can't run in parallel.
> + */
> list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
> struct drm_sched_fence *s_fence = s_job->s_fence;
> struct dma_fence *fence;
> @@ -453,7 +443,6 @@ void drm_sched_start(struct drm_gpu_scheduler *sched,
> bool unpark_only)
> }
>
> drm_sched_start_timeout(sched);
> - spin_unlock_irqrestore(>job_list_lock, flags);
>
> unpark:
> kthread_unpark(sched->thread);
> @@ -505,7 +494,7 @@ int drm_sched_job_init(struct drm_sched_job *job,
> job->sched = sched;
> job->entity = entity;
> job->s_priority = entity->rq - sched->sched_rq;
> - job->s_fence = drm_sched_fence_create(entity, owner);
> + job->s_fence = drm_sched_fence_create(entity, owner, job);
> if (!job->s_fence)
> return -ENOMEM;
> job->id
[PATCH] drm/tegra: sor: Remove temporary workaround
From: Thierry Reding
Remove the temporary workaround of storing the Tegra186 HDMI/DP I/O pad
ID in the SOR driver. The definition has long been available in the
soc/tegra/pmc.h header file.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 22a54434a757..07a077bd73e4 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -31,14 +31,6 @@
#include "sor.h"
#include "trace.h"
-/*
- * XXX Remove this after the commit adding it to soc/tegra/pmc.h has been
- * merged. Having this around after the commit is merged should be safe since
- * the preprocessor will effectively replace all occurrences and therefore no
- * duplicate will be defined.
- */
-#define TEGRA_IO_PAD_HDMI_DP0 26
-
#define SOR_REKEY 0x38
struct tegra_sor_hdmi_settings {
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: sor: Reset the SOR if possible
From: Thierry Reding
If the SOR is already up and running when the kernel driver is probed,
setting a mode will typically fail. This can be seen for example on
Jetson TX2. Under certain circumstances the generic power domain code
will cause the SOR to be reset. However, if the power domain is never
powered off (this can happen if the HDA controller is enabled, which
is part of the same power domain as the SOR), then the SOR will end up
not getting reset and fail to properly set a mode.
To work around this, try to get the reset control and assert/deassert
it, irrespective of whether or not a generic power domain is attached
to the SOR. On platforms where the kernel implements generic power
domains (up to Tegra210) this will fail, because the power domain will
already have acquired an exclusive reference to the reset control. But
on recent platforms there the BPMP provides an ABI to control power
domains, it's possible to acquire the reset control from SOR and use
it to put the SOR into a known good state at probe time.
The proper solution for this is to make the SOR driver capable of
dealing with hardware that's already up and running (by first grace-
fully shutting it down, or perhaps by seamlessly transitioning to the
kernel driver and taking over the running display configuration). That
is fairly involved, though, so we'll go with this quickfix for now.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 07a077bd73e4..ef8692b7075a 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3340,14 +3340,23 @@ static int tegra_sor_probe(struct platform_device *pdev)
goto remove;
}
- if (!pdev->dev.pm_domain) {
- sor->rst = devm_reset_control_get(>dev, "sor");
- if (IS_ERR(sor->rst)) {
- err = PTR_ERR(sor->rst);
+ sor->rst = devm_reset_control_get(>dev, "sor");
+ if (IS_ERR(sor->rst)) {
+ err = PTR_ERR(sor->rst);
+
+ if (err != -EBUSY || WARN_ON(!pdev->dev.pm_domain)) {
dev_err(>dev, "failed to get reset control: %d\n",
err);
goto remove;
}
+
+ /*
+* At this point, the reset control is most likely being used
+* by the generic power domain implementation. With any luck
+* the power domain will have taken care of resetting the SOR
+* and we don't have to do anything.
+*/
+ sor->rst = NULL;
}
sor->clk = devm_clk_get(>dev, NULL);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/sched: Refactor ring mirror list handling.
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++---
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 8 +--
drivers/gpu/drm/scheduler/sched_main.c | 86 +++---
drivers/gpu/drm/v3d/v3d_sched.c| 11 ++--
include/drm/gpu_scheduler.h| 10 ++--
5 files changed, 83 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ef36cc5..42111d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3292,17 +3292,16 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
/* block all schedulers and reset given job's ring */
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
+ bool park_only = job && job->base.sched != >sched;
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_stop(>sched, job ? >base : NULL,
park_only);
- if (job && job->base.sched != >sched)
+ if (park_only)
continue;
- drm_sched_hw_job_reset(>sched, job ? >base : NULL);
-
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3445,6 +3444,7 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
struct amdgpu_job *job)
{
int i;
+ bool unpark_only;
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -3456,10 +3456,13 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
* or all rings (in the case @job is NULL)
* after above amdgpu_reset accomplished
*/
- if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+ unpark_only = (job && job->base.sched != >sched) ||
+ adev->asic_reset_res;
+
+ if (!unpark_only)
+ drm_sched_resubmit_jobs(>sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(>sched, unpark_only);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..fab3b51 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(>sched, sched_job);
+ drm_sched_stop(>sched, sched_job, false);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(>sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(>sched);
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..8fb7f86 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
*cb);
-static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct work_struct
*work)
* @bad: bad scheduler job
*
*/
-void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
+void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad,
+ bool park_only)
{
struct drm_sched_job *s_job;
struct drm_sched_entity *entity, *tmp;
unsigned long flags;
+ struct list_head wait_list;
int i;
+ kthread_park(sched->thread);
+ if (park_only)
+ return;
+
+ INIT_LIST_HEAD(_list);
+
spin_lock_irqsave(>job_list_lock, flags);
list_for_each_entry_reverse(s_job,
[PATCH 2/2] drm/sched: Rework HW fence processing.
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit finish_work
directly from the HW fence callback.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_fence.c | 4 +++-
drivers/gpu/drm/scheduler/sched_main.c | 39 -
include/drm/gpu_scheduler.h | 10 +++--
3 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
b/drivers/gpu/drm/scheduler/sched_fence.c
index d8d2dff..e62c239 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -151,7 +151,8 @@ struct drm_sched_fence *to_drm_sched_fence(struct dma_fence
*f)
EXPORT_SYMBOL(to_drm_sched_fence);
struct drm_sched_fence *drm_sched_fence_create(struct drm_sched_entity *entity,
- void *owner)
+ void *owner,
+ struct drm_sched_job *s_job)
{
struct drm_sched_fence *fence = NULL;
unsigned seq;
@@ -163,6 +164,7 @@ struct drm_sched_fence *drm_sched_fence_create(struct
drm_sched_entity *entity,
fence->owner = owner;
fence->sched = entity->rq->sched;
spin_lock_init(>lock);
+ fence->s_job = s_job;
seq = atomic_inc_return(>fence_seq);
dma_fence_init(>scheduled, _sched_fence_ops_scheduled,
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 8fb7f86..2860037 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -284,31 +284,17 @@ static void drm_sched_job_finish(struct work_struct *work)
cancel_delayed_work_sync(>work_tdr);
spin_lock_irqsave(>job_list_lock, flags);
- /* remove job from ring_mirror_list */
- list_del_init(_job->node);
- /* queue TDR for next job */
drm_sched_start_timeout(sched);
spin_unlock_irqrestore(>job_list_lock, flags);
sched->ops->free_job(s_job);
}
-static void drm_sched_job_finish_cb(struct dma_fence *f,
- struct dma_fence_cb *cb)
-{
- struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-finish_cb);
- schedule_work(>finish_work);
-}
-
static void drm_sched_job_begin(struct drm_sched_job *s_job)
{
struct drm_gpu_scheduler *sched = s_job->sched;
unsigned long flags;
- dma_fence_add_callback(_job->s_fence->finished, _job->finish_cb,
- drm_sched_job_finish_cb);
-
spin_lock_irqsave(>job_list_lock, flags);
list_add_tail(_job->node, >ring_mirror_list);
drm_sched_start_timeout(sched);
@@ -418,13 +404,17 @@ void drm_sched_start(struct drm_gpu_scheduler *sched,
bool unpark_only)
{
struct drm_sched_job *s_job, *tmp;
bool found_guilty = false;
- unsigned long flags;
int r;
if (unpark_only)
goto unpark;
- spin_lock_irqsave(>job_list_lock, flags);
+ /*
+* Locking the list is not required here as the sched thread is parked
+* so no new jobs are being pushed in to HW and in drm_sched_stop we
+* flushed any in flight jobs who didn't signal yet. Also concurrent
+* GPU recovers can't run in parallel.
+*/
list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
struct drm_sched_fence *s_fence = s_job->s_fence;
struct dma_fence *fence;
@@ -453,7 +443,6 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool
unpark_only)
}
drm_sched_start_timeout(sched);
- spin_unlock_irqrestore(>job_list_lock, flags);
unpark:
kthread_unpark(sched->thread);
@@ -505,7 +494,7 @@ int drm_sched_job_init(struct drm_sched_job *job,
job->sched = sched;
job->entity = entity;
job->s_priority = entity->rq - sched->sched_rq;
- job->s_fence = drm_sched_fence_create(entity, owner);
+ job->s_fence = drm_sched_fence_create(entity, owner, job);
if (!job->s_fence)
return -ENOMEM;
job->id = atomic64_inc_return(>job_id_count);
@@ -593,15 +582,25 @@ static void drm_sched_process_job(struct dma_fence *f,
struct dma_fence_cb *cb)
struct drm_sched_fence *s_fence =
container_of(cb, struct drm_sched_fence, cb);
struct drm_gpu_scheduler *sched = s_fence->sched;
+ struct drm_sched_job *s_job = s_fence->s_job;
+ unsigned long flags;
+
+ cancel_delayed_work(>work_tdr);
- dma_fence_get(_fence->finished);
Re: [PATCH 2/2] drm/ttm: Use pr_debug for all output from ttm_bo_evict
On 2018-12-06 5:46 p.m., Joe Perches wrote: > On Thu, 2018-12-06 at 17:39 +0800, Zhang, Jerry(Junwei) wrote: >> On 12/6/18 5:33 PM, Koenig, Christian wrote: >>> Am 06.12.18 um 10:09 schrieb Michel Dänzer: On 2018-12-06 3:43 a.m., Zhang, Jerry(Junwei) wrote: > On 12/6/18 12:56 AM, Michel Dänzer wrote: >> From: Michel Dänzer >> >> All the output is related, so it should all be printed the same way. >> Some of it was using pr_debug, but some of it appeared in dmesg by >> default. The caller should handle failure, so there's no need to spam >> dmesg with potentially quite a lot of output by default. >> >> Signed-off-by: Michel Dänzer > Sounds reasonable, but personally prefer to show error when some > vital incident happens, e.g. no memory on eviction. The amdgpu driver still prints these in that case: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* amdgpu_cs_list_validate(validated) failed. [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission! > > Aren't dump_stack()s already done on all these allocation failures? > I don't notice any use of __GFP_NOWARN on generic allocations in drm. Most of the time, these messages are due to being unable to allocate a TTM BO or move it where it needs to go, not due to the kernel failing to allocate memory in general. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2
Quoting jgli...@redhat.com (2018-12-06 15:47:04) > From: Jérôme Glisse > > The debugfs take reference on fence without dropping them. Also the > rcu section are not well balance. Fix all that ... Wouldn't the code be a lot simpler (and a consistent snapshot) if it used reservation_object_get_fences_rcu()? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: Use pr_debug for all output from ttm_bo_evict
On Thu, 2018-12-06 at 17:39 +0800, Zhang, Jerry(Junwei) wrote: > On 12/6/18 5:33 PM, Koenig, Christian wrote: > > Am 06.12.18 um 10:09 schrieb Michel Dänzer: > > > On 2018-12-06 3:43 a.m., Zhang, Jerry(Junwei) wrote: > > > > On 12/6/18 12:56 AM, Michel Dänzer wrote: > > > > > From: Michel Dänzer > > > > > > > > > > All the output is related, so it should all be printed the same way. > > > > > Some of it was using pr_debug, but some of it appeared in dmesg by > > > > > default. The caller should handle failure, so there's no need to spam > > > > > dmesg with potentially quite a lot of output by default. > > > > > > > > > > Signed-off-by: Michel Dänzer > > > > Sounds reasonable, but personally prefer to show error when some > > > > vital incident happens, e.g. no memory on eviction. > > > The amdgpu driver still prints these in that case: > > > > > >[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* > > > amdgpu_cs_list_validate(validated) failed. > > >[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command > > > submission! Aren't dump_stack()s already done on all these allocation failures? I don't notice any use of __GFP_NOWARN on generic allocations in drm. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1.1 26/29] drm/omap: venc: Use drm_display_mode natively
Replace internal usage of struct videomode with struct drm_display_mode
in order to avoid converting needlessly between the data structures.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Set mode.crtc_* fields and mode name in venc_check_timings()
---
drivers/gpu/drm/omapdrm/dss/venc.c | 90 +++---
1 file changed, 44 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
b/drivers/gpu/drm/omapdrm/dss/venc.c
index 7bce5898654a..f2cbecfd05b5 100644
--- a/drivers/gpu/drm/omapdrm/dss/venc.c
+++ b/drivers/gpu/drm/omapdrm/dss/venc.c
@@ -267,38 +267,34 @@ enum venc_videomode {
VENC_MODE_NTSC,
};
-static const struct videomode omap_dss_pal_vm = {
- .hactive= 720,
- .vactive= 574,
- .pixelclock = 1350,
- .hsync_len = 64,
- .hfront_porch = 12,
- .hback_porch= 68,
- .vsync_len = 5,
- .vfront_porch = 5,
- .vback_porch= 41,
-
- .flags = DISPLAY_FLAGS_INTERLACED | DISPLAY_FLAGS_HSYNC_LOW |
- DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_DE_HIGH |
- DISPLAY_FLAGS_PIXDATA_POSEDGE |
- DISPLAY_FLAGS_SYNC_NEGEDGE,
+static const struct drm_display_mode omap_dss_pal_mode = {
+ .hdisplay = 720,
+ .hsync_start= 732,
+ .hsync_end = 796,
+ .htotal = 864,
+ .vdisplay = 574,
+ .vsync_start= 579,
+ .vsync_end = 584,
+ .vtotal = 625,
+ .clock = 13500,
+
+ .flags = DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_NHSYNC |
+ DRM_MODE_FLAG_NVSYNC,
};
-static const struct videomode omap_dss_ntsc_vm = {
- .hactive= 720,
- .vactive= 482,
- .pixelclock = 1350,
- .hsync_len = 64,
- .hfront_porch = 16,
- .hback_porch= 58,
- .vsync_len = 6,
- .vfront_porch = 6,
- .vback_porch= 31,
-
- .flags = DISPLAY_FLAGS_INTERLACED | DISPLAY_FLAGS_HSYNC_LOW |
- DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_DE_HIGH |
- DISPLAY_FLAGS_PIXDATA_POSEDGE |
- DISPLAY_FLAGS_SYNC_NEGEDGE,
+static const struct drm_display_mode omap_dss_ntsc_mode = {
+ .hdisplay = 720,
+ .hsync_start= 736,
+ .hsync_end = 800,
+ .htotal = 858,
+ .vdisplay = 482,
+ .vsync_start= 488,
+ .vsync_end = 494,
+ .vtotal = 525,
+ .clock = 13500,
+
+ .flags = DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_NHSYNC |
+ DRM_MODE_FLAG_NVSYNC,
};
struct venc_device {
@@ -521,21 +517,19 @@ static void venc_display_disable(struct omap_dss_device
*dssdev)
static int venc_get_modes(struct omap_dss_device *dssdev,
struct drm_connector *connector)
{
- static const struct videomode *modes[] = {
- _dss_pal_vm,
- _dss_ntsc_vm,
+ static const struct drm_display_mode *modes[] = {
+ _dss_pal_mode,
+ _dss_ntsc_mode,
};
unsigned int i;
for (i = 0; i < ARRAY_SIZE(modes); ++i) {
struct drm_display_mode *mode;
- mode = drm_mode_create(connector->dev);
+ mode = drm_mode_duplicate(connector->dev, modes[i]);
if (!mode)
return i;
- drm_display_mode_from_videomode(modes[i], mode);
-
mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
drm_mode_set_name(mode);
drm_mode_probed_add(connector, mode);
@@ -549,14 +543,14 @@ static enum venc_videomode venc_get_videomode(const
struct drm_display_mode *mod
if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
return VENC_MODE_UNKNOWN;
- if (mode->clock == omap_dss_pal_vm.pixelclock / 1000 &&
- mode->hdisplay == omap_dss_pal_vm.hactive &&
- mode->vdisplay == omap_dss_pal_vm.vactive)
+ if (mode->clock == omap_dss_pal_mode.clock &&
+ mode->hdisplay == omap_dss_pal_mode.hdisplay &&
+ mode->vdisplay == omap_dss_pal_mode.vdisplay)
return VENC_MODE_PAL;
- if (mode->clock == omap_dss_ntsc_vm.pixelclock / 1000 &&
- mode->hdisplay == omap_dss_ntsc_vm.hactive &&
- mode->vdisplay == omap_dss_ntsc_vm.vactive)
+ if (mode->clock == omap_dss_ntsc_mode.clock &&
+ mode->hdisplay == omap_dss_ntsc_mode.hdisplay &&
+ mode->vdisplay == omap_dss_ntsc_mode.vdisplay)
return VENC_MODE_NTSC;
return VENC_MODE_UNKNOWN;
@@ -597,16 +591,20 @@ static int venc_check_timings(struct omap_dss_device
*dssdev,
switch (venc_get_videomode(mode)) {
case
Re: [PATCH 1/2] drm: Only #define DEBUG if CONFIG_DYNAMIC_DEBUG is disabled
On Thu, 2018-12-06 at 15:41 +0100, Michel Dänzer wrote: > On 2018-12-06 1:23 p.m., Joe Perches wrote: > > On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote: > > > In contrast to the 2b case, the pr_debug output isn't visible by default > > > with 1b, so the latter doesn't fit "always produce output" either. > > > > I think you are mistaken here. > > Still puzzled as to what you're hoping to achieve with that kind of > language. None of the confusion about this patch has been on my part. :) Doubtful. > > Adding #define DEBUG as Chris did enables pr_debug output > > and is your 1b. > > > > Perhaps your default console logging level is set to a > > non-default value. > > I have CONFIG_DYNAMIC_DEBUG enabled in my kernels. The problem addressed > by this patch is that messages from drm_debug_printer are visible by > default (case 2b), whereas they shouldn't be (case 2a, like 1b). The default for config_dynamic_debug when DEBUG is defined is to output the message equivalent to when DEBUG is defined and config_dynamic_debug is not. That's a good thing and has been the general default since 2011. You want to override that, I suppose that's OK but it's definitely not a _fix_ as you have written. It's just a change in behavior. You added a "Fixes:" line. I believe that wrong. A long time ago, at my suggestion: commit b558c96ffa53f4b3dd52b774e4fb7a52982ab52b Author: Jim Cromie Date: Mon Dec 19 17:11:18 2011 -0500 dynamic_debug: make dynamic-debug supersede DEBUG ccflag If CONFIG_DYNAMIC_DEBUG is defined, honor it over DEBUG, so that pr_debug()s are controllable, instead of always-on. When DEBUG is also defined, change _DPRINTK_FLAGS_DEFAULT to enable printing by default. cheers, Joe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping
On Thu, Dec 06, 2018 at 04:08:12PM +, Koenig, Christian wrote: > Am 06.12.18 um 16:21 schrieb Jerome Glisse: > > On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote: > >> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com: > >>> From: Jérôme Glisse > >>> > >>> The debugfs take reference on fence without dropping them. Also the > >>> rcu section are not well balance. Fix all that ... > >>> > >>> Signed-off-by: Jérôme Glisse > >>> Cc: Christian König > >>> Cc: Daniel Vetter > >>> Cc: Sumit Semwal > >>> Cc: linux-me...@vger.kernel.org > >>> Cc: dri-devel@lists.freedesktop.org > >>> Cc: linaro-mm-...@lists.linaro.org > >>> Cc: Stéphane Marchesin > >>> Cc: sta...@vger.kernel.org > >> Well NAK, you are now taking the RCU lock twice and dropping the RCU and > >> still accessing fobj has a huge potential for accessing freed up memory. > >> > >> The only correct thing I can see here is to grab a reference to the > >> fence before printing any info on it, > >> Christian. > > Hu ? That is exactly what i am doing, take reference under rcu, > > rcu_unlock print the fence info, drop the fence reference, rcu > > lock rinse and repeat ... > > > > Note that the fobj in _existing_ code is access outside the rcu > > end that there is an rcu imbalance in that code ie a lonlely > > rcu_unlock after the for loop. > > > > So that the existing code is broken. > > No, the existing code is perfectly fine. > > Please note the break in the loop before the rcu_unlock(); > > if (!read_seqcount_retry(>seq, seq)) > > break; <- HERE! > > rcu_read_unlock(); > > } > > So your patch breaks that and take the RCU read lock twice. Ok missed that, i wonder if the refcount in balance explains the crash that was reported to me ... i sent a patch just for that. Thank you for reviewing and pointing out the code i was oblivious too :) Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: balance refcount inbalance
From: Jérôme Glisse The debugfs take reference on fence without dropping them. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Daniel Vetter Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Cc: Stéphane Marchesin Cc: sta...@vger.kernel.org --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 13884474d158..69842145c223 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1069,6 +1069,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) fence->ops->get_driver_name(fence), fence->ops->get_timeline_name(fence), dma_fence_is_signaled(fence) ? "" : "un"); + dma_fence_put(fence); } rcu_read_unlock(); -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMDGPU with 4.19.x kernel - cannot enable DPM
the default is -1 (auto). Power management has always been enabled by default on CI. the option is mainly there to disable power management (amdgpu.dpm=0). Since there are two implementations for CI (the older one ported from radeon and the newer powerplay one), explicitly setting it to 1 was used to select between the two implementations for testing purposes. The default implementation changed. Alex On Thu, Dec 6, 2018 at 11:12 AM Chris Rankin wrote: > > OK, thanks. Although for reference, if DPM is now enabled by default I would > have expected amdgpu.dpm=1 to be a no-op rather than cause a black screen and > an oops... ;-). > > Cheers, > Chris > > On Thu, 6 Dec 2018 at 16:09, Alex Deucher wrote: >> >> Then you should be fine to remove it. >> >> Alex >> On Thu, Dec 6, 2018 at 10:58 AM Chris Rankin wrote: >> > >> > Yes, all 4.19.x kernels have been fine without the amdgpu.dpm=1 kernel >> > parameter. In fact, this is how I am running my kernel right now. With the >> > 4.18.x series I did specify amdgpu.dpm=1 explicitly on the GRUB2 command >> > line, and I inherited this setting when I migrated to 4.19. >> > >> > On Thu, 6 Dec 2018 at 15:53, Alex Deucher wrote: >> >> >> >> Does it work without amdgpu.dpm=1 on your kernel command line? You >> >> don't need to specify it, it;s enabled by default. The default dpm >> >> implementation changed so specifying dpm=1 will change the dpm >> >> implementation used by the driver. >> >> >> >> Alex >> >> On Thu, Dec 6, 2018 at 10:47 AM Alex Deucher >> >> wrote: >> >> > >> >> > I can't reproduce this. Can you bisect? >> >> > >> >> > Alex >> >> > On Thu, Dec 6, 2018 at 8:38 AM Chris Rankin wrote: >> >> > > >> >> > > Hi, >> >> > > >> >> > > I'm still unable to enable DPM with my R7 360, AMDGPU driver, Linux >> >> > > 4.19.7 kernel. Dmesg log is attached, showing that it is correctly >> >> > > using PCIE gen2 speeds. >> >> > > >> >> > > Cheers, >> >> > > Chris >> >> > > >> >> > > On Sat, 24 Nov 2018 at 13:12, Chris Rankin wrote: >> >> > >> >> >> > >> Hi, thanks for the reply. >> >> > >> >> >> > >> That patch doesn't solve my issue, although it does mean that the >> >> > >> DRM layer no longer tries to enable "gen 3" PCIE link speeds. >> >> > >> I have attached the dmesg output for a stock 4.19.4 kernel that also >> >> > >> has your patch applied. >> >> > >> >> >> > >> Cheers, >> >> > >> Chris >> >> > >> >> >> > >> On Fri, 23 Nov 2018 at 20:25, Alex Deucher >> >> > >> wrote: >> >> > >>> >> >> > >>> On Thu, Nov 22, 2018 at 7:23 PM Chris Rankin >> >> > >>> wrote: >> >> > >>> > >> >> > >>> > Hi, >> >> > >>> > >> >> > >>> > I have recently tried to use dpm=1 with the amdgpu driver for the >> >> > >>> > 4.19.x kernel, but unfortunately the screen just went black. This >> >> > >>> > is a regression from the 4.18.x kernel. >> >> > >>> > >> >> > >>> > I have attached the full dmesg log, but the relevant section look >> >> > >>> > to be: >> >> > >>> > >> >> > >>> > [8.958679] WARNING: CPU: 0 PID: 320 at >> >> > >>> > drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x1f/0x30 [drm] >> >> > >>> > [9.010509] Code: f6 c3 48 8d 41 c0 eb bb 0f 1f 00 66 66 66 66 >> >> > >>> > 90 48 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 a0 68 26 c0 >> >> > >>> > e8 6b 4d e8 d9 <0f> 0b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 >> >> > >>> > 00 66 66 66 66 90 >> >> > >>> > [9.029395] RSP: 0018:ae0681e8f9e8 EFLAGS: 00010282 >> >> > >>> > [9.034681] RAX: RBX: 91febbb9f900 RCX: >> >> > >>> > >> >> > >>> > [9.041875] RDX: 91fec3a1cf00 RSI: 91fec3a16868 RDI: >> >> > >>> > 91fec3a16868 >> >> > >>> > [9.049068] RBP: 91feb92b29a0 R08: R09: >> >> > >>> > 91fb800bb480 >> >> > >>> > [9.056260] R10: 9a4e7560 R11: 9b9b616d R12: >> >> > >>> > 91feb92b2980 >> >> > >>> > [9.063454] R13: R14: 0170 R15: >> >> > >>> > 91feb938aee0 >> >> > >>> > [9.070647] FS: 7f71200ee180() >> >> > >>> > GS:91fec3a0() knlGS: >> >> > >>> > [9.078821] CS: 0010 DS: ES: CR0: 80050033 >> >> > >>> > [9.084625] CR2: 7f8be0615020 CR3: 00033b014000 CR4: >> >> > >>> > 06f0 >> >> > >>> > >> >> > >>> >> >> > >>> You may need this patch depending on your platform: >> >> > >>> https://patchwork.freedesktop.org/patch/259364/ >> >> > >>> >> >> > >>> Alex >> >> > >>> >> >> > >>> > Cheers, >> >> > >>> > Chris >> >> > >>> > >> >> > >>> > ___ >> >> > >>> > dri-devel mailing list >> >> > >>> > dri-devel@lists.freedesktop.org >> >> > >>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH] drm/msm/dpu: Fix vblank refcount mismatch
On Thu, Dec 06, 2018 at 12:16:53PM +0530, Jayant Shekhar wrote:
> _dpu_crtc_vblank_enable_no_lock releases crtc_lock as
> its needed for power handle operations. This opens up a
> window where in a thread running dpu_crtc_disable and a thread
> running dpu_crtc_vblank can race in using dpu_crtc->enabled.
Looks like you're using an old kernel. Both power_handle and
vblank_enable_no_lock were removed.
If you want something more up-to-date for testing, grab the mtp-testing
branch from my dpu-staging tree [1]
Sean
[1]- https://gitlab.freedesktop.org/seanpaul/dpu-staging.git
>
> dpu_crtc_disable will change the state, where as dpu_crtc_vblank
> use the variable. The fix is to cache the crtc enabled state
> while holding the lock and use it as a gate in calling
> _dpu_crtc_vblank_enable_no_lock.
>
> This issue was introduced with the commit cf871c48
> (drm/msm/dpu: Remove suspend state tracking from crtc).
>
> Below are stack traces of thread 1 and thread 2 in good case
> and bad case:
>
> Bad case:
> -
> Thread 1
> dpu_encoder_phys_vid_control_vblank_irq+0xd0/0x170
> dpu_encoder_register_vblank_callback+0xb8/0x100
> _dpu_crtc_vblank_enable_no_lock+0x240/0x288
> dpu_crtc_disable+0xc4/0x288
> drm_atomic_helper_commit_modeset_disables+0x19c/0x350
> msm_atomic_commit_tail+0x48/0x144
> commit_tail+0x44/0x70
> drm_atomic_helper_commit+0xf0/0xf8
> drm_atomic_commit+0x40/0x4c
> drm_mode_atomic_ioctl+0x374/0x90c
> drm_ioctl_kernel+0xac/0xec
> drm_ioctl+0x218/0x384
> drm_compat_ioctl+0xd8/0xe8
>
> Thread 2:
> dpu_encoder_phys_vid_control_vblank_irq+0x74/0x170
> dpu_encoder_register_vblank_callback+0xb8/0x100
> _dpu_crtc_vblank_enable_no_lock+0x240/0x288
> dpu_crtc_vblank+0xa8/0x118
> dpu_kms_disable_vblank+0x20/0x2c
> vblank_ctrl_worker+0xa0/0xe0
> kthread_worker_fn+0xe4/0x1a4
> kthread+0x11c/0x12c
> ret_from_fork+0x10/0x18
>
> Good case:
> --
> Thread 1:
> dpu_encoder_phys_vid_control_vblank_irq+0xd0/0x170
> dpu_encoder_phys_vid_irq_control+0xc8/0x110
> _dpu_encoder_irq_control+0x48/0xa0
> _dpu_encoder_resource_control_helper+0xb4/0x10c
> dpu_encoder_resource_control+0x4e0/0x664
> dpu_encoder_virt_enable+0xb8/0x120
> dpu_kms_encoder_enable+0x34/0xcc
> drm_atomic_helper_commit_modeset_enables+0x120/0x1b8
> msm_atomic_commit_tail+0x5c/0x144
> commit_tail+0x44/0x70
> drm_atomic_helper_commit+0xf0/0xf8
> drm_atomic_commit+0x40/0x4c
> drm_mode_atomic_ioctl+0x374/0x90c
>
> Thread 2:
> dpu_crtc_vblank+0xc8/0x118
> dpu_kms_disable_vblank+0x20/0x2c
> vblank_ctrl_worker+0xa0/0xe0
> kthread_worker_fn+0xe4/0x1a4
> kthread+0x11c/0x12c
>
> Signed-off-by: Jayant Shekhar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 630cbaa..e81ad8c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -877,6 +877,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
> struct drm_encoder *encoder;
> struct msm_drm_private *priv;
> unsigned long flags;
> + bool crtc_en;
>
> if (!crtc || !crtc->dev || !crtc->dev->dev_private || !crtc->state) {
> DPU_ERROR("invalid crtc\n");
> @@ -901,11 +902,21 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
> atomic_read(_crtc->frame_pending));
>
> trace_dpu_crtc_disable(DRMID(crtc), false, dpu_crtc);
> - if (dpu_crtc->enabled && dpu_crtc->vblank_requested) {
> - _dpu_crtc_vblank_enable_no_lock(dpu_crtc, false);
> - }
> +
> + /*
> + * Cache vblank enabled before calling _dpu_crtc_vblank_enable_no_lock,
> + * because we release crtc_lock inside and acquire it back. While lock
> + * is released, there are cases where dpu_crtc_vblank comes in between
> + * while disable is going on. dpu_crtc_vblank further calls
> + * _dpu_crtc_vblank_enable_no_lock which tries vblank disable again
> + * resulting in refcount mismatch.
> + */
> + crtc_en = dpu_crtc->enabled;
> dpu_crtc->enabled = false;
>
> + if (crtc_en && dpu_crtc->vblank_requested)
> + _dpu_crtc_vblank_enable_no_lock(dpu_crtc, false);
> +
> if (atomic_read(_crtc->frame_pending)) {
> trace_dpu_crtc_disable_frame_pending(DRMID(crtc),
>atomic_read(_crtc->frame_pending));
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Only #define DEBUG if CONFIG_DYNAMIC_DEBUG is disabled
On 2018-12-06 5:10 p.m., Daniel Thompson wrote: > On Thu, Dec 06, 2018 at 03:41:16PM +0100, Michel Dänzer wrote: >> On 2018-12-06 1:23 p.m., Joe Perches wrote: >>> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote: In contrast to the 2b case, the pr_debug output isn't visible by default with 1b, so the latter doesn't fit "always produce output" either. >>> >>> I think you are mistaken here. >> >> Still puzzled as to what you're hoping to achieve with that kind of >> language. None of the confusion about this patch has been on my part. :) >> >> >>> Adding #define DEBUG as Chris did enables pr_debug output >>> and is your 1b. >>> >>> Perhaps your default console logging level is set to a >>> non-default value. >> >> I have CONFIG_DYNAMIC_DEBUG enabled in my kernels. The problem addressed >> by this patch is that messages from drm_debug_printer are visible by >> default (case 2b), whereas they shouldn't be (case 2a, like 1b). > > When enabled (either dynamically or statically) pr_debug() will emit > output at KERN_DEBUG level regardless of whether CONFIG_DYNAMIC_DEBUG > is defined or not. > > Thus unless you change additional settings (either dynamically or > statically) then debug messages should not be shown on the console > because the default settings filter KERN_DEBUG messages. However they > are available via dmesg and system loggers (syslogd, journal, etc). > > The patch proposed will change the behaviour of the debug messages > w.r.t. system loggers based on whether the user has enabled > CONFIG_DYNAMIC_DEBUG or not, violating the principle of least surprise. Ah, that makes sense now, thanks. I'm withdrawing this patch. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMDGPU with 4.19.x kernel - cannot enable DPM
OK, thanks. Although for reference, if DPM is now enabled by default I would have expected amdgpu.dpm=1 to be a no-op rather than cause a black screen and an oops... ;-). Cheers, Chris On Thu, 6 Dec 2018 at 16:09, Alex Deucher wrote: > Then you should be fine to remove it. > > Alex > On Thu, Dec 6, 2018 at 10:58 AM Chris Rankin wrote: > > > > Yes, all 4.19.x kernels have been fine without the amdgpu.dpm=1 kernel > parameter. In fact, this is how I am running my kernel right now. With the > 4.18.x series I did specify amdgpu.dpm=1 explicitly on the GRUB2 command > line, and I inherited this setting when I migrated to 4.19. > > > > On Thu, 6 Dec 2018 at 15:53, Alex Deucher wrote: > >> > >> Does it work without amdgpu.dpm=1 on your kernel command line? You > >> don't need to specify it, it;s enabled by default. The default dpm > >> implementation changed so specifying dpm=1 will change the dpm > >> implementation used by the driver. > >> > >> Alex > >> On Thu, Dec 6, 2018 at 10:47 AM Alex Deucher > wrote: > >> > > >> > I can't reproduce this. Can you bisect? > >> > > >> > Alex > >> > On Thu, Dec 6, 2018 at 8:38 AM Chris Rankin > wrote: > >> > > > >> > > Hi, > >> > > > >> > > I'm still unable to enable DPM with my R7 360, AMDGPU driver, Linux > 4.19.7 kernel. Dmesg log is attached, showing that it is correctly using > PCIE gen2 speeds. > >> > > > >> > > Cheers, > >> > > Chris > >> > > > >> > > On Sat, 24 Nov 2018 at 13:12, Chris Rankin > wrote: > >> > >> > >> > >> Hi, thanks for the reply. > >> > >> > >> > >> That patch doesn't solve my issue, although it does mean that the > DRM layer no longer tries to enable "gen 3" PCIE link speeds. > >> > >> I have attached the dmesg output for a stock 4.19.4 kernel that > also has your patch applied. > >> > >> > >> > >> Cheers, > >> > >> Chris > >> > >> > >> > >> On Fri, 23 Nov 2018 at 20:25, Alex Deucher > wrote: > >> > >>> > >> > >>> On Thu, Nov 22, 2018 at 7:23 PM Chris Rankin > wrote: > >> > >>> > > >> > >>> > Hi, > >> > >>> > > >> > >>> > I have recently tried to use dpm=1 with the amdgpu driver for > the 4.19.x kernel, but unfortunately the screen just went black. This is a > regression from the 4.18.x kernel. > >> > >>> > > >> > >>> > I have attached the full dmesg log, but the relevant section > look to be: > >> > >>> > > >> > >>> > [8.958679] WARNING: CPU: 0 PID: 320 at > drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x1f/0x30 [drm] > >> > >>> > [9.010509] Code: f6 c3 48 8d 41 c0 eb bb 0f 1f 00 66 66 66 > 66 90 48 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 a0 68 26 c0 e8 6b > 4d e8 d9 <0f> 0b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 > >> > >>> > [9.029395] RSP: 0018:ae0681e8f9e8 EFLAGS: 00010282 > >> > >>> > [9.034681] RAX: RBX: 91febbb9f900 RCX: > > >> > >>> > [9.041875] RDX: 91fec3a1cf00 RSI: 91fec3a16868 RDI: > 91fec3a16868 > >> > >>> > [9.049068] RBP: 91feb92b29a0 R08: R09: > 91fb800bb480 > >> > >>> > [9.056260] R10: 9a4e7560 R11: 9b9b616d R12: > 91feb92b2980 > >> > >>> > [9.063454] R13: R14: 0170 R15: > 91feb938aee0 > >> > >>> > [9.070647] FS: 7f71200ee180() > GS:91fec3a0() knlGS: > >> > >>> > [9.078821] CS: 0010 DS: ES: CR0: 80050033 > >> > >>> > [9.084625] CR2: 7f8be0615020 CR3: 00033b014000 CR4: > 06f0 > >> > >>> > > >> > >>> > >> > >>> You may need this patch depending on your platform: > >> > >>> https://patchwork.freedesktop.org/patch/259364/ > >> > >>> > >> > >>> Alex > >> > >>> > >> > >>> > Cheers, > >> > >>> > Chris > >> > >>> > > >> > >>> > ___ > >> > >>> > dri-devel mailing list > >> > >>> > dri-devel@lists.freedesktop.org > >> > >>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH ] drm/msm/dpu: Fix clock issue after bind failure
On Wed, Dec 05, 2018 at 09:51:47PM +0530, Jayant Shekhar wrote: > In case of msm drm bind failure, pm runtime put sync > is called from dsi driver which issues an asynchronous > put on mdss device. Subsequently when dpu_mdss_destroy > is triggered the change will make sure to put the mdss > device in suspend and clearing pending work if not > scheduled. > > Signed-off-by: Jayant Shekhar Thanks for sending this, pushed to dpu-staging/for-next Sean > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c > index 2d66025..030229a 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c > @@ -191,6 +191,7 @@ static void dpu_mdss_destroy(struct drm_device *dev) > struct dss_module_power *mp = _mdss->mp; > int i; > > + pm_runtime_suspend(dev->dev); > pm_runtime_disable(dev->dev); > _dpu_mdss_irq_domain_fini(dpu_mdss); > free_irq(platform_get_irq(pdev, 0), dpu_mdss); > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Only #define DEBUG if CONFIG_DYNAMIC_DEBUG is disabled
On Thu, Dec 06, 2018 at 03:41:16PM +0100, Michel Dänzer wrote: > On 2018-12-06 1:23 p.m., Joe Perches wrote: > > On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote: > >> In contrast to the 2b case, the pr_debug output isn't visible by default > >> with 1b, so the latter doesn't fit "always produce output" either. > > > > I think you are mistaken here. > > Still puzzled as to what you're hoping to achieve with that kind of > language. None of the confusion about this patch has been on my part. :) > > > > Adding #define DEBUG as Chris did enables pr_debug output > > and is your 1b. > > > > Perhaps your default console logging level is set to a > > non-default value. > > I have CONFIG_DYNAMIC_DEBUG enabled in my kernels. The problem addressed > by this patch is that messages from drm_debug_printer are visible by > default (case 2b), whereas they shouldn't be (case 2a, like 1b). When enabled (either dynamically or statically) pr_debug() will emit output at KERN_DEBUG level regardless of whether CONFIG_DYNAMIC_DEBUG is defined or not. Thus unless you change additional settings (either dynamically or statically) then debug messages should not be shown on the console because the default settings filter KERN_DEBUG messages. However they are available via dmesg and system loggers (syslogd, journal, etc). The patch proposed will change the behaviour of the debug messages w.r.t. system loggers based on whether the user has enabled CONFIG_DYNAMIC_DEBUG or not, violating the principle of least surprise. Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMDGPU with 4.19.x kernel - cannot enable DPM
Then you should be fine to remove it. Alex On Thu, Dec 6, 2018 at 10:58 AM Chris Rankin wrote: > > Yes, all 4.19.x kernels have been fine without the amdgpu.dpm=1 kernel > parameter. In fact, this is how I am running my kernel right now. With the > 4.18.x series I did specify amdgpu.dpm=1 explicitly on the GRUB2 command > line, and I inherited this setting when I migrated to 4.19. > > On Thu, 6 Dec 2018 at 15:53, Alex Deucher wrote: >> >> Does it work without amdgpu.dpm=1 on your kernel command line? You >> don't need to specify it, it;s enabled by default. The default dpm >> implementation changed so specifying dpm=1 will change the dpm >> implementation used by the driver. >> >> Alex >> On Thu, Dec 6, 2018 at 10:47 AM Alex Deucher wrote: >> > >> > I can't reproduce this. Can you bisect? >> > >> > Alex >> > On Thu, Dec 6, 2018 at 8:38 AM Chris Rankin wrote: >> > > >> > > Hi, >> > > >> > > I'm still unable to enable DPM with my R7 360, AMDGPU driver, Linux >> > > 4.19.7 kernel. Dmesg log is attached, showing that it is correctly using >> > > PCIE gen2 speeds. >> > > >> > > Cheers, >> > > Chris >> > > >> > > On Sat, 24 Nov 2018 at 13:12, Chris Rankin wrote: >> > >> >> > >> Hi, thanks for the reply. >> > >> >> > >> That patch doesn't solve my issue, although it does mean that the DRM >> > >> layer no longer tries to enable "gen 3" PCIE link speeds. >> > >> I have attached the dmesg output for a stock 4.19.4 kernel that also >> > >> has your patch applied. >> > >> >> > >> Cheers, >> > >> Chris >> > >> >> > >> On Fri, 23 Nov 2018 at 20:25, Alex Deucher >> > >> wrote: >> > >>> >> > >>> On Thu, Nov 22, 2018 at 7:23 PM Chris Rankin >> > >>> wrote: >> > >>> > >> > >>> > Hi, >> > >>> > >> > >>> > I have recently tried to use dpm=1 with the amdgpu driver for the >> > >>> > 4.19.x kernel, but unfortunately the screen just went black. This is >> > >>> > a regression from the 4.18.x kernel. >> > >>> > >> > >>> > I have attached the full dmesg log, but the relevant section look to >> > >>> > be: >> > >>> > >> > >>> > [8.958679] WARNING: CPU: 0 PID: 320 at >> > >>> > drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x1f/0x30 [drm] >> > >>> > [9.010509] Code: f6 c3 48 8d 41 c0 eb bb 0f 1f 00 66 66 66 66 90 >> > >>> > 48 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 a0 68 26 c0 e8 6b >> > >>> > 4d e8 d9 <0f> 0b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 >> > >>> > 66 66 90 >> > >>> > [9.029395] RSP: 0018:ae0681e8f9e8 EFLAGS: 00010282 >> > >>> > [9.034681] RAX: RBX: 91febbb9f900 RCX: >> > >>> > >> > >>> > [9.041875] RDX: 91fec3a1cf00 RSI: 91fec3a16868 RDI: >> > >>> > 91fec3a16868 >> > >>> > [9.049068] RBP: 91feb92b29a0 R08: R09: >> > >>> > 91fb800bb480 >> > >>> > [9.056260] R10: 9a4e7560 R11: 9b9b616d R12: >> > >>> > 91feb92b2980 >> > >>> > [9.063454] R13: R14: 0170 R15: >> > >>> > 91feb938aee0 >> > >>> > [9.070647] FS: 7f71200ee180() GS:91fec3a0() >> > >>> > knlGS: >> > >>> > [9.078821] CS: 0010 DS: ES: CR0: 80050033 >> > >>> > [9.084625] CR2: 7f8be0615020 CR3: 00033b014000 CR4: >> > >>> > 06f0 >> > >>> > >> > >>> >> > >>> You may need this patch depending on your platform: >> > >>> https://patchwork.freedesktop.org/patch/259364/ >> > >>> >> > >>> Alex >> > >>> >> > >>> > Cheers, >> > >>> > Chris >> > >>> > >> > >>> > ___ >> > >>> > dri-devel mailing list >> > >>> > dri-devel@lists.freedesktop.org >> > >>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping
Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
>> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
>>> From: Jérôme Glisse
>>>
>>> The debugfs take reference on fence without dropping them. Also the
>>> rcu section are not well balance. Fix all that ...
>>>
>>> Signed-off-by: Jérôme Glisse
>>> Cc: Christian König
>>> Cc: Daniel Vetter
>>> Cc: Sumit Semwal
>>> Cc: linux-me...@vger.kernel.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: linaro-mm-...@lists.linaro.org
>>> Cc: Stéphane Marchesin
>>> Cc: sta...@vger.kernel.org
>> Well NAK, you are now taking the RCU lock twice and dropping the RCU and
>> still accessing fobj has a huge potential for accessing freed up memory.
>>
>> The only correct thing I can see here is to grab a reference to the
>> fence before printing any info on it,
>> Christian.
> Hu ? That is exactly what i am doing, take reference under rcu,
> rcu_unlock print the fence info, drop the fence reference, rcu
> lock rinse and repeat ...
>
> Note that the fobj in _existing_ code is access outside the rcu
> end that there is an rcu imbalance in that code ie a lonlely
> rcu_unlock after the for loop.
>
> So that the existing code is broken.
No, the existing code is perfectly fine.
Please note the break in the loop before the rcu_unlock();
> if (!read_seqcount_retry(>seq, seq))
> break; <- HERE!
> rcu_read_unlock();
> }
So your patch breaks that and take the RCU read lock twice.
Regards,
Christian.
>
>>> ---
>>>drivers/dma-buf/dma-buf.c | 11 +--
>>>1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index 13884474d158..f6f4de42ac49 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s,
>>> void *unused)
>>> fobj = rcu_dereference(robj->fence);
>>> shared_count = fobj ? fobj->shared_count : 0;
>>> fence = rcu_dereference(robj->fence_excl);
>>> + fence = dma_fence_get_rcu(fence);
>>> if (!read_seqcount_retry(>seq, seq))
>>> break;
>>> rcu_read_unlock();
>>> }
>>> -
>>> - if (fence)
>>> + if (fence) {
>>> seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
>>>fence->ops->get_driver_name(fence),
>>>fence->ops->get_timeline_name(fence),
>>>dma_fence_is_signaled(fence) ? "" : "un");
>>> + dma_fence_put(fence);
>>> + }
>>> +
>>> + rcu_read_lock();
>>> for (i = 0; i < shared_count; i++) {
>>> fence = rcu_dereference(fobj->shared[i]);
>>> if (!dma_fence_get_rcu(fence))
>>> continue;
>>> + rcu_read_unlock();
>>> seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
>>>fence->ops->get_driver_name(fence),
>>>fence->ops->get_timeline_name(fence),
>>>dma_fence_is_signaled(fence) ? "" : "un");
>>> + dma_fence_put(fence);
>>> + rcu_read_lock();
>>> }
>>> rcu_read_unlock();
>>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMDGPU with 4.19.x kernel - cannot enable DPM
Yes, all 4.19.x kernels have been fine without the amdgpu.dpm=1 kernel parameter. In fact, this is how I am running my kernel right now. With the 4.18.x series I did specify amdgpu.dpm=1 explicitly on the GRUB2 command line, and I inherited this setting when I migrated to 4.19. On Thu, 6 Dec 2018 at 15:53, Alex Deucher wrote: > Does it work without amdgpu.dpm=1 on your kernel command line? You > don't need to specify it, it;s enabled by default. The default dpm > implementation changed so specifying dpm=1 will change the dpm > implementation used by the driver. > > Alex > On Thu, Dec 6, 2018 at 10:47 AM Alex Deucher > wrote: > > > > I can't reproduce this. Can you bisect? > > > > Alex > > On Thu, Dec 6, 2018 at 8:38 AM Chris Rankin wrote: > > > > > > Hi, > > > > > > I'm still unable to enable DPM with my R7 360, AMDGPU driver, Linux > 4.19.7 kernel. Dmesg log is attached, showing that it is correctly using > PCIE gen2 speeds. > > > > > > Cheers, > > > Chris > > > > > > On Sat, 24 Nov 2018 at 13:12, Chris Rankin wrote: > > >> > > >> Hi, thanks for the reply. > > >> > > >> That patch doesn't solve my issue, although it does mean that the DRM > layer no longer tries to enable "gen 3" PCIE link speeds. > > >> I have attached the dmesg output for a stock 4.19.4 kernel that also > has your patch applied. > > >> > > >> Cheers, > > >> Chris > > >> > > >> On Fri, 23 Nov 2018 at 20:25, Alex Deucher > wrote: > > >>> > > >>> On Thu, Nov 22, 2018 at 7:23 PM Chris Rankin > wrote: > > >>> > > > >>> > Hi, > > >>> > > > >>> > I have recently tried to use dpm=1 with the amdgpu driver for the > 4.19.x kernel, but unfortunately the screen just went black. This is a > regression from the 4.18.x kernel. > > >>> > > > >>> > I have attached the full dmesg log, but the relevant section look > to be: > > >>> > > > >>> > [8.958679] WARNING: CPU: 0 PID: 320 at > drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x1f/0x30 [drm] > > >>> > [9.010509] Code: f6 c3 48 8d 41 c0 eb bb 0f 1f 00 66 66 66 66 > 90 48 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 a0 68 26 c0 e8 6b 4d > e8 d9 <0f> 0b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 > > >>> > [9.029395] RSP: 0018:ae0681e8f9e8 EFLAGS: 00010282 > > >>> > [9.034681] RAX: RBX: 91febbb9f900 RCX: > > > >>> > [9.041875] RDX: 91fec3a1cf00 RSI: 91fec3a16868 RDI: > 91fec3a16868 > > >>> > [9.049068] RBP: 91feb92b29a0 R08: R09: > 91fb800bb480 > > >>> > [9.056260] R10: 9a4e7560 R11: 9b9b616d R12: > 91feb92b2980 > > >>> > [9.063454] R13: R14: 0170 R15: > 91feb938aee0 > > >>> > [9.070647] FS: 7f71200ee180() > GS:91fec3a0() knlGS: > > >>> > [9.078821] CS: 0010 DS: ES: CR0: 80050033 > > >>> > [9.084625] CR2: 7f8be0615020 CR3: 00033b014000 CR4: > 06f0 > > >>> > > > >>> > > >>> You may need this patch depending on your platform: > > >>> https://patchwork.freedesktop.org/patch/259364/ > > >>> > > >>> Alex > > >>> > > >>> > Cheers, > > >>> > Chris > > >>> > > > >>> > ___ > > >>> > dri-devel mailing list > > >>> > dri-devel@lists.freedesktop.org > > >>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMDGPU with 4.19.x kernel - cannot enable DPM
Does it work without amdgpu.dpm=1 on your kernel command line? You don't need to specify it, it;s enabled by default. The default dpm implementation changed so specifying dpm=1 will change the dpm implementation used by the driver. Alex On Thu, Dec 6, 2018 at 10:47 AM Alex Deucher wrote: > > I can't reproduce this. Can you bisect? > > Alex > On Thu, Dec 6, 2018 at 8:38 AM Chris Rankin wrote: > > > > Hi, > > > > I'm still unable to enable DPM with my R7 360, AMDGPU driver, Linux 4.19.7 > > kernel. Dmesg log is attached, showing that it is correctly using PCIE gen2 > > speeds. > > > > Cheers, > > Chris > > > > On Sat, 24 Nov 2018 at 13:12, Chris Rankin wrote: > >> > >> Hi, thanks for the reply. > >> > >> That patch doesn't solve my issue, although it does mean that the DRM > >> layer no longer tries to enable "gen 3" PCIE link speeds. > >> I have attached the dmesg output for a stock 4.19.4 kernel that also has > >> your patch applied. > >> > >> Cheers, > >> Chris > >> > >> On Fri, 23 Nov 2018 at 20:25, Alex Deucher wrote: > >>> > >>> On Thu, Nov 22, 2018 at 7:23 PM Chris Rankin wrote: > >>> > > >>> > Hi, > >>> > > >>> > I have recently tried to use dpm=1 with the amdgpu driver for the > >>> > 4.19.x kernel, but unfortunately the screen just went black. This is a > >>> > regression from the 4.18.x kernel. > >>> > > >>> > I have attached the full dmesg log, but the relevant section look to be: > >>> > > >>> > [8.958679] WARNING: CPU: 0 PID: 320 at drivers/gpu/drm/drm_mm.c:950 > >>> > drm_mm_takedown+0x1f/0x30 [drm] > >>> > [9.010509] Code: f6 c3 48 8d 41 c0 eb bb 0f 1f 00 66 66 66 66 90 48 > >>> > 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 a0 68 26 c0 e8 6b 4d e8 > >>> > d9 <0f> 0b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 > >>> > [9.029395] RSP: 0018:ae0681e8f9e8 EFLAGS: 00010282 > >>> > [9.034681] RAX: RBX: 91febbb9f900 RCX: > >>> > > >>> > [9.041875] RDX: 91fec3a1cf00 RSI: 91fec3a16868 RDI: > >>> > 91fec3a16868 > >>> > [9.049068] RBP: 91feb92b29a0 R08: R09: > >>> > 91fb800bb480 > >>> > [9.056260] R10: 9a4e7560 R11: 9b9b616d R12: > >>> > 91feb92b2980 > >>> > [9.063454] R13: R14: 0170 R15: > >>> > 91feb938aee0 > >>> > [9.070647] FS: 7f71200ee180() GS:91fec3a0() > >>> > knlGS: > >>> > [9.078821] CS: 0010 DS: ES: CR0: 80050033 > >>> > [9.084625] CR2: 7f8be0615020 CR3: 00033b014000 CR4: > >>> > 06f0 > >>> > > >>> > >>> You may need this patch depending on your platform: > >>> https://patchwork.freedesktop.org/patch/259364/ > >>> > >>> Alex > >>> > >>> > Cheers, > >>> > Chris > >>> > > >>> > ___ > >>> > dri-devel mailing list > >>> > dri-devel@lists.freedesktop.org > >>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2
From: Jérôme Glisse
The debugfs take reference on fence without dropping them. Also the
rcu section are not well balance. Fix all that ...
Changed since v1:
- moved fobj logic around to be rcu safe
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Stéphane Marchesin
Cc: sta...@vger.kernel.org
---
drivers/dma-buf/dma-buf.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..9688d99894d6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1048,27 +1048,38 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
while (true) {
seq = read_seqcount_begin(>seq);
rcu_read_lock();
- fobj = rcu_dereference(robj->fence);
- shared_count = fobj ? fobj->shared_count : 0;
fence = rcu_dereference(robj->fence_excl);
+ fence = dma_fence_get_rcu(fence);
if (!read_seqcount_retry(>seq, seq))
break;
rcu_read_unlock();
}
-
- if (fence)
+ if (fence) {
seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
fence->ops->get_driver_name(fence),
fence->ops->get_timeline_name(fence),
dma_fence_is_signaled(fence) ? "" : "un");
- for (i = 0; i < shared_count; i++) {
+ dma_fence_put(fence);
+ }
+
+ rcu_read_lock();
+ fobj = rcu_dereference(robj->fence);
+ shared_count = fobj ? fobj->shared_count : 0;
+ for (i = 0, fence = NULL; i < shared_count; i++) {
fence = rcu_dereference(fobj->shared[i]);
if (!dma_fence_get_rcu(fence))
continue;
+ rcu_read_unlock();
+
seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
fence->ops->get_driver_name(fence),
fence->ops->get_timeline_name(fence),
dma_fence_is_signaled(fence) ? "" : "un");
+ dma_fence_put(fence);
+
+ rcu_read_lock();
+ fobj = rcu_dereference(robj->fence);
+ shared_count = fobj ? fobj->shared_count : 0;
}
rcu_read_unlock();
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMDGPU with 4.19.x kernel - cannot enable DPM
I can't reproduce this. Can you bisect? Alex On Thu, Dec 6, 2018 at 8:38 AM Chris Rankin wrote: > > Hi, > > I'm still unable to enable DPM with my R7 360, AMDGPU driver, Linux 4.19.7 > kernel. Dmesg log is attached, showing that it is correctly using PCIE gen2 > speeds. > > Cheers, > Chris > > On Sat, 24 Nov 2018 at 13:12, Chris Rankin wrote: >> >> Hi, thanks for the reply. >> >> That patch doesn't solve my issue, although it does mean that the DRM layer >> no longer tries to enable "gen 3" PCIE link speeds. >> I have attached the dmesg output for a stock 4.19.4 kernel that also has >> your patch applied. >> >> Cheers, >> Chris >> >> On Fri, 23 Nov 2018 at 20:25, Alex Deucher wrote: >>> >>> On Thu, Nov 22, 2018 at 7:23 PM Chris Rankin wrote: >>> > >>> > Hi, >>> > >>> > I have recently tried to use dpm=1 with the amdgpu driver for the 4.19.x >>> > kernel, but unfortunately the screen just went black. This is a >>> > regression from the 4.18.x kernel. >>> > >>> > I have attached the full dmesg log, but the relevant section look to be: >>> > >>> > [8.958679] WARNING: CPU: 0 PID: 320 at drivers/gpu/drm/drm_mm.c:950 >>> > drm_mm_takedown+0x1f/0x30 [drm] >>> > [9.010509] Code: f6 c3 48 8d 41 c0 eb bb 0f 1f 00 66 66 66 66 90 48 >>> > 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 a0 68 26 c0 e8 6b 4d e8 >>> > d9 <0f> 0b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 >>> > [9.029395] RSP: 0018:ae0681e8f9e8 EFLAGS: 00010282 >>> > [9.034681] RAX: RBX: 91febbb9f900 RCX: >>> > >>> > [9.041875] RDX: 91fec3a1cf00 RSI: 91fec3a16868 RDI: >>> > 91fec3a16868 >>> > [9.049068] RBP: 91feb92b29a0 R08: R09: >>> > 91fb800bb480 >>> > [9.056260] R10: 9a4e7560 R11: 9b9b616d R12: >>> > 91feb92b2980 >>> > [9.063454] R13: R14: 0170 R15: >>> > 91feb938aee0 >>> > [9.070647] FS: 7f71200ee180() GS:91fec3a0() >>> > knlGS: >>> > [9.078821] CS: 0010 DS: ES: CR0: 80050033 >>> > [9.084625] CR2: 7f8be0615020 CR3: 00033b014000 CR4: >>> > 06f0 >>> > >>> >>> You may need this patch depending on your platform: >>> https://patchwork.freedesktop.org/patch/259364/ >>> >>> Alex >>> >>> > Cheers, >>> > Chris >>> > >>> > ___ >>> > dri-devel mailing list >>> > dri-devel@lists.freedesktop.org >>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201815] Mouse Pointer Disappears when touching top of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=201815 --- Comment #5 from siyia (eutychio...@gmail.com) --- kernel 4.20rc5 completely broke on my laptop cannot boot or look at logs it freezes after grub with cursor blink and cpu fan at 100% -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
KASAN: use-after-free in drm_sched_entity_pop_job with amdgpu
KASAN caught something during today's piglit run, see the attached dmesg excerpt. Looks like amdgpu destroys the VM while the scheduler still has a reference to its entity? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer Dec 6 15:21:35 kaveri kernel: [ 8318.734239] == Dec 6 15:21:35 kaveri kernel: [ 8318.736505] BUG: KASAN: use-after-free in drm_sched_entity_pop_job+0x50f/0x910 [gpu_sched] Dec 6 15:21:35 kaveri kernel: [ 8318.736661] Write of size 4 at addr 888261b9b460 by task sdma0/827 Dec 6 15:21:35 kaveri kernel: [ 8318.736769] Dec 6 15:21:35 kaveri kernel: [ 8318.736941] CPU: 7 PID: 827 Comm: sdma0 Tainted: G OE 4.20.0-rc3+ #118 Dec 6 15:21:35 kaveri kernel: [ 8318.737091] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 TOMAHAWK (MS-7A34), BIOS 1.80 09/13/2017 Dec 6 15:21:35 kaveri kernel: [ 8318.737220] Call Trace: Dec 6 15:21:35 kaveri kernel: [ 8318.737416] dump_stack+0x7c/0xc0 Dec 6 15:21:35 kaveri kernel: [ 8318.737639] print_address_description+0x65/0x22e Dec 6 15:21:35 kaveri kernel: [ 8318.737919] ? drm_sched_entity_pop_job+0x50f/0x910 [gpu_sched] Dec 6 15:21:35 kaveri kernel: [ 8318.738089] kasan_report.cold.5+0x241/0x306 Dec 6 15:21:35 kaveri kernel: [ 8318.738446] drm_sched_entity_pop_job+0x50f/0x910 [gpu_sched] Dec 6 15:21:35 kaveri kernel: [ 8318.738882] drm_sched_main+0xe4/0x5a0 [gpu_sched] Dec 6 15:21:35 kaveri kernel: [ 8318.739340] ? drm_sched_job_recovery+0x470/0x470 [gpu_sched] Dec 6 15:21:35 kaveri kernel: [ 8318.739750] ? lock_acquire+0x103/0x2c0 Dec 6 15:21:35 kaveri kernel: [ 8318.739967] ? __kthread_parkme+0x50/0xf0 Dec 6 15:21:35 kaveri kernel: [ 8318.740275] ? finish_wait+0x230/0x230 Dec 6 15:21:35 kaveri kernel: [ 8318.740517] ? lockdep_hardirqs_on+0x37c/0x560 Dec 6 15:21:35 kaveri kernel: [ 8318.740924] ? drm_sched_job_recovery+0x470/0x470 [gpu_sched] Dec 6 15:21:35 kaveri kernel: [ 8318.74] kthread+0x2e2/0x3a0 Dec 6 15:21:35 kaveri kernel: [ 8318.741279] ? kthread_park+0x120/0x120 Dec 6 15:21:35 kaveri kernel: [ 8318.741536] ret_from_fork+0x27/0x50 Dec 6 15:21:35 kaveri kernel: [ 8318.742118] Dec 6 15:21:35 kaveri kernel: [ 8318.742264] Allocated by task 8273: Dec 6 15:21:35 kaveri kernel: [ 8318.742480] kasan_kmalloc+0xbf/0xe0 Dec 6 15:21:35 kaveri kernel: [ 8318.742652] kmem_cache_alloc_trace+0x12d/0x290 Dec 6 15:21:35 kaveri kernel: [ 8318.743245] amdgpu_driver_open_kms+0xe6/0x4c0 [amdgpu] Dec 6 15:21:35 kaveri kernel: [ 8318.743275] drm_file_alloc+0x43a/0x980 [drm] Dec 6 15:21:35 kaveri kernel: [ 8318.743303] drm_open+0x21c/0x730 [drm] Dec 6 15:21:35 kaveri kernel: [ 8318.743332] drm_stub_open+0x25e/0x410 [drm] Dec 6 15:21:35 kaveri kernel: [ 8318.743339] chrdev_open+0x1e0/0x4e0 Dec 6 15:21:35 kaveri kernel: [ 8318.743346] do_dentry_open+0x3c4/0xda0 Dec 6 15:21:35 kaveri kernel: [ 8318.743353] path_openat+0xa1e/0x3650 Dec 6 15:21:35 kaveri kernel: [ 8318.743359] do_filp_open+0x17c/0x250 Dec 6 15:21:35 kaveri kernel: [ 8318.743365] do_sys_open+0x1db/0x310 Dec 6 15:21:35 kaveri kernel: [ 8318.743373] do_syscall_64+0x9c/0x3d0 Dec 6 15:21:35 kaveri kernel: [ 8318.743380] entry_SYSCALL_64_after_hwframe+0x49/0xbe Dec 6 15:21:35 kaveri kernel: [ 8318.743385] Dec 6 15:21:35 kaveri kernel: [ 8318.743391] Freed by task 6916: Dec 6 15:21:35 kaveri kernel: [ 8318.743398] __kasan_slab_free+0x125/0x170 Dec 6 15:21:35 kaveri kernel: [ 8318.743404] kfree+0xe2/0x290 Dec 6 15:21:35 kaveri kernel: [ 8318.743520] amdgpu_driver_postclose_kms+0x4e7/0x8e0 [amdgpu] Dec 6 15:21:35 kaveri kernel: [ 8318.743548] drm_file_free.part.3+0x7d6/0xe30 [drm] Dec 6 15:21:35 kaveri kernel: [ 8318.743576] drm_release+0x231/0x3f0 [drm] Dec 6 15:21:35 kaveri kernel: [ 8318.743582] __fput+0x235/0x710 Dec 6 15:21:35 kaveri kernel: [ 8318.743590] task_work_run+0x10e/0x180 Dec 6 15:21:35 kaveri kernel: [ 8318.743596] exit_to_usermode_loop+0x136/0x160 Dec 6 15:21:35 kaveri kernel: [ 8318.743602] do_syscall_64+0x32e/0x3d0 Dec 6 15:21:35 kaveri kernel: [ 8318.743609] entry_SYSCALL_64_after_hwframe+0x49/0xbe Dec 6 15:21:35 kaveri kernel: [ 8318.743613] Dec 6 15:21:35 kaveri kernel: [ 8318.743619] The buggy address belongs to the object at 888261b9b300 Dec 6 15:21:35 kaveri kernel: [ 8318.743619] which belongs to the cache kmalloc-4k of size 4096 Dec 6 15:21:35 kaveri kernel: [ 8318.743627] The buggy address is located 352 bytes inside of Dec 6 15:21:35 kaveri kernel: [ 8318.743627] 4096-byte region [888261b9b300, 888261b9c300) Dec 6 15:21:35 kaveri kernel: [ 8318.743633] The buggy address belongs to the page: Dec 6 15:21:35 kaveri kernel: [ 8318.743639] page:ea000986e600 count:1 mapcount:0 mapping:8883ed80e600 index:0x0 compound_mapcount: 0 Dec 6 15:21:35 kaveri kernel: [ 8318.743649] flags:
Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping
On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> > From: Jérôme Glisse
> >
> > The debugfs take reference on fence without dropping them. Also the
> > rcu section are not well balance. Fix all that ...
> >
> > Signed-off-by: Jérôme Glisse
> > Cc: Christian König
> > Cc: Daniel Vetter
> > Cc: Sumit Semwal
> > Cc: linux-me...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: Stéphane Marchesin
> > Cc: sta...@vger.kernel.org
>
> Well NAK, you are now taking the RCU lock twice and dropping the RCU and
> still accessing fobj has a huge potential for accessing freed up memory.
>
> The only correct thing I can see here is to grab a reference to the
> fence before printing any info on it,
> Christian.
Hu ? That is exactly what i am doing, take reference under rcu,
rcu_unlock print the fence info, drop the fence reference, rcu
lock rinse and repeat ...
Note that the fobj in _existing_ code is access outside the rcu
end that there is an rcu imbalance in that code ie a lonlely
rcu_unlock after the for loop.
So that the existing code is broken.
>
> > ---
> > drivers/dma-buf/dma-buf.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 13884474d158..f6f4de42ac49 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s,
> > void *unused)
> > fobj = rcu_dereference(robj->fence);
> > shared_count = fobj ? fobj->shared_count : 0;
> > fence = rcu_dereference(robj->fence_excl);
> > + fence = dma_fence_get_rcu(fence);
> > if (!read_seqcount_retry(>seq, seq))
> > break;
> > rcu_read_unlock();
> > }
> > -
> > - if (fence)
> > + if (fence) {
> > seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
> >fence->ops->get_driver_name(fence),
> >fence->ops->get_timeline_name(fence),
> >dma_fence_is_signaled(fence) ? "" : "un");
> > + dma_fence_put(fence);
> > + }
> > +
> > + rcu_read_lock();
> > for (i = 0; i < shared_count; i++) {
> > fence = rcu_dereference(fobj->shared[i]);
> > if (!dma_fence_get_rcu(fence))
> > continue;
> > + rcu_read_unlock();
> > seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
> >fence->ops->get_driver_name(fence),
> >fence->ops->get_timeline_name(fence),
> >dma_fence_is_signaled(fence) ? "" : "un");
> > + dma_fence_put(fence);
> > + rcu_read_lock();
> > }
> > rcu_read_unlock();
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.14 21/55] drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 97b2a3180a559a33852ac0cd77904166069484fd upstream.
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528]
==
[ 117.904560] BUG: KASAN: global-out-of-bounds in
meson_viu_set_osd_lut+0x7a0/0x890
[ 117.904588] Read of size 4 at addr 2a63ce24 by task systemd-udevd/498
[ 117.904601]
[ 118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted
4.20.0-rc3Lyude-Test+ #20
[ 118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS
2018.07-rc2-armbian 09/11/2018
[ 118.099768] Call trace:
[ 118.102181] dump_backtrace+0x0/0x3e8
[ 118.105796] show_stack+0x14/0x20
[ 118.109083] dump_stack+0x130/0x1c4
[ 118.112539] print_address_description+0x60/0x25c
[ 118.117214] kasan_report+0x1b4/0x368
[ 118.120851] __asan_report_load4_noabort+0x18/0x20
[ 118.125566] meson_viu_set_osd_lut+0x7a0/0x890
[ 118.129953] meson_viu_init+0x10c/0x290
[ 118.133741] meson_drv_bind_master+0x474/0x748
[ 118.138141] meson_drv_bind+0x10/0x18
[ 118.141760] try_to_bring_up_master+0x3d8/0x768
[ 118.146249] component_add+0x214/0x570
[ 118.149978] meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
[ 118.155404] platform_drv_probe+0x98/0x138
[ 118.159455] really_probe+0x2a0/0xa70
[ 118.163070] driver_probe_device+0x1b4/0x2d8
[ 118.167299] __driver_attach+0x200/0x280
[ 118.171189] bus_for_each_dev+0x10c/0x1a8
[ 118.175144] driver_attach+0x38/0x50
[ 118.178681] bus_add_driver+0x330/0x608
[ 118.182471] driver_register+0x140/0x388
[ 118.186361] __platform_driver_register+0xc8/0x108
[ 118.191117] meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
[ 118.198022] do_one_initcall+0x12c/0x3bc
[ 118.201883] do_init_module+0x1fc/0x638
[ 118.205673] load_module+0x4b4c/0x6808
[ 118.209387] __se_sys_init_module+0x2e8/0x3c0
[ 118.213699] __arm64_sys_init_module+0x68/0x98
[ 118.218100] el0_svc_common+0x104/0x210
[ 118.221893] el0_svc_handler+0x48/0xb8
[ 118.225594] el0_svc+0x8/0xc
[ 118.228429]
[ 118.229887] The buggy address belongs to the variable:
[ 118.235007] eotf_33_linear_mapping+0x84/0xc0
[ 118.239301]
[ 118.240752] Memory state around the buggy address:
[ 118.245522] 2a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[ 118.252695] 2a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[ 118.259850] >2a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00
00
[ 118.267000]^
[ 118.271222] 2a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00
00
[ 118.278393] 2a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa
fa
[ 118.285542]
==
[ 118.292699] Disabling lock debugging due to kernel taint
It seems that when looping through the OSD EOTF LUT maps, we use the
same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
which means that we'll stop out of bounds on the EOTF maps.
But, this whole thing is already confusing enough to read through as-is,
so let's just replace all of the hardcoded sizes with
OSD_(OETF/EOTF)_LUT_SIZE / 2.
Signed-off-by: Lyude Paul
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: Neil Armstrong
Cc: Maxime Ripard
Cc: Carlo Caione
Cc: Kevin Hilman
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v4.10+
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-ly...@redhat.com
Signed-off-by: Sean Paul
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/meson/meson_viu.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -184,18 +184,18 @@ void meson_viu_set_osd_lut(struct meson_
if (lut_sel == VIU_LUT_OSD_OETF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_OETF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] |
[PATCH 4.14 20/55] drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Lyude Paul commit 995b278e4723b26f8ebf0e7c119286d16c712747 upstream. Seeing as we use this registermap in the context of our IRQ handlers, we need to be using spinlocks for reading/writing registers so that we can still read them from IRQ handlers without having to grab any mutexes and accidentally sleep. We don't currently do this, as pointed out by lockdep: [ 18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 [ 18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0 [ 18.413864] INFO: lockdep is turned off. [ 18.417675] irq event stamp: 12 [ 18.420778] hardirqs last enabled at (11): [] _raw_spin_unlock_irq+0x2c/0x60 [ 18.429510] hardirqs last disabled at (12): [] __schedule+0xc4/0xa60 [ 18.437345] softirqs last enabled at (0): [] copy_process.isra.4.part.5+0x4d8/0x1c50 [ 18.446684] softirqs last disabled at (0): [<>] (null) [ 18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: GW O 4.20.0-rc3Lyude-Test+ #9 [ 18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018 [ 18.480037] Workqueue: hci0 hci_power_on [bluetooth] [ 18.487138] Call trace: [ 18.494192] dump_backtrace+0x0/0x1b8 [ 18.501280] show_stack+0x14/0x20 [ 18.508361] dump_stack+0xbc/0xf4 [ 18.515427] ___might_sleep+0x140/0x1d8 [ 18.522515] __might_sleep+0x50/0x88 [ 18.529582] __mutex_lock+0x60/0x870 [ 18.536621] mutex_lock_nested+0x1c/0x28 [ 18.543660] regmap_lock_mutex+0x10/0x18 [ 18.550696] regmap_read+0x38/0x70 [ 18.557727] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi] [ 18.564804] __handle_irq_event_percpu+0xac/0x410 [ 18.571891] handle_irq_event_percpu+0x34/0x88 [ 18.578982] handle_irq_event+0x48/0x78 [ 18.586051] handle_fasteoi_irq+0xac/0x160 [ 18.593061] generic_handle_irq+0x24/0x38 [ 18.599989] __handle_domain_irq+0x60/0xb8 [ 18.606857] gic_handle_irq+0x50/0xa0 [ 18.613659] el1_irq+0xb4/0x130 [ 18.620394] debug_lockdep_rcu_enabled+0x2c/0x30 [ 18.627111] schedule+0x38/0xa0 [ 18.633781] schedule_timeout+0x3a8/0x510 [ 18.640389] wait_for_common+0x15c/0x180 [ 18.646905] wait_for_completion+0x14/0x20 [ 18.653319] mmc_wait_for_req_done+0x28/0x168 [ 18.659693] mmc_wait_for_req+0xa8/0xe8 [ 18.665978] mmc_wait_for_cmd+0x64/0x98 [ 18.672180] mmc_io_rw_direct_host+0x94/0x130 [ 18.678385] mmc_io_rw_direct+0x10/0x18 [ 18.684516] sdio_enable_func+0xe8/0x1d0 [ 18.690627] btsdio_open+0x24/0xc0 [btsdio] [ 18.696821] hci_dev_do_open+0x64/0x598 [bluetooth] [ 18.703025] hci_power_on+0x50/0x270 [bluetooth] [ 18.709163] process_one_work+0x2a0/0x6e0 [ 18.715252] worker_thread+0x40/0x448 [ 18.721310] kthread+0x12c/0x130 [ 18.727326] ret_from_fork+0x10/0x1c [ 18.73] [ cut here ] [ 18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<6265ec59>] wait_for_common+0x140/0x180 [ 18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88 [ 18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O) dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas meson_gxbb_wdt pwm_meson efivarfs ipv6 [ 18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: GW O 4.20.0-rc3Lyude-Test+ #9 [ 18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018 [ 18.818045] Workqueue: hci0 hci_power_on [bluetooth] [ 18.824088] pstate: 8085 (Nzcv daIf -PAN -UAO) [ 18.829891] pc : __might_sleep+0x7c/0x88 [ 18.835722] lr : __might_sleep+0x7c/0x88 [ 18.841256] sp : 08003cb0 [ 18.846751] x29: 08003cb0 x28: [ 18.852269] x27: 0938e000 x26: 800010283000 [ 18.857726] x25: 800010353280 x24: 0868ef50 [ 18.863166] x23: x22: [ 18.868551] x21: x20: 038c [ 18.873850] x19: 08cd08c0 x18: 0010 [ 18.879081] x17: 08a68cb0 x16: [ 18.884197] x15: 00aa x14: 0e200e200e200e20 [ 18.889239] x13: 0001 x12: [ 18.894261] x11: 08adfa48 x10: 0001 [ 18.899517] x9 : 092a0158 x8 : [ 18.904674] x7 : 0812136c x6 : [ 18.909895] x5 : x4 : 0001 [ 18.915080] x3 : 0007 x2 : 0007 [ 18.920269] x1 : 99ab8e9ebb6c8500 x0 : [ 18.925443] Call trace: [ 18.929904] __might_sleep+0x7c/0x88 [ 18.934311]
Re: [PATCH 1/2] drm: Only #define DEBUG if CONFIG_DYNAMIC_DEBUG is disabled
On 2018-12-06 1:23 p.m., Joe Perches wrote: > On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote: >> In contrast to the 2b case, the pr_debug output isn't visible by default >> with 1b, so the latter doesn't fit "always produce output" either. > > I think you are mistaken here. Still puzzled as to what you're hoping to achieve with that kind of language. None of the confusion about this patch has been on my part. :) > Adding #define DEBUG as Chris did enables pr_debug output > and is your 1b. > > Perhaps your default console logging level is set to a > non-default value. I have CONFIG_DYNAMIC_DEBUG enabled in my kernels. The problem addressed by this patch is that messages from drm_debug_printer are visible by default (case 2b), whereas they shouldn't be (case 2a, like 1b). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 20/41] drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 97b2a3180a559a33852ac0cd77904166069484fd upstream.
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528]
==
[ 117.904560] BUG: KASAN: global-out-of-bounds in
meson_viu_set_osd_lut+0x7a0/0x890
[ 117.904588] Read of size 4 at addr 2a63ce24 by task systemd-udevd/498
[ 117.904601]
[ 118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted
4.20.0-rc3Lyude-Test+ #20
[ 118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS
2018.07-rc2-armbian 09/11/2018
[ 118.099768] Call trace:
[ 118.102181] dump_backtrace+0x0/0x3e8
[ 118.105796] show_stack+0x14/0x20
[ 118.109083] dump_stack+0x130/0x1c4
[ 118.112539] print_address_description+0x60/0x25c
[ 118.117214] kasan_report+0x1b4/0x368
[ 118.120851] __asan_report_load4_noabort+0x18/0x20
[ 118.125566] meson_viu_set_osd_lut+0x7a0/0x890
[ 118.129953] meson_viu_init+0x10c/0x290
[ 118.133741] meson_drv_bind_master+0x474/0x748
[ 118.138141] meson_drv_bind+0x10/0x18
[ 118.141760] try_to_bring_up_master+0x3d8/0x768
[ 118.146249] component_add+0x214/0x570
[ 118.149978] meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
[ 118.155404] platform_drv_probe+0x98/0x138
[ 118.159455] really_probe+0x2a0/0xa70
[ 118.163070] driver_probe_device+0x1b4/0x2d8
[ 118.167299] __driver_attach+0x200/0x280
[ 118.171189] bus_for_each_dev+0x10c/0x1a8
[ 118.175144] driver_attach+0x38/0x50
[ 118.178681] bus_add_driver+0x330/0x608
[ 118.182471] driver_register+0x140/0x388
[ 118.186361] __platform_driver_register+0xc8/0x108
[ 118.191117] meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
[ 118.198022] do_one_initcall+0x12c/0x3bc
[ 118.201883] do_init_module+0x1fc/0x638
[ 118.205673] load_module+0x4b4c/0x6808
[ 118.209387] __se_sys_init_module+0x2e8/0x3c0
[ 118.213699] __arm64_sys_init_module+0x68/0x98
[ 118.218100] el0_svc_common+0x104/0x210
[ 118.221893] el0_svc_handler+0x48/0xb8
[ 118.225594] el0_svc+0x8/0xc
[ 118.228429]
[ 118.229887] The buggy address belongs to the variable:
[ 118.235007] eotf_33_linear_mapping+0x84/0xc0
[ 118.239301]
[ 118.240752] Memory state around the buggy address:
[ 118.245522] 2a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[ 118.252695] 2a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[ 118.259850] >2a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00
00
[ 118.267000]^
[ 118.271222] 2a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00
00
[ 118.278393] 2a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa
fa
[ 118.285542]
==
[ 118.292699] Disabling lock debugging due to kernel taint
It seems that when looping through the OSD EOTF LUT maps, we use the
same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
which means that we'll stop out of bounds on the EOTF maps.
But, this whole thing is already confusing enough to read through as-is,
so let's just replace all of the hardcoded sizes with
OSD_(OETF/EOTF)_LUT_SIZE / 2.
Signed-off-by: Lyude Paul
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: Neil Armstrong
Cc: Maxime Ripard
Cc: Carlo Caione
Cc: Kevin Hilman
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v4.10+
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-ly...@redhat.com
Signed-off-by: Sean Paul
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/meson/meson_viu.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -184,18 +184,18 @@ void meson_viu_set_osd_lut(struct meson_
if (lut_sel == VIU_LUT_OSD_OETF) {
writel(0, priv->io_base + _REG(addr_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(r_map[i * 2] | (r_map[i * 2 + 1] << 16),
priv->io_base + _REG(data_port));
writel(r_map[OSD_OETF_LUT_SIZE - 1] | (g_map[0] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(g_map[i * 2 + 1] | (g_map[i * 2 + 2] << 16),
priv->io_base + _REG(data_port));
- for (i = 0; i < 20; i++)
+ for (i = 0; i < (OSD_OETF_LUT_SIZE / 2); i++)
writel(b_map[i * 2] |
[PATCH 4.19 19/41] drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config
4.19-stable review patch. If anyone has any objections, please let me know. -- From: Lyude Paul commit 995b278e4723b26f8ebf0e7c119286d16c712747 upstream. Seeing as we use this registermap in the context of our IRQ handlers, we need to be using spinlocks for reading/writing registers so that we can still read them from IRQ handlers without having to grab any mutexes and accidentally sleep. We don't currently do this, as pointed out by lockdep: [ 18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 [ 18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0 [ 18.413864] INFO: lockdep is turned off. [ 18.417675] irq event stamp: 12 [ 18.420778] hardirqs last enabled at (11): [] _raw_spin_unlock_irq+0x2c/0x60 [ 18.429510] hardirqs last disabled at (12): [] __schedule+0xc4/0xa60 [ 18.437345] softirqs last enabled at (0): [] copy_process.isra.4.part.5+0x4d8/0x1c50 [ 18.446684] softirqs last disabled at (0): [<>] (null) [ 18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: GW O 4.20.0-rc3Lyude-Test+ #9 [ 18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018 [ 18.480037] Workqueue: hci0 hci_power_on [bluetooth] [ 18.487138] Call trace: [ 18.494192] dump_backtrace+0x0/0x1b8 [ 18.501280] show_stack+0x14/0x20 [ 18.508361] dump_stack+0xbc/0xf4 [ 18.515427] ___might_sleep+0x140/0x1d8 [ 18.522515] __might_sleep+0x50/0x88 [ 18.529582] __mutex_lock+0x60/0x870 [ 18.536621] mutex_lock_nested+0x1c/0x28 [ 18.543660] regmap_lock_mutex+0x10/0x18 [ 18.550696] regmap_read+0x38/0x70 [ 18.557727] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi] [ 18.564804] __handle_irq_event_percpu+0xac/0x410 [ 18.571891] handle_irq_event_percpu+0x34/0x88 [ 18.578982] handle_irq_event+0x48/0x78 [ 18.586051] handle_fasteoi_irq+0xac/0x160 [ 18.593061] generic_handle_irq+0x24/0x38 [ 18.599989] __handle_domain_irq+0x60/0xb8 [ 18.606857] gic_handle_irq+0x50/0xa0 [ 18.613659] el1_irq+0xb4/0x130 [ 18.620394] debug_lockdep_rcu_enabled+0x2c/0x30 [ 18.627111] schedule+0x38/0xa0 [ 18.633781] schedule_timeout+0x3a8/0x510 [ 18.640389] wait_for_common+0x15c/0x180 [ 18.646905] wait_for_completion+0x14/0x20 [ 18.653319] mmc_wait_for_req_done+0x28/0x168 [ 18.659693] mmc_wait_for_req+0xa8/0xe8 [ 18.665978] mmc_wait_for_cmd+0x64/0x98 [ 18.672180] mmc_io_rw_direct_host+0x94/0x130 [ 18.678385] mmc_io_rw_direct+0x10/0x18 [ 18.684516] sdio_enable_func+0xe8/0x1d0 [ 18.690627] btsdio_open+0x24/0xc0 [btsdio] [ 18.696821] hci_dev_do_open+0x64/0x598 [bluetooth] [ 18.703025] hci_power_on+0x50/0x270 [bluetooth] [ 18.709163] process_one_work+0x2a0/0x6e0 [ 18.715252] worker_thread+0x40/0x448 [ 18.721310] kthread+0x12c/0x130 [ 18.727326] ret_from_fork+0x10/0x1c [ 18.73] [ cut here ] [ 18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<6265ec59>] wait_for_common+0x140/0x180 [ 18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88 [ 18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O) dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas meson_gxbb_wdt pwm_meson efivarfs ipv6 [ 18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: GW O 4.20.0-rc3Lyude-Test+ #9 [ 18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018 [ 18.818045] Workqueue: hci0 hci_power_on [bluetooth] [ 18.824088] pstate: 8085 (Nzcv daIf -PAN -UAO) [ 18.829891] pc : __might_sleep+0x7c/0x88 [ 18.835722] lr : __might_sleep+0x7c/0x88 [ 18.841256] sp : 08003cb0 [ 18.846751] x29: 08003cb0 x28: [ 18.852269] x27: 0938e000 x26: 800010283000 [ 18.857726] x25: 800010353280 x24: 0868ef50 [ 18.863166] x23: x22: [ 18.868551] x21: x20: 038c [ 18.873850] x19: 08cd08c0 x18: 0010 [ 18.879081] x17: 08a68cb0 x16: [ 18.884197] x15: 00aa x14: 0e200e200e200e20 [ 18.889239] x13: 0001 x12: [ 18.894261] x11: 08adfa48 x10: 0001 [ 18.899517] x9 : 092a0158 x8 : [ 18.904674] x7 : 0812136c x6 : [ 18.909895] x5 : x4 : 0001 [ 18.915080] x3 : 0007 x2 : 0007 [ 18.920269] x1 : 99ab8e9ebb6c8500 x0 : [ 18.925443] Call trace: [ 18.929904] __might_sleep+0x7c/0x88 [ 18.934311]
Re: [Spice-devel] [PATCH 1/3] drm/qxl: allow both PRIV and VRAM placement for QXL_GEM_DOMAIN_SURFACE
> > On Thu, Dec 06, 2018 at 05:55:58AM -0500, Frediano Ziglio wrote: > > > > > qxl surfaces (used for framebuffers and gem objects) can live in both > > > VRAM and PRIV ttm domains. Update placement setup to include both. Put > > > PRIV first in the list so it is preferred, so VRAM will have more room > > > for objects which must be allocated there. > > > > > > Signed-off-by: Gerd Hoffmann > > > > I remember these kind of changes in the past made migration > > fails. I proposed similar patches years ago and they were rejected > > for these reasons. > > Pointer? > I think is this: https://patchwork.kernel.org/patch/7374931/ I think all started with Windows where we have: https://gitlab.freedesktop.org/spice/win32/qxl-wddm-dod/commit/0214d5ceda3f0da94de3813fc902150d497c6b26 https://gitlab.freedesktop.org/spice/win32/qxl-wddm-dod/commit/54a719e14f1204143da2c64f8a2aaee4fe5cd7d6 > > Why now they are safe? > > Well, you have to be careful what object you are allocating. Surfaces > can be in both PRIV and VRAM. Everything else (qxl commands, monitors > config, ...) must be in VRAM. > > > Looks like we are improving QXL, so that means we are actively working > > on it. > > Well, I'm just trying make qxl behave better with wayland. > As far as I remember the Linux kernel driver simulates the frame buffer swap with drawings which cause more memory copies. Not also sure if this workaround make the server consume more network bandwidth. Are we supporting multiple monitors for Wayland? > > Should we not then thinking about moving feature in the proper > > places (like spice-server for atomic mode setting instead of implementin > > work around) ?? > > Main advantage is that it doesn't need qxl device changes, so it works > on old hosts too. But, yes, we can consider to also modernize spice > protocol and qxl device. > > cheers, > Gerd > > On the other hand we faced some bugs due these workarounds so we end up with a solution that is less optimal than before and potentially with more bugs to fix. At the end we sell to customer a worst product. Frediano ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 >
[PATCH v2] drm/qxl: use qxl_num_crtc directly
qdev->monitors_config->max_allowed is effectively set by the
qxl.num_heads module parameter, stored in the qxl_num_crtc variable.
Lets get rid of the indirection and use the variable qxl_num_crtc
directly. The kernel doesn't need to dereference pointers each time it
needs the value, and when reading the code you don't have to trace where
and why qdev->monitors_config->max_allowed is set.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index ce0b9c40fc..6437369a31 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -80,10 +80,10 @@ static int
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
DRM_DEBUG_KMS("no client monitors configured\n");
return status;
}
- if (num_monitors > qdev->monitors_config->max_allowed) {
+ if (num_monitors > qxl_num_crtc) {
DRM_DEBUG_KMS("client monitors list will be truncated: %d <
%d\n",
- qdev->monitors_config->max_allowed, num_monitors);
- num_monitors = qdev->monitors_config->max_allowed;
+ qxl_num_crtc, num_monitors);
+ num_monitors = qxl_num_crtc;
} else {
num_monitors = qdev->rom->client_monitors_config.count;
}
@@ -96,8 +96,7 @@ static int qxl_display_copy_rom_client_monitors_config(struct
qxl_device *qdev)
return status;
}
/* we copy max from the client but it isn't used */
- qdev->client_monitors_config->max_allowed =
- qdev->monitors_config->max_allowed;
+ qdev->client_monitors_config->max_allowed = qxl_num_crtc;
for (i = 0 ; i < qdev->client_monitors_config->count ; ++i) {
struct qxl_urect *c_rect =
>rom->client_monitors_config.heads[i];
@@ -204,7 +203,7 @@ static int qxl_add_monitors_config_modes(struct
drm_connector *connector,
if (!qdev->monitors_config)
return 0;
- if (h >= qdev->monitors_config->max_allowed)
+ if (h >= qxl_num_crtc)
return 0;
if (!qdev->client_monitors_config)
return 0;
@@ -307,8 +306,7 @@ static void qxl_crtc_update_monitors_config(struct drm_crtc
*crtc,
return;
}
- if (!qdev->monitors_config ||
- qdev->monitors_config->max_allowed <= i)
+ if (!qdev->monitors_config || qxl_num_crtc <= i)
return;
head.id = i;
@@ -348,9 +346,10 @@ static void qxl_crtc_update_monitors_config(struct
drm_crtc *crtc,
if (oldcount != qdev->monitors_config->count)
DRM_DEBUG_KMS("active heads %d -> %d (%d total)\n",
oldcount, qdev->monitors_config->count,
- qdev->monitors_config->max_allowed);
+ qxl_num_crtc);
qdev->monitors_config->heads[i] = head;
+ qdev->monitors_config->max_allowed = qxl_num_crtc;
qxl_send_monitors_config(qdev);
}
@@ -1097,9 +1096,8 @@ int qxl_create_monitors_object(struct qxl_device *qdev)
{
int ret;
struct drm_gem_object *gobj;
- int max_allowed = qxl_num_crtc;
int monitors_config_size = sizeof(struct qxl_monitors_config) +
- max_allowed * sizeof(struct qxl_head);
+ qxl_num_crtc * sizeof(struct qxl_head);
ret = qxl_gem_object_create(qdev, monitors_config_size, 0,
QXL_GEM_DOMAIN_VRAM,
@@ -1121,7 +1119,6 @@ int qxl_create_monitors_object(struct qxl_device *qdev)
qxl_bo_physical_address(qdev, qdev->monitors_config_bo, 0);
memset(qdev->monitors_config, 0, monitors_config_size);
- qdev->monitors_config->max_allowed = max_allowed;
return 0;
}
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/5] drm/vc4: Attach margin props to the HDMI connector
Now that the plane code takes the margins setup into account, we can
safely attach margin props to the HDMI connector.
We also take care of filling AVI infoframes correctly to expose the
top/botton/left/right bar.
Note that those margin props match pretty well the
overscan_{left,right,top,bottom} properties defined in config.txt and
parsed by the VC4 firmware.
Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
---
Changes in v5:
- Use margin props instead of underscan ones
Changes in v4:
- Add Eric's R-b
Changes in v3:
- none
Changes in v2:
- none
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index fd5522fd179e..2f276222e30f 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -310,6 +310,7 @@ static struct drm_connector *vc4_hdmi_connector_init(struct
drm_device *dev,
{
struct drm_connector *connector;
struct vc4_hdmi_connector *hdmi_connector;
+ int ret;
hdmi_connector = devm_kzalloc(dev->dev, sizeof(*hdmi_connector),
GFP_KERNEL);
@@ -323,6 +324,13 @@ static struct drm_connector
*vc4_hdmi_connector_init(struct drm_device *dev,
DRM_MODE_CONNECTOR_HDMIA);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
+ /* Create and attach TV margin props to this connector. */
+ ret = drm_mode_create_tv_margin_properties(dev);
+ if (ret)
+ return ERR_PTR(ret);
+
+ drm_connector_attach_tv_margin_properties(connector);
+
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT);
@@ -408,6 +416,9 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder
*encoder,
static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
{
struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
+ struct vc4_dev *vc4 = encoder->dev->dev_private;
+ struct vc4_hdmi *hdmi = vc4->hdmi;
+ struct drm_connector_state *cstate = hdmi->connector->state;
struct drm_crtc *crtc = encoder->crtc;
const struct drm_display_mode *mode = >state->adjusted_mode;
union hdmi_infoframe frame;
@@ -426,6 +437,11 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder
*encoder)
vc4_encoder->rgb_range_selectable,
false);
+ frame.avi.right_bar = cstate->tv.margins.right;
+ frame.avi.left_bar = cstate->tv.margins.left;
+ frame.avi.top_bar = cstate->tv.margins.top;
+ frame.avi.bottom_bar = cstate->tv.margins.bottom;
+
vc4_hdmi_write_infoframe(encoder, );
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] drm/vc4: Take margin setup into account when updating planes
Applyin margins is just a matter of scaling all planes appropriately
and adjusting the CRTC X/Y offset to account for the
left/right/top/bottom borders.
Create a vc4_plane_margins_adj() function doing that and call it from
vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
margins properties to the HDMI connector.
Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
---
Changes in v5:
- Use the margins props instead of the underscan ones
Changes in v4:
- Add Eric's R-b
Changes in v3:
- Rebase on top of the "cursor rescaling" changes
Changes in v2:
- Take changes on hborder/vborder meaning into account
---
drivers/gpu/drm/vc4/vc4_crtc.c | 43
drivers/gpu/drm/vc4/vc4_drv.h | 3 ++
drivers/gpu/drm/vc4/vc4_plane.c | 50 +
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 3ce136ba8791..97caf1671dd0 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -49,6 +49,13 @@ struct vc4_crtc_state {
struct drm_mm_node mm;
bool feed_txp;
bool txp_armed;
+
+ struct {
+ unsigned int left;
+ unsigned int right;
+ unsigned int top;
+ unsigned int bottom;
+ } margins;
};
static inline struct vc4_crtc_state *
@@ -624,6 +631,37 @@ static enum drm_mode_status vc4_crtc_mode_valid(struct
drm_crtc *crtc,
return MODE_OK;
}
+void vc4_crtc_get_margins(struct drm_crtc_state *state,
+ unsigned int *left, unsigned int *right,
+ unsigned int *top, unsigned int *bottom)
+{
+ struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(state);
+ struct drm_connector_state *conn_state;
+ struct drm_connector *conn;
+ int i;
+
+ *left = vc4_state->margins.left;
+ *right = vc4_state->margins.right;
+ *top = vc4_state->margins.top;
+ *bottom = vc4_state->margins.bottom;
+
+ /* We have to interate over all new connector states because
+* vc4_crtc_get_margins() might be called before
+* vc4_crtc_atomic_check() which means margins info in vc4_crtc_state
+* might be outdated.
+*/
+ for_each_new_connector_in_state(state->state, conn, conn_state, i) {
+ if (conn_state->crtc != state->crtc)
+ continue;
+
+ *left = conn_state->tv.margins.left;
+ *right = conn_state->tv.margins.right;
+ *top = conn_state->tv.margins.top;
+ *bottom = conn_state->tv.margins.bottom;
+ break;
+ }
+}
+
static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -671,6 +709,10 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
vc4_state->feed_txp = false;
}
+ vc4_state->margins.left = conn_state->tv.margins.left;
+ vc4_state->margins.right = conn_state->tv.margins.right;
+ vc4_state->margins.top = conn_state->tv.margins.top;
+ vc4_state->margins.bottom = conn_state->tv.margins.bottom;
break;
}
@@ -972,6 +1014,7 @@ static struct drm_crtc_state
*vc4_crtc_duplicate_state(struct drm_crtc *crtc)
old_vc4_state = to_vc4_crtc_state(crtc->state);
vc4_state->feed_txp = old_vc4_state->feed_txp;
+ vc4_state->margins = old_vc4_state->margins;
__drm_atomic_helper_crtc_duplicate_state(crtc, _state->base);
return _state->base;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 4f87b03f837d..c24b078f0593 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -707,6 +707,9 @@ bool vc4_crtc_get_scanoutpos(struct drm_device *dev,
unsigned int crtc_id,
const struct drm_display_mode *mode);
void vc4_crtc_handle_vblank(struct vc4_crtc *crtc);
void vc4_crtc_txp_armed(struct drm_crtc_state *state);
+void vc4_crtc_get_margins(struct drm_crtc_state *state,
+ unsigned int *right, unsigned int *left,
+ unsigned int *top, unsigned int *bottom);
/* vc4_debugfs.c */
int vc4_debugfs_init(struct drm_minor *minor);
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 75db62cbe468..f73fd35dfcff 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -258,6 +258,52 @@ static u32 vc4_get_scl_field(struct drm_plane_state
*state, int plane)
}
}
+static int vc4_plane_margins_adj(struct drm_plane_state *pstate)
+{
+ struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
+ unsigned int left, right, top, bottom, adjhdisplay, adjvdisplay;
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state =
[PATCH v4 3/5] drm/connector: Allow creation of margin props alone
TV margins properties can only be added as part of the SDTV TV
connector properties creation, but we might need those props for HDMI
TVs too, so let's move the margins props creation in a separate
function and expose it to drivers.
We also add an helper to attach margins props to a connector.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_connector.c | 81 +
include/drm/drm_connector.h | 2 +
2 files changed, 65 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 408082a57171..ea616fb1501c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1137,6 +1137,68 @@ void drm_hdmi_avi_infoframe_content_type(struct
hdmi_avi_infoframe *frame,
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_content_type);
+/**
+ * drm_mode_attach_tv_margin_properties - attach TV connector margin properties
+ * @connector: DRM connector
+ *
+ * Called by a driver when it needs to attach TV margin props to a connector.
+ * Typically used on SDTV and HDMI connectors.
+ */
+void drm_connector_attach_tv_margin_properties(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+
+ drm_object_attach_property(>base,
+ dev->mode_config.tv_left_margin_property,
+ 0);
+ drm_object_attach_property(>base,
+ dev->mode_config.tv_right_margin_property,
+ 0);
+ drm_object_attach_property(>base,
+ dev->mode_config.tv_top_margin_property,
+ 0);
+ drm_object_attach_property(>base,
+ dev->mode_config.tv_bottom_margin_property,
+ 0);
+}
+
+/**
+ * drm_mode_create_tv_margin_properties - create TV connector margin properties
+ * @dev: DRM device
+ *
+ * Called by a driver's HDMI connector initialization routine, this function
+ * creates the TV margin properties for a given device. No need to call this
+ * function for an SDTV connector, it's already called from
+ * drm_mode_create_tv_properties().
+ */
+int drm_mode_create_tv_margin_properties(struct drm_device *dev)
+{
+ if (dev->mode_config.tv_left_margin_property)
+ return 0;
+
+ dev->mode_config.tv_left_margin_property =
+ drm_property_create_range(dev, 0, "left margin", 0, 100);
+ if (!dev->mode_config.tv_left_margin_property)
+ return -ENOMEM;
+
+ dev->mode_config.tv_right_margin_property =
+ drm_property_create_range(dev, 0, "right margin", 0, 100);
+ if (!dev->mode_config.tv_right_margin_property)
+ return -ENOMEM;
+
+ dev->mode_config.tv_top_margin_property =
+ drm_property_create_range(dev, 0, "top margin", 0, 100);
+ if (!dev->mode_config.tv_top_margin_property)
+ return -ENOMEM;
+
+ dev->mode_config.tv_bottom_margin_property =
+ drm_property_create_range(dev, 0, "bottom margin", 0, 100);
+ if (!dev->mode_config.tv_bottom_margin_property)
+ return -ENOMEM;
+
+ return 0;
+}
+
/**
* drm_mode_create_tv_properties - create TV specific connector properties
* @dev: DRM device
@@ -1183,24 +1245,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
/*
* Other, TV specific properties: margins & TV modes.
*/
- dev->mode_config.tv_left_margin_property =
- drm_property_create_range(dev, 0, "left margin", 0, 100);
- if (!dev->mode_config.tv_left_margin_property)
- goto nomem;
-
- dev->mode_config.tv_right_margin_property =
- drm_property_create_range(dev, 0, "right margin", 0, 100);
- if (!dev->mode_config.tv_right_margin_property)
- goto nomem;
-
- dev->mode_config.tv_top_margin_property =
- drm_property_create_range(dev, 0, "top margin", 0, 100);
- if (!dev->mode_config.tv_top_margin_property)
- goto nomem;
-
- dev->mode_config.tv_bottom_margin_property =
- drm_property_create_range(dev, 0, "bottom margin", 0, 100);
- if (!dev->mode_config.tv_bottom_margin_property)
+ if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
dev->mode_config.tv_mode_property =
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 9d28e8180cfd..594f8d33a61f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1238,9 +1238,11 @@ const char *drm_get_tv_select_name(int val);
const char *drm_get_content_protection_name(int val);
int drm_mode_create_dvi_i_properties(struct drm_device *dev);
+int drm_mode_create_tv_margin_properties(struct drm_device *dev);
int drm_mode_create_tv_properties(struct drm_device *dev,
[PATCH v4 2/5] drm/connector: Clarify the unit of TV margins
All margins are expressed in pixels. Clarify that in the doc.
Signed-off-by: Boris Brezillon
---
include/drm/drm_connector.h | 2 +-
include/drm/drm_mode_config.h | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 665b9cae7f43..9d28e8180cfd 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -394,7 +394,7 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
/**
* struct drm_tv_connector_state - TV connector related states
* @subconnector: selected subconnector
- * @margins: margins
+ * @margins: margins (all margins are expressed in pixels)
* @margins.left: left margin
* @margins.right: right margin
* @margins.top: top margin
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 5dbeabdbaf91..30bb3ce85921 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -674,22 +674,22 @@ struct drm_mode_config {
struct drm_property *tv_mode_property;
/**
* @tv_left_margin_property: Optional TV property to set the left
-* margin.
+* margin (expressed in pixels).
*/
struct drm_property *tv_left_margin_property;
/**
* @tv_right_margin_property: Optional TV property to set the right
-* margin.
+* margin (expressed in pixels).
*/
struct drm_property *tv_right_margin_property;
/**
* @tv_top_margin_property: Optional TV property to set the right
-* margin.
+* margin (expressed in pixels).
*/
struct drm_property *tv_top_margin_property;
/**
* @tv_bottom_margin_property: Optional TV property to set the right
-* margin.
+* margin (expressed in pixels).
*/
struct drm_property *tv_bottom_margin_property;
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/5] vc4/hdmi: Support TV margin props
Hello, As suggested by Ville, this version uses the already available TV margin props to define left/right/top/bottom margins insted of adding new underscan props. This works pretty well for what we want to do in VC4: allow one to define the visible area on a TV. The first 2 patches are fixing the existing doc, patch 3 is allowing one to create and attach TV margins independently of the TV connector props. Finally, patch 4 and 5 add support for those props to the VC4 driver. Regards, Boris Boris Brezillon (5): drm/connector: Fix drm_mode_create_tv_properties() doc drm/connector: Clarify the unit of TV margins drm/connector: Allow creation of margin props alone drm/vc4: Take margin setup into account when updating planes drm/vc4: Attach margin props to the HDMI connector drivers/gpu/drm/drm_connector.c | 83 + drivers/gpu/drm/vc4/vc4_crtc.c | 43 + drivers/gpu/drm/vc4/vc4_drv.h | 3 ++ drivers/gpu/drm/vc4/vc4_hdmi.c | 16 +++ drivers/gpu/drm/vc4/vc4_plane.c | 50 include/drm/drm_connector.h | 4 +- include/drm/drm_mode_config.h | 8 ++-- 7 files changed, 183 insertions(+), 24 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/connector: Fix drm_mode_create_tv_properties() doc
The in the kernel-doc header did not match the function name. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/drm_connector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index fa9baacc863b..408082a57171 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1138,7 +1138,7 @@ void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame, EXPORT_SYMBOL(drm_hdmi_avi_infoframe_content_type); /** - * drm_create_tv_properties - create TV specific connector properties + * drm_mode_create_tv_properties - create TV specific connector properties * @dev: DRM device * @num_modes: number of different TV formats (modes) supported * @modes: array of pointers to strings containing name of each format -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Spice-devel] [PATCH] drm/qxl: use qxl_num_crtc directly
> > qdev->monitors_config->max_allowed is effectively set by a module > > parameter. So using the module parameter variable qxl_num_crtc > > directly is better IMO. The kernel doesn't need to dereference pointers > > each time it needs the value, and when reading the code you don't have > > to trace where and why qdev->monitors_config->max_allowed is set. > > That should go to the commit message! > With that the patch is fine for me. ok, I'll improve the message. > Maybe there's no much point on reusing the same structure used > inside QXLRom/QXLRam but this is OT for this patch. It's part of the qxl device ABI, the same structure is used for both host->guest (config hint from spice-client) and guest->host (actual configuration). cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 = >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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 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
