[PATCH v2 11/14] MAINTAINERS: Add maintainer entry for the MSM DRM driver
Rob and Archit are the main developers behind the driver. v2: Removing Archit for now, correcting the status and adding linux-arm-msm@ mailing list. Cc: Rob Clark Cc: Archit Taneja Signed-off-by: Emil Velikov --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c81e02d..a7c6a80 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3839,6 +3839,17 @@ T: git git://github.com/patjak/drm-gma500 S: Maintained F: drivers/gpu/drm/gma500/ +DRM DRIVER FOR MSM ADRENO GPU +M: Rob Clark +L: linux-arm-msm at vger.kernel.org +L: dri-devel at lists.freedesktop.org +L: freedreno at lists.freedesktop.org +T: git git://people.freedesktop.org/~robclark/linux +S: Maintained +F: drivers/gpu/drm/msm/ +F: include/uapi/drm/msm_drm.h +F: Documentation/devicetree/bindings/display/msm/ + DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS M: Ben Skeggs L: dri-devel at lists.freedesktop.org -- 2.6.2
[PATCH v2 12/14] MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver
Thomas is one of the original authors of the driver, with recent contributions from Sinclair and Brian. v2: Add Sinclair as maintainer. Add Sinclair+Thomas's tree, use Supported as status. Cc: Sinclair Yeh Cc: Thomas Hellstrom Cc: Brian Paul Cc: "VMware Graphics" Signed-off-by: Emil Velikov --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a7c6a80..cf9b6d2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3909,6 +3909,17 @@ F: drivers/gpu/drm/etnaviv/ F: include/uapi/drm/etnaviv_drm.h F: Documentation/devicetree/bindings/display/etnaviv/ +DRM DRIVER FOR VMWARE VIRTUAL GPU +M: "VMware Graphics" +M: Sinclair Yeh +M: Thomas Hellstrom +L: dri-devel at lists.freedesktop.org +T: git git://people.freedesktop.org/~syeh/repos_linux +T: git git://people.freedesktop.org/~thomash/linux +S: Supported +F: drivers/gpu/drm/vmwgfx/ +F: include/uapi/drm/vmwgfx_drm.h + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-media at vger.kernel.org -- 2.6.2
[PATCH 10/14] MAINTAINERS: Add maintainer entry for the Nouveau DRM driver
On 04/22/2016 09:03 AM, Emil Velikov wrote: > Ben has been the maintainer of the driver even before it got included in > the kernel. > > Cc: Ben Skeggs > Cc: Dave Airlie > Signed-off-by: Emil Velikov Acked-by: Ben Skeggs > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b9eddf1..c81e02d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3839,6 +3839,15 @@ T: git git://github.com/patjak/drm-gma500 > S: Maintained > F: drivers/gpu/drm/gma500/ > > +DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS > +M: Ben Skeggs > +L: dri-devel at lists.freedesktop.org > +L: nouveau at lists.freedesktop.org > +T: git git://github.com/skeggsb/linux > +S: Supported > +F: drivers/gpu/drm/nouveau/ > +F: include/uapi/drm/nouveau_drm.h > + > DRM DRIVERS FOR NVIDIA TEGRA > M: Thierry Reding > M: Terje Bergström > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/486714db/attachment-0001.sig>
ubsan report on gfx_v8_0_get_cu_info
While trying to track down some crashes on my Fiji I enabled UBSAN and got this, this led me to look at the function mentioned, and wow totally undefined code land. The code loops over num_shader_engines with i, then uses i * 16 in a calc for a left-shift. On Fiji at least num_shader_engines is 4, so clearly we are going to see shifts > 32 with that. The userspace ABI seems limited to a 32-bit value as well here, which to me seems to point out something stinks in either the UABI design or the calculations here. Dave. [ 733.803161] [ 733.803169] UBSAN: Undefined behaviour in /home/airlied/devel/kernel/linux-2.6/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:5188:29 [ 733.803172] shift exponent 32 is too large for 32-bit type 'unsigned int' [ 733.803176] CPU: 0 PID: 1787 Comm: Xorg Not tainted 4.6.0-rc6+ #94 [ 733.803178] Hardware name: Gigabyte Technology Co., Ltd. GA-A75M-UD2H/GA-A75M-UD2H, BIOS F6 09/28/2012 [ 733.803180] 880232753a78 814628e5 0006 [ 733.803184] 880232753aa0 0003 880232753a90 814a5ce9 [ 733.803188] a0390e5e 880232753b30 814a6576 0202 [ 733.803191] Call Trace: [ 733.803198] [] dump_stack+0x68/0x99 [ 733.803200] [] ubsan_epilogue+0xd/0x3a [ 733.803203] [] __ubsan_handle_shift_out_of_bounds+0x11f/0x148 [ 733.803207] [] ? syscall_trace_enter_phase2+0x240/0x3a9 [ 733.803210] [] ? _raw_spin_unlock_irqrestore+0x3a/0x48 [ 733.803268] [] gfx_v8_0_get_cu_info+0x22b/0x2d1 [amdgpu] [ 733.803318] [] ? gfx_v8_0_get_cu_info+0x22b/0x2d1 [amdgpu] [ 733.803363] [] amdgpu_info_ioctl+0xe91/0xf64 [amdgpu] [ 733.803405] [] drm_ioctl+0x379/0x524 [drm] [ 733.803408] [] ? __pm_runtime_resume+0x84/0x91 [ 733.803452] [] ? amdgpu_debugfs_cleanup+0x6/0x6 [amdgpu] [ 733.803456] [] ? trace_hardirqs_on_caller+0x1f8/0x227 [ 733.803458] [] ? trace_hardirqs_on+0xd/0xf [ 733.803503] [] amdgpu_drm_ioctl+0x99/0xe1 [amdgpu] [ 733.803506] [] vfs_ioctl+0x5a/0x6f [ 733.803508] [] do_vfs_ioctl+0x724/0x7bb [ 733.803511] [] ? security_file_ioctl+0x43/0x57 [ 733.803514] [] ? __fget_light+0xca/0x111 [ 733.803516] [] SyS_ioctl+0x52/0x74 [ 733.803518] [] do_syscall_64+0x85/0x12c [ 733.803521] [] entry_SYSCALL64_slow_path+0x25/0x25 [ 733.803523] = ~ ~ ~
[Bug 71789] [r300g] Visuals not found in (default) depth = 24
https://bugs.freedesktop.org/show_bug.cgi?id=71789 --- Comment #25 from erhard_f at mailbox.org --- Patched on top on 79b0e13913b5189bb8629e80439fea746f99fe79 and it works! Many thanks! Machine used is a PowerMac G5 7,3 with an AGP Radeon 9600 Pro (Mac edition). Running Compton composting manager (Ubuntu MATE 16.04) and it runs without glitches so far, colours look good. Only thing I noticed is the desktop gets unresponsive and the mouse pointer very jerky during youtube video playback. Will try Piglit tests the next days. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/1f0f054a/attachment.html>
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
On 9 March 2016 at 18:57, Archit Taneja wrote: > ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an > additional DSI RX block that takes in DSI video mode output. > > Trying to get this driver merged has had some challenges: > > - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. > After discussions, it was concluded that we'd want to provide an > API to create MIPI DSI devices, rather than expose two different > interfaces on DT. The first version [1] tried the former approach > the second version [2] showed how the driver would look like if > exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI > device creation API provided by [3], this has been accepted and > should be merged for 4.6. > > - The driver was designed as an I2C slave encoder. When ADV7533 > patches were posted [1], it was modelled as a bridge, but ADV7511 > and others were still left as I2C slave encoders. This wasn't > accepted. After discussions, it was decided that ADV7511 too would > be converted into a bridge driver, and all the users of ADV7511 > should assume it is a bridge. This bridge conversion was done in > [4]. There is still some debate over whether the bridge driver be > involved in the connector creation, or the KMS driver that has > the whole view of the display pipeline. This discussion shouldn't > affect this patch set, though. > > This patch set enables ADV7533 support with the above two issues > now resolved. It also incorporates ADV7533 specific features and fixes > that we've discovered since the first version of this patch was posted. > > Tested on ADV7533 chips on DB410c. It should work on the Hikey board too. > I'd appreaciate if someone could test it on a ADV7511 platform since I > don't have one. > > [4] > https://lists.freedesktop.org/archives/dri-devel/2016-January/098287.html > > [3] > https://lkml.org/lkml/2016/2/12/67 > > [2] > https://lists.freedesktop.org/archives/dri-devel/2015-September/089884.html > > [1]: > https://lists.freedesktop.org/archives/dri-devel/2015-July/087088.html > > Archit Taneja (7): > drm/i2c: adv7511: Convert to drm_bridge > drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled > drm/i2c: adv7511: Initial support for ADV7533 > drm/i2c: adv7511: Create a MIPI DSI device > drm/i2c: adv7511: Use internal timing generator > drm/i2c: adv7511: Change number of DSI lanes dynamically > dt-bindings: drm/bridge: Update bindings for ADV7533 > > .../bindings/display/bridge/adi,adv7511.txt| 25 +- > drivers/gpu/drm/i2c/adv7511.c | 539 > + > 2 files changed, 476 insertions(+), 88 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation > This patch set is Tested-by: Xinliang Liu Thanks -xinliang
[PATCH] drm/amdgpu: set metadata pointer to NULL after freeing.
From: Dave Airlie
Without this there was a double free of the metadata,
which ended up freeing the fd table for me here, and taking
out the machine more often than not.
I reproduced with X.org + modesetting DDX + latest llvm/mesa,
also required using dri3.
Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e557fc1..7ecea83 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -541,6 +541,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void
*metadata,
if (!metadata_size) {
if (bo->metadata_size) {
kfree(bo->metadata);
+ bo->metadata = NULL;
bo->metadata_size = 0;
}
return 0;
--
2.5.5
[Bug 73785] [HyperZ] Team Fortress 2 causes random GPU stalls on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=73785 Mat�as Locatti changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #11 from Mat�as Locatti --- I'm having this issue with an HD7750, running mesa-git didn't fix it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/e05154fe/attachment-0001.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Bug 75112 depends on bug 73785, which changed state. Bug 73785 Summary: [HyperZ] Team Fortress 2 causes random GPU stalls on radeonsi https://bugs.freedesktop.org/show_bug.cgi?id=73785 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/14b54bd8/attachment.html>
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commits:
f7e5838bb37d ("drm/i915: Simplify reset_counter handling during atomic
modesetting")
from the drm-intel tree and commit:
81072bfd13f2 ("drm/i915: Rename async to nonblock.")
from the drm-misc 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/i915/intel_display.c
index ff60241b1f76,5d29b838d8d7..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -13462,9 -13414,12 +13462,9 @@@ static int intel_atomic_prepare_commit(
return ret;
ret = drm_atomic_helper_prepare_planes(dev, state);
- if (!ret && !nonblock && !i915_reset_in_progress(&dev_priv->gpu_error))
{
- u32 reset_counter;
-
- reset_counter = atomic_read(&dev_priv->gpu_error.reset_counter);
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
- if (!ret && !async) {
++ if (!ret && !nonblock) {
for_each_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
linux-next: manual merge of the drm-msm tree with the drm-misc tree
Hi Rob,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/msm_atomic.c
between commit:
a3ccfb9feb46 ("drm/msm: Rename async to nonblock.")
from the drm-misc tree and commit:
afadc4bb9380 ("drm/msm: remove fence_cbs")
from the drm-msm 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/msm/msm_atomic.c
index 5c6130969f4d,2b4142a05024..
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@@ -199,11 -190,11 +189,11 @@@ int msm_atomic_check(struct drm_device
* Zero for success or -errno.
*/
int msm_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state, bool async)
+ struct drm_atomic_state *state, bool nonblock)
{
+ struct msm_drm_private *priv = dev->dev_private;
int nplanes = dev->mode_config.num_total_plane;
int ncrtcs = dev->mode_config.num_crtc;
- ktime_t timeout;
struct msm_commit *c;
int i, ret;
@@@ -275,8 -270,8 +269,8 @@@
* current layout.
*/
- if (async) {
+ if (nonblock) {
- msm_queue_fence_cb(dev, &c->fence_cb, c->fence);
+ queue_work(priv->atomic_wq, &c->work);
return 0;
}
[PATCH 1/6] drm/fb: fix missing /** in kerneldoc comment.
From: Dave Airlie Signed-off-by: Dave Airlie --- include/drm/drm_crtc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 297e527..6279989 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -2606,7 +2606,7 @@ static inline uint32_t drm_color_lut_extract(uint32_t user_input, return clamp_val(val, 0, max); } -/* +/** * drm_framebuffer_reference - incr the fb refcnt * @fb: framebuffer * -- 2.5.5
[PATCH 2/6] drm/modes: add connector reference counting. (v2)
From: Dave Airlie
This uses the previous changes to add reference counts
to drm connector objects.
v2: move fbdev changes to their own patch.
add some kerneldoc
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c | 19 +--
drivers/gpu/drm/drm_crtc.c | 28
include/drm/drm_crtc.h | 32 +++-
3 files changed, 72 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8ee1db8..9d5e3c8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -154,6 +154,7 @@ void drm_atomic_state_default_clear(struct drm_atomic_state
*state)
state->connector_states[i]);
state->connectors[i] = NULL;
state->connector_states[i] = NULL;
+ drm_connector_unreference(connector);
}
for (i = 0; i < config->num_crtc; i++) {
@@ -924,6 +925,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state
*state,
if (!connector_state)
return ERR_PTR(-ENOMEM);
+ drm_connector_reference(connector);
state->connector_states[index] = connector_state;
state->connectors[index] = connector;
connector_state->state = state;
@@ -1614,12 +1616,19 @@ retry:
}
obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
- if (!obj || !obj->properties) {
+ if (!obj) {
+ ret = -ENOENT;
+ goto out;
+ }
+
+ if (!obj->properties) {
+ drm_mode_object_unreference(obj);
ret = -ENOENT;
goto out;
}
if (get_user(count_props, count_props_ptr + copied_objs)) {
+ drm_mode_object_unreference(obj);
ret = -EFAULT;
goto out;
}
@@ -1632,12 +1641,14 @@ retry:
struct drm_property *prop;
if (get_user(prop_id, props_ptr + copied_props)) {
+ drm_mode_object_unreference(obj);
ret = -EFAULT;
goto out;
}
prop = drm_property_find(dev, prop_id);
if (!prop) {
+ drm_mode_object_unreference(obj);
ret = -ENOENT;
goto out;
}
@@ -1645,13 +1656,16 @@ retry:
if (copy_from_user(&prop_value,
prop_values_ptr + copied_props,
sizeof(prop_value))) {
+ drm_mode_object_unreference(obj);
ret = -EFAULT;
goto out;
}
ret = atomic_set_prop(state, obj, prop, prop_value);
- if (ret)
+ if (ret) {
+ drm_mode_object_unreference(obj);
goto out;
+ }
copied_props++;
}
@@ -1662,6 +1676,7 @@ retry:
plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
}
+ drm_mode_object_unreference(obj);
}
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4e5b015..a78e202 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -862,6 +862,16 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
mode->interlace ? " interlaced" : "");
}
+static void drm_connector_free(struct kref *kref)
+{
+ struct drm_connector *connector =
+ container_of(kref, struct drm_connector, base.refcount);
+ struct drm_device *dev = connector->dev;
+
+ drm_mode_object_unregister(dev, &connector->base);
+ connector->funcs->destroy(connector);
+}
+
/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
@@ -887,7 +897,9 @@ int drm_connector_init(struct drm_device *dev,
drm_modeset_lock_all(dev);
- ret = drm_mode_object_get_reg(dev, &connector->base,
DRM_MODE_OBJECT_CONNECTOR, false, NULL);
+ ret = drm_mode_object_get_reg(dev, &connector->base,
+ DRM_MODE_OBJECT_CONNECTOR,
+ false, drm_connector_free);
if (ret)
goto out_unlock;
@@ -2147,7 +2159,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*da
[PATCH 3/6] drm/fb_helper: add connector reference counting. (v2)
From: Dave Airlie
This takes a reference count when fbdev adds the connector,
and drops it when it removes the connector.
It also drops the now unneeded code to find connectors
and remove the from the modeset as they are reference counted.
v2: drop references when removing all connectors at end.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c | 38 +-
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 855108e..19a7a71 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -153,40 +153,13 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper
*fb_helper, struct drm_
if (!fb_helper_connector)
return -ENOMEM;
+ drm_connector_reference(connector);
fb_helper_connector->connector = connector;
fb_helper->connector_info[fb_helper->connector_count++] =
fb_helper_connector;
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-static void remove_from_modeset(struct drm_mode_set *set,
- struct drm_connector *connector)
-{
- int i, j;
-
- for (i = 0; i < set->num_connectors; i++) {
- if (set->connectors[i] == connector)
- break;
- }
-
- if (i == set->num_connectors)
- return;
-
- for (j = i + 1; j < set->num_connectors; j++) {
- set->connectors[j - 1] = set->connectors[j];
- }
- set->num_connectors--;
-
- /*
-* TODO maybe need to makes sure we set it back to !=NULL somewhere?
-*/
- if (set->num_connectors == 0) {
- set->fb = NULL;
- drm_mode_destroy(connector->dev, set->mode);
- set->mode = NULL;
- }
-}
-
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector)
{
@@ -206,6 +179,7 @@ int drm_fb_helper_remove_one_connector(struct drm_fb_helper
*fb_helper,
if (i == fb_helper->connector_count)
return -EINVAL;
fb_helper_connector = fb_helper->connector_info[i];
+ drm_connector_unreference(fb_helper_connector->connector);
for (j = i + 1; j < fb_helper->connector_count; j++) {
fb_helper->connector_info[j - 1] = fb_helper->connector_info[j];
@@ -213,10 +187,6 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
fb_helper->connector_count--;
kfree(fb_helper_connector);
- /* also cleanup dangling references to the connector: */
- for (i = 0; i < fb_helper->crtc_count; i++)
- remove_from_modeset(&fb_helper->crtc_info[i].mode_set,
connector);
-
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
@@ -626,8 +596,10 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
*helper)
{
int i;
- for (i = 0; i < helper->connector_count; i++)
+ for (i = 0; i < helper->connector_count; i++) {
+ drm_connector_unreference(helper->connector_info[i]->connector);
kfree(helper->connector_info[i]);
+ }
kfree(helper->connector_info);
for (i = 0; i < helper->crtc_count; i++) {
kfree(helper->crtc_info[i].mode_set.connectors);
--
2.5.5
[PATCH 4/6] drm/crtc: take references to connectors used in a modeset. (v2)
From: Dave Airlie
This just takes a reference on the connector when we set a mode
in the non-atomic paths.
v2: Follow Daniel Stone's suggestions on when to take/drop
references.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc_helper.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 66ca313..f47a252 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -456,6 +456,9 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
* between them is henceforth no longer available.
*/
connector->dpms = DRM_MODE_DPMS_OFF;
+
+ /* we keep a reference while the encoder is bound */
+ drm_connector_unreference(connector);
}
}
@@ -606,6 +609,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
mode_changed = true;
}
+ /* take a reference on all connectors in set */
+ for (ro = 0; ro < set->num_connectors; ro++) {
+ drm_connector_reference(set->connectors[ro]);
+ }
+
/* a) traverse passed in connector list and get encoders for them */
count = 0;
drm_for_each_connector(connector, dev) {
@@ -724,6 +732,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
}
}
+ /* after fail drop reference on all connectors in save set */
+ count = 0;
+ drm_for_each_connector(connector, dev) {
+ drm_connector_unreference(&save_connectors[count++]);
+ }
+
kfree(save_connectors);
kfree(save_encoders);
return 0;
@@ -740,6 +754,11 @@ fail:
*connector = save_connectors[count++];
}
+ /* after fail drop reference on all connectors in set */
+ for (ro = 0; ro < set->num_connectors; ro++) {
+ drm_connector_unreference(set->connectors[ro]);
+ }
+
/* Try to restore the config */
if (mode_changed &&
!drm_crtc_helper_set_mode(save_set.crtc, save_set.mode, save_set.x,
--
2.5.5
[PATCH 5/6] drm/atomic: use connector references (v2)
From: Dave Airlie
Take a reference when setting a crtc on a connecter,
also take one when duplicating if a crtc is set,
and drop one on destroy if a crtc is set.
v2: take Daniel Stone's advice and simplify the
ref/unref dances, also take care of NULL as connector
to state reset.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c| 4
drivers/gpu/drm/drm_atomic_helper.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9d5e3c8..91cae88 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1160,6 +1160,8 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
{
struct drm_crtc_state *crtc_state;
+ if (crtc)
+ drm_connector_reference(conn_state->connector);
if (conn_state->crtc && conn_state->crtc != crtc) {
crtc_state =
drm_atomic_get_existing_crtc_state(conn_state->state,
conn_state->crtc);
@@ -1177,6 +1179,8 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
1 << drm_connector_index(conn_state->connector);
}
+ if (conn_state->crtc)
+ drm_connector_unreference(conn_state->connector);
conn_state->crtc = crtc;
if (crtc)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d25abce..f3e2642 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2762,6 +2762,8 @@ __drm_atomic_helper_connector_duplicate_state(struct
drm_connector *connector,
struct drm_connector_state *state)
{
memcpy(state, connector->state, sizeof(*state));
+ if (state->crtc)
+ drm_connector_reference(connector);
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
@@ -2889,6 +2891,9 @@ __drm_atomic_helper_connector_destroy_state(struct
drm_connector *connector,
* state will automatically do the right thing if code is ever added
* to this function.
*/
+ if (connector && state->crtc) {
+ drm_connector_unreference(state->connector);
+ }
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
--
2.5.5
[PATCH 6/6] drm/i915/mst: use reference counted connectors. (v3)
From: Dave Airlie
Don't just free the connector when we get the destroy callback.
Drop a reference to it, and set it's mst_port to NULL so
no more mst work is done on it.
v2: core mst accepts NULLs fine. Cleanup EDID code properly.
v3: drop the extra reference we were taking.
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_dp_mst.c | 43 +
drivers/gpu/drm/i915/intel_drv.h| 2 +-
2 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 94b4e83..b6bf7fd 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -109,7 +109,7 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder)
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
- drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, intel_mst->port);
+ drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr,
intel_mst->connector->port);
ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
if (ret) {
@@ -134,10 +134,11 @@ static void intel_mst_post_disable_dp(struct
intel_encoder *encoder)
/* and this can also fail */
drm_dp_update_payload_part2(&intel_dp->mst_mgr);
- drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, intel_mst->port);
+ drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr,
intel_mst->connector->port);
intel_dp->active_mst_links--;
- intel_mst->port = NULL;
+
+ intel_mst->connector = NULL;
if (intel_dp->active_mst_links == 0) {
intel_dig_port->base.post_disable(&intel_dig_port->base);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
@@ -177,7 +178,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder)
found->encoder = encoder;
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
- intel_mst->port = found->port;
+
+ intel_mst->connector = found;
if (intel_dp->active_mst_links == 0) {
intel_prepare_ddi_buffer(&intel_dig_port->base);
@@ -195,7 +197,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder)
}
ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr,
- intel_mst->port,
+ intel_mst->connector->port,
intel_crtc->config->pbn, &slots);
if (ret == false) {
DRM_ERROR("failed to allocate vcpi\n");
@@ -244,7 +246,7 @@ static bool intel_dp_mst_enc_get_hw_state(struct
intel_encoder *encoder,
{
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
*pipe = intel_mst->pipe;
- if (intel_mst->port)
+ if (intel_mst->connector)
return true;
return false;
}
@@ -308,10 +310,11 @@ static int intel_dp_mst_get_ddc_modes(struct
drm_connector *connector)
struct edid *edid;
int ret;
- edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr,
intel_connector->port);
- if (!edid)
- return 0;
+ if (!intel_dp) {
+ return intel_connector_update_modes(connector, NULL);
+ }
+ edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr,
intel_connector->port);
ret = intel_connector_update_modes(connector, edid);
kfree(edid);
@@ -324,6 +327,8 @@ intel_dp_mst_detect(struct drm_connector *connector, bool
force)
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
+ if (!intel_dp)
+ return connector_status_disconnected;
return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
intel_connector->port);
}
@@ -389,6 +394,8 @@ static struct drm_encoder
*intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
+ if (!intel_dp)
+ return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
@@ -396,6 +403,8 @@ static struct drm_encoder *intel_mst_best_encoder(struct
drm_connector *connecto
{
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
+ if (!intel_dp)
+ return NULL;
return &intel_dp->mst_encoders[0]->base.base;
}
@@ -506,23 +515,11 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
/* need to nuke the connector */
drm_modeset_lock_all(dev);
- if (connector->state->crtc) {
- struct drm_mode_set set;
- int ret;
-
- memset(&set, 0, sizeof(set));
- set.crtc = connector->state->crtc,
-
- ret = drm_atomic_helper_set_config(&set);
-
[PATCH 02/23] drm: omapdrm: fb: Don't store format BPP for each plane
On 03/05/16 00:01, Rob Clark wrote:
> On Mon, May 2, 2016 at 11:43 AM, Tomi Valkeinen
> wrote:
>> Hi Laurent,
>>
>> On 26/04/16 23:35, Laurent Pinchart wrote:
>>> The number of bits per pixel is identical for all planes, don't store
>>> multiple copies.
>>
>> That's not true, as with NV12, Y has 8 bits per pixel and UV has 16 bits
>> per pixel. But as the subsampling is precalculated into the stride_bpp
>> (is it bytes or bits? bpp always confuses me =), the 'stride_bpp' ends
>> up being same for both planes.
>>
>> To be honest, I'd rather go into more complex struct than simpler one.
>> The current one is already confusing, I think, and your version is too.
>> The main issue is that the sub_x is encoded into the stride_bpp. In
>> kmsxx I used this format:
>>
>> { PixelFormat::NV12, { 2, { { 8, 1, 1, }, { 8, 2, 2 } }, } },
>>
>> The first number is the number of planes, and for each plane, bitspp,
>> xsub and ysub. It's more verbose, but (I think) easier to understand.
>
> fwiw, I guess a lot of data from that table could these days be
> replaced w/ some of the drm format helpers
> (drm_format_num_planes()/drm_format_plane_cpp()/drm_format_{horz,vert}_chroma_subsampling()/etc)
Indeed, I think we can remove all but the DRM -> DSS format mapping.
Btw, what is "cpp" short from?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/56e7eef5/attachment.sig>
[GIT PULL] drm/rockchip: some fixes
Hi Dave Here are some little fixes for rockchip drm, looks good for me, and seems there is no doubt on them, So I'd like you can land them. The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4: Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next (2016-04-29 14:57:51 +1000) are available in the git repository at: https://github.com/markyzq/kernel-drm-rockchip.git drm-rockchip-next-fixes-05-03 for you to fetch changes up to 2db00cf5a07b7c543392ff88163428509cda38ae: drm/rockchip: vop: Initialize vskiplines to zero (2016-05-03 14:11:23 +0800) Dan Carpenter (1): drm/rockchip: inno_hdmi: fix an error code John Keeping (2): drm/rockchip: remove redundant statement drm/rockchip: don't leak iommu mapping Mark Yao (4): drm/rockchip: get rid of rockchip_drm_crtc_mode_config drm/rockchip: support non-iommu buffer path drm/rockchip: vop: fix iommu crash with async atomic drm/rockchip: vop: Initialize vskiplines to zero drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 +++- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 38 -- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17 ++--- drivers/gpu/drm/rockchip/inno_hdmi.c| 20 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 66 +++--- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 10 -- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 95 --- 7 files changed, 196 insertions(+), 98 deletions(-) -- ï¼ark Yao
[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=95247 Bug ID: 95247 Summary: System hangs after ~10 minutes when using Radeon R9 390 Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: sandy.8925 at gmail.com Hardware specs: Intel Core i5-6600k MSI Z170A Gaming Pro motherboard Radeon R9 390 Boot system with Radeon R9 390 as main output (by choosing PEG as output in UEFI settings). Started up Gnome Wayland session. System hangs after some time. Does not respond to keyboard and mouse input. Cannot switch to TTYs either. Can however restart the system using Ctrl + Alt + PrtScr R-S-E-I-S-U-B Works perfectly fine with the integrated Intel GPU. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/30664fd9/attachment.html>
[Bug 71789] [r300g] Visuals not found in (default) depth = 24
https://bugs.freedesktop.org/show_bug.cgi?id=71789 --- Comment #26 from Mathieu Malaterre --- I believe that the testers should also make sure to use PCI instead of AGP during there testing. See bug: https://bugs.freedesktop.org/show_bug.cgi?id=95017. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/7cd27be9/attachment-0001.html>
[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=95247 --- Comment #1 from Sandeep --- Found the following in kernel logs: May 02 23:37:31 GetsugaTenshou kernel: radeon :01:00.0: ring 0 stalled for more than 10052msec May 02 23:37:31 GetsugaTenshou kernel: radeon :01:00.0: GPU lockup (current fence id 0x000121ff last fence id 0x00012209 on ring 0) May 02 23:37:31 GetsugaTenshou kernel: radeon :01:00.0: ring 4 stalled for more than 10084msec May 02 23:37:31 GetsugaTenshou kernel: radeon :01:00.0: GPU lockup (current fence id 0xb547 last fence id 0xb548 on ring 4) May 02 23:37:31 GetsugaTenshou kernel: radeon :01:00.0: ring 3 stalled for more than 10128msec May 02 23:37:31 GetsugaTenshou kernel: radeon :01:00.0: GPU lockup (current fence id 0x2c7c last fence id 0x2c7d on ring 3) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/9abd5435/attachment.html>
[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=95247 --- Comment #2 from Sandeep --- May 02 23:37:32 GetsugaTenshou kernel: [drm:ci_dpm_enable [radeon]] *ERROR* ci_start_dpm failed May 02 23:37:32 GetsugaTenshou kernel: [drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed May 02 23:37:32 GetsugaTenshou kernel: [drm] probing gen 2 caps for device 8086:1901 = 261ad03/e May 02 23:37:32 GetsugaTenshou kernel: [drm] PCIE gen 3 link speeds already enabled May 02 23:37:32 GetsugaTenshou kernel: [drm] PCIE GART of 2048M enabled (table at 0x00324000). May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: WB enabled May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 0 use gpu addr 0x00020c00 and cpu addr 0x880459248c00 May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 1 use gpu addr 0x00020c04 and cpu addr 0x880459248c04 May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 2 use gpu addr 0x00020c08 and cpu addr 0x880459248c08 May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 3 use gpu addr 0x00020c0c and cpu addr 0x880459248c0c May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 4 use gpu addr 0x00020c10 and cpu addr 0x880459248c10 May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00076c98 and cpu addr 0xc90004c36c98 May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 6 use gpu addr 0x00020c18 and cpu addr 0x880459248c18 May 02 23:37:32 GetsugaTenshou kernel: radeon :01:00.0: fence driver on ring 7 use gpu addr 0x00020c1c and cpu addr 0x880459248c1c May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 0 succeeded in 4 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 1 succeeded in 3 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 2 succeeded in 2 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 3 succeeded in 5 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 4 succeeded in 5 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 5 succeeded in 2 usecs May 02 23:37:32 GetsugaTenshou kernel: sysrq: SysRq : Emergency Sync May 02 23:37:32 GetsugaTenshou kernel: [drm] UVD initialized successfully. May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 6 succeeded in 1168 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] ring test on 7 succeeded in 4 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] VCE initialized successfully. May 02 23:37:32 GetsugaTenshou kernel: [drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed May 02 23:37:32 GetsugaTenshou kernel: [drm] ib test on ring 0 succeeded in 0 usecs May 02 23:37:32 GetsugaTenshou kernel: [drm] ib test on ring 1 succeeded in 0 usecs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/7e11f372/attachment.html>
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
On 05/03/2016 07:22 AM, Xinliang Liu wrote: > On 9 March 2016 at 18:57, Archit Taneja wrote: >> ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an >> additional DSI RX block that takes in DSI video mode output. >> >> Trying to get this driver merged has had some challenges: >> >> - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. >>After discussions, it was concluded that we'd want to provide an >>API to create MIPI DSI devices, rather than expose two different >>interfaces on DT. The first version [1] tried the former approach >>the second version [2] showed how the driver would look like if >>exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI >>device creation API provided by [3], this has been accepted and >>should be merged for 4.6. >> >> - The driver was designed as an I2C slave encoder. When ADV7533 >>patches were posted [1], it was modelled as a bridge, but ADV7511 >>and others were still left as I2C slave encoders. This wasn't >>accepted. After discussions, it was decided that ADV7511 too would >>be converted into a bridge driver, and all the users of ADV7511 >>should assume it is a bridge. This bridge conversion was done in >>[4]. There is still some debate over whether the bridge driver be >>involved in the connector creation, or the KMS driver that has >>the whole view of the display pipeline. This discussion shouldn't >>affect this patch set, though. >> >> This patch set enables ADV7533 support with the above two issues >> now resolved. It also incorporates ADV7533 specific features and fixes >> that we've discovered since the first version of this patch was posted. >> >> Tested on ADV7533 chips on DB410c. It should work on the Hikey board too. >> I'd appreaciate if someone could test it on a ADV7511 platform since I >> don't have one. >> >> [4] >> https://lists.freedesktop.org/archives/dri-devel/2016-January/098287.html >> >> [3] >> https://lkml.org/lkml/2016/2/12/67 >> >> [2] >> https://lists.freedesktop.org/archives/dri-devel/2015-September/089884.html >> >> [1]: >> https://lists.freedesktop.org/archives/dri-devel/2015-July/087088.html >> >> Archit Taneja (7): >>drm/i2c: adv7511: Convert to drm_bridge >>drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled >>drm/i2c: adv7511: Initial support for ADV7533 >>drm/i2c: adv7511: Create a MIPI DSI device >>drm/i2c: adv7511: Use internal timing generator >>drm/i2c: adv7511: Change number of DSI lanes dynamically >>dt-bindings: drm/bridge: Update bindings for ADV7533 >> >> .../bindings/display/bridge/adi,adv7511.txt| 25 +- >> drivers/gpu/drm/i2c/adv7511.c | 539 >> + >> 2 files changed, 476 insertions(+), 88 deletions(-) >> >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >> hosted by The Linux Foundation >> > > This patch set is Tested-by: Xinliang Liu Thanks for testing! Archit > > Thanks > -xinliang > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 4/7] drm/i2c: adv7511: Create a MIPI DSI device
Hi Laurent,
On 04/22/2016 10:40 AM, Archit Taneja wrote:
> Hi Laurent,
>
>
> On 04/22/2016 03:59 AM, Laurent Pinchart wrote:
>> Hi Archit,
>>
>> Thank you for the patch.
>>
>> On Wednesday 09 Mar 2016 16:27:15 Archit Taneja wrote:
>>> In order to pass DSI specific parameters to the DSI host, we need the
>>> driver to create a mipi_dsi_device DSI device that attaches to the
>>> host.
>>>
>>> Use of_graph helpers to get the DSI host DT node. Create a MIPI DSI
>>> device using this host. Finally, attach this device to the DSI host.
>>>
>>> Populate DT parameters (number of data lanes for now) that are required
>>> for DSI RX to work correctly. Hardcode few other parameters (rgb,
>>> embedded_sync) for now.
>>>
>>> Signed-off-by: Archit Taneja
>>
>> This adds a hard dependency on CONFIG_DRM_MIPI_DSI, otherwise the
>> kernel won't
>> link. As the ADV7511 doesn't require DSI, could you make it optional with
>> conditional compilation to avoid pulling in dead code ?
>
> You're right. The driver's Kconfig should at least select DRM_MIPI_DSI
> in the current state to make sure we don't break build.
>
> Do you suggest we create another config option for ADV7533, which
> selects DRM_MIPI_DSI and builds the ADV7533 parts? Or did you mean
> something else?
Do you have any suggestions for this point? For the next revision, I've
just selected DRM_MIPI_DSI in the Kconfig to ensure build doesn't break.
For this driver, to conditionally compile DRM_MIPI_DSI, it essentially
means we allow conditional support for ADV7533. I would imagine us
#ifdef-ing out the ADV7533 compatible string in the of_match_table. Is
this something we want to do?
Thanks,
Archit
>
>>
>>> ---
>>> drivers/gpu/drm/i2c/adv7511.c | 130
>>> ---
>>> 1 file changed, 123 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i2c/adv7511.c
>>> b/drivers/gpu/drm/i2c/adv7511.c
>>> index 75be17c..6c2a89a 100644
>>> --- a/drivers/gpu/drm/i2c/adv7511.c
>>> +++ b/drivers/gpu/drm/i2c/adv7511.c
>>> @@ -11,6 +11,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> @@ -19,6 +20,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "adv7511.h"
>>>
>>> @@ -56,6 +58,11 @@ struct adv7511 {
>>>
>>> struct gpio_desc *gpio_pd;
>>>
>>> +/* ADV7533 DSI RX related params */
>>> +struct device_node *host_node;
>>> +struct mipi_dsi_device *dsi;
>>> +u8 num_dsi_lanes;
>>> +
>>> enum adv7511_type type;
>>> };
>>>
>>> @@ -392,8 +399,10 @@ static void adv7511_set_link_config(struct adv7511
>>> *adv7511,
>>>
>>> static void adv7533_dsi_power_on(struct adv7511 *adv)
>>> {
>>> -/* set number of dsi lanes (hardcoded to 4 for now) */
>>> -regmap_write(adv->regmap_cec, 0x1c, 0x4 << 4);
>>> +struct mipi_dsi_device *dsi = adv->dsi;
>>> +
>>> +/* set number of dsi lanes */
>>> +regmap_write(adv->regmap_cec, 0x1c, dsi->lanes << 4);
>>> /* disable internal timing generator */
>>> regmap_write(adv->regmap_cec, 0x27, 0x0b);
>>> /* enable hdmi */
>>> @@ -889,6 +898,51 @@ static void adv7511_bridge_mode_set(struct
>>> drm_bridge
>>> *bridge, adv7511_mode_set(adv, mode, adj_mode);
>>> }
>>>
>>> +static int adv7533_attach_dsi(struct adv7511 *adv)
>>> +{
>>> +struct device *dev = &adv->i2c_main->dev;
>>> +struct mipi_dsi_host *host;
>>> +struct mipi_dsi_device *dsi;
>>> +int ret = 0;
>>> +const struct mipi_dsi_device_info info = { .type = "adv7533",
>>> + .channel = 0,
>>> + .node = NULL,
>>> + };
>>> +
>>> +host = of_find_mipi_dsi_host_by_node(adv->host_node);
>>> +if (!host) {
>>> +dev_err(dev, "failed to find dsi host\n");
>>> +return -EPROBE_DEFER;
>>> +}
>>> +
>>> +dsi = mipi_dsi_device_register_full(host, &info);
>>> +if (IS_ERR(dsi)) {
>>> +dev_err(dev, "failed to create dsi device\n");
>>> +ret = PTR_ERR(dsi);
>>> +goto err_dsi_device;
>>> +}
>>> +
>>> +adv->dsi = dsi;
>>> +
>>> +dsi->lanes = adv->num_dsi_lanes;
>>> +dsi->format = MIPI_DSI_FMT_RGB888;
>>> +dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
>>> + MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
>>> +
>>> +ret = mipi_dsi_attach(dsi);
>>> +if (ret < 0) {
>>> +dev_err(dev, "failed to attach dsi to host\n");
>>> +goto err_dsi_attach;
>>> +}
>>> +
>>> +return 0;
>>> +
>>> +err_dsi_attach:
>>> +mipi_dsi_device_unregister(dsi);
>>> +err_dsi_device:
>>> +return ret;
>>> +}
>>> +
>>> static int adv7511_bridge_attach(struct drm_bridge *bridge)
>>> {
>>> struct adv7511 *adv = bridge_to_adv7511(bridge);
>>> @@ -912,6 +966,9 @@ static int adv7511_bridge_attach(struct drm_bridge
>>> *bridge) &adv7511_connector_helper_funcs);
>>> drm_mode_connector_attach_enco
[PATCH] drm/amdgpu: set metadata pointer to NULL after freeing.
Am 03.05.2016 um 04:44 schrieb Dave Airlie:
> From: Dave Airlie
>
> Without this there was a double free of the metadata,
> which ended up freeing the fd table for me here, and taking
> out the machine more often than not.
>
> I reproduced with X.org + modesetting DDX + latest llvm/mesa,
> also required using dri3.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Dave Airlie
Nice catch, patch is Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index e557fc1..7ecea83 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -541,6 +541,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void
> *metadata,
> if (!metadata_size) {
> if (bo->metadata_size) {
> kfree(bo->metadata);
> + bo->metadata = NULL;
> bo->metadata_size = 0;
> }
> return 0;
[PATCH] drm/vc4: Return -EBUSY if there's already a pending flip event.
Op 02-05-16 om 21:25 schreef robert.foss at collabora.com:
> From: Robert Foss
>
> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
> update is requested and there is an earlier update pending".
>
> Signed-off-by: Robert Foss
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++
> drivers/gpu/drm/vc4/vc4_drv.h | 1 +
> drivers/gpu/drm/vc4/vc4_kms.c | 20 ++--
> 3 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 355ee4b..43193a3 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -802,3 +802,9 @@ struct platform_driver vc4_crtc_driver = {
> .of_match_table = vc4_crtc_dt_match,
> },
> };
> +
> +bool vc4_crtc_has_pending_event(struct drm_crtc *crtc)
> +{
> + assert_spin_locked(&crtc->dev->event_lock);
> + return to_vc4_crtc(crtc)->event;
> +}
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index fa2ad15..54c1fb5 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -414,6 +414,7 @@ extern struct platform_driver vc4_crtc_driver;
> int vc4_enable_vblank(struct drm_device *dev, unsigned int crtc_id);
> void vc4_disable_vblank(struct drm_device *dev, unsigned int crtc_id);
> int vc4_crtc_debugfs_regs(struct seq_file *m, void *arg);
> +bool vc4_crtc_has_pending_event(struct drm_crtc *crtc);
>
> /* vc4_debugfs.c */
> int vc4_debugfs_init(struct drm_minor *minor);
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 4718ae5..dc157a1e 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -107,10 +107,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
>bool async)
> {
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> - int ret;
> - int i;
> uint64_t wait_seqno = 0;
> struct vc4_commit *c;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned long flags;
> + int i, ret;
> +
> + if (async) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> +
> + spin_lock_irqsave(&dev->event_lock, flags);
> +
> + if (crtc->state->event ||
^What's this check for? How can this even happen if you remove the event from
the crtc state in atomic_flush?
~Maarten
[Intel-gfx] [PATCH v2 1/4] drm: Add helper for DP++ adaptors
On Mon, 02 May 2016, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Add a helper which aids in the identification of DP dual mode > (aka. DP++) adaptors. There are several types of adaptors > specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors > may go as high as 300MHz and they provide a register informing the > source device what the actual limit is. Supposedly also type 1 adaptors > may optionally implement this register. This TMDS clock limit is the > main reason why we need to identify these adaptors. > > Type 1 adaptors provide access to their internal registers and the sink > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > and I2C-over-AUX. A type 2 source device may choose to implement either > of these methods. If a source device implements the I2C-over-AUX > method, then the driver will obviously need specific support for such > adaptors since the port is driven like an HDMI port, but DDC > communication happes over the AUX channel. > > This helper should be enough to identify the adaptor type (some > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > clock limit. Another feature that may be available is control over > the TMDS output buffers on the adaptor, possibly allowing for some > power saving when the TMDS link is down. > > Other user controllable features that may be available in the adaptors > are downstream i2c bus speed control when using i2c-over-aux, and > some control over the CEC pin. I chose not to provide any helper > functions for those since I have no use for them in i915 at this time. > The rest of the registers in the adaptor are mostly just information, > eg. IEEE OUI, hardware and firmware revision, etc. > > v2: Pass adaptor type to helper functions to ease driver implementation > Fix a bunch of typoes (Paulo) > Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know > the type (Paulo) > Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) > Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to > ease future LSPCON enabling > Remove the unused DP_DUAL_MODE_LAST_RESERVED define > > Cc: stable at vger.kernel.org > Cc: Tore Anderson > Cc: Paulo Zanoni > Cc: Shashank Sharma > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 > ++ > include/drm/drm_dp_dual_mode_helper.h | 83 +++ > 3 files changed, 440 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1a26b4eb1ce0..29f2ee9b9534 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > - drm_kms_helper_common.o > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > new file mode 100644 > index ..949c0fbeb542 > --- /dev/null > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > @@ -0,0 +1,356 @@ > +/* > + * Copyright © 2016 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/** > + * DOC: DP dual mode (ak
linux-next: manual merge of the drm-misc tree with the drm-intel tree
On Tue, May 03, 2016 at 01:24:12PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/i915/intel_display.c
>
> between commits:
>
> f7e5838bb37d ("drm/i915: Simplify reset_counter handling during atomic
> modesetting")
>
> from the drm-intel tree and commit:
>
> 81072bfd13f2 ("drm/i915: Rename async to nonblock.")
>
> from the drm-misc 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.
Reviewed-by: Daniel Vetter
I kinda wonder whether there's some way we could share these conflict
resolutions among various trees. At least one really valuable part of
doing my own drm-intel-nightly integration tree is that I can soak merges
for a few days before I bake them in for eternity ...
Topic for KS I guess?
Cheers, Daniel
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/intel_display.c
> index ff60241b1f76,5d29b838d8d7..
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@@ -13462,9 -13414,12 +13462,9 @@@ static int intel_atomic_prepare_commit(
> return ret;
>
> ret = drm_atomic_helper_prepare_planes(dev, state);
> -if (!ret && !nonblock && !i915_reset_in_progress(&dev_priv->gpu_error))
> {
> -u32 reset_counter;
> -
> -reset_counter = atomic_read(&dev_priv->gpu_error.reset_counter);
> -mutex_unlock(&dev->struct_mutex);
> +mutex_unlock(&dev->struct_mutex);
>
> - if (!ret && !async) {
> ++if (!ret && !nonblock) {
> for_each_plane_in_state(state, plane, plane_state, i) {
> struct intel_plane_state *intel_plane_state =
> to_intel_plane_state(plane_state);
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 95017] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).
https://bugs.freedesktop.org/show_bug.cgi?id=95017 --- Comment #10 from Rui Salvaterra --- (In reply to Michel D�nzer from comment #4) > (In reply to Mathieu Malaterre from comment #3) > > If AGP is simply not supported on PowerPC, it would be nice to have a > > clearer message (or at least a warning). > > It is supported, it's just unstable on many PowerMacs. > > A patch disabling AGP by default on PowerMacs or even PPC in general > probably wouldn't be rejected. :) Hi, Michel I don't understand. I know about the coherency issues on some UniNorth bridges (DMA writes through the GART going directly to RAM, IIRC), but how did OS X cope with them? Did it also disable AGP transfers? If not, what can be done to fix this bug for real, instead of working around it? (I have a very vague memory that these hangs didn't happen before KMS, but I may be completely wrong.) Also, on a somewhat related note, there are still issues with the Radeon (R600, not SI) DRM on big endian, as for https://bugs.freedesktop.org/show_bug.cgi?id=95015. Thanks, Rui -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/17b4b369/attachment.html>
[PATCH 1/6] drm/fb: fix missing /** in kerneldoc comment.
On Tue, May 03, 2016 at 02:28:21PM +1000, Dave Airlie wrote: > From: Dave Airlie > > Signed-off-by: Dave Airlie Reviewed-by: Daniel Vetter > --- > include/drm/drm_crtc.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index 297e527..6279989 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -2606,7 +2606,7 @@ static inline uint32_t drm_color_lut_extract(uint32_t > user_input, > return clamp_val(val, 0, max); > } > > -/* > +/** > * drm_framebuffer_reference - incr the fb refcnt > * @fb: framebuffer > * > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH 3/6] drm/fb_helper: add connector reference counting. (v2)
On Tue, May 03, 2016 at 02:28:23PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This takes a reference count when fbdev adds the connector,
> and drops it when it removes the connector.
>
> It also drops the now unneeded code to find connectors
> and remove the from the modeset as they are reference counted.
>
> v2: drop references when removing all connectors at end.
>
> Signed-off-by: Dave Airlie
Yeah I think this looks good now.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 38 +-
> 1 file changed, 5 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 855108e..19a7a71 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -153,40 +153,13 @@ int drm_fb_helper_add_one_connector(struct
> drm_fb_helper *fb_helper, struct drm_
> if (!fb_helper_connector)
> return -ENOMEM;
>
> + drm_connector_reference(connector);
> fb_helper_connector->connector = connector;
> fb_helper->connector_info[fb_helper->connector_count++] =
> fb_helper_connector;
> return 0;
> }
> EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
>
> -static void remove_from_modeset(struct drm_mode_set *set,
> - struct drm_connector *connector)
> -{
> - int i, j;
> -
> - for (i = 0; i < set->num_connectors; i++) {
> - if (set->connectors[i] == connector)
> - break;
> - }
> -
> - if (i == set->num_connectors)
> - return;
> -
> - for (j = i + 1; j < set->num_connectors; j++) {
> - set->connectors[j - 1] = set->connectors[j];
> - }
> - set->num_connectors--;
> -
> - /*
> - * TODO maybe need to makes sure we set it back to !=NULL somewhere?
> - */
> - if (set->num_connectors == 0) {
> - set->fb = NULL;
> - drm_mode_destroy(connector->dev, set->mode);
> - set->mode = NULL;
> - }
> -}
> -
> int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> struct drm_connector *connector)
> {
> @@ -206,6 +179,7 @@ int drm_fb_helper_remove_one_connector(struct
> drm_fb_helper *fb_helper,
> if (i == fb_helper->connector_count)
> return -EINVAL;
> fb_helper_connector = fb_helper->connector_info[i];
> + drm_connector_unreference(fb_helper_connector->connector);
>
> for (j = i + 1; j < fb_helper->connector_count; j++) {
> fb_helper->connector_info[j - 1] = fb_helper->connector_info[j];
> @@ -213,10 +187,6 @@ int drm_fb_helper_remove_one_connector(struct
> drm_fb_helper *fb_helper,
> fb_helper->connector_count--;
> kfree(fb_helper_connector);
>
> - /* also cleanup dangling references to the connector: */
> - for (i = 0; i < fb_helper->crtc_count; i++)
> - remove_from_modeset(&fb_helper->crtc_info[i].mode_set,
> connector);
> -
> return 0;
> }
> EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
> @@ -626,8 +596,10 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
> *helper)
> {
> int i;
>
> - for (i = 0; i < helper->connector_count; i++)
> + for (i = 0; i < helper->connector_count; i++) {
> + drm_connector_unreference(helper->connector_info[i]->connector);
> kfree(helper->connector_info[i]);
> + }
> kfree(helper->connector_info);
> for (i = 0; i < helper->crtc_count; i++) {
> kfree(helper->crtc_info[i].mode_set.connectors);
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 4/6] drm/crtc: take references to connectors used in a modeset. (v2)
On Tue, May 03, 2016 at 02:28:24PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This just takes a reference on the connector when we set a mode
> in the non-atomic paths.
>
> v2: Follow Daniel Stone's suggestions on when to take/drop
> references.
>
> Signed-off-by: Dave Airlie
I've already embarrassed myself once with a bonghits r-b, let's try this
again:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 66ca313..f47a252 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -456,6 +456,9 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
>* between them is henceforth no longer available.
>*/
> connector->dpms = DRM_MODE_DPMS_OFF;
> +
> + /* we keep a reference while the encoder is bound */
> + drm_connector_unreference(connector);
> }
> }
>
> @@ -606,6 +609,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
> mode_changed = true;
> }
>
> + /* take a reference on all connectors in set */
> + for (ro = 0; ro < set->num_connectors; ro++) {
> + drm_connector_reference(set->connectors[ro]);
> + }
> +
> /* a) traverse passed in connector list and get encoders for them */
> count = 0;
> drm_for_each_connector(connector, dev) {
> @@ -724,6 +732,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
> }
> }
>
> + /* after fail drop reference on all connectors in save set */
> + count = 0;
> + drm_for_each_connector(connector, dev) {
> + drm_connector_unreference(&save_connectors[count++]);
> + }
> +
> kfree(save_connectors);
> kfree(save_encoders);
> return 0;
> @@ -740,6 +754,11 @@ fail:
> *connector = save_connectors[count++];
> }
>
> + /* after fail drop reference on all connectors in set */
> + for (ro = 0; ro < set->num_connectors; ro++) {
> + drm_connector_unreference(set->connectors[ro]);
> + }
> +
> /* Try to restore the config */
> if (mode_changed &&
> !drm_crtc_helper_set_mode(save_set.crtc, save_set.mode, save_set.x,
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards
https://bugs.freedesktop.org/show_bug.cgi?id=87682 --- Comment #6 from Felix Schwarz --- (In reply to Thom from comment #5) > I don't know what "git bisect" is but eager to learn. "bisecting" is a way to find out which commit caused a specific regression. This involves compiling the linux kernel from git and testing the compiled versions. If you can find out which commit is the culprit chances are pretty good that the problem can be fixed quickly. To learn more about bisecting I suggest seaching for "git bisect". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/e19beb37/attachment-0001.html>
[Bug 95017] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).
https://bugs.freedesktop.org/show_bug.cgi?id=95017 --- Comment #11 from erhard_f at mailbox.org --- Also been hit by this bug on 2 of my 3 machines: PowerMac 7,3 (A1047) w. Radeon 9600 Pro and PowerBook 5,6 (A1106). My PowerBook 5,8 (A1138) magically works with AGP! Which is interesting because both the 5,6 and the 5,8 use a Mobility Radeon 9700. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/75d1ca90/attachment.html>
[PATCH 5/6] drm/atomic: use connector references (v2)
On Tue, May 03, 2016 at 02:28:25PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Take a reference when setting a crtc on a connecter,
> also take one when duplicating if a crtc is set,
> and drop one on destroy if a crtc is set.
>
> v2: take Daniel Stone's advice and simplify the
> ref/unref dances, also take care of NULL as connector
> to state reset.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_atomic.c| 4
> drivers/gpu/drm/drm_atomic_helper.c | 5 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9d5e3c8..91cae88 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1160,6 +1160,8 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> {
> struct drm_crtc_state *crtc_state;
>
> + if (crtc)
> + drm_connector_reference(conn_state->connector);
> if (conn_state->crtc && conn_state->crtc != crtc) {
> crtc_state =
> drm_atomic_get_existing_crtc_state(conn_state->state,
>
> conn_state->crtc);
> @@ -1177,6 +1179,8 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> 1 << drm_connector_index(conn_state->connector);
> }
>
> + if (conn_state->crtc)
> + drm_connector_unreference(conn_state->connector);
> conn_state->crtc = crtc;
>
> if (crtc)
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d25abce..f3e2642 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2762,6 +2762,8 @@ __drm_atomic_helper_connector_duplicate_state(struct
> drm_connector *connector,
> struct drm_connector_state *state)
> {
> memcpy(state, connector->state, sizeof(*state));
> + if (state->crtc)
> + drm_connector_reference(connector);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
>
> @@ -2889,6 +2891,9 @@ __drm_atomic_helper_connector_destroy_state(struct
> drm_connector *connector,
>* state will automatically do the right thing if code is ever added
>* to this function.
>*/
> + if (connector && state->crtc) {
> + drm_connector_unreference(state->connector);
> + }
Bikeshed: no need for {} and you don't need to check that connector is
NULL either. Tbh all the destroy_state helpers don't really need their
object argument, only the state. Cleaning that up is somewhere on my todo.
Reviewed-by: Daniel Vetter
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/fsl-dcu: add COMMON_CLK dependency
On Mon, May 02, 2016 at 02:22:04PM -0700, Stefan Agner wrote:
> On 2016-05-02 04:00, Arnd Bergmann wrote:
> > The fsl dcu now uses the clk-provider interfaces, which are not available
> > when CONFIG_COMMON_CLK is disabled:
> >
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c: In function 'fsl_dcu_drm_probe':
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c:362:20: error: implicit
> > declaration of function '__clk_get_name'
> > [-Werror=implicit-function-declaration]
> > pix_clk_in_name = __clk_get_name(pix_clk_in);
> >
> > This adds a Kconfig dependency to prevent the driver from being enabled
> > in this case.
> >
> > Signed-off-by: Arnd Bergmann
> > Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for
> > pixel clock divider")
>
> Oh right, thx!
>
> Acked-by: Stefan Agner
>
> @Dave, can you pick that up directly or do you prefer a pull request?
Smashed into drm-misc, thanks.
-Daniel
>
> --
> Stefan
>
> > ---
> > drivers/gpu/drm/fsl-dcu/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig
> > b/drivers/gpu/drm/fsl-dcu/Kconfig
> > index c78cf3f605d0..b9c714de6e40 100644
> > --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> > +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> > @@ -1,6 +1,6 @@
> > config DRM_FSL_DCU
> > tristate "DRM Support for Freescale DCU"
> > - depends on DRM && OF && ARM
> > + depends on DRM && OF && ARM && COMMON_CLK
> > select BACKLIGHT_CLASS_DEVICE
> > select BACKLIGHT_LCD_SUPPORT
> > select DRM_KMS_HELPER
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[GIT PULL] imx-drm module autoloading fix
Hi Dave,
here is the imx-ipuv3-crtc autoloading fix so you don't have to revert commit
304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to
corresponding ports").
regards
Philipp
The following changes since commit 02da2d72174c61988eb4456b53f405e3ebdebce4:
Linux 4.6-rc5 (2016-04-24 16:17:05 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2016-05-03
for you to fetch changes up to 7a850aca7e2f0aba312e68285c1a381aabd8860e:
gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading (2016-04-27 16:09:32 +0200)
imx-drm module autoloading fix
Commit 304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to
corresponding ports") broke autoloading of the imx-ipuv3-crtc module, this
reenables the platform modalias to fix it.
Philipp Zabel (1):
gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading
drivers/gpu/ipu-v3/ipu-common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
[PATCH] drm/atomic: Add WARN_ON when state->acquire_ctx is not set.
When I was writing an atomic wrapper for rmfb, I ran into the
following backtrace from lockdep:
=
[ INFO: possible recursive locking detected ]
4.5.0-patser+ #4696 Tainted: G U
-
kworker/2:2/2608 is trying to acquire lock:
(crtc_ww_class_mutex){+.+.+.}, at: []
drm_modeset_lock+0x7c/0x120 [drm]
but task is already holding lock:
(crtc_ww_class_mutex){+.+.+.}, at: []
modeset_backoff+0x8d/0x220 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(crtc_ww_class_mutex);
lock(crtc_ww_class_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/2:2/2608:
#0: ("events"){.+.+.+}, at: [] process_one_work+0x15a/0x6c0
#1: ((&arg.work)){+.+.+.}, at: []
process_one_work+0x15a/0x6c0
#2: (crtc_ww_class_acquire){+.+.+.}, at: []
drm_atomic_helper_remove_fb+0x4a/0x1d0 [drm_kms_helper]
#3: (crtc_ww_class_mutex){+.+.+.}, at: []
modeset_backoff+0x8d/0x220 [drm]
While lockdep probably catches this bug when it happens, it's better
to explicitly warn when state->acquire_ctx is not set.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 0b526423f19f..69adcf3944cc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -263,6 +263,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
int ret, index = drm_crtc_index(crtc);
struct drm_crtc_state *crtc_state;
+ WARN_ON(!state->acquire_ctx);
+
crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
if (crtc_state)
return crtc_state;
@@ -622,6 +624,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
int ret, index = drm_plane_index(plane);
struct drm_plane_state *plane_state;
+ WARN_ON(!state->acquire_ctx);
+
plane_state = drm_atomic_get_existing_plane_state(state, plane);
if (plane_state)
return plane_state;
@@ -890,6 +894,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state
*state,
struct drm_mode_config *config = &connector->dev->mode_config;
struct drm_connector_state *connector_state;
+ WARN_ON(!state->acquire_ctx);
+
ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
if (ret)
return ERR_PTR(ret);
--
2.5.5
[PATCH v3 1/2] drm: bridge: Add sii902x driver
Hi Maxime,
On Mon, 2 May 2016 13:05:57 +0200
Maxime Ripard wrote:
> > +static void sii902x_reset(struct sii902x *sii902x)
> > +{
> > + gpiod_set_value(sii902x->reset_gpio, 1);
> > +
> > + msleep(100);
>
> Sleeping for 100ms seems like a lot. Is it required, or is it just a
> leftover from an early development?
I wish I had the answer, unfortunately I don't have the datasheet and
the implementation I based my work on [1] is sleeping 100ms.
>
> > +
> > + gpiod_set_value(sii902x->reset_gpio, 0);
> > +}
> > +
> > +static void sii902x_connector_destroy(struct drm_connector *connector)
> > +{
> > + drm_connector_unregister(connector);
> > + drm_connector_cleanup(connector);
> > +}
> > +
> > +static enum drm_connector_status
> > +sii902x_connector_detect(struct drm_connector *connector, bool force)
> > +{
> > + struct sii902x *sii902x = connector_to_sii902x(connector);
> > + unsigned int status;
> > +
> > + regmap_read(sii902x->regmap, SI902X_INT_STATUS, &status);
> > +
> > + return (status & SI902X_PLUGGED_STATUS) ?
> > + connector_status_connected : connector_status_disconnected;
> > +}
> > +
> > +static const struct drm_connector_funcs sii902x_atomic_connector_funcs = {
> > + .dpms = drm_atomic_helper_connector_dpms,
> > + .detect = sii902x_connector_detect,
> > + .fill_modes = drm_helper_probe_single_connector_modes,
> > + .destroy = sii902x_connector_destroy,
> > + .reset = drm_atomic_helper_connector_reset,
> > + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > +};
> > +
> > +static const struct drm_connector_funcs sii902x_connector_funcs = {
> > + .dpms = drm_atomic_helper_connector_dpms,
Should be drm_atomic_helper_dpms here.
> > + .detect = sii902x_connector_detect,
> > + .fill_modes = drm_helper_probe_single_connector_modes,
> > + .destroy = sii902x_connector_destroy,
> > +};
>
> I'm guessing this is to support both atomic and !atomic drivers. I
> thought it was working automatically?
Hm, the dw-hdmi driver is providing both, but maybe it's not needed.
Daniel, any comments?
Thanks for the review.
Boris
[1]https://github.com/linux4sam/linux-at91/blob/linux-3.10-at91/drivers/hdmi/encoder-sii9022.c#L92
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[PATCH v3 1/2] drm: bridge: Add sii902x driver
On Tue, May 3, 2016 at 11:39 AM, Boris Brezillon wrote: >> > + .detect = sii902x_connector_detect, >> > + .fill_modes = drm_helper_probe_single_connector_modes, >> > + .destroy = sii902x_connector_destroy, >> > +}; >> >> I'm guessing this is to support both atomic and !atomic drivers. I >> thought it was working automatically? > > Hm, the dw-hdmi driver is providing both, but maybe it's not needed. > Daniel, any comments? You only need this in case you actually have atomic and !atomic users of your bridge. We discussed whether we should have a dpms helper that dtrt automatically, but with just 1 driver that doesn't seem worth it. You wouldn't need to have 2 entier vfunc tables, you could just switch on DRIVER_ATOMIC. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 1/2] drm: bridge: Add sii902x driver
On Tue, 3 May 2016 11:53:18 +0200 Daniel Vetter wrote: > On Tue, May 3, 2016 at 11:39 AM, Boris Brezillon > wrote: > >> > + .detect = sii902x_connector_detect, > >> > + .fill_modes = drm_helper_probe_single_connector_modes, > >> > + .destroy = sii902x_connector_destroy, > >> > +}; > >> > >> I'm guessing this is to support both atomic and !atomic drivers. I > >> thought it was working automatically? > > > > Hm, the dw-hdmi driver is providing both, but maybe it's not needed. > > Daniel, any comments? > > You only need this in case you actually have atomic and !atomic users > of your bridge. We discussed whether we should have a dpms helper that > dtrt automatically, but with just 1 driver that doesn't seem worth it. > You wouldn't need to have 2 entier vfunc tables, you could just switch > on DRIVER_ATOMIC. Ok, I'll drop the !atomic helpers. Should I still test drm_core_check_feature(drm, DRIVER_ATOMIC) in the ->attach() implementation and return an error if the DRM device does not support atomic operations? -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH 5/6] drm/atomic: use connector references (v2)
>>*/
>> + if (connector && state->crtc) {
>> + drm_connector_unreference(state->connector);
>> + }
>
> Bikeshed: no need for {} and you don't need to check that connector is
> NULL either. Tbh all the destroy_state helpers don't really need their
> object argument, only the state. Cleaning that up is somewhere on my todo.
Yes you really do need the connector, lost a boot to an oops,
drm_atomic_state_default_clear does some funky stuff that can possibly go away
after this, but I'm not sure.
Dave.
[PATCH 0/9] drm/msm: Fix issues with DT bindings
Currently, none of the upstream Qualcomm DT files have the display device nodes populated, even when the DT binding documents are upstream. I am not aware of all the issues with the bindings which has prevented it from getting merged, but 2 properties "connectors" (maintains a list of all the external interfaces (DSI, HDMI etc)) and "gpus" (list of GPU devices) seem like the ones that can't be merged. This patch set aligns with the graph bindings to describe the connection between the display controller block (MDP) and the external encoder interfaces. This is similar to the graph bindings used by some of the drivers (imx, rockchip), but not exactly the same. These drivers expect a top level "display-subsytem" DT node which lists down the display interface ports to be used. Our implementation just parses the interface ports in the MDP node as is, and add the components that are needed. I've Cc-ed Heiko and Philipp in case they had any comments on this. The 'gpu' property is removed in a hack-ish way. The driver contains a list of all the compatible strings for gpus, and searches the entire OF firmware for a matching node. Once we know what's the right way to link the gpu and display nodes together (if needed at all) we can add the required binding. The rest of the changes are minor cleanups and fixes to prepare the driver and binding documents before we really start adding the display nodes. Archit Taneja (9): drm/msm: Get mdss components via parsing ports drm/msm: Drop the gpu binding drm/msm/mdp: mdp4: Update LCDC/LVDS port parsing dt-bindings: msm/mdp: Remove connector and gpu bindings dt-bindings: msm/dsi: Some binding doc cleanups drm/msm/dsi: Modify port parsing drm/msm/dsi: Use generic PHY bindings dt-bindings: msm/dsi: Modify port and PHY bindings dt-bindings: msm/dsi: Add assigned clocks bindings .../devicetree/bindings/display/msm/dsi.txt| 79 +++-- .../devicetree/bindings/display/msm/mdp.txt| 75 ++-- drivers/gpu/drm/msm/dsi/dsi.c | 2 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +-- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 8 ++- drivers/gpu/drm/msm/msm_drv.c | 80 +++--- 6 files changed, 213 insertions(+), 41 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/9] drm/msm: Get mdss components via parsing ports
The driver currently identifies all the mdss components it needs by
parsing a phandle list from the 'connectors' DT property.
Instead of this, describe a list of ports that the MDP hardware provides
to the external world. These ports are linked to external encoder
interfaces such as DSI, HDMI in MDSS. These are also the subcomponent
devices that we need add. This description of ports complies with the
generic graph bindings.
In MDP4, the LVDS port's output connects directly to the LVDS panel. In
this case, we don't try to add it as a component.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 54 ++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 955ddfd..30b8f3b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1087,6 +1087,58 @@ static int add_components(struct device *dev, struct
component_match **matchptr,
return 0;
}
+/*
+ * Identify what components need to be added by parsing what the endpoints in
+ * our output ports are we. In the case of LVDS, there is no external component
+ * that we need to add since it's a part of MDP itself.
+ */
+static int add_mdss_components(struct device *dev,
+ struct component_match **matchptr)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *ep_node;
+
+ for_each_endpoint_of_node(np, ep_node) {
+ struct device_node *intf;
+ struct of_endpoint ep;
+ int ret;
+
+ ret = of_graph_parse_endpoint(ep_node, &ep);
+ if (ret) {
+ dev_err(dev, "unable to parse port endpoint\n");
+ of_node_put(ep_node);
+ return ret;
+ }
+
+ /*
+* The LCDC/LVDS port on MDP4 is a speacial case where the
+* remote-endpoint isn't a component that we need to add
+*/
+ if (of_device_is_compatible(np, "qcom,mdp4") && ep.port == 0) {
+ of_node_put(ep_node);
+ continue;
+ }
+
+ /*
+* It's okay if some of the ports don't have a remote endpoint
+* specified. It just means that the port isn't connected to
+* any external interface.
+*/
+ intf = of_graph_get_remote_port_parent(ep_node);
+ if (!intf) {
+ of_node_put(ep_node);
+ continue;
+ }
+
+ component_match_add(dev, matchptr, compare_of, intf);
+
+ of_node_put(intf);
+ of_node_put(ep_node);
+ }
+
+ return 0;
+}
+
static int msm_drm_bind(struct device *dev)
{
return msm_drm_init(dev, &msm_driver);
@@ -1110,7 +1162,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
{
struct component_match *match = NULL;
- add_components(&pdev->dev, &match, "connectors");
+ add_mdss_components(&pdev->dev, &match);
add_components(&pdev->dev, &match, "gpus");
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 2/9] drm/msm: Drop the gpu binding
The driver currently identifies the GPU components it needs by parsing
a phandle list from the 'gpus' DT property.
This isn't the right binding to go with. So, for now, just search all
device nodes and find the gpu node we need by parsing a list of
compatible strings.
Once we know how to link the kms and gpu drivers, we'll drop this method
and use the correct binding.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 30b8f3b..f717a69 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1068,20 +1068,32 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
}
-static int add_components(struct device *dev, struct component_match
**matchptr,
- const char *name)
+static const char * const msm_compatible_gpus[] = {
+ "qcom,adreno-3xx",
+ "qcom,kgsl-3d0",
+};
+
+/*
+ * We don't know what's the best binding to link the gpu with the drm device.
+ * Fow now, we just hunt for all the possible gpus that we support, and add
them
+ * as components.
+ */
+static int add_gpu_components(struct device *dev,
+ struct component_match **matchptr)
{
- struct device_node *np = dev->of_node;
unsigned i;
- for (i = 0; ; i++) {
+ for (i = 0; i < ARRAY_SIZE(msm_compatible_gpus); i++) {
struct device_node *node;
- node = of_parse_phandle(np, name, i);
+ node = of_find_compatible_node(NULL, NULL,
+ msm_compatible_gpus[i]);
if (!node)
- break;
+ continue;
component_match_add(dev, matchptr, compare_of, node);
+
+ of_node_put(node);
}
return 0;
@@ -1163,7 +1175,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
struct component_match *match = NULL;
add_mdss_components(&pdev->dev, &match);
- add_components(&pdev->dev, &match, "gpus");
+ add_gpu_components(&pdev->dev, &match);
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
return component_master_add_with_match(&pdev->dev, &msm_drm_ops, match);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 3/9] drm/msm/mdp: mdp4: Update LCDC/LVDS port parsing
The LCDC port is the first in the list of the output ports in MDP4.
Mention this explicitly in the driver.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index f8e0cea..cd129f4 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -263,9 +263,13 @@ static struct device_node *mdp4_detect_lcdc_panel(struct
drm_device *dev)
struct device_node *endpoint, *panel_node;
struct device_node *np = dev->dev->of_node;
- endpoint = of_graph_get_next_endpoint(np, NULL);
+ /*
+* LCDC/LVDS is the first port described in the list of ports in the
+* MDP4 DT node.
+*/
+ endpoint = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!endpoint) {
- DBG("no endpoint in MDP4 to fetch LVDS panel\n");
+ DBG("no LVDS panel remote endpoint\n");
return NULL;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 4/9] dt-bindings: msm/mdp: Remove connector and gpu bindings
The MDP DT node now contains a list of ports that describe how it connects
to external encoder interfaces like DSI and HDMI. These follow the
standard of_graph bindings, and allow us to get rid of the 'connectors'
phandle that contained a list of all the external encoders connected to
MDP.
The GPU phandle is removed too until we figure out what's the right way
to specify it in DT.
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/mdp.txt| 75 --
1 file changed, 71 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/mdp.txt
b/Documentation/devicetree/bindings/display/msm/mdp.txt
index a214f6c..5f6ae3c 100644
--- a/Documentation/devicetree/bindings/display/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/display/msm/mdp.txt
@@ -6,7 +6,6 @@ Required properties:
* "qcom,mdp5" - mdp5
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt signal from the display controller.
-- connectors: array of phandles for output device(s)
- clocks: device clocks
See ../clocks/clock-bindings.txt for details.
- clock-names: the following clocks are required.
@@ -24,9 +23,33 @@ Required properties:
* "core_clk"
* "lut_clk" (some MDP5 versions may not need this)
* "vsync_clk"
+- ports: contains the list of output ports from MDP. These connect to
interfaces
+ that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
+ special case since it is a part of the MDP block itself).
+
+ Each output port contains an endpoint that describes how it is connected to
an
+ external interface. These are described by the standard properties documented
+ here:
+ Documentation/devicetree/bindings/graph.txt
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+ For MDP4, the output port mappings are:
+ Port 0 -> LCDC/LVDS
+ Port 1 -> DSI1 Cmd/Video
+ Port 2 -> DSI2 Cmd/Video
+ Port 3 -> DTV
+
+ For MDP5, the availability of output ports vary across each SoC revision, but
+ they generally have the following mapping:
+ Port 0 -> MDP_INTF0 (eDP)
+ Port 1 -> MDP_INTF1 (DSI1)
+ Port 2 -> MDP_INTF2 (DSI2)
+ Port 3 -> MDP_INTF3 (HDMI)
+
+ See drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c to see what all INTFs a particular
+ SoC revision has enabled.
Optional properties:
-- gpus: phandle for gpu device
- clock-names: the following clocks are optional:
* "lut_clk"
@@ -35,11 +58,25 @@ Example:
/ {
...
- mdp: qcom,mdp at 510 {
+ hdmi: hdmi at 4a0 {
+ ...
+ ports {
+ ...
+ port at 0 {
+ reg = <0>;
+ hdmi_in: endpoint {
+ remote-endpoint = <&mdp_dtv_out>;
+ };
+ };
+ ...
+ };
+ ...
+ };
+
+ mdp: mdp at 510 {
compatible = "qcom,mdp4";
reg = <0x0510 0xf>;
interrupts = ;
- connectors = <&hdmi>;
gpus = <&gpu>;
clock-names =
"core_clk",
@@ -55,5 +92,35 @@ Example:
<&mmcc TV_SRC>,
<&mmcc HDMI_TV_CLK>,
<&mmcc MDP_TV_CLK>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ mdp_lvds_out: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ mdp_dsi1_out: endpoint {
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ mdp_dsi2_out: endpoint {
+ };
+ };
+
+ port at 3 {
+ reg = <3>;
+ mdp_dtv_out: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 5/9] dt-bindings: msm/dsi: Some binding doc cleanups
Some cleanups:
- Use simpler names for DT nodes in the example
- Fix phandle for specifying data lane mapping in the example.
- Use references instead of dumping Document links everywhere
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/dsi.txt| 23 +++---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index f5948c4..bf41d7c 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -11,8 +11,7 @@ Required properties:
be 0 or 1, since we have 2 DSI controllers at most for now.
- interrupts: The interrupt signal from the DSI block.
- power-domains: Should be <&mmcc MDSS_GDSC>.
-- clocks: device clocks
- See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
+- clocks: Phandles to device clocks as descirbed in [1]
- clock-names: the following clocks are required:
* "mdp_core_clk"
* "iface_clk"
@@ -31,8 +30,7 @@ Required properties:
Optional properties:
- panel at 0: Node of panel connected to this DSI controller.
- See files in Documentation/devicetree/bindings/display/panel/ for each
supported
- panel.
+ See files in [2] for each supported panel.
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
driving a panel which needs 2 DSI links.
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
@@ -48,7 +46,7 @@ Optional properties:
DSI Endpoint properties:
- remote-endpoint: set to phandle of the connected panel's endpoint.
-See Documentation/devicetree/bindings/graph.txt for device graph info.
+See [3] for device graph info.
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
to the physical lanes on the given platform. The value contained in
index n describes what logical data lane is mapped to the physical data
@@ -89,8 +87,7 @@ Required properties:
- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
be 0 or 1, since we have 2 DSI PHYs at most for now.
- power-domains: Should be <&mmcc MDSS_GDSC>.
-- clocks: device clocks
- See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
+- clocks: Phandles to device clocks as descirbed in [1]
- clock-names: the following clocks are required:
* "iface_clk"
- vddio-supply: phandle to vdd-io regulator device node
@@ -99,8 +96,12 @@ Optional properties:
- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
regulator is wanted.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/display/panel/
+[3] Documentation/devicetree/bindings/graph.txt
+
Example:
- mdss_dsi0: qcom,mdss_dsi at fd922800 {
+ dsi0: dsi at fd922800 {
compatible = "qcom,mdss-dsi-ctrl";
qcom,dsi-host-index = <0>;
interrupt-parent = <&mdss_mdp>;
@@ -128,7 +129,7 @@ Example:
vdd-supply = <&pma8084_l22>;
vddio-supply = <&pma8084_l12>;
- qcom,dsi-phy = <&mdss_dsi_phy0>;
+ qcom,dsi-phy = <&dsi_phy0>;
qcom,dual-dsi-mode;
qcom,master-dsi;
@@ -156,12 +157,12 @@ Example:
port {
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
- lanes = <0 1 2 3>;
+ qcom,data-lane-map = <0 1 2 3>;
};
};
};
- mdss_dsi_phy0: qcom,mdss_dsi_phy at fd922a00 {
+ dsi_phy0: dsi_phy at fd922a00 {
compatible = "qcom,dsi-phy-28nm-hpm";
qcom,dsi-phy-index = <0>;
reg-names =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 6/9] drm/msm/dsi: Modify port parsing
The DSI interface is going to have two ports defined in its device node.
The first port is always going to be the link between the MDP output
and the input to DSI, the second port is going to be the link between
the DSI output and the connected panel/bridge:
- - ---
| MDP | --> | DSI | --> | Panel |
- - ---
(Port 0) (Port 1)
Until now, there was only one Port representing the output. Update the
DSI host driver such that it parses Port #1 for a connected device.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 51fbbf8..15c70ac 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1616,12 +1616,12 @@ static int dsi_host_parse_dt(struct msm_dsi_host
*msm_host)
}
/*
-* Get the first endpoint node. In our case, dsi has one output port
-* to which the panel is connected. Don't return an error if a port
-* isn't defined. It's possible that there is nothing connected to
-* the dsi output.
+* Get the endpoint of the output port of the DSI host. In our case,
+* this is mapped to port number with reg = 1. Don't return an error if
+* the remote endpoint isn't defined. It's possible that there is
+* nothing connected to the dsi output.
*/
- endpoint = of_graph_get_next_endpoint(np, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
if (!endpoint) {
dev_dbg(dev, "%s: no endpoint\n", __func__);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 7/9] drm/msm/dsi: Use generic PHY bindings
The DSI host links to the DSI PHY device using a custom binding. Switch to
the generic PHY bindings. The DSI PHY driver itself doesn't use the common
PHY framework for now.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 6edcd6f..ec572f8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -29,7 +29,7 @@ static int dsi_get_phy(struct msm_dsi *msm_dsi)
struct platform_device *phy_pdev;
struct device_node *phy_node;
- phy_node = of_parse_phandle(pdev->dev.of_node, "qcom,dsi-phy", 0);
+ phy_node = of_parse_phandle(pdev->dev.of_node, "phys", 0);
if (!phy_node) {
dev_err(&pdev->dev, "cannot find phy device\n");
return -ENXIO;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 8/9] dt-bindings: msm/dsi: Modify port and PHY bindings
The DSI node now has two ports that describe the connection between the
MDP interface output and the DSI input, and the connection between the DSI
output and the connected panel/bridge. Update the properties and the
example.
Also, use generic PHY bindings instead of the custom one.
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/dsi.txt| 53 +++---
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index bf41d7c..0223f06 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -25,12 +25,18 @@ Required properties:
- vdd-supply: phandle to vdd regulator device node
- vddio-supply: phandle to vdd-io regulator device node
- vdda-supply: phandle to vdda regulator device node
-- qcom,dsi-phy: phandle to DSI PHY device node
+- phys: phandle to DSI PHY device node
+- phy-names: the name of the corresponding PHY device
- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
+- ports: Contains 2 DSI controller ports as child nodes. Each port contains
+ an endpoint subnode as defined in [2] and [3]. port at 0 describes the
+ connection between the MDP interface output and the DSI input. port at 1
+ describes the connection between the DSI output and the connected
+ panel/bridge.
Optional properties:
- panel at 0: Node of panel connected to this DSI controller.
- See files in [2] for each supported panel.
+ See files in [4] for each supported panel.
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
driving a panel which needs 2 DSI links.
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
@@ -42,15 +48,15 @@ Optional properties:
- pinctrl-names: the pin control state names; should contain "default"
- pinctrl-0: the default pinctrl state (active)
- pinctrl-n: the "sleep" pinctrl state
-- port: DSI controller output port, containing one endpoint subnode.
DSI Endpoint properties:
- - remote-endpoint: set to phandle of the connected panel's endpoint.
-See [3] for device graph info.
+ - remote-endpoint: For port at 0, set to phandle of the connected
panel/bridge's
+input endpoint. For port at 1, set to the MDP interface output.
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
to the physical lanes on the given platform. The value contained in
index n describes what logical data lane is mapped to the physical data
-lane n (DATAn, where n lies between 0 and 3).
+lane n (DATAn, where n lies between 0 and 3). Only for the endpoint in
+port at 1.
For example:
@@ -97,8 +103,9 @@ Optional properties:
regulator is wanted.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/display/panel/
-[3] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/graph.txt
+[3] Documentation/devicetree/bindings/media/video-interfaces.txt
+[4] Documentation/devicetree/bindings/display/panel/
Example:
dsi0: dsi at fd922800 {
@@ -129,7 +136,8 @@ Example:
vdd-supply = <&pma8084_l22>;
vddio-supply = <&pma8084_l12>;
- qcom,dsi-phy = <&dsi_phy0>;
+ phys = <&dsi_phy0>;
+ phy-names ="dsi_phy";
qcom,dual-dsi-mode;
qcom,master-dsi;
@@ -139,6 +147,26 @@ Example:
pinctrl-0 = <&mdss_dsi_active>;
pinctrl-1 = <&mdss_dsi_suspend>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&mdp_intf1_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ qcom,data-lane-map = <0 1 2 3>;
+ };
+ };
+ };
+
panel: panel at 0 {
compatible = "sharp,lq101r1sx01";
reg = <0>;
@@ -153,13 +181,6 @@ Example:
};
};
};
-
- port {
- dsi0_out: endpoint {
- remote-endpoint = <&panel_in>;
- qcom,data-lane-map = <0 1 2 3>;
- };
- };
};
dsi_phy0: dsi_phy at fd922a00 {
--
The Qualcomm Innovation Center, Inc. is a member of the
[PATCH 9/9] dt-bindings: msm/dsi: Add assigned clocks bindings
The PLL in the DSI PHY block generates 2 clock outputs (Byte and Pixel clocks) that are fed into the Multimedia Clock Controller (MMCC). The MMCC uses these as source clocks for some of its RCGs to generate clocks that finally feed to the DSI host controller. Use the assigned clocks DT bindings to set up the MMCC RCGs that feed to the DSI host. Use the DSI PHY provided clocks to set up the parents of these assigned clocks. Signed-off-by: Archit Taneja --- Documentation/devicetree/bindings/display/msm/dsi.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index 0223f06..686f475 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -22,6 +22,10 @@ Required properties: * "core_clk" For DSIv2, we need an additional clock: * "src_clk" +- assigned-clocks: Parents of "byte_clk" and "pixel_clk" for the given platform. + See [1] for more details. +- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided + by a DSI PHY block. - vdd-supply: phandle to vdd regulator device node - vddio-supply: phandle to vdd-io regulator device node - vdda-supply: phandle to vdda regulator device node @@ -90,6 +94,8 @@ Required properties: * "dsi_pll" * "dsi_phy" * "dsi_phy_regulator" +- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating + 2 clocks: A byte clock (index 0), and a pixel clock (index 1). - qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should be 0 or 1, since we have 2 DSI PHYs at most for now. - power-domains: Should be <&mmcc MDSS_GDSC>. @@ -132,6 +138,14 @@ Example: <&mmcc MDSS_AHB_CLK>, <&mmcc MDSS_MDP_CLK>, <&mmcc MDSS_PCLK0_CLK>; + + assigned-clocks = +<&mmcc BYTE0_CLK_SRC>, +<&mmcc PCLK0_CLK_SRC>; + assigned-clock-parents = +<&dsi0_phy 0>, +<&dsi0_phy 1>; + vdda-supply = <&pma8084_l2>; vdd-supply = <&pma8084_l22>; vddio-supply = <&pma8084_l12>; @@ -195,6 +209,7 @@ Example: <0xfd922d80 0x7b>; clock-names = "iface_clk"; clocks = <&mmcc MDSS_AHB_CLK>; + #clock-cells = <1>; vddio-supply = <&pma8084_l12>; qcom,dsi-phy-regulator-ldo-mode; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[Bug 94900] HD6950 GPU lockup with various steam games (octodad, saints row 4)
https://bugs.freedesktop.org/show_bug.cgi?id=94900 Daniel T. changed: What|Removed |Added Summary|HD6950 GPU lockup with |HD6950 GPU lockup with |octodad: dadliest catch |various steam games ||(octodad, saints row 4) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/5f4915fd/attachment.html>
[Bug 94900] HD6950 GPU lockup with various steam games (octodad, saints row 4)
https://bugs.freedesktop.org/show_bug.cgi?id=94900 --- Comment #3 from Daniel T. --- Saints row 4 causes this lockup [118144.509627] radeon :01:00.0: ring 0 stalled for more than 10060msec [118144.509638] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118144.582926] radeon :01:00.0: ring 4 stalled for more than 10133msec [118144.582941] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118145.009595] radeon :01:00.0: ring 0 stalled for more than 10560msec [118145.009605] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118145.082921] radeon :01:00.0: ring 4 stalled for more than 10633msec [118145.082930] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118145.509637] radeon :01:00.0: ring 0 stalled for more than 11060msec [118145.509647] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118145.579594] radeon :01:00.0: ring 4 stalled for more than 11130msec [118145.579603] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118146.009631] radeon :01:00.0: ring 0 stalled for more than 11560msec [118146.009641] radeon :01:00.0: GPU lockup (current fence id 0x01dccef9 last fence id 0x01dccefe on ring 0) [118146.082911] radeon :01:00.0: ring 4 stalled for more than 11633msec [118146.082921] radeon :01:00.0: GPU lockup (current fence id 0x00a861a1 last fence id 0x00a861a2 on ring 4) [118146.379880] radeon :01:00.0: Saved 31 dwords of commands on ring 0. [118146.379961] radeon :01:00.0: GPU softreset: 0x0029 [118146.379963] radeon :01:00.0: GRBM_STATUS = 0xE5703828 [118146.379964] radeon :01:00.0: GRBM_STATUS_SE0 = 0xFC07 [118146.379965] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [118146.379966] radeon :01:00.0: SRBM_STATUS = 0x20C0 [118146.380033] radeon :01:00.0: SRBM_STATUS2 = 0x [118146.380034] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [118146.380035] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x00018000 [118146.380036] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x8004 [118146.380037] radeon :01:00.0: R_008680_CP_STAT = 0x80038647 [118146.380039] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [118146.380040] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83146 [118146.380041] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x [118146.380043] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x [118146.380044] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [118146.380045] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [118146.390413] radeon :01:00.0: GRBM_SOFT_RESET=0xDF7B [118146.390465] radeon :01:00.0: SRBM_SOFT_RESET=0x0140 [118146.391620] radeon :01:00.0: GRBM_STATUS = 0x3828 [118146.391621] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [118146.391622] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [118146.391623] radeon :01:00.0: SRBM_STATUS = 0x20C0 [118146.391690] radeon :01:00.0: SRBM_STATUS2 = 0x [118146.391691] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [118146.391692] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [118146.391693] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [118146.391694] radeon :01:00.0: R_008680_CP_STAT = 0x [118146.391696] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [118146.391697] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [118146.391772] radeon :01:00.0: GPU reset succeeded, trying to resume -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/a558fff4/attachment-0001.html>
[PATCH 02/23] drm: omapdrm: fb: Don't store format BPP for each plane
On Tue, May 03, 2016 at 09:08:06AM +0300, Tomi Valkeinen wrote:
>
> On 03/05/16 00:01, Rob Clark wrote:
> > On Mon, May 2, 2016 at 11:43 AM, Tomi Valkeinen
> > wrote:
> >> Hi Laurent,
> >>
> >> On 26/04/16 23:35, Laurent Pinchart wrote:
> >>> The number of bits per pixel is identical for all planes, don't store
> >>> multiple copies.
> >>
> >> That's not true, as with NV12, Y has 8 bits per pixel and UV has 16 bits
> >> per pixel. But as the subsampling is precalculated into the stride_bpp
> >> (is it bytes or bits? bpp always confuses me =), the 'stride_bpp' ends
> >> up being same for both planes.
> >>
> >> To be honest, I'd rather go into more complex struct than simpler one.
> >> The current one is already confusing, I think, and your version is too.
> >> The main issue is that the sub_x is encoded into the stride_bpp. In
> >> kmsxx I used this format:
> >>
> >> { PixelFormat::NV12, { 2, { { 8, 1, 1, }, { 8, 2, 2 } }, } },
> >>
> >> The first number is the number of planes, and for each plane, bitspp,
> >> xsub and ysub. It's more verbose, but (I think) easier to understand.
> >
> > fwiw, I guess a lot of data from that table could these days be
> > replaced w/ some of the drm format helpers
> > (drm_format_num_planes()/drm_format_plane_cpp()/drm_format_{horz,vert}_chroma_subsampling()/etc)
>
> Indeed, I think we can remove all but the DRM -> DSS format mapping.
>
> Btw, what is "cpp" short from?
Bytes per pixel. The 'c' is silent :P
PS.
Actually it's "chars per pixel"
--
Ville Syrjälä
Intel OTC
[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.
Hi,
Sorry for the late response, been very busy with other stuff lately.
I've tested this version against drm-fixes and it indeed fixes the
problem, as far as I can tell.
Tested-by: Thomas Hellstrom
On 03/31/2016 01:26 PM, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
>
> Changes since v1:
> - Add comment.
> Changes since v2:
> - Add fastpath for refcount = 1. (danvet)
>
> Cc: stable at vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2016-2DMarch_102876.html&d=BQIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=_2qOX1NGnSnJOTgqvu1Ud574i5T3fLDlX91oUS3WXXI&s=9D34PFYdb1PT2vzX_M_7lNVoSebfM9-KsAqe5AXAQbQ&e=
>
> Cc: Thomas Hellstrom
> Cc: David Herrmann
> ---
> drivers/gpu/drm/drm_crtc.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 55ffde5a3a4a..743bece1f579 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
> return 0;
> }
>
> +struct drm_mode_rmfb_work {
> + struct work_struct work;
> + struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> + struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> + drm_framebuffer_remove(arg->fb);
> +}
> +
> /**
> * drm_mode_rmfb - remove an FB from the configuration
> * @dev: drm device for the ioctl
> @@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
> mutex_unlock(&dev->mode_config.fb_lock);
> mutex_unlock(&file_priv->fbs_lock);
>
> - drm_framebuffer_unreference(fb);
> + /*
> + * drm_framebuffer_remove may fail with -EINTR on pending signals,
> + * so run this in a separate stack as there's no way to correctly
> + * handle this after the fb is already removed from the lookup table.
> + */
> + if (atomic_read(&fb->refcount.refcount) > 1) {
> + struct drm_mode_rmfb_work arg;
> +
> + INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> + arg.fb = fb;
> +
> + schedule_work(&arg.work);
> + flush_work(&arg.work);
> + destroy_work_on_stack(&arg.work);
> + } else
> + drm_framebuffer_unreference(fb);
>
> return 0;
>
[PATCH 5/6] drm/atomic: use connector references (v2)
On Tue, May 3, 2016 at 12:09 PM, Dave Airlie wrote:
>>>*/
>>> + if (connector && state->crtc) {
>>> + drm_connector_unreference(state->connector);
>>> + }
>>
>> Bikeshed: no need for {} and you don't need to check that connector is
>> NULL either. Tbh all the destroy_state helpers don't really need their
>> object argument, only the state. Cleaning that up is somewhere on my todo.
>
> Yes you really do need the connector, lost a boot to an oops,
>
> drm_atomic_state_default_clear does some funky stuff that can possibly go away
> after this, but I'm not sure.
Surprising, didn't expect that. Do you still have the backtrace
somewhere? I really wonder what goes boom with that one ...
What we might need is check for state->connector (instead of
connector), but that being NULL for a valid state is also a bit a bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm/atomic: Add WARN_ON when state->acquire_ctx is not set.
On Tue, May 03, 2016 at 11:12:31AM +0200, Maarten Lankhorst wrote:
> When I was writing an atomic wrapper for rmfb, I ran into the
> following backtrace from lockdep:
>
> =
> [ INFO: possible recursive locking detected ]
> 4.5.0-patser+ #4696 Tainted: G U
> -
> kworker/2:2/2608 is trying to acquire lock:
> (crtc_ww_class_mutex){+.+.+.}, at: []
> drm_modeset_lock+0x7c/0x120 [drm]
>
> but task is already holding lock:
> (crtc_ww_class_mutex){+.+.+.}, at: []
> modeset_backoff+0x8d/0x220 [drm]
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(crtc_ww_class_mutex);
> lock(crtc_ww_class_mutex);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 4 locks held by kworker/2:2/2608:
> #0: ("events"){.+.+.+}, at: []
> process_one_work+0x15a/0x6c0
> #1: ((&arg.work)){+.+.+.}, at: []
> process_one_work+0x15a/0x6c0
> #2: (crtc_ww_class_acquire){+.+.+.}, at: []
> drm_atomic_helper_remove_fb+0x4a/0x1d0 [drm_kms_helper]
> #3: (crtc_ww_class_mutex){+.+.+.}, at: []
> modeset_backoff+0x8d/0x220 [drm]
>
> While lockdep probably catches this bug when it happens, it's better
> to explicitly warn when state->acquire_ctx is not set.
>
> Signed-off-by: Maarten Lankhorst
Yeah, because of the automagic fallback to normal mutex semantics when
acquire_ctx == NULL in ww_mutex_lock this can go boom, and the lockdep
splat is pretty hard to read. Makes sense to have an explicit WARN_ON
about it.
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 0b526423f19f..69adcf3944cc 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -263,6 +263,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> int ret, index = drm_crtc_index(crtc);
> struct drm_crtc_state *crtc_state;
>
> + WARN_ON(!state->acquire_ctx);
> +
> crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
> if (crtc_state)
> return crtc_state;
> @@ -622,6 +624,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
> int ret, index = drm_plane_index(plane);
> struct drm_plane_state *plane_state;
>
> + WARN_ON(!state->acquire_ctx);
> +
> plane_state = drm_atomic_get_existing_plane_state(state, plane);
> if (plane_state)
> return plane_state;
> @@ -890,6 +894,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state
> *state,
> struct drm_mode_config *config = &connector->dev->mode_config;
> struct drm_connector_state *connector_state;
>
> + WARN_ON(!state->acquire_ctx);
> +
> ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
> if (ret)
> return ERR_PTR(ret);
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 2/9] drm/msm: Drop the gpu binding
On Tue, May 3, 2016 at 5:57 AM, Archit Taneja wrote:
> The driver currently identifies the GPU components it needs by parsing
> a phandle list from the 'gpus' DT property.
>
> This isn't the right binding to go with. So, for now, just search all
> device nodes and find the gpu node we need by parsing a list of
> compatible strings.
>
> Once we know how to link the kms and gpu drivers, we'll drop this method
> and use the correct binding.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/msm/msm_drv.c | 26 +++---
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 30b8f3b..f717a69 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1068,20 +1068,32 @@ static int compare_of(struct device *dev, void *data)
> return dev->of_node == data;
> }
>
> -static int add_components(struct device *dev, struct component_match
> **matchptr,
> - const char *name)
> +static const char * const msm_compatible_gpus[] = {
> + "qcom,adreno-3xx",
> + "qcom,kgsl-3d0",
> +};
> +
> +/*
> + * We don't know what's the best binding to link the gpu with the drm device.
> + * Fow now, we just hunt for all the possible gpus that we support, and add
> them
> + * as components.
> + */
> +static int add_gpu_components(struct device *dev,
> + struct component_match **matchptr)
> {
> - struct device_node *np = dev->of_node;
> unsigned i;
>
> - for (i = 0; ; i++) {
> + for (i = 0; i < ARRAY_SIZE(msm_compatible_gpus); i++) {
You can use of_find_matching_node() here instead of a loop.
Rob
[PATCH v3 1/2] drm: bridge: Add sii902x driver
On Tue, May 03, 2016 at 12:03:08PM +0200, Boris Brezillon wrote: > On Tue, 3 May 2016 11:53:18 +0200 > Daniel Vetter wrote: > > > On Tue, May 3, 2016 at 11:39 AM, Boris Brezillon > > wrote: > > >> > + .detect = sii902x_connector_detect, > > >> > + .fill_modes = drm_helper_probe_single_connector_modes, > > >> > + .destroy = sii902x_connector_destroy, > > >> > +}; > > >> > > >> I'm guessing this is to support both atomic and !atomic drivers. I > > >> thought it was working automatically? > > > > > > Hm, the dw-hdmi driver is providing both, but maybe it's not needed. > > > Daniel, any comments? > > > > You only need this in case you actually have atomic and !atomic users > > of your bridge. We discussed whether we should have a dpms helper that > > dtrt automatically, but with just 1 driver that doesn't seem worth it. > > You wouldn't need to have 2 entier vfunc tables, you could just switch > > on DRIVER_ATOMIC. > > Ok, I'll drop the !atomic helpers. Should I still test > drm_core_check_feature(drm, DRIVER_ATOMIC) in the ->attach() > implementation and return an error if the DRM device does not support > atomic operations? If you feel like. If someone tries to use this bridge driver with a non-atomic driver then - they'll have a big fireworks show either way - a really good reason to fix up their driver to be atomic, like it should be ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
On Tue, May 03, 2016 at 02:46:36PM +0300, Mika Kahola wrote:
> Prep work to improve DP branch device handling.
>
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
>
> The register defines the pixel rate divided by 8 in MP/s.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp.c | 34 ++
> drivers/gpu/drm/i915/intel_drv.h | 9 +
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3633002..74a04ce 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
> int max_rate, mode_rate, max_lanes, max_link_clock;
> int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>
> + /* DP to VGA dongle may define max pixel rate in DPCD */
> + if (intel_dp->dfp.present &&
> + intel_dp->dfp.detailed_cap_info &&
> + (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
> + (intel_dp->dfp.dot_clk > 0))
> + max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
What's dfp?
Looks like most of this stuff is not really needed. Just storing a max
dotclock per downstream port would seem to suffice.
> +
> if (is_edp(intel_dp) && fixed_mode) {
> if (mode->hdisplay > fixed_mode->hdisplay)
> return MODE_PANEL;
> @@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs
> intel_dp_enc_funcs = {
> .destroy = intel_dp_encoder_destroy,
> };
>
> +static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> +{
> + uint8_t dfp_info[4];
> +
> + intel_dp->dfp.detailed_cap_info =
> intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
> < 0) {
> + intel_dp->dfp.present = false;
> + intel_dp->dfp.detailed_cap_info = false;
> + return; /* aux transfer failed */
> + }
> +
> + intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
> +
> + if (intel_dp->dfp.detailed_cap_info) {
> + if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> + intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> + DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> intel_dp->dfp.dot_clk);
> + }
I would suggest putting this sort of stuff into the dp helper. I once
started to hatch something to deal with these downstream port limits,
but never finished it. I pushed my WIP stuff (mostly ideas how to parse
these port caps) to
git://github.com/vsyrjala/linux.git dp_downstream_ports
maybe you can to see if there's anything useful for you there.
> + }
> +}
> +
> enum irqreturn
> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> {
> @@ -4599,6 +4628,11 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> power_domain = intel_display_port_aux_power_domain(intel_encoder);
> intel_display_power_get(dev_priv, power_domain);
>
> + intel_dp->dfp.present = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 0x1;
> +
> + if (intel_dp->dfp.present)
> + intel_dp_get_dfp(intel_dp);
> +
> if (long_hpd) {
> /* indicate that we need to restart link training */
> intel_dp->train_set_valid = false;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 21dee3f..9798a59 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -794,6 +794,13 @@ enum link_m_n_set {
> M2_N2
> };
>
> +struct intel_dp_dfp {
> + bool present;
> + int type;
> + bool detailed_cap_info;
> + int dot_clk; /* pixel rate for VGA dongles */
> +};
> +
> struct intel_dp {
> i915_reg_t output_reg;
> i915_reg_t aux_ch_ctl_reg;
> @@ -861,6 +868,8 @@ struct intel_dp {
>
> bool train_set_valid;
>
> + struct intel_dp_dfp dfp;
> +
> /* Displayport compliance testing */
> unsigned long compliance_test_type;
> unsigned long compliance_test_data;
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[Intel-gfx] [PATCH 3/3] drm/i915: Check HDMI TMDS clock rate from DPCD
On Tue, May 03, 2016 at 02:46:38PM +0300, Mika Kahola wrote:
> Read TMDS clock rate from DPCD for HDMI to filter out
> modes that might require higher TMDS clock rate than
> supported.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp.c | 3 +++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 74a04ce..0fd078c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4591,6 +4591,9 @@ static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> intel_dp->dfp.dot_clk);
> + } else if (!(intel_dp->dfp.type & DP_DS_PORT_TYPE_WIRELESS)) {
> + intel_dp->dfp.tmds_clk = DIV_ROUND_CLOSEST(dfp_info[1]
> * 25 * 1000, 10);
> + DRM_DEBUG_KMS("max TMDS clock is %d kHz\n",
> intel_dp->dfp.tmds_clk);
> }
> }
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9798a59..8bf97da 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -799,6 +799,7 @@ struct intel_dp_dfp {
> int type;
> bool detailed_cap_info;
> int dot_clk; /* pixel rate for VGA dongles */
> + int tmds_clk;
> };
>
> struct intel_dp {
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e1012d6..70e8e17 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1170,13 +1170,14 @@ static void pch_post_disable_hdmi(struct
> intel_encoder *encoder)
> static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool
> respect_dvi_limit)
> {
> struct drm_device *dev = intel_hdmi_to_dev(hdmi);
> + int tmds_clock = hdmi_to_dig_port(hdmi)->dp.dfp.tmds_clk;
>
> if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
> - return 165000;
> + return (tmds_clock > 0 ? min(165000, tmds_clock) : 165000);
> else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
> - return 30;
> + return (tmds_clock > 0 ? min(30, tmds_clock) : 30);
> else
> - return 225000;
> + return (tmds_clock > 0 ? min(225000, tmds_clock) : 225000);
Changing limits for native HDMI ports isn't going to do much when
dealing with active DP dongles.
> }
>
> static enum drm_mode_status
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[Intel-gfx] [PATCH v2 1/4] drm: Add helper for DP++ adaptors
On Tue, May 03, 2016 at 10:46:26AM +0300, Jani Nikula wrote: > On Mon, 02 May 2016, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > Add a helper which aids in the identification of DP dual mode > > (aka. DP++) adaptors. There are several types of adaptors > > specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors > > may go as high as 300MHz and they provide a register informing the > > source device what the actual limit is. Supposedly also type 1 adaptors > > may optionally implement this register. This TMDS clock limit is the > > main reason why we need to identify these adaptors. > > > > Type 1 adaptors provide access to their internal registers and the sink > > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > > and I2C-over-AUX. A type 2 source device may choose to implement either > > of these methods. If a source device implements the I2C-over-AUX > > method, then the driver will obviously need specific support for such > > adaptors since the port is driven like an HDMI port, but DDC > > communication happes over the AUX channel. > > > > This helper should be enough to identify the adaptor type (some > > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > > clock limit. Another feature that may be available is control over > > the TMDS output buffers on the adaptor, possibly allowing for some > > power saving when the TMDS link is down. > > > > Other user controllable features that may be available in the adaptors > > are downstream i2c bus speed control when using i2c-over-aux, and > > some control over the CEC pin. I chose not to provide any helper > > functions for those since I have no use for them in i915 at this time. > > The rest of the registers in the adaptor are mostly just information, > > eg. IEEE OUI, hardware and firmware revision, etc. > > > > v2: Pass adaptor type to helper functions to ease driver implementation > > Fix a bunch of typoes (Paulo) > > Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know > > the type (Paulo) > > Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) > > Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to > > ease future LSPCON enabling > > Remove the unused DP_DUAL_MODE_LAST_RESERVED define > > > > Cc: stable at vger.kernel.org > > Cc: Tore Anderson > > Cc: Paulo Zanoni > > Cc: Shashank Sharma > > Cc: Daniel Vetter > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 > > ++ > > include/drm/drm_dp_dual_mode_helper.h | 83 +++ > > 3 files changed, 440 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index 1a26b4eb1ce0..29f2ee9b9534 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > > - drm_kms_helper_common.o > > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > new file mode 100644 > > index ..949c0fbeb542 > > --- /dev/null > > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > @@ -0,0 +1,356 @@ > > +/* > > + * Copyright © 2016 Intel Corporation > > + * > > + * Permission is hereby granted, free of charge, to any person obtaining a > > + * copy of this software and associated documentation files (the > > "Software"), > > + * to deal in the Software without restriction, including without > > limitation > > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > > + * and/or sell copies of the Software, and to permit persons to whom the > > + * Software is furnished to do so, subject to the following conditions: > > + * > > + * The above copyright notice and this permission notice shall be included > > in > > + * all copies or substantial portions of the Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > > OR > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT O
[PATCH 1/2] drm/exynos/dpi: use of_graph_get_endpoint_by_regs helper
This allows to remove the local of_graph_get_port_by_reg(),
of_graph_get_endpoint_by_reg(), of_get_child_by_name_reg(),
and of_graph_get_remote_port_parent() functions.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 69 +
1 file changed, 2 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 75e570f..5e38e74 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
@@ -164,67 +165,6 @@ static const struct drm_encoder_funcs
exynos_dpi_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-/* of_* functions will be removed after merge of of_graph patches */
-static struct device_node *
-of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 reg)
-{
- struct device_node *np;
-
- for_each_child_of_node(parent, np) {
- u32 r;
-
- if (!np->name || of_node_cmp(np->name, name))
- continue;
-
- if (of_property_read_u32(np, "reg", &r) < 0)
- r = 0;
-
- if (reg == r)
- break;
- }
-
- return np;
-}
-
-static struct device_node *of_graph_get_port_by_reg(struct device_node *parent,
- u32 reg)
-{
- struct device_node *ports, *port;
-
- ports = of_get_child_by_name(parent, "ports");
- if (ports)
- parent = ports;
-
- port = of_get_child_by_name_reg(parent, "port", reg);
-
- of_node_put(ports);
-
- return port;
-}
-
-static struct device_node *
-of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
-{
- return of_get_child_by_name_reg(port, "endpoint", reg);
-}
-
-static struct device_node *
-of_graph_get_remote_port_parent(const struct device_node *node)
-{
- struct device_node *np;
- unsigned int depth;
-
- np = of_parse_phandle(node, "remote-endpoint", 0);
-
- /* Walk 3 levels up only if there is 'ports' node. */
- for (depth = 3; depth && np; depth--) {
- np = of_get_next_parent(np);
- if (depth == 2 && of_node_cmp(np->name, "ports"))
- break;
- }
- return np;
-}
-
enum {
FIMD_PORT_IN0,
FIMD_PORT_IN1,
@@ -237,12 +177,7 @@ static struct device_node
*exynos_dpi_of_find_panel_node(struct device *dev)
{
struct device_node *np, *ep;
- np = of_graph_get_port_by_reg(dev->of_node, FIMD_PORT_RGB);
- if (!np)
- return NULL;
-
- ep = of_graph_get_endpoint_by_reg(np, 0);
- of_node_put(np);
+ ep = of_graph_get_endpoint_by_regs(dev->of_node, FIMD_PORT_RGB, 0);
if (!ep)
return NULL;
--
2.8.0.rc3
[PATCH 2/2] drm/exynos/dsi: use of_graph_get_endpoint_by_regs helper
This allows to remove the local of_graph_get_port_by_reg(),
of_graph_get_endpoint_by_reg(), and of_get_child_by_name_reg()
functions.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 57 ++---
1 file changed, 3 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 63c84a1..61251fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1641,50 +1641,6 @@ static const struct drm_encoder_funcs
exynos_dsi_encoder_funcs = {
MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
-/* of_* functions will be removed after merge of of_graph patches */
-static struct device_node *
-of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 reg)
-{
- struct device_node *np;
-
- for_each_child_of_node(parent, np) {
- u32 r;
-
- if (!np->name || of_node_cmp(np->name, name))
- continue;
-
- if (of_property_read_u32(np, "reg", &r) < 0)
- r = 0;
-
- if (reg == r)
- break;
- }
-
- return np;
-}
-
-static struct device_node *of_graph_get_port_by_reg(struct device_node *parent,
- u32 reg)
-{
- struct device_node *ports, *port;
-
- ports = of_get_child_by_name(parent, "ports");
- if (ports)
- parent = ports;
-
- port = of_get_child_by_name_reg(parent, "port", reg);
-
- of_node_put(ports);
-
- return port;
-}
-
-static struct device_node *
-of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
-{
- return of_get_child_by_name_reg(port, "endpoint", reg);
-}
-
static int exynos_dsi_of_read_u32(const struct device_node *np,
const char *propname, u32 *out_value)
{
@@ -1706,7 +1662,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
{
struct device *dev = dsi->dev;
struct device_node *node = dev->of_node;
- struct device_node *port, *ep;
+ struct device_node *ep;
int ret;
ret = exynos_dsi_of_read_u32(node, "samsung,pll-clock-frequency",
@@ -1714,16 +1670,9 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- port = of_graph_get_port_by_reg(node, DSI_PORT_OUT);
- if (!port) {
- dev_err(dev, "no output port specified\n");
- return -EINVAL;
- }
-
- ep = of_graph_get_endpoint_by_reg(port, 0);
- of_node_put(port);
+ ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
if (!ep) {
- dev_err(dev, "no endpoint specified in output port\n");
+ dev_err(dev, "no output port with endpoint specified\n");
return -EINVAL;
}
--
2.8.0.rc3
[PATCH 1/2] drm/imx: imx-ldb: use of_graph_get_endpoint_by_regs helper
Instead of using of_graph_get_port_by_id() to get the port and then
of_get_child_by_name() to get the first endpoint, get to the endpoint
in a single step.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index a58eee5..d8e7ba4 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -553,7 +553,7 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
for_each_child_of_node(np, child) {
struct imx_ldb_channel *channel;
- struct device_node *port;
+ struct device_node *ep;
ret = of_property_read_u32(child, "reg", &i);
if (ret || i < 0 || i > 1)
@@ -576,22 +576,23 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
* The output port is port at 4 with an external 4-port mux or
* port at 2 with the internal 2-port mux.
*/
- port = of_graph_get_port_by_id(child, imx_ldb->lvds_mux ? 4 :
2);
- if (port) {
- struct device_node *endpoint, *remote;
-
- endpoint = of_get_child_by_name(port, "endpoint");
- if (endpoint) {
- remote =
of_graph_get_remote_port_parent(endpoint);
- if (remote)
- channel->panel =
of_drm_find_panel(remote);
- else
- return -EPROBE_DEFER;
- if (!channel->panel) {
- dev_err(dev, "panel not found: %s\n",
- remote->full_name);
- return -EPROBE_DEFER;
- }
+ ep = of_graph_get_endpoint_by_regs(child,
+ imx_ldb->lvds_mux ? 4 : 2,
+ -1);
+ if (ep) {
+ struct device_node *remote;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+ if (remote)
+ channel->panel = of_drm_find_panel(remote);
+ else
+ return -EPROBE_DEFER;
+ of_node_put(remote);
+ if (!channel->panel) {
+ dev_err(dev, "panel not found: %s\n",
+ remote->full_name);
+ return -EPROBE_DEFER;
}
}
--
2.8.0.rc3
[PATCH 2/2] drm/imx: parallel-display: use of_graph_get_endpoint_by_regs helper
Instead of using of_graph_get_port_by_id() to get the port and then
of_get_child_by_name() to get the first endpoint, get to the endpoint
in a single step.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/parallel-display.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index 363e2c7..27755ec 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -203,7 +203,7 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
{
struct drm_device *drm = data;
struct device_node *np = dev->of_node;
- struct device_node *port;
+ struct device_node *ep;
const u8 *edidp;
struct imx_parallel_display *imxpd;
int ret;
@@ -230,18 +230,18 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
}
/* port at 1 is the output port */
- port = of_graph_get_port_by_id(np, 1);
- if (port) {
- struct device_node *endpoint, *remote;
-
- endpoint = of_get_child_by_name(port, "endpoint");
- if (endpoint) {
- remote = of_graph_get_remote_port_parent(endpoint);
- if (remote)
- imxpd->panel = of_drm_find_panel(remote);
- if (!imxpd->panel)
- return -EPROBE_DEFER;
+ ep = of_graph_get_endpoint_by_regs(np, 1, -1);
+ if (ep) {
+ struct device_node *remote;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+ if (remote) {
+ imxpd->panel = of_drm_find_panel(remote);
+ of_node_put(remote);
}
+ if (!imxpd->panel)
+ return -EPROBE_DEFER;
}
imxpd->dev = dev;
--
2.8.0.rc3
[PATCH 2/3] drm: Add DP port types from DP 1.3 specification
DP specification 1.3 defines DP downstream ports for DP++ and wireless devices. Let's add these to port definitions. Signed-off-by: Mika Kahola --- include/drm/drm_dp_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 92d9a52..9a15099 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -210,6 +210,8 @@ # define DP_DS_PORT_TYPE_DVI 2 # define DP_DS_PORT_TYPE_HDMI 3 # define DP_DS_PORT_TYPE_NON_EDID 4 +# define DP_DP_PORT_TYPE_DP_DUALMODE5 +# define DP_DS_PORT_TYPE_WIRELESS 6 # define DP_DS_PORT_HPD(1 << 3) /* offset 1 for VGA is maximum megapixels per second / 8 */ /* offset 2 */ -- 1.9.1
fsl-dcu not works on latest "drm-next"
Hi, I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and got some log below. And fsl-dcu not works. Since "drm-next" merged some branch , use git bisect had some problem , so I manually checked out that "fsl-dcu" works at d761701c55a99598477f3cb25c03d939a7711e74 And not works now. some log below: [drm] Initialized drm 1.1.0 20060810 panel supply power not found, using dummy regulator [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [ cut here ] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 drm_atomic_helper_wait_for_vblanks+0xff/0x124 [CRTC:24] vblank wait timed out Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189 Hardware name: Freescale LS1021A [<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc) [<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74) [<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0) [<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28) [<80211a7f>] (warn_slowpath_fmt) from [<803ca887>] (drm_atomic_helper_wait_for_vblanks+0xff/0x124) [<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>] (drm_atomic_helper_commit+0x43/0x5c) [<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>] (restore_fbdev_mode+0xad/0x16e) [<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44) [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38) [<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0) [<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4) [<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4) [<803b6f95>] (do_bind_con_driver) from [<803b7287>] (do_take_over_console+0xcf/0x108) [<803b7287>] (do_take_over_console) from [<80397549>] (do_fbcon_takeover+0x35/0x7c) [<80397549>] (do_fbcon_takeover) from [<802229db>] (notifier_call_chain+0x23/0x38) [<802229db>] (notifier_call_chain) from [<80222b63>] (__blocking_notifier_call_chain+0x27/0x36) [<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>] (blocking_notifier_call_chain+0xf/0x14) [<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>] (register_framebuffer+0x179/0x1d0) [<8039bdf9>] (register_framebuffer) from [<803cd15f>] (drm_fb_helper_initial_config+0x1af/0x200) [<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>] (drm_fbdev_cma_init+0x67/0xa8) [<803cd593>] (drm_fbdev_cma_init) from [<803e2269>] (fsl_dcu_fbdev_init+0x11/0x14) [<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba) [<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68) [<803d2d51>] (drm_dev_register) from [<803e1ab7>] (fsl_dcu_drm_probe+0x193/0x240) [<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>] (platform_drv_probe+0x33/0x62) [<803e6d2d>] (platform_drv_probe) from [<803e5e7d>] (driver_probe_device+0xb9/0x1a4) [<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58) [<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46) [<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138) [<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76) [<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138) [<80201517>] (do_one_initcall) from [<80800a61>] (kernel_init_freeable+0xd1/0x168) [<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4) [<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30) ---[ end trace b7946726c4e290c4 ]--- Console: switching to colour frame buffer device 60x34 fsl-dcu 2ce.dcu: fb0: frame buffer device [drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0 And full log in the attachment. does anybody have any idea about this? Best Regards, Meng Yi -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/b726b17e/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: ls1021a-twr.log Type: application/octet-stream Size: 14148 bytes Desc: ls1021a-twr.log URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/b726b17e/attachment-0001.obj>
[PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
Prep work to improve DP branch device handling.
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rate divided by 8 in MP/s.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 34 ++
drivers/gpu/drm/i915/intel_drv.h | 9 +
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3633002..74a04ce 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ /* DP to VGA dongle may define max pixel rate in DPCD */
+ if (intel_dp->dfp.present &&
+ intel_dp->dfp.detailed_cap_info &&
+ (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
+ (intel_dp->dfp.dot_clk > 0))
+ max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
+
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
@@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs intel_dp_enc_funcs
= {
.destroy = intel_dp_encoder_destroy,
};
+static void intel_dp_get_dfp(struct intel_dp *intel_dp)
+{
+ uint8_t dfp_info[4];
+
+ intel_dp->dfp.detailed_cap_info =
intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE;
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
< 0) {
+ intel_dp->dfp.present = false;
+ intel_dp->dfp.detailed_cap_info = false;
+ return; /* aux transfer failed */
+ }
+
+ intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
+
+ if (intel_dp->dfp.detailed_cap_info) {
+ if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
+ intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
+ DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
intel_dp->dfp.dot_clk);
+ }
+ }
+}
+
enum irqreturn
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
{
@@ -4599,6 +4628,11 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
+ intel_dp->dfp.present = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 0x1;
+
+ if (intel_dp->dfp.present)
+ intel_dp_get_dfp(intel_dp);
+
if (long_hpd) {
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 21dee3f..9798a59 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -794,6 +794,13 @@ enum link_m_n_set {
M2_N2
};
+struct intel_dp_dfp {
+ bool present;
+ int type;
+ bool detailed_cap_info;
+ int dot_clk; /* pixel rate for VGA dongles */
+};
+
struct intel_dp {
i915_reg_t output_reg;
i915_reg_t aux_ch_ctl_reg;
@@ -861,6 +868,8 @@ struct intel_dp {
bool train_set_valid;
+ struct intel_dp_dfp dfp;
+
/* Displayport compliance testing */
unsigned long compliance_test_type;
unsigned long compliance_test_data;
--
1.9.1
[nexus7-flo] backlight brightness
On Mon, May 2, 2016 at 12:56 PM, Thierry Reding
wrote:
> On Fri, Apr 29, 2016 at 08:04:09AM -0400, Rob Clark wrote:
>> On Fri, Apr 29, 2016 at 1:32 AM, Vinay Simha wrote:
>> > hi,
>> >
>> > In nx7, backlight brightness control is controlled by dcs commands of
>> > MIPI_DCS_SET_DISPLAY_BRIGHTNESS.
>> > there is no PWM going to panel interface directly as we have in ifc6410/nx5
>>
>> afaiu it is not uncommon to need to control backlight via panel (ie, I
>> think basically all adaptive-backlight panels). I think the answer is
>> for these panels, the panel driver would register it's own backlight
>> driver, rather than get a (pwm, etc) backlight via dt bindings.
>
> Yes, that'd be my recommendation as well.
>
>> Possibly if the backlight commands are standardized enough then we
>> could implement a single drm_panel_dsi_backlight helper which could be
>> created by any of the dsi adaptive-backlight panels (ie. pass in a
>> 'struct mipi_dsi_device *').. something like:
>>
>> struct drm_panel_dsi_backlight {
>> struct mipi_panel_dsi_device *link;
>> ...
>> }
>>
>> struct backlight_device *drm_panel_create_dsi_backlight(struct
>> mipi_panel_dsi_device *link)
>> {
>> struct drm_panel_dsi_backlight *dsi_bl;
>> ...
>> return devm_backlight_device_register(&link->dev, ..., dsi_bl,
>> dsi_bl_ops, props);
>> }
struct backlight_device *devm_backlight_device_register(struct device *dev,
const char *name, struct device *parent, void *devdata,
const struct backlight_ops *ops,
const struct backlight_properties *props)
struct device *dev = &jdi->dsi->dev;
devm_backlight_device_register(
dev,
dev_name(dev),
dev,
jdi,
&dsi_bl_ops, &props);
Here does the parent also should be jdi->dsi->dev ? because the
backlight is not mapped to fb of android ( android->
settings->brightness) , even though i can change the brightness value
from sysfs and it works only when the display is off. When it
awakes(power button press) panel_enable calls, backlight_update_status
will have the latest brightness value.
if echo the brightness value when the display is awake, dsi fails for
brightness control.
echo 100 > /sys/class/backlight/470.qcom,mdss_dsi.0/brightness
[ 152.865949] dsi_cmds2buf_tx: cmd dma tx failed, type=0x15, data0=0x51, len=4
static int dsi_bl_update_status(struct backlight_device *bl)
{
struct jdi_panel *jdi = bl_get_data(bl);
struct mipi_dsi_device *dsi = jdi->dsi;
int ret;
u8 brightness = bl->props.brightness;
ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
&brightness, sizeof(brightness));
if (ret < 0)
return ret;
return 0;
}
static const struct backlight_ops dsi_bl_ops = {
.update_status = dsi_bl_update_status,
};
john,
for android fb do we need to map the backlight in userspace? As i have
seen in 3.4 kernel when we register the backlight using
platform_device_register, backlight used to map with the
userspace(ubuntu/fedora) settings->brightness.
>
> I agree it would make sense to have a DCS specific helper for backlight.
> I'm somewhat sceptical about the standardization, even though these seem
> to be part of DCS 1.3. But perhaps we can start by being optimistic.
>
> Thierry
--
Regards,
Vinay Simha.B.N.
[PATCH 0/3] drm/i915: DP branch devices
This series of patches reads either pixel rate or TMDS clock rate from DPCD. Pixel rate is defined for DP to VGA dongles and TMDS clock rate for others except wireless dongle. The mode that requires either higher pixel rate or TMDS clock rate are filtered out during the mode validity check. Mika Kahola (3): drm/i915: Check pixel rate for DP to VGA dongle drm: Add DP port types from DP 1.3 specification drm/i915: Check HDMI TMDS clock rate from DPCD drivers/gpu/drm/i915/intel_dp.c | 37 + drivers/gpu/drm/i915/intel_drv.h | 10 ++ drivers/gpu/drm/i915/intel_hdmi.c | 7 --- include/drm/drm_dp_helper.h | 2 ++ 4 files changed, 53 insertions(+), 3 deletions(-) -- 1.9.1
[PATCH 3/3] drm/i915: Check HDMI TMDS clock rate from DPCD
Read TMDS clock rate from DPCD for HDMI to filter out
modes that might require higher TMDS clock rate than
supported.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 74a04ce..0fd078c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4591,6 +4591,9 @@ static void intel_dp_get_dfp(struct intel_dp *intel_dp)
if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
intel_dp->dfp.dot_clk);
+ } else if (!(intel_dp->dfp.type & DP_DS_PORT_TYPE_WIRELESS)) {
+ intel_dp->dfp.tmds_clk = DIV_ROUND_CLOSEST(dfp_info[1]
* 25 * 1000, 10);
+ DRM_DEBUG_KMS("max TMDS clock is %d kHz\n",
intel_dp->dfp.tmds_clk);
}
}
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9798a59..8bf97da 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -799,6 +799,7 @@ struct intel_dp_dfp {
int type;
bool detailed_cap_info;
int dot_clk; /* pixel rate for VGA dongles */
+ int tmds_clk;
};
struct intel_dp {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index e1012d6..70e8e17 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1170,13 +1170,14 @@ static void pch_post_disable_hdmi(struct intel_encoder
*encoder)
static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool
respect_dvi_limit)
{
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+ int tmds_clock = hdmi_to_dig_port(hdmi)->dp.dfp.tmds_clk;
if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
- return 165000;
+ return (tmds_clock > 0 ? min(165000, tmds_clock) : 165000);
else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
- return 30;
+ return (tmds_clock > 0 ? min(30, tmds_clock) : 30);
else
- return 225000;
+ return (tmds_clock > 0 ? min(225000, tmds_clock) : 225000);
}
static enum drm_mode_status
--
1.9.1
[PATCH 3/9] drm/msm/mdp: mdp4: Update LCDC/LVDS port parsing
Am Dienstag, den 03.05.2016, 16:27 +0530 schrieb Archit Taneja:
> The LCDC port is the first in the list of the output ports in MDP4.
> Mention this explicitly in the driver.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index f8e0cea..cd129f4 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -263,9 +263,13 @@ static struct device_node *mdp4_detect_lcdc_panel(struct
> drm_device *dev)
> struct device_node *endpoint, *panel_node;
> struct device_node *np = dev->dev->of_node;
>
> - endpoint = of_graph_get_next_endpoint(np, NULL);
> + /*
> + * LCDC/LVDS is the first port described in the list of ports in the
> + * MDP4 DT node.
> + */
> + endpoint = of_graph_get_endpoint_by_regs(np, 0, -1);
> if (!endpoint) {
> - DBG("no endpoint in MDP4 to fetch LVDS panel\n");
> + DBG("no LVDS panel remote endpoint\n");
> return NULL;
> }
Oh nice, I wasn't aware of of_graph_get_endpoint_by_regs().
We should switch imx-drm and exynos to use it, too.
regards
Philipp
[PATCH v2] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.
From: Eric Anholt Signed-off-by: Eric Anholt [Emil Velikov: drop wildcard, add UAPI and Documentation files] Signed-off-by: Emil Velikov --- This patch is rebased/applied on top of the maintainer series from earlier. --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 92e5a12..f864fd6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3980,6 +3980,14 @@ S: Supported F: drivers/gpu/drm/vmwgfx/ F: include/uapi/drm/vmwgfx_drm.h +DRM DRIVERS FOR VC4 +M: Eric Anholt +T: git git://github.com/anholt/linux +S: Supported +F: drivers/gpu/drm/vc4/ +F: include/uapi/drm/vc4_drm.h +F: Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-media at vger.kernel.org -- 2.6.2
[PATCH 8/9] dt-bindings: msm/dsi: Modify port and PHY bindings
Am Dienstag, den 03.05.2016, 16:28 +0530 schrieb Archit Taneja:
> The DSI node now has two ports that describe the connection between the
> MDP interface output and the DSI input, and the connection between the DSI
> output and the connected panel/bridge. Update the properties and the
> example.
>
> Also, use generic PHY bindings instead of the custom one.
>
> Signed-off-by: Archit Taneja
> ---
> .../devicetree/bindings/display/msm/dsi.txt| 53
> +++---
> 1 file changed, 37 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index bf41d7c..0223f06 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -25,12 +25,18 @@ Required properties:
> - vdd-supply: phandle to vdd regulator device node
> - vddio-supply: phandle to vdd-io regulator device node
> - vdda-supply: phandle to vdda regulator device node
> -- qcom,dsi-phy: phandle to DSI PHY device node
> +- phys: phandle to DSI PHY device node
> +- phy-names: the name of the corresponding PHY device
Should "dsi_phy" be specified here?
Also is there any kind of system to the PHY naming? I've seen more
bindings use hyphen instead of underscore in the name, for example.
I have called the MediaTek MIPI_TX PHY "dphy" for no other reason than
it's a MIPI D-PHY.
> - syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
> +- ports: Contains 2 DSI controller ports as child nodes. Each port contains
> + an endpoint subnode as defined in [2] and [3]. port at 0 describes the
> + connection between the MDP interface output and the DSI input. port at 1
> + describes the connection between the DSI output and the connected
> + panel/bridge.
>
> Optional properties:
> - panel at 0: Node of panel connected to this DSI controller.
> - See files in [2] for each supported panel.
> + See files in [4] for each supported panel.
> - qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
>driving a panel which needs 2 DSI links.
> - qcom,master-dsi: Boolean value indicating if the DSI controller is driving
> @@ -42,15 +48,15 @@ Optional properties:
> - pinctrl-names: the pin control state names; should contain "default"
> - pinctrl-0: the default pinctrl state (active)
> - pinctrl-n: the "sleep" pinctrl state
> -- port: DSI controller output port, containing one endpoint subnode.
>
>DSI Endpoint properties:
> - - remote-endpoint: set to phandle of the connected panel's endpoint.
> -See [3] for device graph info.
> + - remote-endpoint: For port at 0, set to phandle of the connected
> panel/bridge's
> +input endpoint. For port at 1, set to the MDP interface output.
>- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
> to the physical lanes on the given platform. The value contained in
> index n describes what logical data lane is mapped to the physical data
> -lane n (DATAn, where n lies between 0 and 3).
> +lane n (DATAn, where n lies between 0 and 3). Only for the endpoint in
> +port at 1.
I approve of the of graph change, but I notice that the
qcom,data-lane-map is very similar to the data-lanes property documented
in Documentation/devicetree/bindings/media/video-interfaces.txt for MIPI
CSI-2. Could that maybe be reused for DSI?
> For example:
>
> @@ -97,8 +103,9 @@ Optional properties:
>regulator is wanted.
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/display/panel/
> -[3] Documentation/devicetree/bindings/graph.txt
> +[2] Documentation/devicetree/bindings/graph.txt
> +[3] Documentation/devicetree/bindings/media/video-interfaces.txt
> +[4] Documentation/devicetree/bindings/display/panel/
>
> Example:
> dsi0: dsi at fd922800 {
> @@ -129,7 +136,8 @@ Example:
> vdd-supply = <&pma8084_l22>;
> vddio-supply = <&pma8084_l12>;
>
> - qcom,dsi-phy = <&dsi_phy0>;
> + phys = <&dsi_phy0>;
> + phy-names ="dsi_phy";
>
> qcom,dual-dsi-mode;
> qcom,master-dsi;
> @@ -139,6 +147,26 @@ Example:
> pinctrl-0 = <&mdss_dsi_active>;
> pinctrl-1 = <&mdss_dsi_suspend>;
>
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <&mdp_intf1_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + dsi0_out: endpoint {
> + remote-endpoint = <&panel_in>;
> +
[Intel-gfx] [PATCH 5/6] drm/atomic: use connector references (v2)
Hi, On 3 May 2016 at 05:28, Dave Airlie wrote: > From: Dave Airlie > > Take a reference when setting a crtc on a connecter, > also take one when duplicating if a crtc is set, > and drop one on destroy if a crtc is set. > > v2: take Daniel Stone's advice and simplify the > ref/unref dances, also take care of NULL as connector > to state reset. > > Signed-off-by: Dave Airlie I expect we'll still end up with all kinds of comedy races here, but on the grounds that it's unambiguously an improvement on what came before, and I can't see anything obviously wrong, for patches 1-5: Reviewed-by: Daniel Stone Cheers, Daniel
[PATCH] drm/i915: Discard previous atomic state on resume if connectors change
If an MST device is disconnected while the machine is suspended, the
number of connectors will change as well after we call
intel_dp_mst_resume(). This means that any previous atomic state we had
before suspending is no longer valid, since it'll still be pointing to
missing connectors. We need to check for this before committing the
state, otherwise we'll kernel panic on resume whenever if any MST
display was disconnected before we started resuming:
BUG: unable to handle kernel NULL pointer dereference at 0008
IP: [] drm_atomic_helper_check_modeset+0x29f/0xb40
[drm_kms_helper]
Call Trace:
[] intel_atomic_check+0x34/0x1180 [i915]
[] ? mark_held_locks+0x6f/0xa0
[] ? trace_hardirqs_on_caller+0x129/0x1b0
[] drm_atomic_check_only+0x192/0x620 [drm]
[] ? pci_pm_thaw+0x21/0x90
[] drm_atomic_commit+0x17/0x60 [drm]
[] intel_display_resume+0xbd/0x160 [i915]
[] ? pci_pm_thaw+0x90/0x90
[] i915_drm_resume+0xd8/0x160 [i915]
[] i915_pm_resume+0x25/0x30 [i915]
[] pci_pm_resume+0x64/0xa0
[] dpm_run_callback+0x90/0x190
[] device_resume+0xd5/0x1f0
[] async_resume+0x1d/0x50
[] async_run_entry_fn+0x48/0x150
[] process_one_work+0x1e9/0x5c0
[] ? process_one_work+0x166/0x5c0
[] worker_thread+0x48/0x4e0
[] ? process_one_work+0x5c0/0x5c0
[] kthread+0xe4/0x100
[] ret_from_fork+0x22/0x50
[] ? kthread_create_on_node+0x200/0x200
Cc: stable at vger.kernel.org
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6e0d828..252c06c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15945,6 +15945,17 @@ void intel_display_resume(struct drm_device *dev)
dev_priv->modeset_restore_state = NULL;
/*
+* With MST, the number of connectors can change between suspend and
+* resume, which means that the state we want to restore might now be
+* impossible to use since it'll be pointing to non-existant
+* connectors.
+*/
+ if (state->num_connector != dev->mode_config.num_connector) {
+ drm_atomic_state_free(state);
+ state = NULL;
+ }
+
+ /*
* This is a cludge because with real atomic modeset mode_config.mutex
* won't be taken. Unfortunately some probed state like
* audio_codec_enable is still protected by mode_config.mutex, so lock
--
2.5.5
[PATCH 5/9] dt-bindings: msm/dsi: Some binding doc cleanups
Am Dienstag, den 03.05.2016, 16:27 +0530 schrieb Archit Taneja:
> Some cleanups:
>
> - Use simpler names for DT nodes in the example
> - Fix phandle for specifying data lane mapping in the example.
> - Use references instead of dumping Document links everywhere
>
> Signed-off-by: Archit Taneja
> ---
> .../devicetree/bindings/display/msm/dsi.txt| 23
> +++---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index f5948c4..bf41d7c 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -11,8 +11,7 @@ Required properties:
>be 0 or 1, since we have 2 DSI controllers at most for now.
> - interrupts: The interrupt signal from the DSI block.
> - power-domains: Should be <&mmcc MDSS_GDSC>.
> -- clocks: device clocks
> - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
> details.
> +- clocks: Phandles to device clocks as descirbed in [1]
s/descirbed/described/
> - clock-names: the following clocks are required:
>* "mdp_core_clk"
>* "iface_clk"
> @@ -31,8 +30,7 @@ Required properties:
>
> Optional properties:
> - panel at 0: Node of panel connected to this DSI controller.
> - See files in Documentation/devicetree/bindings/display/panel/ for each
> supported
> - panel.
> + See files in [2] for each supported panel.
> - qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
>driving a panel which needs 2 DSI links.
> - qcom,master-dsi: Boolean value indicating if the DSI controller is driving
> @@ -48,7 +46,7 @@ Optional properties:
>
>DSI Endpoint properties:
>- remote-endpoint: set to phandle of the connected panel's endpoint.
> -See Documentation/devicetree/bindings/graph.txt for device graph info.
> +See [3] for device graph info.
>- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
> to the physical lanes on the given platform. The value contained in
> index n describes what logical data lane is mapped to the physical data
> @@ -89,8 +87,7 @@ Required properties:
> - qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
>be 0 or 1, since we have 2 DSI PHYs at most for now.
> - power-domains: Should be <&mmcc MDSS_GDSC>.
> -- clocks: device clocks
> - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
> details.
> +- clocks: Phandles to device clocks as descirbed in [1]
s/descirbed/described/
> - clock-names: the following clocks are required:
>* "iface_clk"
> - vddio-supply: phandle to vdd-io regulator device node
> @@ -99,8 +96,12 @@ Optional properties:
> - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode
> PHY
>regulator is wanted.
>
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/display/panel/
> +[3] Documentation/devicetree/bindings/graph.txt
> +
> Example:
> - mdss_dsi0: qcom,mdss_dsi at fd922800 {
> + dsi0: dsi at fd922800 {
> compatible = "qcom,mdss-dsi-ctrl";
> qcom,dsi-host-index = <0>;
> interrupt-parent = <&mdss_mdp>;
> @@ -128,7 +129,7 @@ Example:
> vdd-supply = <&pma8084_l22>;
> vddio-supply = <&pma8084_l12>;
>
> - qcom,dsi-phy = <&mdss_dsi_phy0>;
> + qcom,dsi-phy = <&dsi_phy0>;
>
>
> qcom,dual-dsi-mode;
> qcom,master-dsi;
> @@ -156,12 +157,12 @@ Example:
> port {
> dsi0_out: endpoint {
> remote-endpoint = <&panel_in>;
> - lanes = <0 1 2 3>;
> + qcom,data-lane-map = <0 1 2 3>;
See my comment about the CSI-2 data-lanes binding in the other mail,
could the existing binding be reused?
regards
Philipp
[PATCH] drm/vc4: Return -EBUSY if there's already a pending flip event.
On 05/02/2016 08:57 PM, Eric Anholt wrote:
> robert.foss at collabora.com writes:
>
>> From: Robert Foss
>>
>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>> update is requested and there is an earlier update pending".
>
> Note: docs cited here are drm_crtc.h, and the whole quote is:
>
>* - -EBUSY, if an asynchronous updated is requested and there is
>*an earlier updated pending. Drivers are allowed to support a queue
>*of outstanding updates, but currently no driver supports that.
>*Note that drivers must wait for preceding updates to complete if a
>*synchronous update is requested, they are not allowed to fail the
>*commit in that case.
>
>> Signed-off-by: Robert Foss
>> ---
>> drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++
>> drivers/gpu/drm/vc4/vc4_drv.h | 1 +
>> drivers/gpu/drm/vc4/vc4_kms.c | 20 ++--
>> 3 files changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
>> index 355ee4b..43193a3 100644
>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
>> @@ -802,3 +802,9 @@ struct platform_driver vc4_crtc_driver = {
>> .of_match_table = vc4_crtc_dt_match,
>> },
>> };
>> +
>> +bool vc4_crtc_has_pending_event(struct drm_crtc *crtc)
>> +{
>> +assert_spin_locked(&crtc->dev->event_lock);
>> +return to_vc4_crtc(crtc)->event;
>> +}
>> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
>> index fa2ad15..54c1fb5 100644
>> --- a/drivers/gpu/drm/vc4/vc4_drv.h
>> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
>> @@ -414,6 +414,7 @@ extern struct platform_driver vc4_crtc_driver;
>> int vc4_enable_vblank(struct drm_device *dev, unsigned int crtc_id);
>> void vc4_disable_vblank(struct drm_device *dev, unsigned int crtc_id);
>> int vc4_crtc_debugfs_regs(struct seq_file *m, void *arg);
>> +bool vc4_crtc_has_pending_event(struct drm_crtc *crtc);
>>
>> /* vc4_debugfs.c */
>> int vc4_debugfs_init(struct drm_minor *minor);
>> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
>> index 4718ae5..dc157a1e 100644
>> --- a/drivers/gpu/drm/vc4/vc4_kms.c
>> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
>> @@ -107,10 +107,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
>> bool async)
>> {
>> struct vc4_dev *vc4 = to_vc4_dev(dev);
>> -int ret;
>> -int i;
>> uint64_t wait_seqno = 0;
>> struct vc4_commit *c;
>> +struct drm_crtc_state *crtc_state;
>> +struct drm_crtc *crtc;
>> +unsigned long flags;
>> +int i, ret;
>> +
>> +if (async) {
>> +for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> +
>> +spin_lock_irqsave(&dev->event_lock, flags);
>> +
>> +if (crtc->state->event ||
>> +vc4_crtc_has_pending_event(crtc)) {
>> +spin_unlock_irqrestore(&dev->event_lock, flags);
>> +return -EBUSY;
>> +}
>> +spin_unlock_irqrestore(&dev->event_lock, flags);
>> +}
>> +}
>
> By my reading, the point of returning -EBUSY here is just to avoid
> blocking when the compositor asked for nonblocking. You're checking
> that each CRTC involved in the commit doesn't have a queued pageflip
> event, except that then we immediately proceed to:
>
> /* Make sure that any outstanding modesets have finished. */
> ret = down_interruptible(&vc4->async_modeset);
> if (ret) {
> kfree(c);
> return ret;
> }
>
> so this per-CRTC check doesn't prevent blocking if the set of CRTCs for
> this commit was disjoint from the last one, right? To implement the
> minimal behavior, I think we'd want to just down_trylock instead in the
> async case, I think. And to implement the disjoint CRTC thing you were
> trying for, I think we'd need to track a mask kind of like msm's
> pending_crtcs.
>
So what you're saying is that the set of CRTCs in state
might not contain all CRTCs and that this check might be incomplete for
that reason?
I'm fairly new to these waters, so don't hesitate to tell me if I seem
to be misunderstanding something or am on a wild goose chase of some sort.
So you're suggesting something like this instead of
the per CRTC check:
- /* Make sure that any outstanding modesets have finished. */
- ret = down_interruptible(&vc4->async_modeset);
- if (ret) {
- kfree(c);
- return ret;
- }
+ /* Make sure that any outstanding modesets have finished. */
+ ret = down_trylock(&vc4->async_modeset);
+ if (ret) {
+ kfree(c);
+ return -EBUSY;
+ }
I've quickly tested the above patch and it does seem to work and fulfill
all of my requirements.
[PATCH] drm/imx: ipuv3-plane: enable UYVY and VYUY formats
Advertise the DRM_FORMAT_UYVY and DRM_FORMAT_VYUY formats to userspace.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 681ec6e..8c24df7 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -38,6 +38,8 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_RGBX,
DRM_FORMAT_BGRA,
DRM_FORMAT_BGRA,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_YUV420,
--
2.8.0.rc3
[Intel-gfx] [PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
On Tue, May 03, 2016 at 04:23:34PM +0300, Ville Syrjälä wrote:
> On Tue, May 03, 2016 at 02:46:36PM +0300, Mika Kahola wrote:
> > Prep work to improve DP branch device handling.
> >
> > Filter out a mode that exceeds the max pixel rate setting
> > for DP to VGA dongle. This is defined in DPCD register 0x81
> > if detailed cap info i.e. info field is 4 bytes long and
> > it is available for DP downstream port.
> >
> > The register defines the pixel rate divided by 8 in MP/s.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 34 ++
> > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > 2 files changed, 43 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 3633002..74a04ce 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> >
> > + /* DP to VGA dongle may define max pixel rate in DPCD */
> > + if (intel_dp->dfp.present &&
> > + intel_dp->dfp.detailed_cap_info &&
> > + (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
> > + (intel_dp->dfp.dot_clk > 0))
> > + max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
>
> What's dfp?
>
> Looks like most of this stuff is not really needed. Just storing a max
> dotclock per downstream port would seem to suffice.
>
> > +
> > if (is_edp(intel_dp) && fixed_mode) {
> > if (mode->hdisplay > fixed_mode->hdisplay)
> > return MODE_PANEL;
> > @@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs
> > intel_dp_enc_funcs = {
> > .destroy = intel_dp_encoder_destroy,
> > };
> >
> > +static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> > +{
> > + uint8_t dfp_info[4];
> > +
> > + intel_dp->dfp.detailed_cap_info =
> > intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE;
> > +
> > + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
> > < 0) {
> > + intel_dp->dfp.present = false;
> > + intel_dp->dfp.detailed_cap_info = false;
> > + return; /* aux transfer failed */
> > + }
> > +
> > + intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
> > +
> > + if (intel_dp->dfp.detailed_cap_info) {
> > + if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> > + intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> > + DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> > intel_dp->dfp.dot_clk);
> > + }
>
> I would suggest putting this sort of stuff into the dp helper. I once
> started to hatch something to deal with these downstream port limits,
> but never finished it. I pushed my WIP stuff (mostly ideas how to parse
> these port caps) to
>
> git://github.com/vsyrjala/linux.git dp_downstream_ports
>
> maybe you can to see if there's anything useful for you there.
Seconded on at least moving the computation into the dp helpers. i915.ko
really should only ask the helpers for the final result, maybe with an
intermediate step to cache the dp aux register stuff. There's already some
structures in the dp helpers to store sink state, we could start using
those (unfortunately they're not agreeing on what the canonical one should
be).
-Daniel
>
> > + }
> > +}
> > +
> > enum irqreturn
> > intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool
> > long_hpd)
> > {
> > @@ -4599,6 +4628,11 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > power_domain = intel_display_port_aux_power_domain(intel_encoder);
> > intel_display_power_get(dev_priv, power_domain);
> >
> > + intel_dp->dfp.present = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 0x1;
> > +
> > + if (intel_dp->dfp.present)
> > + intel_dp_get_dfp(intel_dp);
> > +
> > if (long_hpd) {
> > /* indicate that we need to restart link training */
> > intel_dp->train_set_valid = false;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 21dee3f..9798a59 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -794,6 +794,13 @@ enum link_m_n_set {
> > M2_N2
> > };
> >
> > +struct intel_dp_dfp {
> > + bool present;
> > + int type;
> > + bool detailed_cap_info;
> > + int dot_clk; /* pixel rate for VGA dongles */
> > +};
> > +
> > struct intel_dp {
> > i915_reg_t output_reg;
> > i915_reg_t aux_ch_ctl_reg;
> > @@ -861,6 +868,8 @@ struct intel_dp {
> >
> > bool train_set_valid;
> >
> > + struct intel_dp_dfp dfp;
> > +
> > /* Displayport compliance testing */
> > unsigned long compliance_test_type;
> > unsigned long compli
[Intel-gfx] [PATCH] drm/i915: Discard previous atomic state on resume if connectors change
On Tue, May 03, 2016 at 10:03:40AM -0400, Lyude wrote:
> If an MST device is disconnected while the machine is suspended, the
> number of connectors will change as well after we call
> intel_dp_mst_resume(). This means that any previous atomic state we had
> before suspending is no longer valid, since it'll still be pointing to
> missing connectors. We need to check for this before committing the
> state, otherwise we'll kernel panic on resume whenever if any MST
> display was disconnected before we started resuming:
>
> BUG: unable to handle kernel NULL pointer dereference at 0008
> IP: [] drm_atomic_helper_check_modeset+0x29f/0xb40
> [drm_kms_helper]
> Call Trace:
> [] intel_atomic_check+0x34/0x1180 [i915]
> [] ? mark_held_locks+0x6f/0xa0
> [] ? trace_hardirqs_on_caller+0x129/0x1b0
> [] drm_atomic_check_only+0x192/0x620 [drm]
> [] ? pci_pm_thaw+0x21/0x90
> [] drm_atomic_commit+0x17/0x60 [drm]
> [] intel_display_resume+0xbd/0x160 [i915]
> [] ? pci_pm_thaw+0x90/0x90
> [] i915_drm_resume+0xd8/0x160 [i915]
> [] i915_pm_resume+0x25/0x30 [i915]
> [] pci_pm_resume+0x64/0xa0
> [] dpm_run_callback+0x90/0x190
> [] device_resume+0xd5/0x1f0
> [] async_resume+0x1d/0x50
> [] async_run_entry_fn+0x48/0x150
> [] process_one_work+0x1e9/0x5c0
> [] ? process_one_work+0x166/0x5c0
> [] worker_thread+0x48/0x4e0
> [] ? process_one_work+0x5c0/0x5c0
> [] kthread+0xe4/0x100
> [] ret_from_fork+0x22/0x50
> [] ? kthread_create_on_node+0x200/0x200
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Lyude
This should be addressed by the connector refcounting fixes Dave Airlie
has for 4.7 (not all merged yet though). Can you please retest with those?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6e0d828..252c06c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15945,6 +15945,17 @@ void intel_display_resume(struct drm_device *dev)
> dev_priv->modeset_restore_state = NULL;
>
> /*
> + * With MST, the number of connectors can change between suspend and
> + * resume, which means that the state we want to restore might now be
> + * impossible to use since it'll be pointing to non-existant
> + * connectors.
> + */
> + if (state->num_connector != dev->mode_config.num_connector) {
> + drm_atomic_state_free(state);
> + state = NULL;
> + }
> +
> + /*
>* This is a cludge because with real atomic modeset mode_config.mutex
>* won't be taken. Unfortunately some probed state like
>* audio_codec_enable is still protected by mode_config.mutex, so lock
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH 1/3] drm/i915: Check pixel rate for DP to VGA dongle
On Tue, May 03, 2016 at 04:28:00PM +0200, Daniel Vetter wrote:
> On Tue, May 03, 2016 at 04:23:34PM +0300, Ville Syrjälä wrote:
> > On Tue, May 03, 2016 at 02:46:36PM +0300, Mika Kahola wrote:
> > > Prep work to improve DP branch device handling.
> > >
> > > Filter out a mode that exceeds the max pixel rate setting
> > > for DP to VGA dongle. This is defined in DPCD register 0x81
> > > if detailed cap info i.e. info field is 4 bytes long and
> > > it is available for DP downstream port.
> > >
> > > The register defines the pixel rate divided by 8 in MP/s.
> > >
> > > Signed-off-by: Mika Kahola
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 34 ++
> > > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > > 2 files changed, 43 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 3633002..74a04ce 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -201,6 +201,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > > int max_rate, mode_rate, max_lanes, max_link_clock;
> > > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > >
> > > + /* DP to VGA dongle may define max pixel rate in DPCD */
> > > + if (intel_dp->dfp.present &&
> > > + intel_dp->dfp.detailed_cap_info &&
> > > + (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) &&
> > > + (intel_dp->dfp.dot_clk > 0))
> > > + max_dotclk = min(max_dotclk, intel_dp->dfp.dot_clk);
> >
> > What's dfp?
> >
> > Looks like most of this stuff is not really needed. Just storing a max
> > dotclock per downstream port would seem to suffice.
> >
> > > +
> > > if (is_edp(intel_dp) && fixed_mode) {
> > > if (mode->hdisplay > fixed_mode->hdisplay)
> > > return MODE_PANEL;
> > > @@ -4566,6 +4573,28 @@ static const struct drm_encoder_funcs
> > > intel_dp_enc_funcs = {
> > > .destroy = intel_dp_encoder_destroy,
> > > };
> > >
> > > +static void intel_dp_get_dfp(struct intel_dp *intel_dp)
> > > +{
> > > + uint8_t dfp_info[4];
> > > +
> > > + intel_dp->dfp.detailed_cap_info =
> > > intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > > DP_DETAILED_CAP_INFO_AVAILABLE;
> > > +
> > > + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DOWNSTREAM_PORT_0, dfp_info, 4)
> > > < 0) {
> > > + intel_dp->dfp.present = false;
> > > + intel_dp->dfp.detailed_cap_info = false;
> > > + return; /* aux transfer failed */
> > > + }
> > > +
> > > + intel_dp->dfp.type = dfp_info[0] & DP_DS_PORT_TYPE_MASK;
> > > +
> > > + if (intel_dp->dfp.detailed_cap_info) {
> > > + if (intel_dp->dfp.type & DP_DS_PORT_TYPE_VGA) {
> > > + intel_dp->dfp.dot_clk = dfp_info[1] * 8 * 1000;
> > > + DRM_DEBUG_KMS("max pixel rate for VGA is %d kHz\n",
> > > intel_dp->dfp.dot_clk);
> > > + }
> >
> > I would suggest putting this sort of stuff into the dp helper. I once
> > started to hatch something to deal with these downstream port limits,
> > but never finished it. I pushed my WIP stuff (mostly ideas how to parse
> > these port caps) to
> >
> > git://github.com/vsyrjala/linux.git dp_downstream_ports
> >
> > maybe you can to see if there's anything useful for you there.
>
> Seconded on at least moving the computation into the dp helpers. i915.ko
> really should only ask the helpers for the final result, maybe with an
> intermediate step to cache the dp aux register stuff. There's already some
> structures in the dp helpers to store sink state, we could start using
> those (unfortunately they're not agreeing on what the canonical one should
> be).
Yeah that thing is a bit of mess right now. As usual, I have a branch to
clean some of it up a bit. Mainly aiming to respect the sink HDMI TMDS
clock limits better. But I need to get the DP++ stuff landed before
I continue with that.
--
Ville Syrjälä
Intel OTC
[PATCH 2/3] drm: Add DP port types from DP 1.3 specification
On May 3, 2016 9:49 AM, "Mika Kahola" wrote: > > DP specification 1.3 defines DP downstream ports for > DP++ and wireless devices. Let's add these to port > definitions. > > Signed-off-by: Mika Kahola > --- > include/drm/drm_dp_helper.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 92d9a52..9a15099 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -210,6 +210,8 @@ > # define DP_DS_PORT_TYPE_DVI 2 > # define DP_DS_PORT_TYPE_HDMI 3 > # define DP_DS_PORT_TYPE_NON_EDID 4 > +# define DP_DP_PORT_TYPE_DP_DUALMODE5 DP_DS right? (Like all the others) > +# define DP_DS_PORT_TYPE_WIRELESS 6 > # define DP_DS_PORT_HPD(1 << 3) > /* offset 1 for VGA is maximum megapixels per second / 8 */ > /* offset 2 */ > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part ------ An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/f18b6fe9/attachment.html>
[PATCH] st/omx/enc: fix incorrect reference picture order for B frames
Stacking frames is for driver that's capable to do dual instances
encoding. Such feature is not enabled for B frames currently.
Signed-off-by: Leo Liu
Cc: "11.1 11.2"
---
src/gallium/state_trackers/omx/vid_enc.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/gallium/state_trackers/omx/vid_enc.c
index 5565241..d70439a 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -180,11 +180,6 @@ static OMX_ERRORTYPE vid_enc_Constructor(OMX_COMPONENTTYPE
*comp, OMX_STRING nam
PIPE_VIDEO_ENTRYPOINT_ENCODE,
PIPE_VIDEO_CAP_SUPPORTED))
return OMX_ErrorBadParameter;
- priv->stacked_frames_num = screen->get_video_param(screen,
-PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
-PIPE_VIDEO_ENTRYPOINT_ENCODE,
-PIPE_VIDEO_CAP_STACKED_FRAMES);
-
priv->s_pipe = screen->context_create(screen, priv->screen, 0);
if (!priv->s_pipe)
return OMX_ErrorInsufficientResources;
@@ -699,9 +694,19 @@ static OMX_ERRORTYPE
vid_enc_MessageHandler(OMX_COMPONENTTYPE* comp, internalReq
priv->scale.xWidth :
port->sPortParam.format.video.nFrameWidth;
templat.height = priv->scale_buffer[priv->current_scale_buffer] ?
priv->scale.xHeight :
port->sPortParam.format.video.nFrameHeight;
- templat.max_references = (templat.profile ==
PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) ?
-1 : OMX_VID_ENC_P_PERIOD_DEFAULT;
+ if (templat.profile == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) {
+struct pipe_screen *screen = priv->screen->pscreen;
+templat.max_references = 1;
+priv->stacked_frames_num =
+ screen->get_video_param(screen,
+ PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
+ PIPE_VIDEO_ENTRYPOINT_ENCODE,
+ PIPE_VIDEO_CAP_STACKED_FRAMES);
+ } else {
+templat.max_references = OMX_VID_ENC_P_PERIOD_DEFAULT;
+priv->stacked_frames_num = 1;
+ }
priv->codec = priv->s_pipe->create_video_codec(priv->s_pipe,
&templat);
} else if ((msg->messageParam == OMX_StateLoaded) && (priv->state ==
OMX_StateIdle)) {
--
2.7.4
[PATCH v3 1/4] drm: Add helper for DP++ adaptors
From: Ville Syrjälä Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes Cc: stable at vger.kernel.org Cc: Tore Anderson Cc: Paulo Zanoni Cc: Shashank Sharma Cc: Daniel Vetter Signed-off-by: Ville Syrjälä --- Documentation/DocBook/gpu.tmpl| 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 ++ include/drm/drm_dp_dual_mode_helper.h | 92 4 files changed, 455 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c create mode 100644 include/drm/drm_dp_dual_mode_helper.h diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 1464fb2f3c46..c248124357df 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1623,6 +1623,12 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_dp_helper.c + Display Port Dual Mode Adaptor Helper Functions Reference +!Pdrivers/gpu/drm/drm_dp_dual_mode_helper.c dp dual mode helpers +!Iinclude/drm/drm_dp_dual_mode_helper.h +!Edrivers/gpu/drm/drm_dp_dual_mode_helper.c + + Display Port MST Helper Functions Reference !Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper !Iinclude/drm/drm_dp_mst_helper.h diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1a26b4eb1ce0..29f2ee9b9534 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ - drm_kms_helper_common.o + drm_kms_helper_common.o drm_dp_dual_mode_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c b/drivers/gpu/drm/drm_dp_dual_mode_helper.c new file mode 100644 index ..af68c4cdf817 --- /dev/null +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c @@ -0,0 +1,356 @@ +/* + * Copyright © 2016 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in +
[PATCH] Revert "drm/i915: start adding dp mst audio"
Right now MST audio is causing too many kernel panics to really keep
around in the kernel. On top of that, even after fixing said panics it's
still basically non-functional (at least on all the setups I've tested
it on). Revert until we have a proper solution for this.
This reverts commit 3d52ccf52f2c51f613e42e65be0f06e4e6788093.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/i915_debugfs.c | 16
drivers/gpu/drm/i915/intel_audio.c | 9 +++--
drivers/gpu/drm/i915/intel_ddi.c| 24 +---
drivers/gpu/drm/i915/intel_dp_mst.c | 22 --
drivers/gpu/drm/i915/intel_drv.h| 2 --
5 files changed, 8 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a0f1bd7..e3f4c72 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2872,20 +2872,6 @@ static void intel_dp_info(struct seq_file *m,
intel_panel_info(m, &intel_connector->panel);
}
-static void intel_dp_mst_info(struct seq_file *m,
- struct intel_connector *intel_connector)
-{
- struct intel_encoder *intel_encoder = intel_connector->encoder;
- struct intel_dp_mst_encoder *intel_mst =
- enc_to_mst(&intel_encoder->base);
- struct intel_digital_port *intel_dig_port = intel_mst->primary;
- struct intel_dp *intel_dp = &intel_dig_port->dp;
- bool has_audio = drm_dp_mst_port_has_audio(&intel_dp->mst_mgr,
- intel_connector->port);
-
- seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
-}
-
static void intel_hdmi_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
@@ -2929,8 +2915,6 @@ static void intel_connector_info(struct seq_file *m,
intel_hdmi_info(m, intel_connector);
else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
intel_lvds_info(m, intel_connector);
- else if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
- intel_dp_mst_info(m, intel_connector);
}
seq_printf(m, "\tmodes:\n");
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 30f9214..7d281b4 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -262,8 +262,7 @@ static void hsw_audio_codec_disable(struct intel_encoder
*encoder)
tmp |= AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_UPPER_N_MASK;
tmp &= ~AUD_CONFIG_LOWER_N_MASK;
- if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
- intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
+ if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
@@ -476,8 +475,7 @@ static void ilk_audio_codec_enable(struct drm_connector
*connector,
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
- if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
- intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
+ if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
else
tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
@@ -515,8 +513,7 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
/* ELD Conn_Type */
connector->eld[5] &= ~(3 << 2);
- if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
- intel_pipe_has_type(crtc, INTEL_OUTPUT_DP_MST))
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
connector->eld[5] |= (1 << 2);
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 62de9f4..1c3487a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3098,23 +3098,6 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
}
-bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
-struct intel_crtc *intel_crtc)
-{
- u32 temp;
-
- if (intel_display_power_get_if_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
- temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
-
- intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
-
- if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
- return true;
- }
-
- return false;
-}
-
void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -3175,8 +3158,11 @@ void intel_ddi_get_config(struct intel_encoder *
[Intel-gfx] [PATCH] drm/i915: Discard previous atomic state on resume if connectors change
Yeah airlied said the same thing. This patch is more intended for just 4.6 since
the refcounting patch isn't very likely to get into 4.6.
On Tue, 2016-05-03 at 16:29 +0200, Daniel Vetter wrote:
> On Tue, May 03, 2016 at 10:03:40AM -0400, Lyude wrote:
> >
> > If an MST device is disconnected while the machine is suspended, the
> > number of connectors will change as well after we call
> > intel_dp_mst_resume(). This means that any previous atomic state we had
> > before suspending is no longer valid, since it'll still be pointing to
> > missing connectors. We need to check for this before committing the
> > state, otherwise we'll kernel panic on resume whenever if any MST
> > display was disconnected before we started resuming:
> >
> > BUG: unable to handle kernel NULL pointer dereference at 0008
> > IP: [] drm_atomic_helper_check_modeset+0x29f/0xb40
> > [drm_kms_helper]
> > Call Trace:
> > Â [] intel_atomic_check+0x34/0x1180 [i915]
> > Â [] ? mark_held_locks+0x6f/0xa0
> > Â [] ? trace_hardirqs_on_caller+0x129/0x1b0
> > Â [] drm_atomic_check_only+0x192/0x620 [drm]
> > Â [] ? pci_pm_thaw+0x21/0x90
> > Â [] drm_atomic_commit+0x17/0x60 [drm]
> > Â [] intel_display_resume+0xbd/0x160 [i915]
> > Â [] ? pci_pm_thaw+0x90/0x90
> > Â [] i915_drm_resume+0xd8/0x160 [i915]
> > Â [] i915_pm_resume+0x25/0x30 [i915]
> > Â [] pci_pm_resume+0x64/0xa0
> > Â [] dpm_run_callback+0x90/0x190
> > Â [] device_resume+0xd5/0x1f0
> > Â [] async_resume+0x1d/0x50
> > Â [] async_run_entry_fn+0x48/0x150
> > Â [] process_one_work+0x1e9/0x5c0
> > Â [] ? process_one_work+0x166/0x5c0
> > Â [] worker_thread+0x48/0x4e0
> > Â [] ? process_one_work+0x5c0/0x5c0
> > Â [] kthread+0xe4/0x100
> > Â [] ret_from_fork+0x22/0x50
> > Â [] ? kthread_create_on_node+0x200/0x200
> >
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Lyude
> This should be addressed by the connector refcounting fixes Dave Airlie
> has for 4.7 (not all merged yet though). Can you please retest with those?
> -Daniel
>
> >
> > ---
> > Â drivers/gpu/drm/i915/intel_display.c | 11 +++
> > Â 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 6e0d828..252c06c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15945,6 +15945,17 @@ void intel_display_resume(struct drm_device *dev)
> > Â dev_priv->modeset_restore_state = NULL;
> > Â
> > Â /*
> > + Â * With MST, the number of connectors can change between suspend
> > and
> > + Â * resume, which means that the state we want to restore might now
> > be
> > + Â * impossible to use since it'll be pointing to non-existant
> > + Â * connectors.
> > + Â */
> > + if (state->num_connector != dev->mode_config.num_connector) {
> > + drm_atomic_state_free(state);
> > + state = NULL;
> > + }
> > +
> > + /*
> > Â Â * This is a cludge because with real atomic modeset
> > mode_config.mutex
> > Â Â * won't be taken. Unfortunately some probed state like
> > Â Â * audio_codec_enable is still protected by mode_config.mutex, so
> > lock
> > --Â
> > 2.5.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH] st/omx/enc: fix incorrect reference picture order for B frames
Never mind. Sorry about it.
On 05/03/2016 10:49 AM, Leo Liu wrote:
> Stacking frames is for driver that's capable to do dual instances
> encoding. Such feature is not enabled for B frames currently.
>
> Signed-off-by: Leo Liu
> Cc: "11.1 11.2"
> ---
> src/gallium/state_trackers/omx/vid_enc.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/state_trackers/omx/vid_enc.c
> b/src/gallium/state_trackers/omx/vid_enc.c
> index 5565241..d70439a 100644
> --- a/src/gallium/state_trackers/omx/vid_enc.c
> +++ b/src/gallium/state_trackers/omx/vid_enc.c
> @@ -180,11 +180,6 @@ static OMX_ERRORTYPE
> vid_enc_Constructor(OMX_COMPONENTTYPE *comp, OMX_STRING nam
> PIPE_VIDEO_ENTRYPOINT_ENCODE,
> PIPE_VIDEO_CAP_SUPPORTED))
> return OMX_ErrorBadParameter;
>
> - priv->stacked_frames_num = screen->get_video_param(screen,
> -PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
> -PIPE_VIDEO_ENTRYPOINT_ENCODE,
> -PIPE_VIDEO_CAP_STACKED_FRAMES);
> -
> priv->s_pipe = screen->context_create(screen, priv->screen, 0);
> if (!priv->s_pipe)
> return OMX_ErrorInsufficientResources;
> @@ -699,9 +694,19 @@ static OMX_ERRORTYPE
> vid_enc_MessageHandler(OMX_COMPONENTTYPE* comp, internalReq
> priv->scale.xWidth :
> port->sPortParam.format.video.nFrameWidth;
>templat.height = priv->scale_buffer[priv->current_scale_buffer] ?
> priv->scale.xHeight :
> port->sPortParam.format.video.nFrameHeight;
> - templat.max_references = (templat.profile ==
> PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) ?
> -1 : OMX_VID_ENC_P_PERIOD_DEFAULT;
>
> + if (templat.profile == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) {
> +struct pipe_screen *screen = priv->screen->pscreen;
> +templat.max_references = 1;
> +priv->stacked_frames_num =
> + screen->get_video_param(screen,
> + PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH,
> + PIPE_VIDEO_ENTRYPOINT_ENCODE,
> + PIPE_VIDEO_CAP_STACKED_FRAMES);
> + } else {
> +templat.max_references = OMX_VID_ENC_P_PERIOD_DEFAULT;
> +priv->stacked_frames_num = 1;
> + }
>priv->codec = priv->s_pipe->create_video_codec(priv->s_pipe,
> &templat);
>
> } else if ((msg->messageParam == OMX_StateLoaded) && (priv->state ==
> OMX_StateIdle)) {
[PATCH v2 12/14] MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver
Reviewed-by: Sinclair Yeh On Tue, May 03, 2016 at 12:15:39AM +0100, Emil Velikov wrote: > Thomas is one of the original authors of the driver, with recent > contributions from Sinclair and Brian. > > v2: Add Sinclair as maintainer. Add Sinclair+Thomas's tree, use > Supported as status. > > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Brian Paul > Cc: "VMware Graphics" > Signed-off-by: Emil Velikov > --- > MAINTAINERS | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a7c6a80..cf9b6d2 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3909,6 +3909,17 @@ F: drivers/gpu/drm/etnaviv/ > F: include/uapi/drm/etnaviv_drm.h > F: Documentation/devicetree/bindings/display/etnaviv/ > > +DRM DRIVER FOR VMWARE VIRTUAL GPU > +M: "VMware Graphics" > +M: Sinclair Yeh > +M: Thomas Hellstrom > +L: dri-devel at lists.freedesktop.org > +T: git git://people.freedesktop.org/~syeh/repos_linux > +T: git git://people.freedesktop.org/~thomash/linux > +S: Supported > +F: drivers/gpu/drm/vmwgfx/ > +F: include/uapi/drm/vmwgfx_drm.h > + > DSBR100 USB FM RADIO DRIVER > M: Alexey Klimov > L: linux-media at vger.kernel.org > -- > 2.6.2 >
[PATCH] drm: sun4i: print DMA address correctly
The newly added sun4i drm driver prints a dma address using the %x
format string, which cannot work when dma_addr_t is 64 bit,
and gcc warns about this configuration:
drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer':
drm/sun4i/sun4i_backend.c:193:84: error: format '%x' expects argument of type
'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned
int}' [-Werror=format=]
DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
drm/sun4i/sun4i_backend.c:201:84: error: format '%x' expects argument of type
'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned
int}' [-Werror=format=]
DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr);
This changes the code to use the explicit %pad format string, which
always prints the right length.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index f7a15c1a93bf..3ab560450a82 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -190,7 +190,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend
*backend,
/* Get the physical address of the buffer in memory */
gem = drm_fb_cma_get_gem_obj(fb, 0);
- DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
+ DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
/* Compute the start of the displayed memory */
bpp = drm_format_plane_cpp(fb->pixel_format, 0);
@@ -198,7 +198,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend
*backend,
paddr += (state->src_x >> 16) * bpp;
paddr += (state->src_y >> 16) * fb->pitches[0];
- DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr);
+ DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
/* Write the 32 lower bits of the address (in bits) */
lo_paddr = paddr << 3;
--
2.7.0
[PATCH] drm/amdgpu: set metadata pointer to NULL after freeing.
On Tue, May 3, 2016 at 3:06 AM, Christian König
wrote:
> Am 03.05.2016 um 04:44 schrieb Dave Airlie:
>>
>> From: Dave Airlie
>>
>> Without this there was a double free of the metadata,
>> which ended up freeing the fd table for me here, and taking
>> out the machine more often than not.
>>
>> I reproduced with X.org + modesetting DDX + latest llvm/mesa,
>> also required using dri3.
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Dave Airlie
>
>
> Nice catch, patch is Reviewed-by: Christian König amd.com>
Applied! thanks.
Alex
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index e557fc1..7ecea83 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -541,6 +541,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void
>> *metadata,
>> if (!metadata_size) {
>> if (bo->metadata_size) {
>> kfree(bo->metadata);
>> + bo->metadata = NULL;
>> bo->metadata_size = 0;
>> }
>> return 0;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: support BO freeing without dev->struct_mutex
On Mon, May 2, 2016 at 4:40 AM, Daniel Vetter wrote:
> Finally all the core gem and a lot of drivers are entirely free of
> dev->struct_mutex depencies, and we can start to have an entirely
> lockless unref path.
>
> To make sure that no one who touches the core code accidentally breaks
> existing drivers which still require dev->struct_mutex I've made the
> might_lock check unconditional.
>
> While at it de-inline the ref/unref functions, they've become a bit
> too big.
>
> v2: Make it not leak like a sieve.
>
> v3: Review from Lucas:
> - drop != NULL in pointer checks.
> - fixup copypasted kerneldoc to actually match the functions.
>
> v4:
> Add __drm_gem_object_unreference as a fastpath helper for drivers who
> abolished dev->struct_mutex, requested by Chris.
>
> v5: Fix silly mistake in drm_gem_object_unreference_unlocked caught by
> intel-gfx CI - I checked for gem_free_object instead of
> gem_free_object_unlocked ...
>
> Cc: Chris Wilson
> Cc: Alex Deucher
> Cc: Lucas Stach
> Reviewed-by: Lucas Stach (v3)
> Reviewed-by: Chris Wilson (v4)
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_gem.c | 54
> ++-
> include/drm/drmP.h| 15 ++---
> include/drm/drm_gem.h | 48 +
> 3 files changed, 80 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 25dac31eef37..973eb8805ce0 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -806,12 +806,64 @@ drm_gem_object_free(struct kref *kref)
>
> WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>
> - if (dev->driver->gem_free_object != NULL)
> + if (dev->driver->gem_free_object_unlocked)
> + dev->driver->gem_free_object_unlocked(obj);
> + else if (dev->driver->gem_free_object)
> dev->driver->gem_free_object(obj);
> }
> EXPORT_SYMBOL(drm_gem_object_free);
>
> /**
> + * drm_gem_object_unreference_unlocked - release a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This releases a reference to @obj. Callers must not hold the
> + * dev->struct_mutex lock when calling this function.
> + *
> + * See also __drm_gem_object_unreference().
> + */
> +void
> +drm_gem_object_unreference_unlocked(struct drm_gem_object *obj)
> +{
> + struct drm_device *dev;
> +
> + if (!obj)
> + return;
> +
> + dev = obj->dev;
> + might_lock(&dev->struct_mutex);
> +
> + if (dev->driver->gem_free_object_unlocked)
> + kref_put(&obj->refcount, drm_gem_object_free);
> + else if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
> + &dev->struct_mutex))
> + mutex_unlock(&dev->struct_mutex);
> +}
> +EXPORT_SYMBOL(drm_gem_object_unreference_unlocked);
> +
> +/**
> + * drm_gem_object_unreference - release a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This releases a reference to @obj. Callers must hold the dev->struct_mutex
> + * lock when calling this function, even when the driver doesn't use
> + * dev->struct_mutex for anything.
> + *
> + * For drivers not encumbered with legacy locking use
> + * drm_gem_object_unreference_unlocked() instead.
> + */
> +void
> +drm_gem_object_unreference(struct drm_gem_object *obj)
> +{
> + if (obj) {
> + WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
> +
> + kref_put(&obj->refcount, drm_gem_object_free);
> + }
> +}
> +EXPORT_SYMBOL(drm_gem_object_unreference);
> +
> +/**
> * drm_gem_vm_open - vma->ops->open implementation for GEM
> * @vma: VM area structure
> *
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index c81dd2250fc6..bd7b262d7af0 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -580,12 +580,21 @@ struct drm_driver {
> void (*debugfs_cleanup)(struct drm_minor *minor);
>
> /**
> -* Driver-specific constructor for drm_gem_objects, to set up
> -* obj->driver_private.
> +* @gem_free_object: deconstructor for drm_gem_objects
> *
> -* Returns 0 on success.
> +* This is deprecated and should not be used by new drivers. Use
> +* @gem_free_object_unlocked instead.
> */
> void (*gem_free_object) (struct drm_gem_object *obj);
> +
> + /**
> +* @gem_free_object_unlocked: deconstructor for drm_gem_objects
> +*
> +* This is for drivers which are not encumbered with dev->struct_mutex
> +* legacy locking schemes. Use this hook instead of @gem_free_object.
> +*/
> + void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
> +
> int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
> void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
>
> diff --git a/include/drm/drm_gem.h b/include/drm/dr
[PATCH v3 2/2] dt-bindings: imx: ldb: Add ddc-i2c-bus property
On Fri, Apr 29, 2016 at 09:44:12AM +0200, Philipp Zabel wrote: > Am Donnerstag, den 28.04.2016, 16:48 -0500 schrieb Rob Herring: > > On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote: > > > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID > > > information via I2C interface. > > > > > > Signed-off-by: Akshay Bhat > > > --- > > > > > > v3: > > > Newly added. > > > > > > Documentation/devicetree/bindings/display/imx/ldb.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/Documentation/devicetree/bindings/display/imx/ldb.txt > > > b/Documentation/devicetree/bindings/display/imx/ldb.txt > > > index 0a175d9..a407462 100644 > > > --- a/Documentation/devicetree/bindings/display/imx/ldb.txt > > > +++ b/Documentation/devicetree/bindings/display/imx/ldb.txt > > > @@ -62,6 +62,7 @@ Required properties: > > > display-timings are used instead. > > > > > > Optional properties (required if display-timings are used): > > > > The required part doesn't make sense if you add this, but... > > > > > + - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > > > Really, this should be part of a connector node since i2c goes from the > > i2c controller to a connector and is not part of the display controller. > > If the ddc i2c bus does indeed go through a connector, yes. Would that > warrant a generic "lvds-connector" binding for all those different types > of internal LVDS connectors? Probably an overkill for that case. It could be part of the panel node, but I'm reluctant to define a 3rd way. So this is fine as is. Acked-by: Rob Herring Rob
fsl-dcu not works on latest "drm-next"
Hi Meng,
Please use plain text mails on mailing lists.
On 2016-05-03 02:26, Meng Yi wrote:
> Hi,
>
> I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and
> got some log below. And fsl-dcu not works.
>
> Since "drm-next" merged some branch , use git bisect had some problem ,
>
> so I manually checked out that "fsl-dcu" works at
> d761701c55a99598477f3cb25c03d939a7711e74
Hm, that commit seems rather unrelated... is that what git bisect told
you?
I guess my last pull request could be related to that, so maybe you can
check those two commits manually:
077d67374e ("drm: rcar-du: Fix compilation warning")
vs.
0449eefe2d ("drm/fsl-dcu: increment version and date")
>
> And not works now. some log below:
>
> [drm] Initialized drm 1.1.0 20060810
>
> panel supply power not found, using dummy regulator
>
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>
> [drm] No driver support for vblank timestamp query.
>
> [ cut here ]
>
> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106
> drm_atomic_helper_wait_for_vblanks+0xff/0x124
>
> [CRTC:24] vblank wait timed out
It seems that interrupt do not work properly. Could it be that work
elsewhere caused that issue?
--
Stefan
[PATCH 00/14] Add/update DRM entries in the MAINTAINERS file
On Fri, Apr 22, 2016 at 12:03:48AM +0100, Emil Velikov wrote: > Hi all, > > A bunch of trivial updates for the MAINTAINERS file - corrected files > lists, git repos. The last few patches 'nominate' developers who have > already been the effective maintainers of the specific drivers. > > With the final patch we explicitly list the legacy/UMS drivers, as > Orphan/Obsolete. Who knows we might get a few volunteers to give them > the some love for the first time in ~8 years. > > > Maintainers, > > Can we get a few acks and get all (most) of them in one go or do you > prefer to carry them via your tree ? Makes all sense and Dave said I should just go ahead and pick up the ones who haven't seen an ack yet. All applied to drm-misc, thanks. -Daniel > > > Thanks > Emil > > > Emil Velikov (14): > MAINTAINERS: Remove unneded wildcard for the Radeon/AMDGPU drivers > MAINTAINERS: Remove unneded wildcard for the i915 DRM driver > MAINTAINERS: Update the files list for the Exynos DRM driver > MAINTAINERS: Update the files list for the GMA500 DRM driver > MAINTAINERS: Update the files list for the Rockchip DRM driver > MAINTAINERS: Update the files list for the Etnaviv DRM driver > MAINTAINERS: Update the files list for the Armada DRM driver > MAINTAINERS: Update the files list for the Renesas DRM drivers > MAINTAINERS: List the correct git repo for the Renesas DRM drivers > MAINTAINERS: Add maintainer entry for the Nouveau DRM driver > MAINTAINERS: Add maintainer entry for the MSM DRM driver > MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver > MAINTAINERS: Add a few DRM drivers by Dave Airlie > MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers > > MAINTAINERS | 113 > ++-- > 1 file changed, 102 insertions(+), 11 deletions(-) > > -- > 2.6.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2 1/4] drm: Add helper for DP++ adaptors
On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Add a helper which aids in the identification of DP dual mode > (aka. DP++) adaptors. There are several types of adaptors > specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors > may go as high as 300MHz and they provide a register informing the > source device what the actual limit is. Supposedly also type 1 adaptors > may optionally implement this register. This TMDS clock limit is the > main reason why we need to identify these adaptors. > > Type 1 adaptors provide access to their internal registers and the sink > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > and I2C-over-AUX. A type 2 source device may choose to implement either > of these methods. If a source device implements the I2C-over-AUX > method, then the driver will obviously need specific support for such > adaptors since the port is driven like an HDMI port, but DDC > communication happes over the AUX channel. > > This helper should be enough to identify the adaptor type (some > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > clock limit. Another feature that may be available is control over > the TMDS output buffers on the adaptor, possibly allowing for some > power saving when the TMDS link is down. > > Other user controllable features that may be available in the adaptors > are downstream i2c bus speed control when using i2c-over-aux, and > some control over the CEC pin. I chose not to provide any helper > functions for those since I have no use for them in i915 at this time. > The rest of the registers in the adaptor are mostly just information, > eg. IEEE OUI, hardware and firmware revision, etc. > > v2: Pass adaptor type to helper functions to ease driver implementation > Fix a bunch of typoes (Paulo) > Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know > the type (Paulo) > Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) > Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to > ease future LSPCON enabling > Remove the unused DP_DUAL_MODE_LAST_RESERVED define > > Cc: stable at vger.kernel.org > Cc: Tore Anderson > Cc: Paulo Zanoni > Cc: Shashank Sharma > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 356 > ++ > include/drm/drm_dp_dual_mode_helper.h | 83 +++ > 3 files changed, 440 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1a26b4eb1ce0..29f2ee9b9534 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > - drm_kms_helper_common.o > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > new file mode 100644 > index ..949c0fbeb542 > --- /dev/null > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > @@ -0,0 +1,356 @@ > +/* > + * Copyright © 2016 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/** > + * DOC: D
[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
https://bugs.freedesktop.org/show_bug.cgi?id=94708 --- Comment #12 from Arthur Hrast Essenfelder --- I am also facing a similar issue. I also get very low performance when using the DIS Card and the radeon driver in comparison with the IGD Intel card. # vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. ATTENTION: default value of option vblank_mode overridden by environment. 35719 frames in 5.0 seconds = 7143.730 FPS 35715 frames in 5.0 seconds = 7142.853 FPS 34593 frames in 5.0 seconds = 6910.545 FPS # DRI_PRIME=1 vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 8298 frames in 5.0 seconds = 1659.484 FPS 8313 frames in 5.0 seconds = 1662.389 FPS 8315 frames in 5.0 seconds = 1662.897 FPS I posted this issue a few days ago on ask.fedoraproject.org but so far no luck: https://ask.fedoraproject.org/en/question/87235/low-performance-when-using-the-dis-card/ In any case, I think this is the best place to seek help. Here are more details on my system: Distributor ID:Fedora Description:Fedora release 23 (Twenty Three) # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6730M/6770M/7690M XT] # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Pwr::01:00.0 # glxinfo | grep "OpenGL renderer" OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile # DRI_PRIME=1 glxinfo | grep "OpenGL renderer" OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.7.0) # Xorg -version X.Org X Server 1.18.3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/ed8d8b81/attachment.html>
