We are missing OMAP5 DSIPHY lane-enable support, which has prevented
OMAP5 DSI working in mainline. This patch adds the lane-enable similarly
to the recently added OMAP4 version.
Signed-off-by: Tomi Valkeinen
---
Based on Laurent's recent omapdrm series.
drivers/gpu/drm/omapdrm/dss/dsi.c | 50
On Wed, Aug 9, 2017 at 10:16 PM, Michel Dänzer wrote:
> On 09/08/17 07:30 PM, Dan Carpenter wrote:
>> My static checker complains that it's possible for "r" to be
>> uninitialized. It used to be set to zero so this returns it to the old
>> behavior.
>>
>> Fixes: 98a7f88ce9a9 ("drm/amdgpu: bind BO
Chnage GPL license of Exynos relevant code to X11/MIT.
I'd like to keep license consistency to all Exynos code
because License checker notices two more licenses exist
in libdrm.
For the license change I need to get your agree - all committers.
So please give me Acked-by if you agree with me.
Sig
On 09/08/17 07:30 PM, Dan Carpenter wrote:
> My static checker complains that it's possible for "r" to be
> uninitialized. It used to be set to zero so this returns it to the old
> behavior.
>
> Fixes: 98a7f88ce9a9 ("drm/amdgpu: bind BOs with GTT space allocated directly
> v2")
> Signed-off-by:
Hi Dave,
On Wed, 2 Aug 2017 12:23:06 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/nouveau/nv50_display.c
>
> between commit:
>
> 4a5431af19bc ("drm/nouveau/kms/nv50: update vblank state in response to
> modeset act
snd_pcm_ops are not supposed to change at runtime. All functions
working with snd_pcm_ops provided by work with
const snd_pcm_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 2 +-
1 file changed, 1 insertion(+),
On 8/8/2017 11:37 PM, Alex Williamson wrote:
> On Tue, 8 Aug 2017 14:18:07 +0530
> Kirti Wankhede wrote:
>
>> On 8/7/2017 11:13 PM, Alex Williamson wrote:
>>> On Mon, 7 Aug 2017 08:11:43 +
>>> "Zhang, Tina" wrote:
>>>
After going through the previous discussions, here are some summ
On Wed, Aug 09, 2017 at 04:07:24PM -0700, Matthias Kaehlcke wrote:
> rockchip_drm_sys_suspend/resume() obains a struct drm_device pointer
> from drvdata, the pointer is then dereferenced to obtain private data.
> drvdata is set when a display is bound, on systems without a
> (successfully probed) d
* Tomi Valkeinen [170809 05:57]:
> > diff --git a/arch/arm/mach-omap2/board-generic.c
> > b/arch/arm/mach-omap2/board-generic.c
> > index dc9e34e670a2..5303402ed5c2 100644
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -33,6 +33,7 @@ static void
Vulkan VkFence semantics require that the application be able to perform
a CPU wait on work which may not yet have been submitted. This is
perfectly safe because the CPU wait has a timeout which will get
triggered eventually if no work is ever submitted. This behavior is
advantageous for multi-th
On Wed, Aug 9, 2017 at 6:23 PM, Chris Wilson
wrote:
> Quoting Jason Ekstrand (2017-08-10 02:02:43)
> > On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson
> wrote:
> >
> > To further facilitate GEM testing, allow testing of drm_syncobj by
> > attaching them to vgem fences. These fences are alr
On 9 August 2017 at 09:42, Michał Mirosław wrote:
> Default config value for all other drivers is N.
>
> Signed-off-by: Michał Mirosław
I've pulled this into drm-fixes, ouch default y is bad.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedeskto
Quoting Jason Ekstrand (2017-08-10 02:02:43)
> On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson
> wrote:
>
> To further facilitate GEM testing, allow testing of drm_syncobj by
> attaching them to vgem fences. These fences are already employed by igt
> for testing inter-driver fence hand
On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson
wrote:
> To further facilitate GEM testing, allow testing of drm_syncobj by
> attaching them to vgem fences. These fences are already employed by igt
> for testing inter-driver fence handling (across dmabuf and sync_file).
>
> An igt example use would
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #26 from Shmerl ---
Is there anything else useful that can be done to help Mesa / kernel developers
to nail it down?
--
You are receiving this mail because:
You are the assignee for the bug._
On Tue, 2017-07-11 at 15:30 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Implement support for this DisplayPort feature.
>
> The cec device is created whenever it detects an adapter that
> has this feature. It is only removed when a new adapter is connected
> that does not support this. I
On Tue, 2017-07-11 at 15:30 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.
>
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this capabilit
On Wed, Aug 9, 2017 at 2:21 PM, Chris Wilson
wrote:
> Quoting Jason Ekstrand (2017-08-08 23:46:02)
> > The atomic exchange operation we were doing before in replace_fence was
> > sufficient for the case where it raced with itself. However, if you
> > have a race between a replace_fence and dma_f
On Wed, Aug 02, 2017 at 09:06:26PM +0200, Jernej Škrabec wrote:
> Hi,
>
> Dne sreda, 02. avgust 2017 ob 07:02:39 CEST je icen...@aosc.io napisal(a):
> > 在 2017-08-02 12:53,Jernej Škrabec 写道:
> >
> > > Hi Icenowy,
> > >
> > > Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng
> > >
> >
On Tue, Aug 01, 2017 at 09:12:52PM +0800, Icenowy Zheng wrote:
> Allwinner H3 features a "Display Engine 2.0".
>
> Add device tree bindings for the following parts:
> - H3 TCONs
> - H3 Mixers
> - H3 Display engine
>
> Signed-off-by: Icenowy Zheng
> ---
> .../bindings/display/sunxi/sun4i-drm.txt
On Wed, Aug 9, 2017 at 3:41 PM, Chris Wilson
wrote:
> Quoting Chris Wilson (2017-08-09 18:57:44)
> > So we are taking a snapshot here. It looks like this could have been
> > done using a dma_fence_array + dma_fence_proxy for capturing the future
> > fence.
>
> A quick sketch of this idea looks li
On Mon, Jul 31, 2017 at 12:04:35PM +0200, Philipp Zabel wrote:
> The parallel display device tree binding documentation incorrectly lists
> the interface-pix-fmt property with underscores ("interface_pix_fmt").
> This was never supported by any driver, and the DT example in the same
> file always c
On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes wrote:
>
> Den 09.08.2017 01.42, skrev Joe Kniss:
>>
>> Because all drivers currently use gem objects for framebuffer planes,
>> the virtual create_handle() is not required. This change adds a
>> struct drm_gem_object *gems[4] field to drm_framebuff
rockchip_drm_sys_suspend/resume() obains a struct drm_device pointer
from drvdata, the pointer is then dereferenced to obtain private data.
drvdata is set when a display is bound, on systems without a
(successfully probed) display drvdata is NULL and the PM functions
try to dereference a NULL point
Quoting Chris Wilson (2017-08-09 18:57:44)
> So we are taking a snapshot here. It looks like this could have been
> done using a dma_fence_array + dma_fence_proxy for capturing the future
> fence.
A quick sketch of this idea looks like:
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
On Wed, Aug 9, 2017 at 2:31 PM, Chris Wilson
wrote:
> Quoting Jason Ekstrand (2017-08-09 18:00:54)
> > +static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj
> **syncobjs,
> > + uint32_t count,
> > +
Quoting Jason Ekstrand (2017-08-09 18:00:54)
> +static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj
> **syncobjs,
> + uint32_t count,
> + uint32_t flags,
> +
Quoting Jason Ekstrand (2017-08-08 23:46:02)
> The atomic exchange operation we were doing before in replace_fence was
> sufficient for the case where it raced with itself. However, if you
> have a race between a replace_fence and dma_fence_get(syncobj->fence),
> you may end up with the entire rep
https://bugzilla.kernel.org/show_bug.cgi?id=196615
--- Comment #4 from Peter Spiess-Knafl (p...@autistici.org) ---
Created attachment 257861
--> https://bugzilla.kernel.org/attachment.cgi?id=257861&action=edit
dmesg log regarding the freeze.
dmesg log regarding the freeze.
--
You are receivin
https://bugzilla.kernel.org/show_bug.cgi?id=196615
--- Comment #3 from Peter Spiess-Knafl (p...@autistici.org) ---
Hi Alex!
Thanks for getting back. First there are strange artefacts where the mouse
pointer should be and shortly after the system freezes all together.
I'll attach a dmesg log. But
On Wed, Aug 9, 2017 at 11:25 AM, Christian König
wrote:
> Am 09.08.2017 um 19:57 schrieb Chris Wilson:
>
>> Quoting Jason Ekstrand (2017-08-09 18:00:54)
>>
>>> Vulkan VkFence semantics require that the application be able to perform
>>> a CPU wait on work which may not yet have been submitted. T
On Wed, Aug 09, 2017 at 12:11:05PM +0200, Noralf Trønnes wrote:
> Use the new drm_gem_framebuffer_helper who's code was copied
> from this helper.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 172
> +++-
> 1 file changed, 30 ins
On Wed, Aug 09, 2017 at 12:11:04PM +0200, Noralf Trønnes wrote:
> This library provides helpers for drivers that don't subclass
> drm_framebuffer and are backed by drm_gem_object. The code is
> taken from drm_fb_cma_helper.
>
> Signed-off-by: Noralf Trønnes
lgtm, a few nits below to polish the d
On Wed, Aug 09, 2017 at 06:00:59PM +0800, Sandy Huang wrote:
> This adds support for Rockchip soc lvds found on rk3288
> Based on the patches from Mark yao and Heiko Stuebner
>
> Signed-off-by: Sandy Huang
> Signed-off-by: Mark yao
> Signed-off-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockch
https://bugs.freedesktop.org/show_bug.cgi?id=101900
--- Comment #6 from Alex Deucher ---
Here's the relevant ALSA code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/pci/hda/hda_eld.c
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/pci
https://bugs.freedesktop.org/show_bug.cgi?id=101900
--- Comment #5 from Harry Wentland ---
I think the info on this ticket is pretty good. We just haven't had a chance to
look at this yet.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=101900
--- Comment #4 from Direx ---
Is there any information missing from my side? Do I need to provide any logs or
something like that? I just checked the very latest amd-staging-drm-next and
the issue is still present there.
I don't know if this is
Den 09.08.2017 01.42, skrev Joe Kniss:
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_
To further facilitate GEM testing, allow testing of drm_syncobj by
attaching them to vgem fences. These fences are already employed by igt
for testing inter-driver fence handling (across dmabuf and sync_file).
An igt example use would be like:
int vgem = drm_driver_open(DRIVER_VGEM);
uint32
On 08/09/2017 08:00 PM, Daniel Vetter wrote:
On Wed, Aug 9, 2017 at 7:50 PM, Thomas Hellstrom wrote:
On 08/09/2017 07:40 PM, Daniel Vetter wrote:
On Wed, Aug 09, 2017 at 07:38:29PM +0200, Daniel Vetter wrote:
On Wed, Aug 09, 2017 at 07:17:54PM +0200, Sinclair Yeh wrote:
From: Thomas Hellst
Am 09.08.2017 um 19:57 schrieb Chris Wilson:
Quoting Jason Ekstrand (2017-08-09 18:00:54)
Vulkan VkFence semantics require that the application be able to perform
a CPU wait on work which may not yet have been submitted. This is
perfectly safe because the CPU wait has a timeout which will get
t
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #17 from Christoph Schwerdtfeger ---
Fo what it's worth, the issue is still present in mesa 17.2.0~rc3-1 and llvm
1:4.0.1-1 (Debian/experimental).
--
You are receiving this mail because:
You are the assignee for the bug.
On Wed, Aug 9, 2017 at 6:41 AM, Jeffy Chen wrote:
> Currently we are allocating drm_device in rockchip_drm_bind, so if the
> suspend/resume code access it when drm is not bound, we would hit this
> crash:
>
> [ 253.402836] Unable to handle kernel NULL pointer dereference at virtual
> address 000
On 08/09/2017 07:40 PM, Daniel Vetter wrote:
On Wed, Aug 09, 2017 at 07:38:29PM +0200, Daniel Vetter wrote:
On Wed, Aug 09, 2017 at 07:17:54PM +0200, Sinclair Yeh wrote:
From: Thomas Hellstrom
See LWN article at
https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_302043_&d=D
On Wed, Aug 9, 2017 at 7:50 PM, Thomas Hellstrom wrote:
> On 08/09/2017 07:40 PM, Daniel Vetter wrote:
>>
>> On Wed, Aug 09, 2017 at 07:38:29PM +0200, Daniel Vetter wrote:
>>>
>>> On Wed, Aug 09, 2017 at 07:17:54PM +0200, Sinclair Yeh wrote:
From: Thomas Hellstrom
See LWN arti
Den 07.08.2017 19.39, skrev David Lechner:
LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the LEGO MINDSTORMS
EV3 LCD display.
Signed-off-by: David Lechner
---
This looks good, even I understand the pixel packing
Quoting Jason Ekstrand (2017-08-09 18:00:54)
> Vulkan VkFence semantics require that the application be able to perform
> a CPU wait on work which may not yet have been submitted. This is
> perfectly safe because the CPU wait has a timeout which will get
> triggered eventually if no work is ever s
On Wed, Aug 09, 2017 at 07:38:29PM +0200, Daniel Vetter wrote:
> On Wed, Aug 09, 2017 at 07:17:54PM +0200, Sinclair Yeh wrote:
> > From: Thomas Hellstrom
> >
> > See LWN article at
> > https://lwn.net/Articles/302043/
> >
> > Signed-off-by: Thomas Hellstrom
> > Reviewed-by: Deepak Singh Rawat
On Wed, Aug 09, 2017 at 07:17:54PM +0200, Sinclair Yeh wrote:
> From: Thomas Hellstrom
>
> See LWN article at
> https://lwn.net/Articles/302043/
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Deepak Singh Rawat
> Reviewed-by: Sinclair Yeh
We definitely can't do this in general due to lat
Boris Brezillon writes:
> On Tue, 25 Jul 2017 09:27:33 -0700
> Eric Anholt wrote:
>
>> This is useful to allow GL to provide defined results for overlapping
>> glBlitFramebuffer, which X11 in turn uses to accelerate uncomposited
>> window movement without first blitting to a temporary. x11perf
On Tue, Aug 08, 2017 at 01:56:05PM -0700, Eric Anholt wrote:
> We don't keep a pointer to it around anywhere, so it's our job to free
> it.
>
> Cc: Stefan Wahren
> Link: https://github.com/anholt/linux/issues/101
> Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
> Signed-off-by
---
include/drm/i915_drm.h | 61 ++
1 file changed, 52 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 5ebe046..c26bf7c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -412,6 +412,
Make the fields and flags available.
Signed-off-by: Sinclair Yeh
Reviewed-by: Deepak Singh Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 5 -
include/uapi/drm/vmwgfx_drm.h | 11 ---
2 files changed, 8 insertions(+), 8 deletions(-)
dif
From: Brian Paul
Fix comment mistake
Signed-off-by: Brian Paul
Reviewed-by: Neha Bhende
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 3cd4
Added code to link a fence to a out_fence_fd file descriptor and
thread out_fence_fd down to vmw_execbuf_copy_fence_user() so it can be
copied into the IOCTL reply and be passed back up the the user.
v2:
Make sure to sync and clean up in case of failure
Signed-off-by: Sinclair Yeh
Reviewed-by: D
From: Thomas Hellstrom
This gets rid of the irq bottom half tasklets and instead performs the
work needed in process context. We also convert irq-disabling spinlocks to
ordinary spinlocks.
This should decrease system latency for other system components, like
sound for example but has the potenti
Minor version bump to indicate support for fence FD
Signed-off-by: Sinclair Yeh
Reviewed-by: Deepak Singh Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/d
From: Thomas Hellstrom
Sometimes it appears like the device modifies the command header offset
member. So explicitly clear it when restarting after an error.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 1 +
1 file changed, 1 insertion
This allows vmwgfx to wait on a fence created by another
device.
v2:
* Remove special handling for vmwgfx fence and just use dma_fence_wait()
* Use interruptible waits
* Added function documentation
Signed-off-by: Sinclair Yeh
Reviewed-by: Deepak Singh Rawat
Reviewed-by: Thomas Hellstrom
---
From: Thomas Hellstrom
Can be used by user-space applications to test and verify the kernel
command buffer error recovery functionality.
Malicious user-space apps could potentially use this command to slow down
graphics processing somewhat, but they could also accomplish the same thing
using a r
From: Thomas Hellstrom
Previously we skipped the command buffer and added an extra fence to
avoid hangs due to skipped fence commands.
Now we instead restart the command buffer after the failing command,
if there are any commands left.
In addition we print out some information about the failing c
These, along with "drm: Support drivers with threaded irqs", are
queued for the next vmwgfx-next pull request.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Thomas Hellstrom
See LWN article at
https://lwn.net/Articles/302043/
Signed-off-by: Thomas Hellstrom
Reviewed-by: Deepak Singh Rawat
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/drm_irq.c | 6 --
include/drm/drm_drv.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
di
Vulkan VkFence semantics require that the application be able to perform
a CPU wait on work which may not yet have been submitted. This is
perfectly safe because the CPU wait has a timeout which will get
triggered eventually if no work is ever submitted. This behavior is
advantageous for multi-th
We don't keep a pointer to it around anywhere, so it's our job to free
it.
Cc: Stefan Wahren
Link: https://github.com/anholt/linux/issues/101
Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 1 +
1 file changed, 1
On Wed, 9 Aug 2017 08:31:00 +
"Zhang, Tina" wrote:
> > -Original Message-
> > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> > Behalf Of Alex Williamson
> > Sent: Tuesday, August 8, 2017 1:43 AM
> > To: Zhang, Tina
> > Cc: Tian, Kevin ; intel-...@lists.
On 8 August 2017 at 21:36, Eric Anholt wrote:
> Daniel Stone writes:
>> + case DRM_FORMAT_YUV422:
>> + case DRM_FORMAT_YVU422:
>> + case DRM_FORMAT_YUV420:
>> + case DRM_FORMAT_YVU420:
>> + case DRM_FORMAT_NV12:
>> + case DRM_FORMAT_NV16:
>> + return (modifier
Cihangir Akturk writes:
> drm_*_reference() and drm_*_unreference() functions are just
> compatibility alias for drm_*_get() and drm_*_put() adn should not be
> used by new code. So convert all users of compatibility functions to use
> the new APIs.
Reviewed and pushed. Thanks!
signature.asc
On Wed, Aug 09, 2017 at 09:23:01AM +0530, Nikhil Mahale wrote:
> Do not leak framebuffer if client provided crtc id found invalid.
>
> Signed-off-by: Nikhil Mahale
Nice catch, applied for 4.13-rc and cc: stable.
-Daniel
> ---
> drivers/gpu/drm/drm_plane.c | 1 +
> 1 file changed, 1 insertion(+
On Tue, Aug 08, 2017 at 08:44:05PM +0530, Bhumika Goyal wrote:
> Make these structures const as they are only passed to the function
> drm_fb_helper_prepare and the corresponding argument is of type const.
> Done using Coccinelle
>
> @match disable optional_qualifier@
> identifier s;
> @@
> static
Daniel Stone writes:
> The IN_FORMATS blob allows the kernel to advertise to userspace which
> format/modifier combinations are supported, per plane. Use this to
> advertise that we support both T_TILED and linear.
>
> v2:
> - Only advertise T_TILED for RGB (Eric)
> - Actually turn on allow_f
On Wed, Aug 09, 2017 at 04:02:45PM +0530, Archit Taneja wrote:
>
>
> On 08/08/2017 04:58 PM, Bhumika Goyal wrote:
> > Declare drm_connector_funcs structures as const.
>
> Could you rebase this series over the latest drm-misc-next? The
> recently merged patch "drm: Nuke drm_atomic_helper_connecto
Den 07.08.2017 19.39, skrev David Lechner:
This adds parameters for vaddr and clip to tinydrm_xrgb_to_gray8() to
make it more generic.
dma_buf_{begin,end}_cpu_access() are moved out to the repaper driver.
Return type is change to void to simplify error handling by callers.
Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=101881
--- Comment #22 from Mike Lothian ---
I'm not totally sure this is the same bug, #101484 seems to suggest that
reverting 2b8b9a56efc24cc0f27469bf1532c288cdca2076 fixes the issue (it doesn't
for me) and they don't get segfaults, I don't have issu
On Tue, Aug 08, 2017 at 01:54:52PM +0200, Peter Rosin wrote:
> On 2017-08-07 11:21, Daniel Vetter wrote:
> > On Fri, Aug 04, 2017 at 12:45:06PM +0200, Peter Rosin wrote:
> >> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> >> no longer used. Remove the dead code that was not doi
Le Fri, 04 Aug 2017 14:15:56 -0700,
Eric Anholt a écrit :
> Boris Brezillon writes:
>
> > On Tue, 18 Jul 2017 14:05:05 -0700
> > Eric Anholt wrote:
> >
> >> The incoming mode might have a missing vrefresh field if it came from
> >> drmModeSetCrtc(), which the kernel is supposed to calculate
On 9 August 2017 at 15:36, Sean Paul wrote:
> On Wed, Aug 09, 2017 at 02:19:06PM +0300, Dan Carpenter wrote:
>> "plane->format_count" can go up to 64. (It's capped in
>> drm_universal_plane_init().) So we should be using ULL type instead of
>> int here to prevent shift wrapping.
>>
>> Fixes: db1
On Wed, Aug 09, 2017 at 02:19:06PM +0300, Dan Carpenter wrote:
> "plane->format_count" can go up to 64. (It's capped in
> drm_universal_plane_init().) So we should be using ULL type instead of
> int here to prevent shift wrapping.
>
> Fixes: db1689aa61bd ("drm: Create a format/modifier blob")
>
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 102030, which changed state.
Bug 102030 Summary: private memory overflow in openCL
https://bugs.freedesktop.org/show_bug.cgi?id=102030
What|Removed |Added
---
Hi Dave,
Here's the -fixes pull for last week. Considering this is 2 weeks worth, it's
pretty light.
You might recognize some of these patches. The rockchip set and Chris' dma-buf
patch were also applied to -misc-next. Misplaced patches continues to be
the primary growing pain for the misc trees.
Hi Alex,
On 8 August 2017 at 21:13, Deucher, Alexander wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Tuesday, August 08, 2017 7:57 AM
>> To: Alex Deucher
>> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.free
On Mon, Jul 31, 2017 at 5:49 AM, Mark Yao wrote:
> Here are some fixes port from rockchip_linux project[0],
>
> Tested on rk3399 and rk3288 board.
>
> [0]: https://github.com/rockchip-linux/kernel
>
> Mark Yao (6):
> drm/rockchip: vop: no need wait vblank on crtc enable
> drm/rockchip: vop: fi
https://bugs.freedesktop.org/show_bug.cgi?id=101325
--- Comment #22 from MirceaKitsune ---
(In reply to Matt from comment #21)
I sincerely don't mean to complicate this report with anything potentially
unrelated, and apologize if I'm adding more noise. However I have to make an
observation on so
https://bugs.freedesktop.org/show_bug.cgi?id=102130
--- Comment #1 from Alex Deucher ---
Please attach your xorg log and dmesg output. Are you using multiple monitors?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-d
On Wed, 09 Aug 2017, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> dim | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/dim b/dim
> index eaabcec43c8f..a656afa0d255 100755
> --- a/dim
> +++ b/dim
> @@ -1958,6 +1958,16 @@ function dim_fi
This message contains a digitally signed email which can be read by opening
the attachment.
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--- Begin Message ---
Hi Tony,
On 05/08/17 01:43, Laurent Pinchart wrote:
On Wed, 09 Aug 2017, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> dim | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dim b/dim
> index af1baa11c7b2..eaabcec43c8f 100755
> --- a/dim
> +++ b/dim
> @@ -1970,7 +1970,7 @@ function dim_add_missing_cc
>
On Wed, 09 Aug 2017, Eric Engestrom wrote:
> get_maintainer.pl needs a diff, so this script can't run on a merge
> commit.
>
> Signed-off-by: Eric Engestrom
> ---
> dim | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/dim b/dim
> index 619d855b321b..af1baa11c7b2 100755
> --- a/dim
>
On 07/30/2017 06:37 PM, Hans Verkuil wrote:
From: Hans Verkuil
This patch series adds CEC support to the drm adv7511/adv7533 drivers.
I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).
Note: the Dragonboard needs this p
On 08/09/2017 02:08 PM, Laurent Pinchart wrote:
Hi Arvind,
Thank you for the patch.
On Wednesday 09 Aug 2017 13:08:37 Arvind Yadav wrote:
snd_pcm_ops are not supposed to change at runtime. All functions
working with snd_pcm_ops provided by work with
const snd_pcm_ops. So mark the non-const
On 08/08/2017 09:33 PM, Laurent Pinchart wrote:
Hi Bhumika,
Thank you for the patch.
On Tuesday 08 Aug 2017 21:24:10 Bhumika Goyal wrote:
Make these structures const as they are only stored in the funcs field
of drm_bridge structure, which is of type const.
Done using Coccinelle.
Signed-off
Hi Dave, drm/i915 fixes for v4.13-rc5.
BR,
Jani.
The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e:
Linux 4.13-rc4 (2017-08-06 18:44:49 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-08-09-1
f
DRM core already checks the validity of the pixelformat.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 +---
3 files changed, 3 insertions(+
A recent commit (272725c7db4da1fd3229d944fc76d2e98e3a144e) has removed
the use of 'bits_per_pixel' in DRM. However the corresponding Exynos
driver code still uses the ambiguous 'bpp', even though it is now
initialized from fb->cpp[0].
Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers.
S
Both FIMD and DECON5433 support a pitch in bytes.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu
In some of drivers we compute something like 'pitch / cpp' at some
point, silently assuming that the pitch (which is in bytes) is
divisible by the buffer's cpp. This is not always true, in particular
DRM core does not check for pitch alignment in the common case.
Introduce a new cap which indicate
DRM core already checks the validity of the pixelformats, so we
can simplify the checks here. The same applies to the FB modifier,
which is now checked in common Exynos plane code.
Also rename the booleans to reflect what true/false actually
means.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/d
The current comment sounds like the division op is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c |
The video processor supports a tiled version of the NV12 format,
known as NV12MT in V4L2 terms. The support was removed in commit
083500baefd5f4c215a5a93aef2492c1aa775828 due to not being a real
pixel format, but rather NV12 with a special memory layout.
With the introduction of FB modifiers, we c
Hello,
this is basically a resend of [1] with some minor changes to the commit
messages, the RFC tag removed, and a rebase on vanilla 4.13-rc4.
Summary:
(a) Enables support for NV12MT in the mixer.
(b) Sanitizes buffer pitch for HW with restrictions.
(c) Misc fixes
With best wishes,
Tobias
[1]
1 - 100 of 145 matches
Mail list logo