Hi,
On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard
wrote:
> The A33 has a significantly different pipeline, with components that differ
> too.
>
> Make sure we had compatible for them.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 +++
t part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161105/aeac01f0/attachment.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161105/f03595cf/attachment.html>
|x86-64 (AMD64)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161105/8f7aff92/attachment.html>
edesktop.org/archives/dri-devel/attachments/20161105/e9ab039e/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161105/c2724452/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161105/b072fa0b/attachment-0001.html>
On Sat, Nov 05, 2016 at 01:27:30PM +0900, Norbert Preining wrote:
> > It won't apply directly, but you could try testing that commit and its
> > parent to see if my hunch was correct.
>
> Unfortunately parent commit was also ok. I am trying to bisect, but
> somehow git tells me something about "..
On 11/05/2016 01:06 PM, Christian König wrote:
> Am 05.11.2016 um 01:56 schrieb Mario Kleiner:
>> External clients which import our bo's wait only
>> for exclusive dmabuf-fences, not on shared ones,
>> so attach fences on such exported buffers as
>> exclusive ones.
>>
>> See discussion in thread:
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20161105/49457db4/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161105/7c55c5df/attachment.html>
On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
> > +typedef char drm_format_name_buf[32];
>
> Please don't use a typedef for this, just define the maximum size of
> characters the function might write somewhere.
>
> See the kernel
For the vmwgfx part:
Acked-by: Thomas Hellstrom
On 11/05/2016 08:33 AM, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the returned pointer must be freed
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1225:10-29: WARNING: casting value
returned by memory allocation function to (struct dma_fence * *) is useless.
Remove casting the values returned by memory allocation functions
like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc.
Semantic patc
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.10-wip
head: 2f5945e707b5dffbf12444ad8bea079626ad30ec
commit: 2f5945e707b5dffbf12444ad8bea079626ad30ec [56/56] drm/amdgpu: add the
interface of waiting multiple fences (v4)
coccinelle warnings: (new ones prefixed by >>)
>> drive
> It won't apply directly, but you could try testing that commit and its
> parent to see if my hunch was correct.
Unfortunately parent commit was also ok. I am trying to bisect, but
somehow git tells me something about "...merge commit..." - will see
how it goes.
Norbert
--
PREINING Norbert + Te
Am 04.11.2016 um 21:16 schrieb Alex Deucher:
> From: "monk.liu"
>
> Return the index of the first signaled fence. This information
> is useful in some APIs like Vulkan.
>
> v2: rebase on drm-next (fence -> dma_fence)
>
> Signed-off-by: monk.liu
> Signed-off-by: Alex Deucher
> Cc: Sumit Semwal
Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
> +typedef char drm_format_name_buf[32];
Please don't use a typedef for this, just define the maximum size of
characters the function might write somewhere.
See the kernel coding style as well:
> In general, a pointer, or a struct that has elements
Am 05.11.2016 um 01:56 schrieb Mario Kleiner:
> External clients which import our bo's wait only
> for exclusive dmabuf-fences, not on shared ones,
> so attach fences on such exported buffers as
> exclusive ones.
>
> See discussion in thread:
> https://lists.freedesktop.org/archives/dri-devel/2016-
On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom wrote:
> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
>> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
>> > +typedef char drm_format_name_buf[32];
>>
>> Please don't use a typedef for this, just define the maximum size of
>> chara
Previously, SMP block allocation was not checked in the plane's
atomic_check() fxn, so we could fail allocation SMP block allocation at
atomic_update() time. Re-work the block allocation to request blocks
during atomic_check(), but not update the hw until committing the atomic
update.
Since SMP b
(re)assign the hw pipes to planes based on required caps, and to handle
situations where we could not modify an in-use plane (ie. SMP block
reallocation).
This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates
Add basic state duplication/apply mechanism. Following commits will
move actual global hw state into this.
The state_lock allows multiple concurrent updates to proceed as long as
they don't both try to alter global state. The ww_mutex mechanism will
trigger backoff in case of deadlock between mu
This will give the kms backends a slot to stash their own hw specific
global state.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_atomic.c | 31 +++
drivers/gpu/drm/msm/msm_drv.c| 3 +++
drivers/gpu/drm/msm/msm_drv.h| 3 +++
drivers/gpu/drm/msm/msm_km
Split out the hardware pipe specifics from mdp5_plane. To start, the hw
pipes are statically assigned to planes, but next step is to assign the
hw pipes during plane->atomic_check() based on requested caps (scaling,
YUV, etc). And then hw pipe re-assignment if required if required SMP
blocks chan
In the process of getting kms fence fd (and related gpu egl fence fd
extension) working with real hardware (using android drm-hwc) I found
a lot of issues w/ plane support. Perhaps that is to be expected the
first time getting a userspace that actually makes heavy use of overlay
planes working. S
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c | 10 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 11 +++
drivers/gpu/drm/msm/msm_drv.c | 4
3 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
b/drivers/gpu
We subclass drm_plane_state, so add mdp5_plane_atomic_print_state() to
dump out our own driver specific plane state.
Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 12
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 18 +-
Useful to dump current state from debugfs, if turning on the drm.debug
bit is too much overhead.
The drm_state_dump() can also be used by drivers, for example to
implement a module param that dumps state on error irqs.
Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_ato
The contents of drm_{plane,crtc,connector}_state is dumped before
commit. If a driver extends any of the state structs, it can implement
the corresponding funcs->atomic_print_state() to add it's own driver
specific state.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic.c | 93 ++
Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_plane_helper.c | 11 ++-
drivers/gpu/drm/i915/intel_display.c | 10 ++
drivers/gpu/drm/i915/intel_sprite.c | 11 ++-
include/drm/drm_plane.h | 23 +++
4 files chang
Sometimes it is nice not to duplicate equivalent printk() and
seq_printf() code.
v2: simplify things w/ va_format, and use dev_printk, docs
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-internals.rst | 17 ++
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_print.c
I'll want to print things in a similar way in a later patch. This will
make it easier.
Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_modes.c | 8 +---
drivers/gpu/drm/drm_rect.c | 11 ++-
include/drm/drmP.h | 21 +
3 files ch
I realized that I had not re-sent this after updating from review
comments, and adding kerneldoc.
The drm/msm bits I can include in my msm-next pull-req for 4.10. Just
including them here to show example usage.
There will be a minor conflict to resolve around drm_get_format_name(),
depending on
It is kind of a pointless restriction. If userspace does silly things
like using crtcA's cursor plane on crtcB, and then setcursor on crtcA,
it will end up with the overlay disabled on crtcB. But userspace is
allowed to shoot itself like this.
v2: don't WARN_ON() if caller did not set ->possible
Le 02/11/2016 à 19:14, Maxime Ripard a écrit :
> Hi,
>
> On Sun, Oct 30, 2016 at 12:53:02PM +0100, Christophe JAILLET wrote:
>> BTW, memory allocation in 'sun4i_layers_init()' looks spurious, especially
>> the use of 'layer' in the for loop.
>> Just my 2 cents.
> What do you mean by it's spurious
Hi Liviu,
On Fri, 4 Nov 2016 15:48:02 + Liviu Dudau wrote:
>
> Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> alone should be good. Baoyou's patch is in my tree to stop him repeatedly
> send me the same patch over and over again :) But yes, I will add my
> Signe
Hi Chris,
> https://cgit.freedesktop.org/drm-intel/
I pulled from there and rebuild my kernel. Rebooting and everything
is fine. Looks much better!!!
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued&id=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you want me to test this
On 10/28/2016 07:48 PM, Christian König wrote:
> Am 28.10.2016 um 19:37 schrieb Mario Kleiner:
>>
>>
>> On 10/28/2016 03:34 AM, Michel Dänzer wrote:
>>> On 27/10/16 10:33 PM, Mike Lothian wrote:
Just another gentle ping to see where you are with this?
>>>
>>> I haven't got a chance to
External clients which import our bo's wait only
for exclusive dmabuf-fences, not on shared ones,
so attach fences on such exported buffers as
exclusive ones.
See discussion in thread:
https://lists.freedesktop.org/archives/dri-devel/2016-October/122370.html
Tested on Intel iGPU + AMD Tonga dGPU
Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
drm: make drm_get_format_name thread-safe
Signed-off-by: Eric Engestrom
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Eric En
On Friday, 2016-11-04 13:50:25 -0400, Rob Clark wrote:
> On Fri, Nov 4, 2016 at 1:32 PM, Eric Engestrom
> wrote:
> > On Friday, 2016-11-04 13:12:51 -0400, Rob Clark wrote:
> >> On Fri, Nov 4, 2016 at 12:27 PM, Ville Syrjälä
> >> wrote:
> >> > On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark
42 matches
Mail list logo
