The .enable_vblank() operation is only called when vblank interrupts are
disabled, but no similar check exists when disabling vblank interrupts.
This leads to .disable_vblank() being called with vblank interrupts
already disabled and the device possibly runtime suspended. As the
operation is called
Hey Oded,
so I pulled -fixes into -next this morning and made amdkfd build
again, it had a few conflicts in it,
I've pushed a drm-next branch with the conflicts resolved and amdkfd
that builds, the only one I'm a bit scared on was the size calculation
fixup for the removal of the max processes.
From: Dave Airlie
Al Viro added this to the mm finally, so instead
of opencoding it use kvfree instead.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
include/drm/drm_mem_util.h| 5 +
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git
On 29.01.2015 11:36, Dave Airlie wrote:
> From: Dave Airlie
>
> Al Viro added this to the mm finally, so instead
> of opencoding it use kvfree instead.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
> include/drm/drm_mem_util.h| 5 +
> 2
On 29.01.2015 08:09, Laurent Pinchart wrote:
> The .enable_vblank() operation is only called when vblank interrupts are
> disabled, but no similar check exists when disabling vblank interrupts.
> This leads to .disable_vblank() being called with vblank interrupts
> already disabled and the device p
These two copy to/from VGA memory, however on the Silicon
Motion SMI750 VGA card on a 64-bit system cause console corruption.
This is due to the hw being buggy and not handling a 64-bit transaction
correctly.
We could try and create a 32-bit version of these routines,
but I'm not sure the optimis
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150129/c6468389/attachment-0001.html>
ppear
Tom, any ideas?
--
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/20150129/a9f75139/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/fe77d06e/attachment.html>
On 01/28/2015 09:41 PM, Alex Deucher wrote:
> 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.freedeskt
On 01/29/2015 03:49 AM, Dave Airlie wrote:
> Hey Oded,
>
> so I pulled -fixes into -next this morning and made amdkfd build
> again, it had a few conflicts in it,
>
> I've pushed a drm-next branch with the conflicts resolved and amdkfd
> that builds, the only one I'm a bit scared on was the size
org/archives/dri-devel/attachments/20150129/1a050515/attachment.html>
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 0d8694f..0fd5927 100644
---
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index a8be6df..1c385c2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_modu
This patch changes a BUG_ON() statement to pr_debug, in case the user tries to
update a non-existing queue.
Signed-off-by: Oded Gabbay
Reviewed-by: Ben Goz
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers
Hi Dave -
i915 fixes all around, mostly cc: stable.
Was surprised to see your pull request already on Tuesday, are you
planning on doing another one before -rc7?
BR,
Jani.
The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce:
Linux 3.19-rc6 (2015-01-25 20:04:41 -0800
u for fixing this, and remembering the bug!
How did you know it was fixed?
--
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/20150129/
From: Jay Cornwall
dqm->queue_count tracks queues in the active state only. In a few
places this count is modified unconditionally, leading to an incorrect
value when the UPDATE_QUEUE ioctl is used to make a queue inactive.
Signed-off-by: Jay Cornwall
Reviewed-by: Ben Goz
Signed-off-by: Oded G
From: Jay Cornwall
CP microcode uses undocumented bits in this register to record queue
state information. The KFD zeroes these bits in update_mqd, when invoked
through the UPDATE_QUEUE ioctl, causing incoherent state when the ioctl
is used to successively unmap and map a queue.
Since the queue
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/ffdea6e9/attachment.html>
ves/dri-devel/attachments/20150129/480e475d/attachment.html>
The series are Reviewed-by: Jammy Zhou
Regards,
Jammy
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Gabbay, Oded
Sent: Thursday, January 29, 2015 4:35 PM
To: dri-devel at lists.freedesktop.org
Subject: [PATCH 3/3] drm/amdkfd: Don't crea
Am 29.01.2015 um 08:46 schrieb Oded Gabbay:
>
>
> On 01/28/2015 09:41 PM, Alex Deucher wrote:
>> 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
il if you have more questions.
Thanks,
Christian.
--
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/20150129/88111f02/attachment.html>
From: Fabio Estevam
drm_bridge_attach() may return different errors on failure, not just -EINVAL, so
it is better to propagate the real error instead.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/bridge/dw_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/g
The exynos_plane_dpms can cause misunderstanding as using dpms term
because it is irrelevant with dpms functionality of DRM. Split to
functions fit for the one purpose instead of DPMS flags.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm/ex
The exynos_update_plane functions can be called from set_plane as well
as set_crtc and pageflip. Currently the plane displayed by set_plane
isn't called exynos_plane_on function and if plane is disabled, it calls
exynos_plane_off, so it causes disharmory of plane on/off.
This is caused from commit
Am Donnerstag, den 29.01.2015, 08:48 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam
>
> drm_bridge_attach() may return different errors on failure, not just -EINVAL,
> so
> it is better to propagate the real error instead.
>
> Signed-off-by: Fabio Estevam
Acked-by: Philipp Zabel
> ---
>
ac7 M drivers
Attached the complete 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/20150129/b16be879/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/835daf25/attachment.html>
On Wed, Jan 28, 2015 at 01:46:53PM -0500, Rob Clark wrote:
> 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 c
On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
>
> 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 alwa
On Thu, Jan 29, 2015 at 12:15:03PM +0900, Michel Dänzer wrote:
> On 29.01.2015 08:09, Laurent Pinchart wrote:
> > The .enable_vblank() operation is only called when vblank interrupts are
> > disabled, but no similar check exists when disabling vblank interrupts.
> > This leads to .disable_vblank()
On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
>
> On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> >On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
> >>
> >>On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> >>>From: Rob Clark
> >>>
> >>>In DRM/KMS we are lacking a goo
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #29 from Maarten Lankhorst ---
Thanks, that rules out 1 possibility. There is probably no bug in refcounting
irqs. :P
--
You are receiving this mail because:
You are watching the assignee of the bug.
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/d4b9420a/attachment.html>
u 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/20150129/757fad0b/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #30 from Maarten Lankhorst ---
Can you empty the contents of the radeon_fence_schedule_check function in
radeon_fence.c?
It should make the pauses worse, giving me a chance to find them in the log.
:-)
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #31 from Gustaw Smolarczyk ---
Do you mean on top of the latest patch?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=91861
--- Comment #7 from Christian König ---
(In reply to Mike S. from comment #6)
> 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
On Thu, Jan 29, 2015 at 12:55:48PM +, Tvrtko Ursulin wrote:
>
> On 01/29/2015 11:57 AM, Daniel Vetter wrote:
> >On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
> >>
> >>On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> >>>On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wr
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #32 from Maarten Lankhorst ---
You can keep print refcounts or remove it, it doesn't matter much either way. I
just want to have at least 'another approach' applied.
--
You are receiving this mail because:
You are watching the assign
On Tue, Jan 27, 2015 at 03:43:49PM +, 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 unles
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #33 from Gustaw Smolarczyk ---
Created attachment 165161
--> https://bugzilla.kernel.org/attachment.cgi?id=165161&action=edit
dmesg after disabling radeon_fence_schedule_check()
I chose to leave the refcount printing patch as it is.
> -Original Message-
> From: Gabbay, Oded
> Sent: Thursday, January 29, 2015 2:46 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH] drm/radeon: don't init gpuvm if accel is disabled
>
>
>
> On 01/28/2015 0
-
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/20150129/1a47ca3a/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150129/28a140af/attachment.html>
On 01/29/2015 03:54 PM, Deucher, Alexander wrote:
>> -Original Message-
>> From: Gabbay, Oded
>> Sent: Thursday, January 29, 2015 2:46 AM
>> To: Alex Deucher; dri-devel at lists.freedesktop.org
>> Cc: Deucher, Alexander; stable at vger.kernel.org
>> Subject: Re: [PATCH] drm/radeon: don't
g 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/20150129/22da7161/attachment.html>
Op 27-01-15 om 09:25 schreef Sumit Semwal:
> Add some helpers to share the constraints of devices while attaching
> to the dmabuf buffer.
>
> At each attach, the constraints are calculated based on the following:
> - max_segment_size, max_segment_count, segment_boundary_mask from
>device_dma_pa
> */
> > - for (j = 0; j < msgs[i].len; j++) {
> > + transfer_size = dp_aux_i2c_transfer_size;
> > + for (j = 0; j < msgs[i].len; j += msg.size) {
> > msg.buffer = msgs[i].buf + j;
> > - msg.size = 1;
> > + msg.size = min((unsigned)transfer_size, msgs[i].len -
> > j);
>
> Could make transfer_size unsigned in the first place.
>
> >
> > - err = drm_dp_i2c_do_msg(aux, &msg);
> > - if (err < 0)
> > + transfer_size = drm_dp_i2c_drain_msg(aux, &msg);
> > + if (transfer_size < 0) {
> > + err = transfer_size;
> > break;
> > + }
>
> Maybe this is a bit more straight forward?
>
> err = drm_dp_i2c_drain_msg(aux, &msg);
> if (err < 0)
> break;
> transfer_size = err;
>
That and making transfer_size unsigned seems like a good combination. Will
adopt for v4.
--
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/20150129/ecf4d954/attachment.sig>
Hi Ajay,
2015-01-20 Ajay Kumar :
> Use drm_bridge helpers to modify the driver to support
> i2c driver model.
>
> Signed-off-by: Ajay Kumar
> Acked-by: Inki Dae
> Tested-by: Rahul Sharma
> Tested-by: Javier Martinez Canillas
> Tested-by: Gustavo Padovan
> Tested-by: Sjoerd Simons
> ---
>
On Thu, Jan 29, 2015 at 02:24:09PM +, Simon Farnsworth wrote:
> On Thursday 29 January 2015 15:30:36 you wrote:
> > On Tue, Jan 27, 2015 at 03:43:49PM +, Simon Farnsworth wrote:
> --snip--
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > inde
.16rc6 I get always 60FPS (vsync enabled).
--
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/20150129/894ba786/attachment-0001.html>
Hi Gustavo,
I think Thierry already fixed it. Check this.
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/Kconfig
Regards,
Ajay
On Thu, Jan 29, 2015 at 7:59 PM, Gustavo Padovan wrote:
> Hi Ajay,
>
> 2015-01-20 Ajay Kumar :
>
>> Use drm_bridge helpe
On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
> +/*
> + * recalc_constraints - recalculates constraints for all attached devices;
> + * useful for detach() recalculation, and for dma_buf_recalc_constraints()
> + * helper.
> + * Returns recalculated constraints in recalc_cons, or
Hi Thierry,
I think you forgot to take this patch!
Can you check this?
Regards,
Ajay Kumar
On Tue, Jan 20, 2015 at 10:08 PM, Ajay Kumar
wrote:
> From: Vincent Palatin
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin
> Sig
From: Christian König
This is a workaround for RS880 and older chips which seem to have
an additional limit on the minimum PLL input frequency.
v2: fix signed/unsigned warning
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_display.c | 3 +++
1 file changed, 3 insertions(+)
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/20150129/64a81239/attachment.html>
On Thu, Jan 29, 2015 at 7:55 AM, Tvrtko Ursulin
wrote:
>
> On 01/29/2015 11:57 AM, Daniel Vetter wrote:
>>
>> On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
>>>
>>>
>>> On 01/29/2015 11:30 AM, Daniel Vetter wrote:
On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin
device would be capable of 3
> > byte transfers, and could possibly perform better with 3 byte transfers
> > rather than 1.
> >
> > Having said that, this is all hypothetical until we find devices that do
> > partial replies - no-one's been able to find such a device so far.
> >
--
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/20150129/a4913bad/attachment.sig>
On Thu, Jan 29, 2015 at 10:01 AM, Christian König
wrote:
> From: Christian König
>
> This is a workaround for RS880 and older chips which seem to have
> an additional limit on the minimum PLL input frequency.
>
> v2: fix signed/unsigned warning
>
> Signed-off-by: Christian König
Added to my
Cairo
- Add cflags only when needed (tests/util).
- Leave the link against cairo for the final object, not the static
library.
- Use Makefile.sources for the sources list.
- Drop unused includes
Signed-off-by: Emil Velikov
---
tests/modetest/Makefile.am | 1 -
tests/modetest/buffers.c|
Signed-off-by: Emil Velikov
---
Android.mk| 1 +
CleanSpec.mk | 1 +
tests/modetest/Android.mk | 5 -
tests/util/Android.mk | 13 +
4 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 tests/util/Android.mk
diff --git a/Android.
Signed-off-by: Emil Velikov
---
tests/util/Makefile.sources | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/util/Makefile.sources b/tests/util/Makefile.sources
index e91fa72..e5f8511 100644
--- a/tests/util/Makefile.sources
+++ b/tests/util/Makefile.sources
@@ -2,5 +2,7 @@ UTIL_FILES
Signed-off-by: Emil Velikov
---
tests/kms/Makefile.am | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am
index c84bae0..764a00d 100644
--- a/tests/kms/Makefile.am
+++ b/tests/kms/Makefile.am
@@ -8,6 +8,9 @@ AM_CFLAGS = \
noinst_LTLIBRARIES = lib
Hi Russell!
On 29 January 2015 at 20:09, Russell King - ARM Linux
wrote:
> On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
>> +/*
>> + * recalc_constraints - recalculates constraints for all attached devices;
>> + * useful for detach() recalculation, and for dma_buf_recalc_constrai
Signed-off-by: Emil Velikov
---
tests/kms/Makefile.am | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am
index 0e1b4ef..d033934 100644
--- a/tests/kms/Makefile.am
+++ b/tests/kms/Makefile.am
@@ -29,5 +29,11 @@ noinst_PROGRAMS =
Signed-off-by: Emil Velikov
---
tests/kms/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am
index 3b37e3e..fe7dd98 100644
--- a/tests/kms/Makefile.am
+++ b/tests/kms/Makefile.am
@@ -41,4 +41,4 @@ kms_steal_crtc_SOURCES =
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/a234f456/attachment.html>
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.
v2: handle vm_fini as well
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786
S
On 23/01/15 16:08, Thierry Reding wrote:
> From: Thierry Reding
>
> This is a stash of commits that I've been carrying for a couple months.
> Laurent really wanted to have the connector name patch for modetest so
> I thought I'd send them all out for review.
>
Hi Thierry,
As mentioned earlier I
On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
> So, short answer is, it is left to the exporter to decide. The dma-buf
> framework should not even attempt to decide or enforce any of the
> above.
>
> At each dma_buf_attach(), there's a callback to the exporter, where
> the exporter
On Thu, Jan 29, 2015 at 3:35 AM, Oded Gabbay wrote:
> Signed-off-by: Oded Gabbay
For the series:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_dev
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/6a5fac0f/attachment.html>
The shmobile drm driver selects BACKLIGHT_CLASS_DEVICE
as of 0a5a5499ad88 "drm: shmobile: Add dependency on
BACKLIGHT_CLASS_DEVICE", but that option in turn depends
on BACKLIGHT_LCD_SUPPORT, so we actually have to select
both, or alternatively use 'depends on BACKLIGHT_CLASS_DEVICE'.
Further, the
id as on 3.16rc6 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/20150129/e6e89734/attachment.html>
On 29 January 2015 at 21:17, Russell King - ARM Linux
wrote:
> On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
>> So, short answer is, it is left to the exporter to decide. The dma-buf
>> framework should not even attempt to decide or enforce any of the
>> above.
>>
>> At each dma_bu
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
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/f7e0f7e5/attachment.html>
On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
>>
>> 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
The irony here of the hung task detector triggering a locking disaster.
The laptop hung completely after spewing this partial trace.
[11881.16] ==
[11881.16] [ INFO: possible circular locking dependency detected ]
[11881.16] 3.19.0-rc
Commits 8eb17f05bc1802b50f8b536406357b87f63cf61d
("drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init") and
fbc4572e9c48e45bdfeb2ee8c8f0198b3e70c030
("drm/bridge: make bridge registration independent of drm flow")
changed the bridge API without taking into account sti_dvo bridge
which caus
On 01/29/2015 11:57 AM, Daniel Vetter wrote:
> On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
>>
>> On 01/29/2015 11:30 AM, Daniel Vetter wrote:
>>> On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> From: R
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on
ing 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/20150129/77021e96/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/4a1c3133/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/1b7d5917/attachment.html>
On 64-bit targets, tegra_gem_mmap doesn't return the
offset to userspace. As such, subsequent calls to mmap(2)
fail. Add a new tegra_gem_mmap2 ioctl to fix this.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/tegra/drm.c | 21 +
include/uapi/drm/tegra_drm.h | 8
2 fi
Hello all,
It's time for another Android fueled round of fixes.
Mostly trivial and self explanatory patches enough to get things
building (rather quietly) on Android 5, x86_64
The series can be found at in branch for-android at
https://github.com/evelikov/libdrm/
Cheers,
Emil
freedreno/Androi
Signed-off-by: Emil Velikov
---
tests/util/Makefile.am | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tests/util/Makefile.am b/tests/util/Makefile.am
index f8e0b17..aaaf932 100644
--- a/tests/util/Makefile.am
+++ b/tests/util/Makefile.am
@@ -1,13 +1,14 @@
inclu
Signed-off-by: Emil Velikov
---
tests/modetest/Makefile.am | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 40dad3e..a8b9a3a 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -1,12 +1,
With 64bit bionic mmap now handles 64bit offset, thus we no longer
need the __mmap2 trick.
Fix from Chih-Wei Huang, over at the google forums.
Cc: Chih-Wei Huang
Signed-off-by: Emil Velikov
---
libdrm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libdrm.h b/libdrm.h
ind
Under 64bit Android the compiler throws a -Wsign-compare warning.
Typecast the variable dev to silence the build.
Signed-off-by: Emil Velikov
---
xf86drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xf86drm.c b/xf86drm.c
index 345325a..b41c1d8 100644
--- a/xf86drm.c
+++
drm_stats_t::count is of type unsigned long, while i is an int. Make the
latter an unsigned int.
Spotted as -Wsign-compare warning while building under Android 5.
Signed-off-by: Emil Velikov
---
xf86drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xf86drm.c b/xf86drm.c
i
From: Chih-Wei Huang
Signed-off-by: Chih-Wei Huang
---
freedreno/Android.mk | 3 ---
intel/Android.mk | 1 -
nouveau/Android.mk | 3 ---
radeon/Android.mk| 3 ---
4 files changed, 10 deletions(-)
diff --git a/freedreno/Android.mk b/freedreno/Android.mk
index 243a1e2..22520fb 100644
-
On Thu, Jan 29, 2015 at 10:47 AM, Russell King - ARM Linux
wrote:
> On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
>> So, short answer is, it is left to the exporter to decide. The dma-buf
>> framework should not even attempt to decide or enforce any of the
>> above.
>>
>> At each d
On Thu, Jan 29, 2015 at 1:46 PM, Sean Paul wrote:
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index c15d781..9035257 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -167,6 +167,12 @@ struct drm_tegra_gem_get_flags {
>
On Thu, Jan 29, 2015 at 10:47 AM, Emil Velikov
wrote:
> With 64bit bionic mmap now handles 64bit offset, thus we no longer
> need the __mmap2 trick.
>
> Fix from Chih-Wei Huang, over at the google forums.
>
> Cc: Chih-Wei Huang
> Signed-off-by: Emil Velikov
> ---
> libdrm.h | 2 +-
> 1 file ch
On 64-bit targets, tegra_gem_mmap doesn't return the
offset to userspace. As such, subsequent calls to mmap(2)
fail. Add a new tegra_gem_mmap2 ioctl to fix this.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/tegra/drm.c | 21 +
include/uapi/drm/tegra_drm.h | 9 +
2 f
1 - 100 of 114 matches
Mail list logo
