Buffer index / access mode bits are the same as on Gen6.
Signed-off-by: Chris Forbes
---
intel/intel_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 7d5cbe5..adda29a 100644
--- a/intel/intel_decode.c
+++ b/intel/intel
Hi Javier,
On 2014ë
11ì 20ì¼ 23:28, Javier Martinez Canillas wrote:
> Hello Inki,
>
> On 11/20/2014 03:07 PM, Inki Dae wrote:
>> Could you re-base this patch on top of exynos-drm-next? I tried to
>> separate sub drivers into independent drivers but it seems that we need
>> more times. So I w
2014-11-21 0:26 GMT+09:00 Javier Martinez Canillas
:
> Hello Inki,
>
> On 11/20/2014 04:06 PM, Inki Dae wrote:
>>> BTW, it would be great if exynos-drm-next is pulled in linux-next. That is
>>> what most people use to test integration issues so you can catch earlier any
>>> regression that may aris
On 2014ë
11ì 21ì¼ 08:12, Gustavo Padovan wrote:
> 2014-11-13 Inki Dae :
>
>> This patch fixes null pointer dereference issue incurred
>> when ipp driver is enabled and Exynos drm driver is closed.
>>
>> Non kms driver should register its own sub driver to setup necessary
>> resources, which i
From: Michel Dänzer
Setting a mode seems to clear the cursor registers, so we need to
re-program them to make sure the cursor is visible.
Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 +
drivers/gpu/drm/radeon/radeon_cursor.c
From: Michel Dänzer
It's only needed in radeon_crtc_cursor_set2.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cursor.c | 36 --
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/
On 2014ë
11ì 21ì¼ 08:54, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_drm_component_add() correctly checks if a component is present on
> drm_component_list however it release the lock right after the check
> and before we add the new component to the list. That just creates roo
On Thu, Nov 20, 2014 at 04:26:16PM -0800, Zach Reizner wrote:
> This patch implements the virtual GEM driver with PRIME sharing which
> allows vgem to import a gem object from other drivers for the purpose
> of mmap-ing them to userspace.
>
> Reviewed-by: Stéphane Marchesin
> Signed-off-by: Adam
On Thu, Nov 20, 2014 at 07:59:15PM -0800, Jasper St. Pierre wrote:
> This code was in drm_plane_helper, but missing from drm_atomic_helper,
> causing various crashes when the plane was already disabled. Just copy
> over the quick return there to prevent a crash.
>
> Signed-off-by: Jasper St. Pierr
Hi,
This patch-set contains mostly fixes for sparse warnings.
In addition, there is a fix for a memory leak, for suspend operation and
a patch that prevents the blocking of IOMMU PPR handling while waiting
to sync with hw
Oded
Alexey Skidanov (1):
amdkfd: Instead of using get function, use cont
On 11/20/2014 03:37 PM, Inki Dae wrote:
> On 2014ë
11ì 20ì¼ 23:23, Andrzej Hajda wrote:
>> On 11/20/2014 02:56 PM, Inki Dae wrote:
>>> On 2014ë
11ì 20ì¼ 22:19, Andrzej Hajda wrote:
On 11/20/2014 11:24 AM, Inki Dae wrote:
> This patch makes kms drivers to be independent drivers.
>
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 64c73ba..3b3fce7 100644
--- a/drivers/gpu/drm/am
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 40 +++
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 77cd7d5..5733e28 100644
--- a
From: kbuild test robot
Signed-off-by: Fengguang Wu
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/k
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c
b/drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c
index 2dfc4c0..66df4da 100644
--- a/drivers/gpu/
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
index 59d2407..adc3147 100644
--- a/drivers/gpu/drm/am
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 8c40d04..718f50e 10064
This patch was done due to sparse warning. It changes the definition of
doorbell_ptr in queue_properties to be with __iomem attribute, so it would
match the type which the doorbell module functions are returning.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 9 ++
From: Jay Cornwall
struct device_process_node was allocated during process registration but
not released at process deregistration.
Signed-off-by: Jay Cornwall
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 1 +
1 file changed, 1 insertion(+)
diff --gi
amdkfd uses cpu_relax() in its sync_with_hw() function. Because cpu_relax() is
defined as 'REP; NOP' on x86_64, it will block the CPU from servicing
IOMMU PPR requests.
This may cause a deadlock, because sync_with_hw() won't be completed
until the PPR request has been served.
Therefore, we need t
From: Alexey Skidanov
Signed-off-by: Alexey Skidanov
Signed-off-by: Oded Gabbay
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 21 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 ++
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/driv
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 9beb6f7..43884eb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/g
From: kbuild test robot
Signed-off-by: Fengguang Wu
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
in
s are unrelated to my issue.
Thanks!
--
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/20141121/e2ad202f/attachment-0001.html>
f-by: Oded Gabbay
It seems v6 of this patch is included in today's linux-next (ie,
next-20141121).
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/amd/amdkfd/Kconfig | 10 ++
> drivers/gpu/drm/a
On Fri, Nov 21, 2014 at 3:31 AM, Daniel Vetter wrote:
> On Thu, Nov 20, 2014 at 07:59:15PM -0800, Jasper St. Pierre wrote:
>> This code was in drm_plane_helper, but missing from drm_atomic_helper,
>> causing various crashes when the plane was already disabled. Just copy
>> over the quick return th
Inspired in part by some cute iterator macros I noticed in i915. I
currently have these in drm/msm, but seems like they should be useful
for others. Quite possibly other iterators would be useful to add for
other drivers.
Signed-off-by: Rob Clark
---
NOTE: to actually merge this, depending on t
Am 21.11.2014 um 00:49 schrieb Paolo Pisati:
> vanilla kgene/for-next as of today:
>
> 7552917 Revert "ARM: exynos_defconfig: Enable options for display panel
> support"
> ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
> 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
> cf8
On Thu, Nov 20, 2014 at 10:22:54AM -0800, Kevin Hilman wrote:
> Javier Martinez Canillas writes:
>
> > Hello,
> >
> > For completeness I'll comment what we talked with Kevin on IRC
> > since probably this is the same issue that Paolo is facing.
> >
> > On 11/20/2014 05:41 PM, Kevin Hilman wrote:
Hello Inki,
On 11/20/2014 06:01 PM, Inki Dae wrote:
> Ah, sorry. There was my misunderstanding. drm-next already is merged
> to linux-next so I think we can do the integration test if
> exynos-drm-next is merged to drm-next earlier. Anyway, I will try to
> consider your opinion.
>
Cool, having e
On Mon, 17 Nov 2014, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
>
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
>
> Specifically this
2014-11-21 Inki Dae :
> On 2014ë
11ì 21ì¼ 08:54, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > exynos_drm_component_add() correctly checks if a component is present on
> > drm_component_list however it release the lock right after the check
> > and before we add the new component
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> There is no need to dump the whole EDID block in case it contains no
> information. Just print a single line stating the block is empty instead
> of 8 lines containing only zeroes.
>
> Signed-off-by: Stefan Brüns
Reviewed-by: Jani Nikula
> ---
> dr
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> The function will also be used by a later patch, so factor it out.
>
> Signed-off-by: Stefan Brüns
> ---
> drivers/gpu/drm/drm_edid.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> Signed-off-by: Stefan Brüns
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b072041..3a10f3
On Thu, 20 Nov 2014, Stefan Brüns wrote:
> Checksumming was disabled for CEA blocks by
>
> commit 4a638b4e38234233f5c7e6705662fbc0b58d80c2
> Author: Adam Jackson
> Date: Tue May 25 16:33:09 2010 -0400
>
> drm/edid: Allow non-fatal checksum errors in CEA blocks
>
> If only the checksum is w
On Thu, 2014-11-20 at 16:26 -0800, Zach Reizner wrote:
> This patch implements the virtual GEM driver with PRIME sharing which
> allows vgem to import a gem object from other drivers for the purpose
> of mmap-ing them to userspace.
The reason I initially wanted this was to get zero-copy llvmpipe,
On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote:
> It happens on occasion that developers of generic user-space applications
> abuse the dumb buffer API to get hold of drm buffers that they can both
> mmap() and use for GPU acceleration, using the assumptions that dumb buffers
> an
2014-11-21 Inki Dae :
> On 2014ë
11ì 21ì¼ 08:12, Gustavo Padovan wrote:
> > 2014-11-13 Inki Dae :
> >
> >> This patch fixes null pointer dereference issue incurred
> >> when ipp driver is enabled and Exynos drm driver is closed.
> >>
> >> Non kms driver should register its own sub driver to
On 11/21/2014 03:14 PM, Chris Wilson wrote:
> On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote:
>> It happens on occasion that developers of generic user-space applications
>> abuse the dumb buffer API to get hold of drm buffers that they can both
>> mmap() and use for GPU accelerat
On Fri, Nov 21, 2014 at 03:48:33PM +0100, Thomas Hellstrom wrote:
> On 11/21/2014 03:14 PM, Chris Wilson wrote:
> > On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote:
> >> It happens on occasion that developers of generic user-space applications
> >> abuse the dumb buffer API to get
On 11/21/2014 03:51 PM, Chris Wilson wrote:
> On Fri, Nov 21, 2014 at 03:48:33PM +0100, Thomas Hellstrom wrote:
>> On 11/21/2014 03:14 PM, Chris Wilson wrote:
>>> On Thu, Nov 20, 2014 at 09:56:25AM +0100, Thomas Hellstrom wrote:
It happens on occasion that developers of generic user-space appl
On Fri, Nov 21, 2014 at 3:38 AM, Oded Gabbay wrote:
> Hi,
> This patch-set contains mostly fixes for sparse warnings.
> In addition, there is a fix for a memory leak, for suspend operation and
> a patch that prevents the blocking of IOMMU PPR handling while waiting
> to sync with hw
Series is:
Re
On Fri, Nov 21, 2014 at 07:17:48AM -0500, Rob Clark wrote:
> On Fri, Nov 21, 2014 at 3:31 AM, Daniel Vetter wrote:
> > On Thu, Nov 20, 2014 at 07:59:15PM -0800, Jasper St. Pierre wrote:
> >> This code was in drm_plane_helper, but missing from drm_atomic_helper,
> >> causing various crashes when th
On Fri, Nov 21, 2014 at 07:39:11AM -0500, Rob Clark wrote:
> Inspired in part by some cute iterator macros I noticed in i915. I
> currently have these in drm/msm, but seems like they should be useful
> for others. Quite possibly other iterators would be useful to add for
> other drivers.
>
> Sig
I've missed checking this and so didn't notice that there's a NULL
check missing. Since depending upon calling context the crtc might not
even be there (disable-me-harder does happen around planes, especially
in cleanup code) we need to dodge the oops and look at the global
acquire ctx.
Reported-b
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/76ad3c29/attachment.html>
On Thu, Nov 20, 2014 at 9:48 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Setting a mode seems to clear the cursor registers, so we need to
> re-program them to make sure the cursor is visible.
>
> Signed-off-by: Michel Dänzer
> Reviewed-by: Alex Deucher
Applied the series to my -next
On Fri, Nov 21, 2014 at 04:40:18PM +0100, Daniel Vetter wrote:
> I've missed checking this and so didn't notice that there's a NULL
> check missing. Since depending upon calling context the crtc might not
> even be there (disable-me-harder does happen around planes, especially
> in cleanup code) we
From: Thierry Reding
In most situations it will be useful to have the old state passed to the
->atomic_update() callback. For example if a plane is being disabled the
new state's .crtc field will be NULL, but some drivers may rely on this
field to program the CRTCs registers.
Signed-off-by: Thie
From: Thierry Reding
The plane helpers aren't pulled into the DocBook yet, so these weren't
noticed.
Signed-off-by: Thierry Reding
---
include/drm/drm_plane_helper.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index d3
From: Thierry Reding
In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -
d
From: Thierry Reding
This header uses a bunch of declarations from the drm/drm_crtc.h header,
so make sure to include that as well so that drm_atomic_helper.h can be
included standalone.
Signed-off-by: Thierry Reding
---
include/drm/drm_atomic_helper.h | 2 ++
1 file changed, 2 insertions(+)
From: Thierry Reding
The current state of CRTCs, planes and connectors currently leaks during
DRM driver ->unload() unless drivers explicitly clean it up. Since there
is nothing driver-specific about it, that cleanup can be done within the
DRM core.
Signed-off-by: Thierry Reding
---
drivers/gp
t 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/20141121/352435c6/attachment.sig>
On Fri, Nov 21, 2014 at 05:23:53PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The current state of CRTCs, planes and connectors currently leaks during
> DRM driver ->unload() unless drivers explicitly clean it up. Since there
> is nothing driver-specific about it, that cleanup can be
iving 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/20141121/61412e1a/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/4094f6d8/attachment.html>
On Fri, Nov 21, 2014 at 05:23:49PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> In most situations it will be useful to have the old state passed to the
> ->atomic_update() callback. For example if a plane is being disabled the
> new state's .crtc field will be NULL, but some drivers m
On Fri, Nov 21, 2014 at 05:23:51PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> In order to prevent drivers from having to perform the same checks over
> and over again, add an optional ->atomic_disable callback which the core
> calls under the right circumstances.
>
> Signed-off-by:
I've missed checking this and so didn't notice that there's a NULL
check missing. Since depending upon calling context the crtc might not
even be there (disable-me-harder does happen around planes, especially
in cleanup code) we need to dodge the oops and look at the global
acquire ctx.
v2: Actual
5d1 drm/exynos: Move platform drivers registration to module init
ed6778a Add linux-next specific files for 20141121
I have attached the rebased patches as well.
I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*.
Display is totally fine with exynos_defconfig (booti
Hi Gustavo,
On Fri, Nov 21, 2014 at 5:24 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> DP was leaked everytime function returns EPROBE_DEFER, free it before
> returning.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
> 1
his 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/20141121/1e248912/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/1b9dc304/attachment.html>
rubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/5c52ecdf/attachment.html>
s it was never used
>> Add skeleton implementation of the Get Version IOCTL
>>
>> Signed-off-by: Oded Gabbay
>
> It seems v6 of this patch is included in today's linux-next (ie,
> next-20141121).
>
>> drivers/gpu/drm/Kconfig | 2 +
>>
On 11/21/2014 07:04 PM, Jim Davis wrote:
> Building with the attached random configuration file,
>
> drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c: In function
> âkfd_doorbell_initâ:
> drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:97:2: error: implicit
> declaration of function âioremapâ
> [-We
This patch fixes a compilation error when using certain configuration by
including the file io.h in kfd_doorbell.c
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
b/drivers/gpu
On Fri, Nov 21, 2014 at 09:34:45PM +0200, Oded Gabbay wrote:
> The DRM_AMDGPU symbol belongs to AMD's new Linux kernel graphic
> driver, called amdgpu. That driver is not yet upstreamed, so its
> symbol is not present in any Kconfig file. However, internally we work
> with that driver so that's why
desktop.org/archives/dri-devel/attachments/20141121/0a1aab0c/attachment.sig>
Hi Linus,
just two radeon and two intel fixes, endian and regression fixes.
Dave.
The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9:
Linux 3.18-rc5 (2014-11-16 16:36:20 -0800)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux dr
Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.
Solve this by adding a bitmask of currently attached planes
Add helper macros to iterate the current, or incoming set of planes
attached to a crtc. These helpers are only available for drivers
converted to use atomic-helpers.
Signed-off-by: Rob Clark
---
Documentation/DocBook/drm.tmpl | 1 +
include/drm/drm_atomic_helper.h | 26 +++
On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote:
> On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote:
> > on vlv, if ipvr is installed, it need be manually unloaded before
> > i915, otherwise user might run into use-after-free issue.
>
> Huh? That doesn't sound right. What e
On Fri, Nov 21, 2014 at 03:28:32PM -0500, Rob Clark wrote:
> Add helper macros to iterate the current, or incoming set of planes
> attached to a crtc. These helpers are only available for drivers
> converted to use atomic-helpers.
>
> Signed-off-by: Rob Clark
> ---
> Documentation/DocBook/drm.t
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index e13c67c..8dfac37 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/d
gt; > + if ((crtc)->state->plane_mask & (1 << drm_plane_index(plane)))
>
> Implement this as drm_crtc_for_each_pending_plane(plane, (crtc)->state)?
> Which means _pending is a strange name ...
Yeah, I think the drm_crtc_for_each_pending_plane() could be
drm_crtc
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/068c8ae6/attachment.sig>
pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/725d4a45/attachment-0001.sig>
On Fri, Nov 21, 2014 at 3:40 PM, Oded Gabbay wrote:
> Signed-off-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
> b/drivers/gpu/drm/amd/amdkfd/Kco
This patch removes the dependency of amdkfd upon DRM_AMDGPU symbol in amdkfd's
Kconfig file.
This is done because amdgpu driver is not yet upstreamed and therefore,
DRM_AMDGPU symbol is not present in any Kconfig file.
Reviewed-by: Alex Deucher
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/am
On Fri, Nov 21, 2014 at 3:07 PM, Oded Gabbay wrote:
> This patch fixes a compilation error when using certain configuration by
> including the file io.h in kfd_doorbell.c
>
> Signed-off-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 1 +
> 1 file
Hi Dave,
first batch of amdkfd patches after initial merge. Highlights:
- Fixes for sparse warnings
- Memory leak fix
- Fix for deadlock between amdkfd and iommu
The following changes since commit ed1e8777a56f3523712506d608a29f57ed37b613:
Merge branch 'drm-next-3.19' of git://people.freedeskt
Hi Dave,
Now that we have the bits needed for mdp5 atomic, here is the followup
pull request I mentioned. Main highlights are:
1) mdp5 multiple crtc and public plane support (no more hard-coded mixer setup!)
2) mdp5 atomic conversion
3) couple atomic helper fixes for issues found during mdp5 ato
2014-11-21 16:10 GMT-05:00 Rob Clark :
> Hi Dave,
>
> Now that we have the bits needed for mdp5 atomic, here is the followup
> pull request I mentioned. Main highlights are:
>
> 1) mdp5 multiple crtc and public plane support (no more hard-coded mixer
> setup!)
> 2) mdp5 atomic conversion
> 3) cou
https://bugzilla.kernel.org/show_bug.cgi?id=85421
--- Comment #12 from Hin-Tak Leung ---
Created attachment 158451
--> https://bugzilla.kernel.org/attachment.cgi?id=158451&action=edit
/var/log/message, another GPU crash under mesa 10.3.3
Fedora shipped mesa 10.3.3
http://koji.fedoraproject.or
This fixes an issue when trying to use -v and -C together. When trying
to read the page flip event, we are interrupted by the SIGALRM that
comes in, and so we think we timed out when we simply got EINTR. While
we could just loop checking for EINTR, SIGALRM is just bad idea to
begin with, so just re
chan);
> >>
> >> and add back
> >>
> >> nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);
> > Making your suggested change on top of each 86be4f21 and 1c6aafb5 made
> > no noticeable difference in either of the two behaviors.
> >
> >> If that fails you should compile your kernel with trace events, to get
some debugging info from the fences. I'll post debugging info if this does
not fix it.
> > Happy to gather whatever debug log or tracing data you need :)
> >
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141121/4614ffb4/attachment-0001.html>
On Fri, Nov 21 2014 at 03:48:33 AM, Stefano Stabellini wrote:
> On Mon, 17 Nov 2014, Stefano Stabellini wrote:
>> Hi all,
>> I am writing this email to ask for your advice.
>>
>> On architectures where dma addresses are different from physical
>> addresses, it can be difficult to retrieve the phy
Fixes not returning correct error code value in qxl_drv.c for the function,
qxl_pci_probe as this is a error with the device rather then an incorrect
value as stated by the DRM_ERROR statement above the return if this function
returns a error.
Signed-off-by: Nicholas Krause
---
drivers/gpu/drm/qx
[1.] gma500_gfx black LVDS if VGA connected
[2.] bugs.launchpad.net/ubuntu/+source/linux/+bug/1393945
[3.] gma500_gfx lvds vga
[4.] 3.18.0-031800rc5-generic
Greetings David,
I am wondering whether we can remove the fix me in this file related to
not needing a spin lock or should I remove the comment for locks and then
remove the FIX ME if we need the lock here.
Regards Nick
On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst
wrote:
> Op 20-11-14 om 05:06 schreef Michael Marineau:
>> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
>> wrote:
>>> Hey,
>>>
>>> On 19-11-14 07:43, Michael Marineau wrote:
On 3.18-rc kernel's I have been intermittently experiencing
Building with the attached random configuration file,
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c: In function âkfd_doorbell_initâ:
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c:97:2: error: implicit
declaration of function âioremapâ
[-Werror=implicit-function-declaration]
kfd->doorbell_kernel
ot pass drm_bridge_funcs to drm_bridge_init
> 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups
> 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 28655d1 drm/exynos: Move platform drivers registration to module init
> ed6778a Add linux-next specific files for 201411
96 matches
Mail list logo
