[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later
https://bugzilla.kernel.org/show_bug.cgi?id=91861 --- Comment #6 from Mike S. --- I can confirm that the patch https://bugzilla.kernel.org/attachment.cgi?id=163891 to cap ref_div to 7 fixes the problem on my RS780. I did the test on kernel 3.18.3. Note that I also cast the number 7 in the min() to unsigned to avoid a compiler warning. I'd like to run it for a few days to ensure that it is stable. I'd also like to ask a question, please. With this patch, the GPU divider values are now running at: 148500 - 148490, pll dividers - fb: 580.7 ref: 7, post 8 while on 3.14 they were: 14851, pll dividers - fb: 145.2 ref: 2, post: 7 These new values produce a marginally different dot clock rate (the old debug msg displayed the value 10x less than the new one), but the difference is tiny, and probably doesn't make any practical difference. Other than the dot clock, do the values of the 3 dividers affect anything else in the GPU? Are there any advantages or disadvantages running the FB and REF substantially higher (as they are now)? Thank you! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #9 from Woody Suwalski --- Created attachment 112924 --> https://bugs.freedesktop.org/attachment.cgi?id=112924&action=edit dmesg with new crash on a patched kernel With the patch, the original crash is not happening anymore. However Radeon still crashes, now in radeon_driver_postclose_kms. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/a462a155/attachment.html>
drm/nouveau/devinit: move simple pll setting routines to devinit
[ Hm... That's weird. I don't know why this old bug is showing up in my new bugs pile. Oh well, it looks valid. ] Hello Ben Skeggs, The patch 88524bc06926: "drm/nouveau/devinit: move simple pll setting routines to devinit" from Mar 5, 2013, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c:404 nv04_devinit_fini() warn: impossible condition '(priv->owner < 0) => (0-255 < 0)' drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c 402 403 /* unslave crtcs */ 404 if (priv->owner < 0) ^^^ This condition is never true. We could change the -1 in nv04_devinit_ctor() to 0xff or make owner an int. 405 priv->owner = nv_rdvgaowner(priv); 406 nv_wrvgaowner(priv, 0); 407 return 0; 408 } regards, dan carpenter
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #19 from Alex Deucher --- (In reply to Chernovsky Oleg from comment #18) > Hm-m, just tried drm-next-3.20 branch and: > > [ 365.200918] [drm:radeon_uvd_send_upll_ctlreq [radeon]] *ERROR* Timeout > setting UVD clocks! > [ 365.200922] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: failed to > raise UVD clocks (-110). > [ 365.200928] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed > testing IB on ring 5 (-110). > > > Both on cold start and resume from suspend, Pitcairn, Mesa 10.4.3 > Ah yes, the card is factory overclocked (at least box states so) > > It's not very painful for me but if I can help somehow, I'm in I don't think it will make a difference, but you can try limiting the clocks in si_apply_state_adjust_rules(). Take a look at the quirk handling code for how to limit the sclk and mclk. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/f7204742/attachment.html>
[PATCH 1/2] drm/udl: optimize udl_compress_hline16
On Wed, Jan 28, 2015 at 10:15:29AM -0800, Haixia Shi wrote: > The run-length encoding algorithm should compare 16-bit encoded pixel > values instead of comparing raw pixel values. It allows pixels > with similar but different colors to be encoded as repeat pixels, and > thus potentially save USB bandwidth. > > Signed-off-by: Haixia Shi > Reviewed-by: Daniel Kurtz > Tested-by: Haixia Shi This is not based on upstream code, similar but it won't apply. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 2/2] drm/udl: fix excessive prefetch_range
On Wed, Jan 28, 2015 at 10:15:30AM -0800, Haixia Shi wrote: > The prefetch_range amount is already in number of bytes. Multiplying again by > bpp is unnecessary. > > Signed-off-by: Haixia Shi > Reviewed-by: Daniel Kurtz > Tested-by: Haixia Shi Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur
https://bugs.freedesktop.org/show_bug.cgi?id=84648 --- Comment #5 from commiethebeastie at gmail.com --- Confirm this bug with agd5/linux/drm-next-3.20-wip in ETS2 :( -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/2145b6d3/attachment.html>
[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur
https://bugs.freedesktop.org/show_bug.cgi?id=84648 --- Comment #4 from commiethebeastie at gmail.com --- Created attachment 112921 --> https://bugs.freedesktop.org/attachment.cgi?id=112921&action=edit Lags in ETS2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/ab9801d1/attachment.html>
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #18 from Chernovsky Oleg --- (In reply to Alex Deucher from comment #16) > (In reply to Christian König from comment #14) > > (In reply to Ãyvind Saether from comment #13) > > > on 3.18.1, could this be because the card is factory overclocked? > > > > Yes, that's possible. If you activate UVD you must downclock the system > > clock for it to work reliable. Not sure if we have implemented that > > correctly for SI. > > We already handle it. SI has UVD power states which also include validated > sclk and mclk levels that are often different than the performance state. > The driver switches to those states when UVD is used. At driver load time > (when the ring and IB tests are done), the hw is still in the boot state > (which has really low clocks) anyway. Hm-m, just tried drm-next-3.20 branch and: [ 365.200918] [drm:radeon_uvd_send_upll_ctlreq [radeon]] *ERROR* Timeout setting UVD clocks! [ 365.200922] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: failed to raise UVD clocks (-110). [ 365.200928] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on ring 5 (-110). Both on cold start and resume from suspend, Pitcairn, Mesa 10.4.3 Ah yes, the card is factory overclocked (at least box states so) It's not very painful for me but if I can help somehow, I'm in -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/53ce7a79/attachment.html>
[Bug 47201] Absolute modifier does not work with 3-source TGSI instructions
https://bugs.freedesktop.org/show_bug.cgi?id=47201 --- Comment #7 from xbx --- I stumbled upon this bug while testing and debugging a game using the st/nine. And I made a tentative fix that works for me. (caveat: I know nothing about mesa/gallium/graphic cards, but hey..) Here is the proposed patch: https://github.com/xxxbxxx/Mesa-3D/commit/0722d721f8e5ec496bf8ce4591a3b8a5bf87745d or attached. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/2ae300b7/attachment.html>
[Bug 47201] Absolute modifier does not work with 3-source TGSI instructions
https://bugs.freedesktop.org/show_bug.cgi?id=47201 --- Comment #6 from xbx --- Created attachment 112920 --> https://bugs.freedesktop.org/attachment.cgi?id=112920&action=edit r600g patch to fix dropped abs() modifier on op3 alu operations. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/9ab5d931/attachment.html>
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #28 from Gustaw Smolarczyk --- Created attachment 165091 --> https://bugzilla.kernel.org/attachment.cgi?id=165091&action=edit dmesg after "Print refcounts..." patch I have applied this patch on top of original "another approach" one. I think the pauses are now shorter, but more frequent. The contents of dmesg has been attached. I have taken it from /var/log/messages, since the in-kernel dmesg buffer was overwritten many times over. I truncated the messages a bit, since I stopped testing a game at ~80s of uptime. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #8 from Alex Deucher --- Created attachment 112919 --> https://bugs.freedesktop.org/attachment.cgi?id=112919&action=edit possible fix This patch will fix the crash you are seeing on 32 bit. However it won't fix the fact the that acceleration does not seem to initialized properly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/a46f0814/attachment.html>
[PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible
Hi Mauro,
On 28 January 2015 at 18:53, Mauro Carvalho Chehab
wrote:
> Em Wed, 28 Jan 2015 18:24:03 +0530
> Sumit Semwal escreveu:
>
>> +/**
>> + * helper macro for exporters; zeros and fills in most common values
>> + */
>> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
>> + struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
>> +
>
> I suspect that this will let the other fields not initialized.
>
> You likely need to do:
>
> #define DEFINE_DMA_BUF_EXPORT_INFO(a) \
> struct dma_buf_export_info a = {\
> .exp_name = KBUILD_MODNAME; \
> .fields = 0;\
> ...
> }
I suspected the same, but Daniel kindly referred to the C99 standard,
which states:
" If there are fewer initializers in a brace-enclosed list than there
are elements or members
of an aggregate, or fewer characters in a string literal used to
initialize an array of known
size than there are elements in the array, the remainder of the
aggregate shall be
initialized implicitly the same as objects that have static storage duration."
So I think we're well covered there?
>
> Regards,
> Mauro
--
Thanks and regards,
Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org â Open source software for ARM SoCs
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #17 from Alex Deucher --- On older versions of the driver we init dpm after everything else, so the ring and ib tests happen before we even touch the dpm hw so clocks are at their low boot up levels. On newer versions of the driver we init dpm early, but we don't enable the non boot states until the end of the init sequence after the ring and ib tests. >From the log: [5.237881] == power state 0 == [5.237882] ui class: none [5.237883] internal class: boot [5.237884] caps: [5.237885] uvdvclk: 0 dclk: 0 [5.237887] power level 0sclk: 15000 mclk: 15000 vddc: 900 vddci: 950 pcie gen: 2 [5.237887] status: c r b This is the boot state. The clocks are fixed at 150Mhz for both sclk and mclk. [5.237889] == power state 1 == [5.237890] ui class: performance [5.237890] internal class: none [5.237891] caps: [5.237892] uvdvclk: 0 dclk: 0 [5.237893] power level 0sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 [5.237895] power level 1sclk: 45000 mclk: 12 vddc: 900 vddci: 975 pcie gen: 2 [5.237896] power level 2sclk: 10 mclk: 12 vddc: 1219 vddci: 975 pcie gen: 2 [5.237896] status: This is the performance state. The sclk can range from 300 Mhz to 1Ghz and the mclk can range from 150Mhz to 1.2Ghz based on GPU demand. [5.237897] == power state 2 == [5.237898] ui class: none [5.237898] internal class: uvd [5.237899] caps: video [5.237901] uvdvclk: 72000 dclk: 56000 [5.237902] power level 0sclk: 45000 mclk: 12 vddc: 900 vddci: 975 pcie gen: 2 [5.237903] power level 1sclk: 45000 mclk: 12 vddc: 900 vddci: 975 pcie gen: 2 [5.237904] power level 2sclk: 10 mclk: 12 vddc: 1219 vddci: 975 pcie gen: 2 [5.237905] status: This is the UVD state. As you can see there is a floor of 450Mhz on the sclk to maintain the necessary performance level for post processing and presentation. [5.237905] == power state 3 == [5.237906] ui class: none [5.237907] internal class: ulv [5.237908] caps: [5.237909] uvdvclk: 0 dclk: 0 [5.237910] power level 0sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 [5.237911] power level 1sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 [5.237912] power level 2sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 This is the ulv state which is only active when the board is completely idle. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/b0a61de1/attachment.html>
[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)
From: Rob Clark
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.
The proposal is to add a per-plane format modifier. This allows to, if
necessary, use different tiling patters for sub-sampled planes, etc.
The format modifiers are added at the end of the ioctl struct, so for
legacy userspace it will be zero padded.
TODO how best to deal with assignment of modifier token values? The
rough idea was to namespace things with an 8bit vendor-id, and then
beyond that it is treated as an opaque value. But that was a relatively
arbitrary choice. There are cases where same tiling pattern and/or
compression is supported by various different vendors. So we should
standardize to use the vendor-id and value of the first one who
documents the format?
v1: original
v1.5: increase modifier to 64b
v2: Incorporate review comments from the big thread, plus a few more.
- Add a getcap so that userspace doesn't have to jump through hoops.
- Allow modifiers only when a flag is set. That way drivers know when
they're dealing with old userspace and need to fish out e.g. tiling
from other information.
- After rolling out checks for ->modifier to all drivers I've decided
that this is way too fragile and needs an explicit opt-in flag. So
do that instead.
- Add a define (just for documentation really) for the "NONE"
modifier. Imo we don't need to add mask #defines since drivers
really should only do exact matches against values defined with
fourcc_mod_code.
- Drop the Samsung tiling modifier on Rob's request since he's not yet
sure whether that one is accurate.
Cc: Rob Clark
Cc: Tvrtko Ursulin
Cc: Laurent Pinchart
Cc: Daniel Stone
Cc: Ville Syrjälä
Cc: Michel Dänzer
Signed-off-by: Rob Clark (v1.5)
Signed-off-by: Daniel Vetter
--
I've picked this up since we want to push out some fancy new tiling
modes soonish. No defines yet, but Tvrkto is working on the i915 parts
of this.
I think the only part I haven't done from the discussion is exposing a
list of supported modifiers. Not sure that's really useful though
since all this is highly hw specific.
And a note to driver writes: They need to check or the flag and in its
absence make a reasonable choice about the internal layet (e.g. for
i915 consult the tiling mode of the underlying bo).
-Daniel
---
drivers/gpu/drm/drm_crtc.c| 14 +-
drivers/gpu/drm/drm_ioctl.c | 3 +++
include/drm/drm_crtc.h| 3 +++
include/uapi/drm/drm.h| 1 +
include/uapi/drm/drm_fourcc.h | 26 ++
include/uapi/drm/drm_mode.h | 9 +
6 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 419f9d915c78..8090e3d64f67 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3324,6 +3324,12 @@ static int framebuffer_check(const struct
drm_mode_fb_cmd2 *r)
DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
return -EINVAL;
}
+
+ if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
+ DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
+ r->modifier[i], i);
+ return -EINVAL;
+ }
}
return 0;
@@ -3337,7 +3343,7 @@ static struct drm_framebuffer
*add_framebuffer_internal(struct drm_device *dev,
struct drm_framebuffer *fb;
int ret;
- if (r->flags & ~DRM_MODE_FB_INTERLACED) {
+ if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
return ERR_PTR(-EINVAL);
}
@@ -3353,6 +3359,12 @@ static struct drm_framebuffer
*add_framebuffer_internal(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}
+ if (r->flags & DRM_MODE_FB_MODIFIERS &&
+ !dev->mode_config.allow_fb_modifiers) {
+ DRM_DEBUG_KMS("driver does not support fb modifiers\n");
+ return ERR_PTR(-EINVAL);
+ }
+
ret = framebuffer_check(r);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 3785d66721f2..a6d773a61c2d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -321,6 +321,9 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
else
req->value = 64;
break;
+ case DRM_CAP_ADDFB2_MODIFIERS:
+ req->value = dev->mode_config.allow_fb_modifiers;
+ break;
default:
return -EINVAL;
}
diff --git a/incl
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #16 from Alex Deucher --- (In reply to Christian König from comment #14) > (In reply to Ãyvind Saether from comment #13) > > on 3.18.1, could this be because the card is factory overclocked? > > Yes, that's possible. If you activate UVD you must downclock the system > clock for it to work reliable. Not sure if we have implemented that > correctly for SI. We already handle it. SI has UVD power states which also include validated sclk and mclk levels that are often different than the performance state. The driver switches to those states when UVD is used. At driver load time (when the ring and IB tests are done), the hw is still in the boot state (which has really low clocks) anyway. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/91ae11d2/attachment-0001.html>
[PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.
Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().
While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.
Signed-off-by: Sumit Semwal
---
v3: Daniel Thompson caught the C99 warning issue w/ using {0}; using
{.exp_name = xxx} instead.
v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default
drivers/dma-buf/dma-buf.c | 47 +-
drivers/gpu/drm/armada/armada_gem.c| 10 --
drivers/gpu/drm/drm_prime.c| 12 ---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 -
drivers/gpu/drm/tegra/gem.c| 10 --
drivers/gpu/drm/ttm/ttm_object.c | 9 +++--
drivers/gpu/drm/udl/udl_dmabuf.c | 9 -
drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 -
drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 -
drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 -
drivers/staging/android/ion/ion.c | 9 +++--
include/linux/dma-buf.h| 34 +++
14 files changed, 142 insertions(+), 50 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
}
/**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
* Also connect the allocator specific data and ops to the buffer.
* Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
* @exp_name: [in]name of the exporting module - useful for debugging.
* @resv: [in]reservation-object, NULL to allocate default one.
*
+ * All the above info comes from struct dma_buf_export_info.
+ *
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
* ops, or error in allocating struct dma_buf, will return negative error.
*
*/
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags, const char *exp_name,
- struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
{
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
- if (!resv)
+ if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent &dma_buf[1] == dma_buf->resv */
alloc_size += 1;
- if (WARN_ON(!priv || !ops
- || !ops->map_dma_buf
- || !ops->unmap_dma_buf
- || !ops->release
- || !ops->kmap_atomic
- || !ops->kmap
- || !ops->mmap)) {
+ if (WARN_ON(!exp_info->priv
+ || !exp_info->ops
+ || !exp_info->ops->map_dma_buf
+ || !exp_info->ops->unmap_dma_buf
+ || !exp_info->ops->release
+ || !exp_info->ops->kmap_atomic
+ || !exp_info->ops->kmap
+ || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
- dmabuf->priv = priv;
- dmabuf->ops = ops;
- dmabuf->size = size;
- dmabuf->exp_name = exp_name;
+ dmabuf->priv = exp_info->priv;
+ dmabuf->ops = exp_info->ops;
+ dmabuf->size = exp_info->size;
+ dmabuf->exp_name = exp_info->exp_name;
init_waitqueue_head(&dmabuf->poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
- if (!resv) {
- resv = (struct reservation_object *)&dmabuf[1];
- reservation_object_init(resv);
+ if (!exp_info->resv) {
+ exp_info->resv = (struct reservation_object *)&dmabuf[1];
+ reservation_object_init(exp_info->resv);
}
- dmabuf->resv = resv;
+ dmabuf->resv = ex
[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)
On 01/28/2015 05:37 PM, Daniel Vetter wrote: > From: Rob Clark > > In DRM/KMS we are lacking a good way to deal with tiled/compressed > formats. Especially in the case of dmabuf/prime buffer sharing, where > we cannot always rely on under-the-hood flags passed to driver specific > gem-create ioctl to pass around these extra flags. > > The proposal is to add a per-plane format modifier. This allows to, if > necessary, use different tiling patters for sub-sampled planes, etc. > The format modifiers are added at the end of the ioctl struct, so for > legacy userspace it will be zero padded. > > TODO how best to deal with assignment of modifier token values? The > rough idea was to namespace things with an 8bit vendor-id, and then > beyond that it is treated as an opaque value. But that was a relatively > arbitrary choice. There are cases where same tiling pattern and/or > compression is supported by various different vendors. So we should > standardize to use the vendor-id and value of the first one who > documents the format? Maybe: __u64 modifier[4]; __u64 vendor_modifier[4]; ? Regards, Tvrtko
[PATCH v2] dma-buf: cleanup dma_buf_export() to make it easily extensible
On 28 January 2015 at 16:50, Daniel Thompson
wrote:
> On 28/01/15 06:00, Sumit Semwal wrote:
>> +/**
>> + * helper macro for exporters; zeros and fills in most common values
>> + */
>> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
>> + struct dma_buf_export_info a = {0}; \
>> + exp_info.exp_name = KBUILD_MODNAME
>> +
>
> This risks generating C99 warnings unless used with care (and only once
> per function). Shouldn't this be more like:
>
> #define DEFINE_DMA_BUF_EXPORT_INFO(a) \
> struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
>
Ah! My bad; thanks for catching this, Daniel; I'll send out the
updated patch in a minute!
> Daniel.
>
--
Thanks and regards,
Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org â Open source software for ARM SoCs
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #15 from Chernovsky Oleg --- I can help with code here. What should be implemented, roughly? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/50792b78/attachment.html>
[PATCH 03/24] Documentation: DT bindings: add more chip compatible strings for Tegra SOR
Add compatible strings for the SOR IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegra&m=142201349727836&w=2 Signed-off-by: Paul Walmsley Cc: Thierry Reding Cc: "Terje Bergström" Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Stephen Warren Cc: Alexandre Courbot Cc: dri-devel at lists.freedesktop.org Cc: linux-tegra at vger.kernel.org Cc: devicetree at vger.kernel.org Cc: linux-kernel at vger.kernel.org --- .../bindings/gpu/nvidia,tegra20-host1x.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index 4c32ef0b7db8..0e828c00e7e4 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -198,6 +198,7 @@ of the following host1x client modules: Required properties: - compatible: "nvidia,tegra124-sor" +"nvidia,tegra132-sor" (not yet matched in the driver) - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt outputs from the controller. - clocks: Must contain an entry for each entry in clock-names. @@ -223,6 +224,7 @@ of the following host1x client modules: - dpaux: DisplayPort AUX interface - compatible: "nvidia,tegra124-dpaux" +"nvidia,tegra132-dpaux" (not yet matched in the driver) - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt outputs from the controller. - clocks: Must contain an entry for each entry in clock-names.
[PATCH] drm/mst: fix recursive sleep warning on qlock
From: Dave Airlie
With drm-next, we can get a backtrace like below,
this is due to the callback checking the txmsg state taking
the mutex, which can cause a sleep inside a sleep,
Fix this my creating a spinlock protecting the txmsg state
and locking it in appropriate places.
: [ cut here ]
: WARNING: CPU: 3 PID: 252 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
: do not call blocking ops when !TASK_RUNNING; state=2 set at
[] prepare_to_wait_event+0x5d/0x110
: Modules linked in: i915 i2c_algo_bit drm_kms_helper drm e1000e ptp pps_core
i2c_core video
: CPU: 3 PID: 252 Comm: kworker/3:2 Not tainted 3.19.0-rc5+ #18
: Hardware name: LENOVO 20ARS25701/20ARS25701, BIOS GJET72WW (2.22 ) 02/21/2014
: Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
: 81a4027c 88030a763af8 81752699
: 88030a763b48 88030a763b38 810974ca 88030a763b38
: 81a41123 026d 0fa0
: Call Trace:
: [] dump_stack+0x4c/0x65
: [] warn_slowpath_common+0x8a/0xc0
: [] warn_slowpath_fmt+0x46/0x50
: [] ? prepare_to_wait_event+0x5d/0x110
: [] ? prepare_to_wait_event+0x5d/0x110
: [] __might_sleep+0xbd/0xd0
: [] mutex_lock_nested+0x2e/0x3e0
: [] ? prepare_to_wait_event+0x98/0x110
: [] drm_dp_mst_wait_tx_reply+0xa7/0x220 [drm_kms_helper]
: [] ? wait_woken+0xc0/0xc0
: [] drm_dp_send_link_address+0x61/0x240 [drm_kms_helper]
: [] ? process_one_work+0x14f/0x530
: [] drm_dp_check_and_send_link_address+0x8d/0xa0
[drm_kms_helper]
: [] drm_dp_mst_link_probe_work+0x1c/0x20 [drm_kms_helper]
: [] process_one_work+0x1c6/0x530
: [] ? process_one_work+0x14f/0x530
: [] worker_thread+0x6b/0x490
: [] ? rescuer_thread+0x350/0x350
: [] kthread+0x10a/0x120
: [] ? _raw_spin_unlock_irq+0x30/0x50
: [] ? kthread_create_on_node+0x220/0x220
: [] ret_from_fork+0x7c/0xb0
: [] ? kthread_create_on_node+0x220/0x220
: ---[ end trace bb11c9634a7217c6 ]---
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 15 +--
include/drm/drm_dp_mst_helper.h | 4 +++-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9a5b687..07662ae 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -733,10 +733,10 @@ static bool check_txmsg_state(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_sideband_msg_tx *txmsg)
{
bool ret;
- mutex_lock(&mgr->qlock);
+ spin_lock(&mgr->state_lock);
ret = (txmsg->state == DRM_DP_SIDEBAND_TX_RX ||
txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT);
- mutex_unlock(&mgr->qlock);
+ spin_unlock(&mgr->state_lock);
return ret;
}
@@ -750,6 +750,7 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
check_txmsg_state(mgr, txmsg),
(4 * HZ));
mutex_lock(&mstb->mgr->qlock);
+ spin_lock(&mgr->state_lock);
if (ret > 0) {
if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
ret = -EIO;
@@ -773,6 +774,7 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
}
}
out:
+ spin_unlock(&mgr->state_lock);
mutex_unlock(&mgr->qlock);
return ret;
@@ -1318,10 +1320,12 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
memset(&hdr, 0, sizeof(struct drm_dp_sideband_msg_hdr));
+ spin_lock(&mgr->state_lock);
if (txmsg->state == DRM_DP_SIDEBAND_TX_QUEUED) {
txmsg->seqno = -1;
txmsg->state = DRM_DP_SIDEBAND_TX_START_SEND;
}
+ spin_unlock(&mgr->state_lock);
/* make hdr from dst mst - for replies use seqno
otherwise assign one */
@@ -1357,7 +1361,9 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
txmsg->cur_offset += tosend;
if (txmsg->cur_offset == txmsg->cur_len) {
+ spin_lock(&mgr->state_lock);
txmsg->state = DRM_DP_SIDEBAND_TX_SENT;
+ spin_unlock(&mgr->state_lock);
return 1;
}
return 0;
@@ -1386,7 +1392,9 @@ static void process_single_down_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr)
list_del(&txmsg->next);
if (txmsg->seqno != -1)
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
+ spin_lock(&mgr->state_lock);
txmsg->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
+ spin_unlock(&mgr->state_lock);
wake_up(&mgr->tx_waitq);
}
if (list_empty(&mgr->tx_msg_downq)) {
@@ -2083,7 +2091,9 @@ static int drm_dp_mst_handle_down_rep(struct
drm_dp_mst_topology_mgr *mgr)
drm_dp_put_mst_branch_device(mstb
[PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible
Op 28-01-15 om 13:54 schreef Sumit Semwal:
> At present, dma_buf_export() takes a series of parameters, which
> makes it difficult to add any new parameters for exporters, if required.
>
> Make it simpler by moving all these parameters into a struct, and pass
> the struct * as parameter to dma_buf_export().
>
> While at it, unite dma_buf_export_named() with dma_buf_export(), and
> change all callers accordingly.
>
> Signed-off-by: Sumit Semwal
> ---
> v3: Daniel Thompson caught the C99 warning issue w/ using {0}; using
> {.exp_name = xxx} instead.
>
> v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default
>
> drivers/dma-buf/dma-buf.c | 47
> +-
> drivers/gpu/drm/armada/armada_gem.c| 10 --
> drivers/gpu/drm/drm_prime.c| 12 ---
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++--
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 -
> drivers/gpu/drm/tegra/gem.c| 10 --
> drivers/gpu/drm/ttm/ttm_object.c | 9 +++--
> drivers/gpu/drm/udl/udl_dmabuf.c | 9 -
> drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 -
> drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 -
> drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 -
> drivers/staging/android/ion/ion.c | 9 +++--
> include/linux/dma-buf.h| 34 +++
> 14 files changed, 142 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 5be225c2ba98..6d3df3dd9310 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
> }
>
> /**
> - * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
> + * dma_buf_export - Creates a new dma_buf, and associates an anon file
> * with this buffer, so it can be exported.
> * Also connect the allocator specific data and ops to the buffer.
> * Additionally, provide a name string for exporter; useful in debugging.
> @@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
> * @exp_name:[in]name of the exporting module - useful for
> debugging.
> * @resv:[in]reservation-object, NULL to allocate default one.
> *
> + * All the above info comes from struct dma_buf_export_info.
> + *
> * Returns, on success, a newly created dma_buf object, which wraps the
> * supplied private data and operations for dma_buf_ops. On either missing
> * ops, or error in allocating struct dma_buf, will return negative error.
> *
> */
> -struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops
> *ops,
> - size_t size, int flags, const char *exp_name,
> - struct reservation_object *resv)
> +struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
This function should probably take a const struct dma_buf_export_info here..
Rest looks sane.
~Maarten
> {
> struct dma_buf *dmabuf;
> struct file *file;
> size_t alloc_size = sizeof(struct dma_buf);
> - if (!resv)
> + if (!exp_info->resv)
> alloc_size += sizeof(struct reservation_object);
> else
> /* prevent &dma_buf[1] == dma_buf->resv */
> alloc_size += 1;
>
> - if (WARN_ON(!priv || !ops
> - || !ops->map_dma_buf
> - || !ops->unmap_dma_buf
> - || !ops->release
> - || !ops->kmap_atomic
> - || !ops->kmap
> - || !ops->mmap)) {
> + if (WARN_ON(!exp_info->priv
> + || !exp_info->ops
> + || !exp_info->ops->map_dma_buf
> + || !exp_info->ops->unmap_dma_buf
> + || !exp_info->ops->release
> + || !exp_info->ops->kmap_atomic
> + || !exp_info->ops->kmap
> + || !exp_info->ops->mmap)) {
> return ERR_PTR(-EINVAL);
> }
>
> @@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const
> struct dma_buf_ops *ops,
> if (dmabuf == NULL)
> return ERR_PTR(-ENOMEM);
>
> - dmabuf->priv = priv;
> - dmabuf->ops = ops;
> - dmabuf->size = size;
> - dmabuf->exp_name = exp_name;
> + dmabuf->priv = exp_info->priv;
> + dmabuf->ops = exp_info->ops;
> + dmabuf->size = exp_info->size;
> + dmabuf->exp_name = exp_info->exp_name;
> init_waitqueue_head(&dmabuf->poll);
> dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
> dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
>
> - if (!resv) {
> - resv = (struct reservation_ob
[GIT PULL] imx-drm fixes for IPUv3 DC and i.MX5 IPUv3 IC and TVE
Hi Dave, please consider merging these fixes that correct issues in the IPUv3 IPUv3 core and imx-drm TVE encoder code: The following changes since commit 5159571ceb44eba9bf9f9a34ec625386d421de9c: Merge branch 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2015-01-27 09:56:13 +1000) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2015-01-28 for you to fetch changes up to a49e7c0d079610062048a4ed1cff2bb09436127c: gpu: ipu-v3: Fix IC control register offset (2015-01-27 16:28:01 +0100) imx-drm fixes for IPUv3 DC and i.MX5 IPUv3 IC and TVE - Corrected handling of wait_for_completion_timeout return value when disabling IPUv3 DC channels - Fixed error return value propagation in TVE mode_set - Fixed IPUv3 register offsets for IC module on i.MX51 and i.MX53 Fabio Estevam (1): drm: imx: imx-tve: Check and propagate the errors Nicholas Mc Guire (1): gpu: ipu-v3: wait_for_completion_timeout does not return negative status Philipp Zabel (1): gpu: ipu-v3: Fix IC control register offset drivers/gpu/drm/imx/imx-tve.c | 24 drivers/gpu/ipu-v3/ipu-common.c | 4 ++-- drivers/gpu/ipu-v3/ipu-dc.c | 5 +++-- 3 files changed, 21 insertions(+), 12 deletions(-) regards Philipp
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #27 from Maarten Lankhorst --- Created attachment 165071 --> https://bugzilla.kernel.org/attachment.cgi?id=165071&action=edit Print refcounts on sw irq, panic on disabled. Can you test this patch on top of 'another approach', keep the sw_irq_get/put commented? Also enable CONFIG_FENCE_TRACE please. And then print the entire dmesg.. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: msm: add missing dependencies on OF and COMMON_CLK
On Wednesday 28 January 2015 14:48:09 Arnd Bergmann wrote: > The msm gpu drivers depend on both the DT mechanism and the > common clk handling code, if they are not enabled, we get > ... As should be obvious, this one was meant to be [PATCH 5/5], but I messed up the subject line. Arnd
[RFCv3 1/2] device: add dma_params->max_segment_count
Hello,
On 2015-01-27 09:25, Sumit Semwal wrote:
> From: Rob Clark
>
> For devices which have constraints about maximum number of segments in
> an sglist. For example, a device which could only deal with contiguous
> buffers would set max_segment_count to 1.
>
> The initial motivation is for devices sharing buffers via dma-buf,
> to allow the buffer exporter to know the constraints of other
> devices which have attached to the buffer. The dma_mask and fields
> in 'struct device_dma_parameters' tell the exporter everything else
> that is needed, except whether the importer has constraints about
> maximum number of segments.
>
> Signed-off-by: Rob Clark
> [sumits: Minor updates wrt comments]
> Signed-off-by: Sumit Semwal
This feature is definitely needed to start thinking of real buffer
sharing between devices.
Acked-by: Marek Szyprowski
> ---
>
> v3: include Robin Murphy's fix[1] for handling '0' as a value for
> max_segment_count
> v2: minor updates wrt comments on the first version
>
> [1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/
>
> include/linux/device.h | 1 +
> include/linux/dma-mapping.h | 19 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index fb506738f7b7..a32f9b67315c 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -647,6 +647,7 @@ struct device_dma_parameters {
>* sg limitations.
>*/
> unsigned int max_segment_size;
> + unsigned int max_segment_count;/* INT_MAX for unlimited */
> unsigned long segment_boundary_mask;
> };
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index c3007cb4bfa6..d3351a36d5ec 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct
> device *dev,
> return -EIO;
> }
>
> +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
> +
> +static inline unsigned int dma_get_max_seg_count(struct device *dev)
> +{
> + if (dev->dma_parms && dev->dma_parms->max_segment_count)
> + return dev->dma_parms->max_segment_count;
> + return DMA_SEGMENTS_MAX_SEG_COUNT;
> +}
> +
> +static inline int dma_set_max_seg_count(struct device *dev,
> + unsigned int count)
> +{
> + if (dev->dma_parms) {
> + dev->dma_parms->max_segment_count = count;
> + return 0;
> + }
> + return -EIO;
> +}
> +
> static inline unsigned long dma_get_seg_boundary(struct device *dev)
> {
> return dev->dma_parms ?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH] drm: msm: add missing dependencies on OF and COMMON_CLK
The msm gpu drivers depend on both the DT mechanism and the common clk handling code, if they are not enabled, we get a number of build errors: In file included from drivers/gpu/drm/msm/hdmi/hdmi.h:27:0, from drivers/gpu/drm/msm/hdmi/hdmi_bridge.c:18: drivers/gpu/drm/msm/msm_drv.h:45:24: fatal error: mach/board.h: No such file or directory #include ^ drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c:503:2: error: implicit declaration of function 'devm_clk_register' [-Werror=implicit-function-declaration] Signed-off-by: Arnd Bergmann diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 5b2a1ff95d3d..bacbbb70f679 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -3,6 +3,7 @@ config DRM_MSM tristate "MSM DRM" depends on DRM depends on ARCH_QCOM || (ARM && COMPILE_TEST) + depends on OF && COMMON_CLK select REGULATOR select DRM_KMS_HELPER select DRM_PANEL
[PATCH 4/5] drm: sti: add panel dependency
The newly added sti driver requires the drm_panel helpers, and we get a link error if they are not enabled ERROR: "drm_panel_attach" [drivers/gpu/drm/sti/stidvo.ko] undefined! ERROR: "of_drm_find_panel" [drivers/gpu/drm/sti/stidvo.ko] undefined! This adds a 'select' statement as we have for the other drivers. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/sti/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index d6d6b705b8c1..20d5f7787667 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -5,6 +5,7 @@ config DRM_STI select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER + select DRM_PANEL select FW_LOADER_USER_HELPER_FALLBACK help Choose this option to enable DRM on STM stiH41x chipset -- 2.1.0.rc2
[PATCH 3/5] drm: rockchip: add reset controller dependency
When the reset controller subsystem is disabled, this driver fails to build: drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function 'vop_initial': drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1267:2: error: implicit declaration of function 'devm_reset_control_get' [-Werror=implicit-function-declaration] The easiest solution is to add a dependency in Kconfig to avoid that case. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index cb21e3821244..35215f6867d3 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -1,6 +1,7 @@ config DRM_ROCKCHIP tristate "DRM Support for Rockchip" depends on DRM && ROCKCHIP_IOMMU + depends on RESET_CONTROLLER select DRM_KMS_HELPER select DRM_KMS_FB_HELPER select DRM_PANEL -- 2.1.0.rc2
[PATCH 2/5] drm: panel/simple: add backlight dependency
The simple panel code uses the backlight interface to find a device, which fails when backlight is disabled: drivers/built-in.o: In function `panel_simple_platform_probe': :(.text+0xd3c48): undefined reference to `of_find_backlight_by_node' Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/panel/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 84506053a7ca..d84583776d50 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -10,6 +10,7 @@ menu "Display Panels" config DRM_PANEL_SIMPLE tristate "support for simple panels" depends on OF + depends on BACKLIGHT_CLASS_DEVICE help DRM panel driver for dumb panels that need at most a regulator and a GPIO to be powered up. Optionally a backlight can be attached so -- 2.1.0.rc2
[PATCH 1/5] drm: panel/sharp: add backlight dependency
The sharp panel code uses the backlight interface to find a device, which fails when backlight is disabled: drivers/built-in.o: In function `sharp_panel_probe': :(.text+0x5ceac): undefined reference to `of_find_backlight_by_node' Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/panel/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 024e98ef8e4d..84506053a7ca 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -31,6 +31,7 @@ config DRM_PANEL_SHARP_LQ101R1SX01 tristate "Sharp LQ101R1SX01 panel" depends on OF depends on DRM_MIPI_DSI + depends on BACKLIGHT_CLASS_DEVICE help Say Y here if you want to enable support for Sharp LQ101R1SX01 TFT-LCD modules. The panel has a 2560x1600 resolution and uses -- 2.1.0.rc2
[PATCH 0/5] drm: add missing dependencies
I did lots of randconfig tests over time, which resulted in many patches, five of which are for drm. In each of these cases, the Kconfig dependencies are incomplete, which can lead to broken builds, and specifying the complete dependencies solves it. The patches are all independent from one another and solve separate issues. Please apply. Arnd Bergmann (5): drm: panel/sharp: add backlight dependency drm: panel/simple: add backlight dependency drm: rockchip: add reset controller dependency drm: sti: add panel dependency drm: msm: add missing dependencies on OF and COMMON_CLK drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/panel/Kconfig| 2 ++ drivers/gpu/drm/rockchip/Kconfig | 1 + drivers/gpu/drm/sti/Kconfig | 1 + 4 files changed, 5 insertions(+) -- 2.1.0.rc2
[patch] drm/bridge: checking the wrong variable
Hi Dan,
nit: this patch is not really for "drm/bridge".
On Wed, Jan 28, 2015 at 2:43 PM, Dan Carpenter
wrote:
>
> We were supposed to check "fmts" here instead of "formats". I suppose
> it eventually leads to a NULL dereference.
>
> Signed-off-by: Dan Carpenter
>
Otherwise, good catch!
Reviewed-by: Daniel Kurtz
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 98fb640..8ae239f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -783,7 +783,7 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> if (formats && num_formats) {
> fmts = kmemdup(formats, sizeof(*formats) * num_formats,
>GFP_KERNEL);
> - if (!formats)
> + if (!fmts)
> return -ENOMEM;
> }
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: don't init gpuvm if accel is disabled
If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it. Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_kms.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 3cf9c1f..60751c1 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -605,14 +605,14 @@ int radeon_driver_open_kms(struct drm_device *dev, struct
drm_file *file_priv)
return -ENOMEM;
}
- vm = &fpriv->vm;
- r = radeon_vm_init(rdev, vm);
- if (r) {
- kfree(fpriv);
- return r;
- }
-
if (rdev->accel_working) {
+ vm = &fpriv->vm;
+ r = radeon_vm_init(rdev, vm);
+ if (r) {
+ kfree(fpriv);
+ return r;
+ }
+
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (r) {
radeon_vm_fini(rdev, vm);
--
1.8.3.1
[Bug 88758] Low FPS in settings on Dota2
https://bugs.freedesktop.org/show_bug.cgi?id=88758 --- Comment #10 from Michel Dänzer --- (In reply to Lorenzo Bona from comment #8) > git_bisect.log That looks way too short to be the final result. Keep going until git bisect tells you which commit is the first bad one. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/d916942e/attachment.html>
[Bug 88758] Low FPS in settings on Dota2
https://bugs.freedesktop.org/show_bug.cgi?id=88758 --- Comment #9 from Lorenzo Bona --- Another hint, running current drm-fixes-3.19 with radeon.dpm=0 doesn't change anything. My GPU is based on pitcairn microcode. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/102b4432/attachment.html>
imx6 DRI/DRM
On Wed, Jan 28, 2015 at 12:56:06PM +, Ian Molton wrote: > On 28/01/15 12:52, Sascha Hauer wrote: > >Hi Ian, > > > >On Wed, Jan 28, 2015 at 12:08:19PM +, Ian Molton wrote: > >>Hi, > >> > >>Can anyone tell me where best to follow / contribute to *mainline* kernel > >>based imx6 graphics stuff? > >> > >>I'm currently running a 3.19-rc kernel with imx6 drm (fbdev emulation) and > >>it works, but I'm seeing segfaults from Xfbdev. > >> > >>Presumably, theres a proper DRM/DRI X driver to go with the kernel bits? > > > >There is the xf86modesetting driver: > > > >http://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting/ > > > >There's no dedicated i.MX X driver that works with imx-drm. > > Im not currently "up" on how the whole stack works - is this driver generic > to anything using kms? do I still need fbdev? The xf86modesetting driver should work with any kms driver (though it's been some time since I last tested it with imx-drm) You won't need fbdev, but without it the kernel does not activate the display during boot, so it will just stay dark until X starts. > > Is there a good overview of things, particularly wrt. imx6? Not that I know of, at least there's no i.MX specific drm documentation. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
imx6 DRI/DRM
Hi Ian, On Wed, Jan 28, 2015 at 12:08:19PM +, Ian Molton wrote: > Hi, > > Can anyone tell me where best to follow / contribute to *mainline* kernel > based imx6 graphics stuff? > > I'm currently running a 3.19-rc kernel with imx6 drm (fbdev emulation) and it > works, but I'm seeing segfaults from Xfbdev. > > Presumably, theres a proper DRM/DRI X driver to go with the kernel bits? There is the xf86modesetting driver: http://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting/ There's no dedicated i.MX X driver that works with imx-drm. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 1/2] drm/udl: optimize udl_compress_hline16
Sorry about that; I have just re-sent the patches based on upstream code. On Wed, Jan 28, 2015 at 1:12 PM, Chris Wilson wrote: > On Wed, Jan 28, 2015 at 10:15:29AM -0800, Haixia Shi wrote: >> The run-length encoding algorithm should compare 16-bit encoded pixel >> values instead of comparing raw pixel values. It allows pixels >> with similar but different colors to be encoded as repeat pixels, and >> thus potentially save USB bandwidth. >> >> Signed-off-by: Haixia Shi >> Reviewed-by: Daniel Kurtz >> Tested-by: Haixia Shi > > This is not based on upstream code, similar but it won't apply. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)
On Wed, Jan 28, 2015 at 12:37 PM, Daniel Vetter
wrote:
> From: Rob Clark
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats. Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem-create ioctl to pass around these extra flags.
>
> The proposal is to add a per-plane format modifier. This allows to, if
> necessary, use different tiling patters for sub-sampled planes, etc.
> The format modifiers are added at the end of the ioctl struct, so for
> legacy userspace it will be zero padded.
>
> TODO how best to deal with assignment of modifier token values? The
> rough idea was to namespace things with an 8bit vendor-id, and then
> beyond that it is treated as an opaque value. But that was a relatively
> arbitrary choice. There are cases where same tiling pattern and/or
> compression is supported by various different vendors. So we should
> standardize to use the vendor-id and value of the first one who
> documents the format?
iirc, I think we decided that drm_fourcc.h in drm-next is a sufficient
authority for coordinating assignment of modifier token values, so we
could probably drop this TODO. Perhaps it wouldn't hurt to document
somewhere that, as with fourcc/format values, new additions are
expected to come with some description of the format?
>
> v1: original
> v1.5: increase modifier to 64b
>
> v2: Incorporate review comments from the big thread, plus a few more.
>
> - Add a getcap so that userspace doesn't have to jump through hoops.
> - Allow modifiers only when a flag is set. That way drivers know when
> they're dealing with old userspace and need to fish out e.g. tiling
> from other information.
> - After rolling out checks for ->modifier to all drivers I've decided
> that this is way too fragile and needs an explicit opt-in flag. So
> do that instead.
> - Add a define (just for documentation really) for the "NONE"
> modifier. Imo we don't need to add mask #defines since drivers
> really should only do exact matches against values defined with
> fourcc_mod_code.
> - Drop the Samsung tiling modifier on Rob's request since he's not yet
> sure whether that one is accurate.
>
> Cc: Rob Clark
> Cc: Tvrtko Ursulin
> Cc: Laurent Pinchart
> Cc: Daniel Stone
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
> Signed-off-by: Rob Clark (v1.5)
> Signed-off-by: Daniel Vetter
>
you forgot to change subject line to (v2).. but other than that, looks good
Reviewed-by: Rob Clark
> --
>
> I've picked this up since we want to push out some fancy new tiling
> modes soonish. No defines yet, but Tvrkto is working on the i915 parts
> of this.
>
> I think the only part I haven't done from the discussion is exposing a
> list of supported modifiers. Not sure that's really useful though
> since all this is highly hw specific.
>
> And a note to driver writes: They need to check or the flag and in its
> absence make a reasonable choice about the internal layet (e.g. for
> i915 consult the tiling mode of the underlying bo).
> -Daniel
> ---
> drivers/gpu/drm/drm_crtc.c| 14 +-
> drivers/gpu/drm/drm_ioctl.c | 3 +++
> include/drm/drm_crtc.h| 3 +++
> include/uapi/drm/drm.h| 1 +
> include/uapi/drm/drm_fourcc.h | 26 ++
> include/uapi/drm/drm_mode.h | 9 +
> 6 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 419f9d915c78..8090e3d64f67 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3324,6 +3324,12 @@ static int framebuffer_check(const struct
> drm_mode_fb_cmd2 *r)
> DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> r->pitches[i], i);
> return -EINVAL;
> }
> +
> + if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
> + DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
> + r->modifier[i], i);
> + return -EINVAL;
> + }
> }
>
> return 0;
> @@ -3337,7 +3343,7 @@ static struct drm_framebuffer
> *add_framebuffer_internal(struct drm_device *dev,
> struct drm_framebuffer *fb;
> int ret;
>
> - if (r->flags & ~DRM_MODE_FB_INTERLACED) {
> + if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
> DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
> return ERR_PTR(-EINVAL);
> }
> @@ -3353,6 +3359,12 @@ static struct drm_framebuffer
> *add_framebuffer_internal(struct drm_device *dev,
> return ERR_PTR(-EINVAL);
> }
>
> + if (r->flags & DRM_MODE_FB_MODIFIERS &&
> + !dev->mode_config.allow_fb_modifiers) {
> + DRM_DEBUG_KMS("driver does not support fb modifiers\n");
> + retu
[Bug 88758] Low FPS in settings on Dota2
https://bugs.freedesktop.org/show_bug.cgi?id=88758 --- Comment #8 from Lorenzo Bona --- Created attachment 112910 --> https://bugs.freedesktop.org/attachment.cgi?id=112910&action=edit git_bisect.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/44b054b7/attachment.html>
[Bug 88758] Low FPS in settings on Dota2
https://bugs.freedesktop.org/show_bug.cgi?id=88758 --- Comment #7 from Lorenzo Bona --- So, I've attached the result from git bisect log. Looks like the last good commit is ae045e2455429c418a418a3376301a9e5753a0a8 and the first bad commit is 0a44e68ca0a8456ed33c62c99b8c42bebdcbbc8c I'm really sorry, it's the first time I've made a git bisect, so take this with salt. If I've missed something or I can bisect more give me a hint. Hope this will help you. :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/d0ac7a36/attachment.html>
[PATCH 2/2] drm/udl: fix excessive prefetch_range
The prefetch_range amount is already in number of bytes. Multiplying again by
bpp is unnecessary.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Tested-by: Haixia Shi
---
drivers/gpu/drm/udl/udl_transfer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index eadddf9..91e4ae2 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -156,7 +156,7 @@ static void udl_compress_hline16(
min((int)(pixel_end - pixel) / bpp,
(int)(cmd_buffer_end - cmd) / 2))) * bpp;
- prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * bpp);
+ prefetch_range((void *) pixel, cmd_pixel_end - pixel);
pixel_val16 = get_pixel_val16(pixel, bpp);
while (pixel < cmd_pixel_end) {
--
2.2.0.rc0.207.ga3a616c
[PATCH 1/2] drm/udl: optimize udl_compress_hline16
The run-length encoding algorithm should compare 16-bit encoded pixel
values instead of comparing raw pixel values. It allows pixels
with similar but different colors to be encoded as repeat pixels, and
thus potentially save USB bandwidth.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Tested-by: Haixia Shi
---
drivers/gpu/drm/udl/udl_transfer.c | 41 +++---
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index f343db7..eadddf9 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -82,12 +82,14 @@ static inline u16 pixel32_to_be16(const uint32_t pixel)
((pixel >> 8) & 0xf800));
}
-static bool pixel_repeats(const void *pixel, const uint32_t repeat, int bpp)
+static inline u16 get_pixel_val16(const uint8_t *pixel, int bpp)
{
+ u16 pixel_val16 = 0;
if (bpp == 2)
- return *(const uint16_t *)pixel == repeat;
- else
- return *(const uint32_t *)pixel == repeat;
+ pixel_val16 = *(uint16_t *)pixel;
+ else if (bpp == 4)
+ pixel_val16 = pixel32_to_be16p(pixel);
+ return pixel_val16;
}
/*
@@ -134,6 +136,7 @@ static void udl_compress_hline16(
uint8_t *cmd_pixels_count_byte = NULL;
const u8 *raw_pixel_start = NULL;
const u8 *cmd_pixel_start, *cmd_pixel_end = NULL;
+ uint16_t pixel_val16;
prefetchw((void *) cmd); /* pull in one cache line at least */
@@ -154,33 +157,29 @@ static void udl_compress_hline16(
(int)(cmd_buffer_end - cmd) / 2))) * bpp;
prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * bpp);
+ pixel_val16 = get_pixel_val16(pixel, bpp);
while (pixel < cmd_pixel_end) {
- const u8 *const start = pixel;
- u32 repeating_pixel;
-
- if (bpp == 2) {
- repeating_pixel = *(uint16_t *)pixel;
- *(uint16_t *)cmd = cpu_to_be16(repeating_pixel);
- } else {
- repeating_pixel = *(uint32_t *)pixel;
- *(uint16_t *)cmd =
cpu_to_be16(pixel32_to_be16(repeating_pixel));
- }
+ const u8 * const repeating_pixel = pixel;
+ const uint16_t repeating_pixel_val16 = pixel_val16;
+
+ *(uint16_t *)cmd = cpu_to_be16(pixel_val16);
cmd += 2;
pixel += bpp;
- if (unlikely((pixel < cmd_pixel_end) &&
-(pixel_repeats(pixel, repeating_pixel,
bpp {
+ while (pixel < cmd_pixel_end) {
+ pixel_val16 = get_pixel_val16(pixel, bpp);
+ if (pixel_val16 != repeating_pixel_val16)
+ break;
+ pixel += bpp;
+ }
+
+ if (unlikely(pixel > repeating_pixel + bpp)) {
/* go back and fill in raw pixel count */
*raw_pixels_count_byte = (((start -
raw_pixel_start) / bpp) + 1) &
0xFF;
- while ((pixel < cmd_pixel_end) &&
- (pixel_repeats(pixel, repeating_pixel,
bpp))) {
- pixel += bpp;
- }
-
/* immediately after raw data is repeat byte */
*cmd++ = (((pixel - start) / bpp) - 1) & 0xFF;
--
2.2.0.rc0.207.ga3a616c
imx6 DRI/DRM
On 28/01/15 12:52, Sascha Hauer wrote: > Hi Ian, > > On Wed, Jan 28, 2015 at 12:08:19PM +, Ian Molton wrote: >> Hi, >> >> Can anyone tell me where best to follow / contribute to *mainline* kernel >> based imx6 graphics stuff? >> >> I'm currently running a 3.19-rc kernel with imx6 drm (fbdev emulation) and >> it works, but I'm seeing segfaults from Xfbdev. >> >> Presumably, theres a proper DRM/DRI X driver to go with the kernel bits? > > There is the xf86modesetting driver: > > http://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting/ > > There's no dedicated i.MX X driver that works with imx-drm. Im not currently "up" on how the whole stack works - is this driver generic to anything using kms? do I still need fbdev? Is there a good overview of things, particularly wrt. imx6? -Ian
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #26 from Jon Arne Jørgensen --- I've tested, and can confirm that they are needed for the patch to fix the crash. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #25 from Maarten Lankhorst --- Oke, can you test without the calls to sw_irq_get/put? -- You are receiving this mail because: You are watching the assignee of the bug.
imx6 DRI/DRM
Hi, Can anyone tell me where best to follow / contribute to *mainline* kernel based imx6 graphics stuff? I'm currently running a 3.19-rc kernel with imx6 drm (fbdev emulation) and it works, but I'm seeing segfaults from Xfbdev. Presumably, theres a proper DRM/DRI X driver to go with the kernel bits? Where can I find that? Thanks, -Ian
[PATCH v3 03/10] drm/panel: add support for Samsung LTN140AT29 panel
From: Stéphane Marchesin
This panel is used by the Nyan Blaze board and supported by the simple-panel
driver.
Signed-off-by: Stéphane Marchesin
[tomeu.vizoso at collabora.com: add device tree binding document]
Signed-off-by: Tomeu Vizoso
---
.../bindings/panel/samsung,ltn140at29-301.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
2 files changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
b/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
new file mode 100644
index 000..e7f969d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
@@ -0,0 +1,7 @@
+Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
+
+Required properties:
+- compatible: should be "samsung,ltn140at29-301"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 39806c3..2da2285 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -779,6 +779,29 @@ static const struct panel_desc samsung_ltn101nt05 = {
},
};
+static const struct drm_display_mode samsung_ltn140at29_301_mode = {
+ .clock = 76300,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 64,
+ .hsync_end = 1366 + 64 + 48,
+ .htotal = 1366 + 64 + 48 + 128,
+ .vdisplay = 768,
+ .vsync_start = 768 + 2,
+ .vsync_end = 768 + 2 + 5,
+ .vtotal = 768 + 2 + 5 + 17,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc samsung_ltn140at29_301 = {
+ .modes = &samsung_ltn140at29_301_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 320,
+ .height = 187,
+ },
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "auo,b101aw03",
@@ -841,6 +864,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "samsung,ltn101nt05",
.data = &samsung_ltn101nt05,
}, {
+ .compatible = "samsung,ltn140at29-301",
+ .data = &samsung_ltn140at29_301,
+ }, {
/* sentinel */
}
};
--
1.9.3
[PATCH v3 00/10] Improvements to Tegra-based Chromebook support
v3: * Added bindings for the LTN140AT29 panel * Removed the delay in pwrseq, as what was actually needed was to add a dependency on the power supplies of the host * Uses the pinmux for the Blaze as generated by tegra-pinmux-scripts * Uses the pinmux for the Big as in the last patch from Simon Glass Hello, this series adds support for the Tegra-based HP Chromebook 14 (aka nyan blaze), which is very similar to the Acer Chromebook 13 (aka nyan big). Because they both include tegra124-nyan.dtsi, some improvements to Blaze support have also benefitted the Big. I have tested that USB2, the panels, HDMI, the trackpad, Wifi and sound work on both. The DT for the Big includes the pinmux configuration as generated by tegra-pinmux-scripts with Simon's patch at: https://patchwork.ozlabs.org/patch/417779/ These patches are based on top of linux-next 20150128. http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=nyan-v3 Regards, Tomeu Stéphane Marchesin (1): drm/panel: add support for Samsung LTN140AT29 panel Tomeu Vizoso (9): ARM: tegra: Set the sound card model that alsaucm expects ARM: tegra: Move out nyan-generic parts out from the nyan-big DT ARM: tegra: Add DTS for the nyan-blaze board ARM: tegra: Add node for trackpad in Nyan boards ASoC: tegra: Add a control for the headphone switch ASoC: tegra: add sink for the internal mic to tegra_max98090 ARM: tegra: Use pwrseq-simple for the wifi in Nyan ARM: tegra: Use the generated pinmux data ARM: tegra: Set spi-max-frequency property to flash node .../bindings/panel/samsung,ltn140at29-301.txt |7 + .../bindings/sound/nvidia,tegra-audio-max98090.txt |1 + arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/tegra124-nyan-big.dts| 2112 +++- arch/arm/boot/dts/tegra124-nyan-blaze.dts | 1325 arch/arm/boot/dts/tegra124-nyan.dtsi | 692 +++ drivers/gpu/drm/panel/panel-simple.c | 26 + sound/soc/tegra/tegra_max98090.c |3 + 8 files changed, 3206 insertions(+), 961 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt create mode 100644 arch/arm/boot/dts/tegra124-nyan-blaze.dts create mode 100644 arch/arm/boot/dts/tegra124-nyan.dtsi -- 1.9.3
[PATCH] drm/dp: Use large transactions for I2C over AUX
On Wed, 28 Jan 2015, Daniel Vetter wrote:
> On Wed, Jan 28, 2015 at 10:59:06AM +0200, Jani Nikula wrote:
>> On Tue, 27 Jan 2015, Ville Syrjälä
>> wrote:
>> > So I've been experimenting a bit with various dongles here, and sadly I've
>> > not managed to get any one of them to return short reads :(
>> >
>> > I did find one that allows changing the speed of the i2c bus, but even if
>> > I reduce it to 1khz there are no short reads, just a lot more defers. The
>> > dongle in question has OUI 001cf8.
>> >
>> > However the good news is that EDID reads seem to get faster across the
>> > board with 16 byte messages. How much faster depends on the dongle.
>> >
>> > Here are my measurements how long it took to read a single EDID block:
>> > DP->DVI (OUI 001cf8): 40ms -> 35ms
>> > DP->VGA (OUI 0022b9): 45ms -> 38ms
>> > Zotac DP->2xHDMI: 25ms -> 4ms
>> >
>> >
>> > Oh and this is how I mangled my drm_dp_i2c_xfer():
>> > transferred = 0;
>> > while (msgs[i].len > transferred) {
>> >msg.buffer = msgs[i].buf + transferred;
>> >msg.size = min_t(unsigned int, drm_dp_i2c_msg_size,
>> > msgs[i].len - transferred);
>> >err = drm_dp_i2c_do_msg(aux, &msg);
>> >if (err < 0)
>> >break;
>> >WARN_ON(err == 0);
>> >transferred += err;
>> > }
>> >
>> > I made the msg size configurable via a module param just to help me test
>> > this stuff, but I'm thinking we might want to upstream that just to make
>> > it easier to try smaller message sizes if/when people encounter problematic
>> > sinks/dongles.
>>
>> How about just letting that happen first, to see if and how the problems
>> occur? If there's a pattern, maybe we can fall back to 1-byte transfers
>> in those cases (or even add OUI based quirks). I've grown really
>> hesitant about adding new module parameters, they are ABI we can't
>> easily remove/regress once added.
>
> module_param_debug takes care of any such risks imo.
No such thing, maybe you mean module_param_unsafe?
Jani.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v3] drm/dp: Use large transactions for I2C over AUX
On Wed, Jan 28, 2015 at 11:09:21AM +0200, Jani Nikula wrote: > On Tue, 27 Jan 2015, Simon Farnsworth > wrote: > > DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in > > their I2C over AUX implementation. They work fine with Windows, but fail > > with Linux. > > > > It turns out that they cannot keep an I2C transaction open unless the > > previous read was 16 bytes; shorter reads can only be followed by a zero > > byte transfer ending the I2C transaction. > > > > Copy Windows's behaviour, and read 16 bytes at a time. If we get a short > > reply, assume that there's a hardware bottleneck, and shrink our read size > > to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec, > > in the hopes that it'll be closest to what Windows does, as no sink I've > > found actually gives short replies. > > > > Also provide a module parameter for testing smaller transfer sizes, in case > > there are sinks out there that cannot work with Windows. > > > > Signed-off-by: Simon Farnsworth > > --- > > > > v3 changes, after feedback from Ville and more testing of Windows: > > > > * Change the short reply algorithm to match Ville's description of the > >DisplayPort 1.2 spec wording. > > > > * Add a module parameter to set the default transfer size for > >experiments. Requested over IRC by Ville. > > IMO module parameters are ABI we shouldn't add just because we might > need them. Also see my reply in the other thread > http://mid.gmane.org/877fw7s2lh.fsf at intel.com Imo just marking it as _unsafe is good enough to make it clear that it's for debugging only. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/dp: Use large transactions for I2C over AUX
On Wed, Jan 28, 2015 at 11:33:34AM +0200, Jani Nikula wrote:
> On Wed, 28 Jan 2015, Daniel Vetter wrote:
> > On Wed, Jan 28, 2015 at 10:59:06AM +0200, Jani Nikula wrote:
> >> On Tue, 27 Jan 2015, Ville Syrjälä
> >> wrote:
> >> > So I've been experimenting a bit with various dongles here, and sadly
> >> > I've
> >> > not managed to get any one of them to return short reads :(
> >> >
> >> > I did find one that allows changing the speed of the i2c bus, but even if
> >> > I reduce it to 1khz there are no short reads, just a lot more defers. The
> >> > dongle in question has OUI 001cf8.
> >> >
> >> > However the good news is that EDID reads seem to get faster across the
> >> > board with 16 byte messages. How much faster depends on the dongle.
> >> >
> >> > Here are my measurements how long it took to read a single EDID block:
> >> > DP->DVI (OUI 001cf8): 40ms -> 35ms
> >> > DP->VGA (OUI 0022b9): 45ms -> 38ms
> >> > Zotac DP->2xHDMI: 25ms -> 4ms
> >> >
> >> >
> >> > Oh and this is how I mangled my drm_dp_i2c_xfer():
> >> > transferred = 0;
> >> > while (msgs[i].len > transferred) {
> >> > msg.buffer = msgs[i].buf + transferred;
> >> > msg.size = min_t(unsigned int, drm_dp_i2c_msg_size,
> >> > msgs[i].len - transferred);
> >> > err = drm_dp_i2c_do_msg(aux, &msg);
> >> > if (err < 0)
> >> > break;
> >> > WARN_ON(err == 0);
> >> > transferred += err;
> >> > }
> >> >
> >> > I made the msg size configurable via a module param just to help me test
> >> > this stuff, but I'm thinking we might want to upstream that just to make
> >> > it easier to try smaller message sizes if/when people encounter
> >> > problematic
> >> > sinks/dongles.
> >>
> >> How about just letting that happen first, to see if and how the problems
> >> occur? If there's a pattern, maybe we can fall back to 1-byte transfers
> >> in those cases (or even add OUI based quirks). I've grown really
> >> hesitant about adding new module parameters, they are ABI we can't
> >> easily remove/regress once added.
> >
> > module_param_debug takes care of any such risks imo.
>
> No such thing, maybe you mean module_param_unsafe?
Indeed that's what I've meant.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2] dma-buf: cleanup dma_buf_export() to make it easily extensible
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.
Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().
While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.
Signed-off-by: Sumit Semwal
---
v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default
drivers/dma-buf/dma-buf.c | 47 +-
drivers/gpu/drm/armada/armada_gem.c| 10 --
drivers/gpu/drm/drm_prime.c| 12 ---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 -
drivers/gpu/drm/tegra/gem.c| 10 --
drivers/gpu/drm/ttm/ttm_object.c | 9 +++--
drivers/gpu/drm/udl/udl_dmabuf.c | 9 -
drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 -
drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 -
drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 -
drivers/staging/android/ion/ion.c | 9 +++--
include/linux/dma-buf.h| 35 +++
14 files changed, 143 insertions(+), 50 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
}
/**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
* Also connect the allocator specific data and ops to the buffer.
* Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
* @exp_name: [in]name of the exporting module - useful for debugging.
* @resv: [in]reservation-object, NULL to allocate default one.
*
+ * All the above info comes from struct dma_buf_export_info.
+ *
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
* ops, or error in allocating struct dma_buf, will return negative error.
*
*/
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags, const char *exp_name,
- struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
{
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
- if (!resv)
+ if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent &dma_buf[1] == dma_buf->resv */
alloc_size += 1;
- if (WARN_ON(!priv || !ops
- || !ops->map_dma_buf
- || !ops->unmap_dma_buf
- || !ops->release
- || !ops->kmap_atomic
- || !ops->kmap
- || !ops->mmap)) {
+ if (WARN_ON(!exp_info->priv
+ || !exp_info->ops
+ || !exp_info->ops->map_dma_buf
+ || !exp_info->ops->unmap_dma_buf
+ || !exp_info->ops->release
+ || !exp_info->ops->kmap_atomic
+ || !exp_info->ops->kmap
+ || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
- dmabuf->priv = priv;
- dmabuf->ops = ops;
- dmabuf->size = size;
- dmabuf->exp_name = exp_name;
+ dmabuf->priv = exp_info->priv;
+ dmabuf->ops = exp_info->ops;
+ dmabuf->size = exp_info->size;
+ dmabuf->exp_name = exp_info->exp_name;
init_waitqueue_head(&dmabuf->poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
- if (!resv) {
- resv = (struct reservation_object *)&dmabuf[1];
- reservation_object_init(resv);
+ if (!exp_info->resv) {
+ exp_info->resv = (struct reservation_object *)&dmabuf[1];
+ reservation_object_init(exp_info->resv);
}
- dmabuf->resv = resv;
+ dmabuf->resv = exp_info->resv;
- file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
+ fil
[PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible
Em Wed, 28 Jan 2015 18:24:03 +0530
Sumit Semwal escreveu:
> +/**
> + * helper macro for exporters; zeros and fills in most common values
> + */
> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
> + struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
> +
I suspect that this will let the other fields not initialized.
You likely need to do:
#define DEFINE_DMA_BUF_EXPORT_INFO(a) \
struct dma_buf_export_info a = {\
.exp_name = KBUILD_MODNAME; \
.fields = 0;\
...
}
Regards,
Mauro
[PATCH v2] dma-buf: cleanup dma_buf_export() to make it easily extensible
On 28/01/15 06:00, Sumit Semwal wrote:
> At present, dma_buf_export() takes a series of parameters, which
> makes it difficult to add any new parameters for exporters, if required.
>
> Make it simpler by moving all these parameters into a struct, and pass
> the struct * as parameter to dma_buf_export().
>
> While at it, unite dma_buf_export_named() with dma_buf_export(), and
> change all callers accordingly.
>
> Signed-off-by: Sumit Semwal
> ---
> v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default
>
> drivers/dma-buf/dma-buf.c | 47
> +-
> drivers/gpu/drm/armada/armada_gem.c| 10 --
> drivers/gpu/drm/drm_prime.c| 12 ---
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++--
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 -
> drivers/gpu/drm/tegra/gem.c| 10 --
> drivers/gpu/drm/ttm/ttm_object.c | 9 +++--
> drivers/gpu/drm/udl/udl_dmabuf.c | 9 -
> drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 -
> drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 -
> drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 -
> drivers/staging/android/ion/ion.c | 9 +++--
> include/linux/dma-buf.h| 35 +++
> 14 files changed, 143 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 5be225c2ba98..6d3df3dd9310 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
> }
>
> /**
> - * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
> + * dma_buf_export - Creates a new dma_buf, and associates an anon file
> * with this buffer, so it can be exported.
> * Also connect the allocator specific data and ops to the buffer.
> * Additionally, provide a name string for exporter; useful in debugging.
> @@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
> * @exp_name:[in]name of the exporting module - useful for
> debugging.
> * @resv:[in]reservation-object, NULL to allocate default one.
> *
> + * All the above info comes from struct dma_buf_export_info.
> + *
> * Returns, on success, a newly created dma_buf object, which wraps the
> * supplied private data and operations for dma_buf_ops. On either missing
> * ops, or error in allocating struct dma_buf, will return negative error.
> *
> */
> -struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops
> *ops,
> - size_t size, int flags, const char *exp_name,
> - struct reservation_object *resv)
> +struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
> {
> struct dma_buf *dmabuf;
> struct file *file;
> size_t alloc_size = sizeof(struct dma_buf);
> - if (!resv)
> + if (!exp_info->resv)
> alloc_size += sizeof(struct reservation_object);
> else
> /* prevent &dma_buf[1] == dma_buf->resv */
> alloc_size += 1;
>
> - if (WARN_ON(!priv || !ops
> - || !ops->map_dma_buf
> - || !ops->unmap_dma_buf
> - || !ops->release
> - || !ops->kmap_atomic
> - || !ops->kmap
> - || !ops->mmap)) {
> + if (WARN_ON(!exp_info->priv
> + || !exp_info->ops
> + || !exp_info->ops->map_dma_buf
> + || !exp_info->ops->unmap_dma_buf
> + || !exp_info->ops->release
> + || !exp_info->ops->kmap_atomic
> + || !exp_info->ops->kmap
> + || !exp_info->ops->mmap)) {
> return ERR_PTR(-EINVAL);
> }
>
> @@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const
> struct dma_buf_ops *ops,
> if (dmabuf == NULL)
> return ERR_PTR(-ENOMEM);
>
> - dmabuf->priv = priv;
> - dmabuf->ops = ops;
> - dmabuf->size = size;
> - dmabuf->exp_name = exp_name;
> + dmabuf->priv = exp_info->priv;
> + dmabuf->ops = exp_info->ops;
> + dmabuf->size = exp_info->size;
> + dmabuf->exp_name = exp_info->exp_name;
> init_waitqueue_head(&dmabuf->poll);
> dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
> dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
>
> - if (!resv) {
> - resv = (struct reservation_object *)&dmabuf[1];
> - reservation_object_init(resv);
> + if (!exp_info->resv) {
> + exp_info->resv = (struct reservation_object *)&dmabuf[1];
> + reservation_object_init(e
[PATCH v3] drm/dp: Use large transactions for I2C over AUX
On Tue, 27 Jan 2015, Simon Farnsworth wrote:
> DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> their I2C over AUX implementation. They work fine with Windows, but fail
> with Linux.
>
> It turns out that they cannot keep an I2C transaction open unless the
> previous read was 16 bytes; shorter reads can only be followed by a zero
> byte transfer ending the I2C transaction.
>
> Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
> reply, assume that there's a hardware bottleneck, and shrink our read size
> to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
> in the hopes that it'll be closest to what Windows does, as no sink I've
> found actually gives short replies.
>
> Also provide a module parameter for testing smaller transfer sizes, in case
> there are sinks out there that cannot work with Windows.
>
> Signed-off-by: Simon Farnsworth
> ---
>
> v3 changes, after feedback from Ville and more testing of Windows:
>
> * Change the short reply algorithm to match Ville's description of the
>DisplayPort 1.2 spec wording.
>
> * Add a module parameter to set the default transfer size for
>experiments. Requested over IRC by Ville.
IMO module parameters are ABI we shouldn't add just because we might
need them. Also see my reply in the other thread
http://mid.gmane.org/877fw7s2lh.fsf at intel.com
BR,
Jani.
>
> No-one's been able to find a device that does short replies, but experiments
> show that bigger reads are faster on most devices. Ville got:
>
> DP->DVI (OUI 001cf8): 40ms -> 35ms
> DP->VGA (OUI 0022b9): 45ms -> 38ms
> Zotac DP->2xHDMI: 25ms -> 4ms
>
> v2 changes, after feedback from Thierry and Ville:
>
> * Handle short replies. I've decided (arbitrarily) that a short reply
>results in us dropping back to the newly chosen size for the rest of this
>I2C transaction. Thus, given an attempt to read the first 16 bytes of
>EDID, and a sink that only does 4 bytes of buffering, we will see the
>following AUX transfers for the EDID read (after address is set):
>
>
>Read 16 bytes from I2C over AUX.
>Reply with 4 bytes
>Read 4 bytes
>Reply with 4 bytes
>Read 4 bytes
>Reply with 4 bytes
>Read 4 bytes
>Reply with 4 bytes
>
>
> Note that I've not looked at MST support - I have neither the DP 1.2 spec
> nor any MST branch devices, so I can't test anything I write or check it
> against a spec. It looks from the code, however, as if MST has the branch
> device do the split from a big request into small transactions.
>
> drivers/gpu/drm/drm_dp_helper.c | 91
> -
> include/drm/drm_dp_helper.h | 5 +++
> 2 files changed, 77 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 79968e3..3db116c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -396,11 +396,13 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter
> *adapter)
> * retrying the transaction as appropriate. It is assumed that the
> * aux->transfer function does not modify anything in the msg other than the
> * reply field.
> + *
> + * Returns bytes transferred on success, or a negative error code on failure.
> */
> static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> *msg)
> {
> unsigned int retry;
> - int err;
> + int ret;
>
> /*
>* DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device
> @@ -409,14 +411,14 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
>*/
> for (retry = 0; retry < 7; retry++) {
> mutex_lock(&aux->hw_mutex);
> - err = aux->transfer(aux, msg);
> + ret = aux->transfer(aux, msg);
> mutex_unlock(&aux->hw_mutex);
> - if (err < 0) {
> - if (err == -EBUSY)
> + if (ret < 0) {
> + if (ret == -EBUSY)
> continue;
>
> - DRM_DEBUG_KMS("transaction failed: %d\n", err);
> - return err;
> + DRM_DEBUG_KMS("transaction failed: %d\n", ret);
> + return ret;
> }
>
>
> @@ -457,9 +459,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
>* Both native ACK and I2C ACK replies received. We
>* can assume the transfer was successful.
>*/
> - if (err < msg->size)
> - return -EPROTO;
> - return 0;
> + return ret;
>
> case DP_AUX_I2C_REPLY_NACK:
> DRM_DEBUG_KMS("I2C nack\n");
> @@ -482,14 +482,67 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp
[PATCH] drm/dp: Use large transactions for I2C over AUX
On Tue, 27 Jan 2015, Ville Syrjälä wrote:
> So I've been experimenting a bit with various dongles here, and sadly I've
> not managed to get any one of them to return short reads :(
>
> I did find one that allows changing the speed of the i2c bus, but even if
> I reduce it to 1khz there are no short reads, just a lot more defers. The
> dongle in question has OUI 001cf8.
>
> However the good news is that EDID reads seem to get faster across the
> board with 16 byte messages. How much faster depends on the dongle.
>
> Here are my measurements how long it took to read a single EDID block:
> DP->DVI (OUI 001cf8):40ms -> 35ms
> DP->VGA (OUI 0022b9):45ms -> 38ms
> Zotac DP->2xHDMI:25ms -> 4ms
>
>
> Oh and this is how I mangled my drm_dp_i2c_xfer():
> transferred = 0;
> while (msgs[i].len > transferred) {
> msg.buffer = msgs[i].buf + transferred;
> msg.size = min_t(unsigned int, drm_dp_i2c_msg_size,
>msgs[i].len - transferred);
> err = drm_dp_i2c_do_msg(aux, &msg);
> if (err < 0)
> break;
> WARN_ON(err == 0);
> transferred += err;
> }
>
> I made the msg size configurable via a module param just to help me test
> this stuff, but I'm thinking we might want to upstream that just to make
> it easier to try smaller message sizes if/when people encounter problematic
> sinks/dongles.
How about just letting that happen first, to see if and how the problems
occur? If there's a pattern, maybe we can fall back to 1-byte transfers
in those cases (or even add OUI based quirks). I've grown really
hesitant about adding new module parameters, they are ABI we can't
easily remove/regress once added.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/dp: Use large transactions for I2C over AUX
On Wednesday 28 January 2015 11:33:34 Jani Nikula wrote: > On Wed, 28 Jan 2015, Daniel Vetter wrote: > > On Wed, Jan 28, 2015 at 10:59:06AM +0200, Jani Nikula wrote: > >> On Tue, 27 Jan 2015, Ville Syrjälä > >> wrote: --snip-- > >> > I made the msg size configurable via a module param just to help me test > >> > this stuff, but I'm thinking we might want to upstream that just to make > >> > it easier to try smaller message sizes if/when people encounter > >> > problematic > >> > sinks/dongles. > >> > >> How about just letting that happen first, to see if and how the problems > >> occur? If there's a pattern, maybe we can fall back to 1-byte transfers > >> in those cases (or even add OUI based quirks). I've grown really > >> hesitant about adding new module parameters, they are ABI we can't > >> easily remove/regress once added. > > > > module_param_debug takes care of any such risks imo. > > No such thing, maybe you mean module_param_unsafe? > > Jani. Changing to module_param_unsafe is trivial. That would taint the kernel if you play with it, hopefully making it clear that this is not permanent ABI. I'm now seeing the Bizlink adapters fail after about 45 seconds of isochronous link up, so it'll be a few days before I do a v4 of this patch, as I need Datapath's assistance analysing the differences in behaviour between us and Windows). -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/336fc10c/attachment.sig>
[Bug 88408] Black screen in Nuclear Dawn
https://bugs.freedesktop.org/show_bug.cgi?id=88408 --- Comment #21 from Iwo --- (In reply to commiethebeastie from comment #20) > Created attachment 112885 [details] > llvm-3.6-rc1 Hi guys, thanks for quick response and testing of llvm 3.6. I've ran into problems on Arch Linux with combining llvm 3.6 with mesa-git, unfortunately i don't have a luxury of time these days. I will test llvm 3.6 when it lands on stable tree and it will be in february. Maybe someone else will test it to make sure that is llvm's 3.5 bug and close bug report. I will add my observation of llvm 3.6 behavior in lately february. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/6466d8a5/attachment-0001.html>
[Bug 88758] Low FPS in settings on Dota2
https://bugs.freedesktop.org/show_bug.cgi?id=88758 --- Comment #6 from Lorenzo Bona --- (In reply to Michel Dänzer from comment #5) > (In reply to Lorenzo Bona from comment #4) > > So, could be a kernel regression or a dumb kernel configuration? > > Have you changed the kernel configuration compared to before the problem > started? If not, it's probably a kernel regression, can you bisect? Ok. First impression, I've done some tests. I've used my 3.19-rc5 configuration, and I've rebuilded from drm-fixes-3.16 to drm-fixes-3.19. It looks like the issue is between drm-fixes-3.16 and drm-fixes-3.17. In 3.16 I get about 70 (or more)FPS in settings/menus, and 60FPS in game. After, from 3.17 on, I get about 4 (or less) FPS in settings/menus, and 30FPS in game. I'll try to dig more. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/993e1411/attachment.html>
[PATCH 2/2] drm/udl: fix excessive prefetch_range
The prefetch_range amount is already in number of bytes. Multiplying again by
bpp is unnecessary.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Tested-by: Haixia Shi
---
drivers/gpu/drm/udl/udl_transfer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index eadddf9..91e4ae2 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -156,7 +156,7 @@ static void udl_compress_hline16(
min((int)(pixel_end - pixel) / bpp,
(int)(cmd_buffer_end - cmd) / 2))) * bpp;
- prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * bpp);
+ prefetch_range((void *) pixel, cmd_pixel_end - pixel);
pixel_val16 = get_pixel_val16(pixel, bpp);
while (pixel < cmd_pixel_end) {
--
2.2.0.rc0.207.ga3a616c
[PATCH 1/2] drm/udl: optimize udl_compress_hline16
The run-length encoding algorithm should compare 16-bit encoded pixel
values instead of comparing raw pixel values. It allows pixels
with similar but different colors to be encoded as repeat pixels, and
thus potentially save USB bandwidth.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Tested-by: Haixia Shi
---
drivers/gpu/drm/udl/udl_transfer.c | 41 +++---
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_transfer.c
b/drivers/gpu/drm/udl/udl_transfer.c
index f343db7..eadddf9 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -82,12 +82,14 @@ static inline u16 pixel32_to_be16(const uint32_t pixel)
((pixel >> 8) & 0xf800));
}
-static bool pixel_repeats(const void *pixel, const uint32_t repeat, int bpp)
+static inline u16 get_pixel_val16(const uint8_t *pixel, int bpp)
{
+ u16 pixel_val16 = 0;
if (bpp == 2)
- return *(const uint16_t *)pixel == repeat;
- else
- return *(const uint32_t *)pixel == repeat;
+ pixel_val16 = *(uint16_t *)pixel;
+ else if (bpp == 4)
+ pixel_val16 = pixel32_to_be16p(pixel);
+ return pixel_val16;
}
/*
@@ -134,6 +136,7 @@ static void udl_compress_hline16(
uint8_t *cmd_pixels_count_byte = NULL;
const u8 *raw_pixel_start = NULL;
const u8 *cmd_pixel_start, *cmd_pixel_end = NULL;
+ uint16_t pixel_val16;
prefetchw((void *) cmd); /* pull in one cache line at least */
@@ -154,33 +157,29 @@ static void udl_compress_hline16(
(int)(cmd_buffer_end - cmd) / 2))) * bpp;
prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * bpp);
+ pixel_val16 = get_pixel_val16(pixel, bpp);
while (pixel < cmd_pixel_end) {
- const u8 *const start = pixel;
- u32 repeating_pixel;
-
- if (bpp == 2) {
- repeating_pixel = *(uint16_t *)pixel;
- *(uint16_t *)cmd = cpu_to_be16(repeating_pixel);
- } else {
- repeating_pixel = *(uint32_t *)pixel;
- *(uint16_t *)cmd =
cpu_to_be16(pixel32_to_be16(repeating_pixel));
- }
+ const u8 * const repeating_pixel = pixel;
+ const uint16_t repeating_pixel_val16 = pixel_val16;
+
+ *(uint16_t *)cmd = cpu_to_be16(pixel_val16);
cmd += 2;
pixel += bpp;
- if (unlikely((pixel < cmd_pixel_end) &&
-(pixel_repeats(pixel, repeating_pixel,
bpp {
+ while (pixel < cmd_pixel_end) {
+ pixel_val16 = get_pixel_val16(pixel, bpp);
+ if (pixel_val16 != repeating_pixel_val16)
+ break;
+ pixel += bpp;
+ }
+
+ if (unlikely(pixel > repeating_pixel + bpp)) {
/* go back and fill in raw pixel count */
*raw_pixels_count_byte = (((start -
raw_pixel_start) / bpp) + 1) &
0xFF;
- while ((pixel < cmd_pixel_end) &&
- (pixel_repeats(pixel, repeating_pixel,
bpp))) {
- pixel += bpp;
- }
-
/* immediately after raw data is repeat byte */
*cmd++ = (((pixel - start) / bpp) - 1) & 0xFF;
--
2.2.0.rc0.207.ga3a616c
[PATCH] drm/dp: Use large transactions for I2C over AUX
On Wed, Jan 28, 2015 at 10:59:06AM +0200, Jani Nikula wrote:
> On Tue, 27 Jan 2015, Ville Syrjälä wrote:
> > So I've been experimenting a bit with various dongles here, and sadly I've
> > not managed to get any one of them to return short reads :(
> >
> > I did find one that allows changing the speed of the i2c bus, but even if
> > I reduce it to 1khz there are no short reads, just a lot more defers. The
> > dongle in question has OUI 001cf8.
> >
> > However the good news is that EDID reads seem to get faster across the
> > board with 16 byte messages. How much faster depends on the dongle.
> >
> > Here are my measurements how long it took to read a single EDID block:
> > DP->DVI (OUI 001cf8): 40ms -> 35ms
> > DP->VGA (OUI 0022b9): 45ms -> 38ms
> > Zotac DP->2xHDMI: 25ms -> 4ms
> >
> >
> > Oh and this is how I mangled my drm_dp_i2c_xfer():
> > transferred = 0;
> > while (msgs[i].len > transferred) {
> > msg.buffer = msgs[i].buf + transferred;
> > msg.size = min_t(unsigned int, drm_dp_i2c_msg_size,
> > msgs[i].len - transferred);
> > err = drm_dp_i2c_do_msg(aux, &msg);
> > if (err < 0)
> > break;
> > WARN_ON(err == 0);
> > transferred += err;
> > }
> >
> > I made the msg size configurable via a module param just to help me test
> > this stuff, but I'm thinking we might want to upstream that just to make
> > it easier to try smaller message sizes if/when people encounter problematic
> > sinks/dongles.
>
> How about just letting that happen first, to see if and how the problems
> occur? If there's a pattern, maybe we can fall back to 1-byte transfers
> in those cases (or even add OUI based quirks). I've grown really
> hesitant about adding new module parameters, they are ABI we can't
> easily remove/regress once added.
module_param_debug takes care of any such risks imo.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[GIT PULL] drm/panel: Changes for v3.20-rc1
Hi Dave,
The following changes since commit 21773f16f2cb3c056051c679da542f0b494252e2:
Merge tag 'topic/atomic-core-2015-01-27' of
git://anongit.freedesktop.org/drm-intel into drm-next (2015-01-28 09:34:27
+1000)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-3.20-rc1
for you to fetch changes up to b5217bf4692218d202d3d2cd772864fa1e10be4d:
drm/bridge: dw-hdmi: Adapt to bridge API change (2015-01-28 10:01:30 +0100)
This one is essentially the previous one, but rebased on drm-next and a
couple of fixups for the drm_bridge breakage. And one more fixup for the
dw-hdmi bridge that was posted earlier today.
Thanks,
Thierry
drm/panel: Changes for v3.20-rc1
This contains the long-awaited drm_bridge series that makes Chromebooks
work for people. I had thought this would've been perfect by now, but
then I go and build test it and the first thing it does is yell about a
recursive dependency. I fixed that up because I was feeling bad for not
getting around to look at this earlier.
Biseds that there is new support for two more panels, a couple of fixup
patches to the Sharp LQ101R1SX01 dual-channel DSI panel driver and a
potential NULL pointer dereference fix.
Ajay Kumar (11):
drm/bridge: ptn3460: Few trivial cleanups
drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
drm/bridge: make bridge registration independent of drm flow
drm/bridge: ptn3460: Convert to I2C driver model
drm/exynos: dp: support drm_bridge
drm/bridge: ptn3460: support drm_panel
drm/bridge: ptn3460: probe connector at the end of bridge attach
drm/bridge: ptn3460: use gpiod interface
Documentation: drm: bridge: move to video/bridge
Documentation: devicetree: Add vendor prefix for parade
Documentation: bridge: Add documentation for ps8622 DT properties
Dan Carpenter (1):
drm: Check the right variable when setting formats
Dave Airlie (1):
drm/sti: fixup for bridge interface
Fabio Estevam (2):
drm/bridge: dw-hdmi: Fix return error path
drm/bridge: dw-hdmi: Adapt to bridge API change
Philipp Zabel (4):
of: Add vendor prefix for Giantplus Technology Co., Ltd.
drm/panel: simple: Add support for Giantplus GPG482739QS5
of: Add vendor prefix for Shanghai AVIC Optoelectronics Co., Ltd.
drm/panel: simple: Add AVIC TM070DDH03 panel support
Thierry Reding (4):
drm/mipi-dsi: Avoid potential NULL pointer dereference
drm/panel: sharp: lq101r1sx01: Add delay after display on
drm/panel: sharp: lq101r1sx01: Respect power timings
drm/panel: sharp: lq101r1sx01: Remove unneeded include
.../devicetree/bindings/panel/avic,tm070ddh03.txt | 7 +
.../bindings/panel/giantplus,gpg482739qs5.txt | 7 +
.../devicetree/bindings/vendor-prefixes.txt| 3 +
.../devicetree/bindings/video/bridge/ps8622.txt| 31 +++
.../bindings/{drm => video}/bridge/ptn3460.txt | 16 +-
.../devicetree/bindings/video/exynos_dp.txt| 12 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/bridge/Kconfig | 13 +-
drivers/gpu/drm/bridge/dw_hdmi.c | 13 +-
drivers/gpu/drm/bridge/ptn3460.c | 310 +
drivers/gpu/drm/drm_bridge.c | 91 ++
drivers/gpu/drm/drm_crtc.c | 72 +
drivers/gpu/drm/drm_mipi_dsi.c | 6 +-
drivers/gpu/drm/exynos/exynos_dp_core.c| 53 ++--
drivers/gpu/drm/exynos/exynos_dp_core.h| 1 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 4 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 7 +-
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c| 33 ++-
drivers/gpu/drm/panel/panel-simple.c | 57
drivers/gpu/drm/sti/sti_dvo.c | 29 +-
drivers/gpu/drm/sti/sti_hda.c | 11 +-
drivers/gpu/drm/sti/sti_hdmi.c | 11 +-
include/drm/bridge/ptn3460.h | 8 +
include/drm/drm_crtc.h | 27 +-
25 files changed, 531 insertions(+), 294 deletions(-)
create mode 100644 Documentation/devicetree/bindings/panel/avic,tm070ddh03.txt
create mode 100644
Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
rename Documentation/devicetree/bindings/{drm => video}/bridge/ptn3460.txt
(65%)
create mode 100644 drivers/gpu/drm/drm_bridge.c
[Intel-gfx] [PATCH] drm/mst: fix recursive sleep warning on qlock
On Wed, Jan 28, 2015 at 04:37:01PM +1300, Dave Airlie wrote:
> From: Dave Airlie
>
> With drm-next, we can get a backtrace like below,
> this is due to the callback checking the txmsg state taking
> the mutex, which can cause a sleep inside a sleep,
>
> Fix this my creating a spinlock protecting the txmsg state
> and locking it in appropriate places.
>
> : [ cut here ]
> : WARNING: CPU: 3 PID: 252 at kernel/sched/core.c:7300
> __might_sleep+0xbd/0xd0()
> : do not call blocking ops when !TASK_RUNNING; state=2 set at
> [] prepare_to_wait_event+0x5d/0x110
> : Modules linked in: i915 i2c_algo_bit drm_kms_helper drm e1000e ptp pps_core
> i2c_core video
> : CPU: 3 PID: 252 Comm: kworker/3:2 Not tainted 3.19.0-rc5+ #18
> : Hardware name: LENOVO 20ARS25701/20ARS25701, BIOS GJET72WW (2.22 )
> 02/21/2014
> : Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
> : 81a4027c 88030a763af8 81752699
> : 88030a763b48 88030a763b38 810974ca 88030a763b38
> : 81a41123 026d 0fa0
> : Call Trace:
> : [] dump_stack+0x4c/0x65
> : [] warn_slowpath_common+0x8a/0xc0
> : [] warn_slowpath_fmt+0x46/0x50
> : [] ? prepare_to_wait_event+0x5d/0x110
> : [] ? prepare_to_wait_event+0x5d/0x110
> : [] __might_sleep+0xbd/0xd0
> : [] mutex_lock_nested+0x2e/0x3e0
> : [] ? prepare_to_wait_event+0x98/0x110
> : [] drm_dp_mst_wait_tx_reply+0xa7/0x220 [drm_kms_helper]
> : [] ? wait_woken+0xc0/0xc0
> : [] drm_dp_send_link_address+0x61/0x240 [drm_kms_helper]
> : [] ? process_one_work+0x14f/0x530
> : [] drm_dp_check_and_send_link_address+0x8d/0xa0
> [drm_kms_helper]
> : [] drm_dp_mst_link_probe_work+0x1c/0x20 [drm_kms_helper]
> : [] process_one_work+0x1c6/0x530
> : [] ? process_one_work+0x14f/0x530
> : [] worker_thread+0x6b/0x490
> : [] ? rescuer_thread+0x350/0x350
> : [] kthread+0x10a/0x120
> : [] ? _raw_spin_unlock_irq+0x30/0x50
> : [] ? kthread_create_on_node+0x220/0x220
> : [] ret_from_fork+0x7c/0xb0
> : [] ? kthread_create_on_node+0x220/0x220
> : ---[ end trace bb11c9634a7217c6 ]---
>
> Signed-off-by: Dave Airlie
Imo much simpler with the below diff. Not tested though.
-Daniel
--
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9a5b68717ec8..379ab4555756 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -733,10 +733,14 @@ static bool check_txmsg_state(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_sideband_msg_tx *txmsg)
{
bool ret;
- mutex_lock(&mgr->qlock);
+
+ /*
+* All updates to txmsg->state are protected by mgr->qlock, and the two
+* cases we check here are terminal states. For those the barriers
+* provided by the wake_up/wait_event pair are enough.
+*/
ret = (txmsg->state == DRM_DP_SIDEBAND_TX_RX ||
txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT);
- mutex_unlock(&mgr->qlock);
return ret;
}
@@ -1363,12 +1367,13 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
return 0;
}
-/* must be called holding qlock */
static void process_single_down_tx_qlock(struct drm_dp_mst_topology_mgr *mgr)
{
struct drm_dp_sideband_msg_tx *txmsg;
int ret;
+ WARN_ON(!mutex_is_locked(&mgr->qlock));
+
/* construct a chunk from the first msg in the tx_msg queue */
if (list_empty(&mgr->tx_msg_downq)) {
mgr->tx_down_in_progress = false;
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
randconfig build error with next-20150128, in drivers/gpu/drm/panel
Building with the attached random configuration file, drivers/built-in.o: In function `panel_simple_probe': panel-simple.c:(.text+0x37cfd): undefined reference to `of_find_backlight_by_node' drivers/built-in.o: In function `sharp_panel_probe': panel-sharp-lq101r1sx01.c:(.text+0x383ef): undefined reference to `of_find_backlight_by_node' make: *** [vmlinux] Error 1 -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.19.0-rc6 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_RCU_FAST_NO_HZ is not set CONFIG_TREE_RCU_TRACE=y CONFIG_RCU_KTHREAD_PRIO=0 CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_NONE=y # CONFIG_RCU_NOCB_CPU_ZERO is not set # CONFIG_RCU_NOCB_CPU_ALL is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y # CONFIG_MEMCG_KMEM is not set # CONFIG_CGROUP_HUGETLB is not set CONFIG_CGROUP_PERF=y # CONFIG_CGROUP_SCHED is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_RD_LZ4 is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_LTO_MENU is not set CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y # CONFIG_BUG is not set # CONFIG_PCSPKR_PLATFORM is not set CONFIG_BASE_FULL=y # CONFIG_FUTEX
[PATCH] drm: bridge/dw_hdmi: Fix return error path
Hi Thierry,
Am Mittwoch, den 28.01.2015, 09:00 +0100 schrieb Thierry Reding:
> On Tue, Jan 27, 2015 at 04:17:51PM +0100, Philipp Zabel wrote:
> > Hi Fabio,
> >
> > Am Dienstag, den 27.01.2015, 10:54 -0200 schrieb Fabio Estevam:
> > > If devm_request_threaded_irq() fails we should jump to 'err_iahb' label
> > > that
> > > will disable the clocks that were previously enabled.
> > >
> > > Signed-off-by: Fabio Estevam
> > > ---
> > > drivers/gpu/drm/bridge/dw_hdmi.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c
> > > b/drivers/gpu/drm/bridge/dw_hdmi.c
> > > index ed3dfe7..cd6a706 100644
> > > --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> > > +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> > > @@ -1642,7 +1642,7 @@ int dw_hdmi_bind(struct device *dev, struct device
> > > *master,
> > > dw_hdmi_irq, IRQF_SHARED,
> > > dev_name(dev), hdmi);
> > > if (ret)
> > > - return ret;
> > > + goto err_iahb;
> > >
> > > /*
> > >* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
> >
> > Thanks for the fix. I have applied this to my tree since I've introduced
> > the bug in there.
>
> I'm currently redoing the drm/{panel,bridge} pull request anyway, so I
> could apply this while at it.
Thanks, I have a few fixes for the last pull anyway:
git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2015-01-28
I can remove this patch from the branch if you'll take it, let me know
what you prefer. Just in case:
Acked-by: Philipp Zabel
regards
Philipp
[patch] drm/bridge: checking the wrong variable
We were supposed to check "fmts" here instead of "formats". I suppose
it eventually leads to a NULL dereference.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 98fb640..8ae239f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -783,7 +783,7 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
if (formats && num_formats) {
fmts = kmemdup(formats, sizeof(*formats) * num_formats,
GFP_KERNEL);
- if (!formats)
+ if (!fmts)
return -ENOMEM;
}
[PATCH] drm: bridge/dw_hdmi: Fix return error path
On Tue, Jan 27, 2015 at 04:17:51PM +0100, Philipp Zabel wrote:
> Hi Fabio,
>
> Am Dienstag, den 27.01.2015, 10:54 -0200 schrieb Fabio Estevam:
> > If devm_request_threaded_irq() fails we should jump to 'err_iahb' label
> > that
> > will disable the clocks that were previously enabled.
> >
> > Signed-off-by: Fabio Estevam
> > ---
> > drivers/gpu/drm/bridge/dw_hdmi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c
> > b/drivers/gpu/drm/bridge/dw_hdmi.c
> > index ed3dfe7..cd6a706 100644
> > --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> > @@ -1642,7 +1642,7 @@ int dw_hdmi_bind(struct device *dev, struct device
> > *master,
> > dw_hdmi_irq, IRQF_SHARED,
> > dev_name(dev), hdmi);
> > if (ret)
> > - return ret;
> > + goto err_iahb;
> >
> > /*
> > * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
>
> Thanks for the fix. I have applied this to my tree since I've introduced
> the bug in there.
I'm currently redoing the drm/{panel,bridge} pull request anyway, so I
could apply this while at it.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/3112241e/attachment-0001.sig>
[patch] drm/bridge: checking the wrong variable
On Wed, Jan 28, 2015 at 02:46:46PM +0800, Daniel Kurtz wrote: > Hi Dan, > > nit: this patch is not really for "drm/bridge". > > On Wed, Jan 28, 2015 at 2:43 PM, Dan Carpenter > wrote: > > > > We were supposed to check "fmts" here instead of "formats". I suppose > > it eventually leads to a NULL dereference. > > > > Signed-off-by: Dan Carpenter > > > > Otherwise, good catch! > > Reviewed-by: Daniel Kurtz I've reworded the commit message slightly and applied this. Thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/96e4203c/attachment.sig>
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #45 from darkbasic --- By the way, we still have corruption in KWin without compositor but I guess it's a known long standing issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/35a7d5aa/attachment.html>
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 darkbasic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #44 from darkbasic --- Yes, fortunately the (not so) old, good glamor times are past. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/087d95c3/attachment.html>
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #43 from Michel Dänzer --- (In reply to darkbasic from comment #42) > Native backend is still much faster (especially while scrolling), but at > least raster is usable now. So can this report be resolved? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/32e900a4/attachment.html>
[git pull] drm fixes
On 28 January 2015 at 04:04, Linus Torvalds wrote: > On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie wrote: >> >> are available in the git repository at: >> >> git://people.freedesktop.org/~airlied/linux drm-fixes > > No they aren't, actually, because you've screwed up your repository. > > It looks like you were using an alternates that has gone away: > >remote: error: object directory > /srv/anongit.freedesktop.org/git/nouveau/linux-2.6/objects does not > exist; check .git/objects/info/alternates. >remote: error: Could not read fe06a892edbcd0cd42ea5928e4492a337e3bd90c >remote: fatal: bad tree object fe06a892edbcd0cd42ea5928e4492a337e3bd90c >remote: aborting due to possible repository corruption on the remote side. > > it really looks like you started your repo by doing a shared clone > from an insane source (ie the nouveau tree), and then the nouveau tree > got renamed or deleted (perhaps somebody decided that the whole > "linux-2.6" naming doesn't make sense any more, since we haven't been > at 2.6 for years). So now your repository depends on another repo that > is gone. > > It's should be trivially fixable by just editing the git "alternates" > file to point to the proper base again, since that fe06a892edbc object > is definitely part of my base kernel, but basically you shouldn't do > shared clones unless you know you can really *rely* on the clone > you're sharing from. Doing it from some random side project like the > nouveau tree sounds like a bad bad idea. Actually everything was there, just one tree is NFS mounted from somewhere else, and fd.o got rebooted and the mount didn't come back up automatically, fixed it now. But yes I'll reorganise my tree to be a clean copy, I built it years ago temporarily and it kinda ended up permanent, and I forgot where I cloned it from. Dave.
[Bug 88364] Xorg hangs after videocard switching
https://bugs.freedesktop.org/show_bug.cgi?id=88364 --- Comment #3 from Michel Dänzer --- (In reply to Liss from comment #2) > If I restart notebook and try to run something again I'll get black window > (Xorg will continue to work) Note that DRI_PRIME currently requires a compositing manager for the contents to be visible. > and next dmesg log: Looks like the normal messages from powering up and initializing the Radeon GPU. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/f241f922/attachment.html>
[Bug 88758] Low FPS in settings on Dota2
https://bugs.freedesktop.org/show_bug.cgi?id=88758 --- Comment #5 from Michel Dänzer --- (In reply to Lorenzo Bona from comment #4) > So, could be a kernel regression or a dumb kernel configuration? Have you changed the kernel configuration compared to before the problem started? If not, it's probably a kernel regression, can you bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/2befa7d0/attachment.html>
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #26 from Arthur Marsh --- Created attachment 112901 --> https://bugs.freedesktop.org/attachment.cgi?id=112901&action=edit 2015012814dmesg.txt - lockup after updating kernel to latest radeon patches With the latest radeon patches in the 3.19.0-rc6+ kernel, I still experienced a lockup. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/eef95106/attachment.html>
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #7 from Woody Suwalski --- Added files from a successful 64-bit kernel. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/6a5e2010/attachment-0001.html>
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #6 from Woody Suwalski --- Created attachment 112898 --> https://bugs.freedesktop.org/attachment.cgi?id=112898&action=edit Xorg log 64bit -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/60f0f0d2/attachment.html>
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #5 from Woody Suwalski --- Created attachment 112895 --> https://bugs.freedesktop.org/attachment.cgi?id=112895&action=edit dmesg for 64bit kernel, no Radeon crash dmesg Ubuntu 14.10 AMD64 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/4ce26189/attachment.html>
[Bug 78951] gl_PrimitiveID is zero if no geometry shader is present
https://bugs.freedesktop.org/show_bug.cgi?id=78951 --- Comment #8 from Dave Airlie --- fix for this pushed to mesa master -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/6d6236fd/attachment.html>
