https://bugzilla.kernel.org/show_bug.cgi?id=22312
Chris Nystrom changed:
What|Removed |Added
CC||cnystrom at gmail.com
--- Comment #8 from
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/37fb78c7/attachment.html>
On Tue, Mar 25, 2014 at 12:35:06PM -0700, Joe Perches wrote:
> Just about all of these have been converted to __func__,
> so convert the last uses.
>
> Signed-off-by: Joe Perches
Pulled into drm-intel, should land in 3.15.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++---
On Tue, Mar 25, 2014 at 7:51 PM, Damien Lespiau
wrote:
> On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
>> Or we simply do this per-pixel format with one for each framebuffer plane,
>> i.e.
>>
>> struct drm_get_plane_fb_limits {
>> uint32_t plane_id; /* in */
>> uint32_
ant to take a second look at this and try to compare the settings
fglrx and radeon uses for the same mode.
--
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/20140325/e1b25102/attachment.html>
2014-03-25 20:06 GMT+09:00 Arnd Bergmann :
> The recently added PTN3460 device driver uses interfaces that
> are provided by the KMS helper infrastructure, so we should
> explicitly select that to avoid this linker error:
>
> ERROR: "drm_helper_probe_single_connector_modes"
> [drivers/gpu/drm/brid
ttachments/20140325/10a55ac0/attachment.html>
On Tue, Mar 25, 2014 at 7:40 PM, David Herrmann
wrote:
> Hi
>
> On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter wrote:
>> Besides the issue at hand though I think drivers need to make sure
>> that the device they use for attaching does outlive the dma-buf. Which
>> for real hotpluggin probably me
On Tue, Mar 25, 2014 at 6:24 PM, Daniel Vetter wrote:
> On Tue, Mar 25, 2014 at 6:53 AM, Dave Airlie wrote:
>> So with runtime pm on nouveau, if the card gets powered down, and then
>> you access a connector via sysfs,
>>
>> drm_sysfs.c:status_show locks the connector and calls into the driver,
>
From: Sagar Kamble
v2: Added description for "src-color" and "constant-alpha" property.
Cc: Rob Landley
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: David Herrmann
Cc: Alex Deucher
Cc: "Ville Syrj?l?"
Cc: Sagar Kamble
Cc: "Purushothaman, Vijay A"
Cc: linux-doc at vger.kern
From: Sagar Kamble
This patch creates a generic blending bitmask property modeled after
glBlendFunc. Drivers may support subset of these values.
v2: Removing blend properties that are not applicable
[Damien's Review Comments].
Adding DRM_MODE_PROP_32BIT_PAIR flag to blend property.
Cc:
From: Sagar Kamble
With this patch new flag DRM_MODE_PROP_32BIT_PAIR is added that will help make
use
of 64 bit value of bitmask property as two 32 bit values.
Cc: airlied at linux.ie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Sagar Kamble
---
dr
of the display mode. See radeon_compute_pll_avivo() in
radeon_display.c
--
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/20140325/e
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/cf56cf69/attachment.html>
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
> On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote:
> > On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
> > > For the record,
> > >
> > > 16:30 < agd5f> ickle, our GPUs don't have selectable cursor sizes
> >
On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote:
> On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
> > For the record,
> >
> > 16:30 < agd5f> ickle, our GPUs don't have selectable cursor sizes
> > 16:31 < agd5f> so on the newer ones, xf86-video-modesetting, etc. would
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/20140325/ad84fb03/attachment.html>
>
> There are two things that don't work too well with this. First this
> causes the build to break if the build machine doesn't have the new
> public header (include/uapi/linux/dma-buf.h) installed yet. So the only
> way to make this work would be by building the kernel once with SAMPLES
> disabl
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
> Or we simply do this per-pixel format with one for each framebuffer plane,
> i.e.
>
> struct drm_get_plane_fb_limits {
> uint32_t plane_id; /* in */
> uint32_t fourcc; /* in */
> struct drm_plane_limits limits[MAX_F
On Mon, 24 Mar 2014, Daniel Vetter wrote:
> >> Like I've said the entire teardown sequence for legacy drm drivers is
> >> terminally busted, so the only hope we have is to reapply this missing
> >> duct-tape which made your X crash. But if that itself isn't a regression
> >> there's no way to fi
Hi all,
On 2014? 03? 24? 16:35, Daniel Vetter wrote:
> Hi all,
>
> Adding piles more people.
>
> For the first case of caching the iommu mapping there's different
> answers, depening upon the exact case:
>
> 1) You need to fix your userspace to not constantly re-establish the sharing.
>
> 2) W
has a better idea on how to solve
this.
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/20140325/319b0d46/attachment.sig>
On Mon, 24 Mar 2014 23:39:01 +0100
Laurent Pinchart wrote:
> Hi Jean-Fran?ois,
Hi Laurent,
> Thank you for the patch.
>
> On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote:
> > The 'slave encoder' structure of the tda998x driver asks for glue
> > between the DRM driver and the encoder
So with runtime pm on nouveau, if the card gets powered down, and then
you access a connector via sysfs,
drm_sysfs.c:status_show locks the connector and calls into the driver,
the driver then does a runtime_get_sync, which causes resume to happen
which causes modesetting to reset the mode, which t
Hi Sean,
In your commit "drm/exynos: hdmi: support extra resolutions using
drm_display_mode timings" you added several more HDMI PHY configs to
exynos-drm. Thanks for that.
Can you explain where these magic numbers came from?
I'm interested in adding 85.5MHz for 1366x768 support.
Thanks,
Danie
2014-03-25 0:53 GMT+09:00 Damien Lespiau :
> As patch 8/11 explains, I noticed that we where evaluating the arguments to
> drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good
> reason. By pulling the test on drm_debug before calling drm_ut_debug_printk(),
> we skip those in
Hey,
op 21-03-14 14:04, Thomas Hellstrom schreef:
> On 03/21/2014 01:12 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 21-03-14 09:27, Thomas Hellstrom schreef:
>>> On 03/21/2014 12:55 AM, Dave Airlie wrote:
On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse
wrote:
> On Thu, Oct 18, 2012
The patch adds LD9040 parallel RGB panel driver with SPI control interface.
The driver uses drm_panel framework.
Signed-off-by: Andrzej Hajda
---
v2: removed useless include
---
drivers/gpu/drm/panel/Kconfig| 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/pane
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/6b8907b7/attachment-0001.html>
From: Dave Airlie
this stops the device from being deleted before all the dma-bufs
on it are freed, this fixes an oops when you unplug a udl device while
it has imported a buffer from another device.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_gem.c | 11 ---
1 file changed,
/vmwgfx/vmwgfx_drv.h
index 8c6b71f..6b252a8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -40,9 +40,9 @@
#include
#include "vmwgfx_fence.h"
-#define VMWGFX_DRIVER_DATE "20140228"
+#define VMWGFX_DRIVER_DATE "20140325"
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index de8a9dc..c7
Make sure only buffer objects that are referenced by the client can be mapped.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resou
A function to be used to check whether a caller has put a ref object
(opened) a struct ttm_base_object
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/ttm/ttm_object.c | 46 ++
include/drm/ttm/ttm_object.h |4
2 file
If using legacy (non-prime) surface sharing, only allow surfaces
to be shared between clients with the same master. This will block
malicious clients from peeking at contents at surfaces from other
(possibly vt-switched) masters.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drive
Allow prime fds and at the same time block legacy handles for render-nodes
in the surface reference ioctls. This means these ioctls can be used
directly from prime-aware clients, and that they can be called from
render-nodes.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/g
These ioctls will anyway only succeed if the client previously opened
referenced the object. Furthermore, closing the client would implicitly
execute the same action. This prevents clients from blocking on UNREF if
their master dropped, and will allow masters to UNREF after dropping
master privileg
The following restrictions affect clients connecting using legacy nodes:
*) Masters that have dropped master privilieges are not considered
authenticated until they regain master privileges.
*) Clients whose master have dropped master privileges block interruptibly on
ioctls requiring authe
Don't use a per-master semaphore (ttm lock) for reservation protection, but
rather a per-device semaphore. This is needed since clients connecting using
render nodes aren't master aware.
The ttm lock used should probably be replaced with a reader-write semaphore
once the function down_xx_interrupt
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/drm_drv.c | 18 ++
include/drm/drmP.h|1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index cf2dfb7..03711d0 100644
--- a/drivers/g
The master management was previously protected by the drm_device::struct_mutex.
In order to avoid locking order violations in a reworked dropped master
security check in the vmwgfx driver, break it out into a separate master_mutex.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
dri
It doesn't appear to be used anywhere.
Signed-off-by: Thomas Hellstrom
Reviewed-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c |5 -
include/drm/drmP.h |2 --
2 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index dc2c6
Add a drm_is_legacy() helper, constify argument to drm_is_render_client(),
and use / change helpers where appropriate.
v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/drm_crtc.c |4 ++--
dr
Like for render-nodes, there is no point in maintaining the master concept
for control nodes, so set the struct drm_file::master pointer to NULL.
At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
allowed when called through the control node. Previously the caller also
ne
Helps reviewing and understanding these checks.
v2: Remove misplaced newlines.
Signed-off-by: Thomas Hellstrom
Reviewed-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 113 ++---
1 file changed, 75 insertions(+), 38 deletions(-)
diff --git a/drivers/
control- and render nodes are intended to be master-less.
v2: Replace tests for !legacy with tests for !mode_group for readability.
Signed-off-by: Thomas Hellstrom
Reviewed-by: David Herrmann
---
drivers/gpu/drm/drm_crtc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
Hi!
Some of the patches are already reviewed on dri-devel, but included for
completeness.
Patch 6 and 7 are drm patches and in particular patch 6 might be good to
have an extra pair of eyes on.
Thanks,
Thomas
So I've got a reproducable oops with udl sharing from i915,
start X, connect UDL, randr it into position, rip out udl device, kill X,
we get an oops when dma_unmap_sg in i915_gem_unmap_dma_buf gets
called, attachment->dev is pointing to a freed structure, now the drm
+ udl driver points dev->dev
On Tue, Mar 25, 2014 at 01:25:15PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc"
> causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to
> complain loudly during a kernel panic or sysrq processing. This is
On Tue, Mar 25, 2014 at 11:23:46AM +, Dmitry Malkin wrote:
> Hi,
> will you accept bash scripts for reloading driver/X/FLR for intel-gpu-tools
> to uncover exists and future bugs besides those patches?
i-g-t/tests/drv_module_reload we have already, so basic coverage is there.
It it's run in o
Hi Dave,
this is the third pull request for 3.15 radeon changes. Highlights this
time:
- More DP work from Alex, especially making use of the new DP aux helpers
- Marek's 1D and linear tiling fixes for CIK
The following changes since commit 63ac07cdee6e1f2bf748ac3f28662e3c01a72496:
drm/bridg
From: Thierry Reding
Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc"
causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to
complain loudly during a kernel panic or sysrq processing. This is
caused by nobody acquiring the modeset lock in these code paths.
This pa
This patch replaces panel bindings for panel initialized by boot loader
with bindings to proper ld9040 panel.
Signed-off-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4210-universal_c210.dts | 71 +++--
1 file changed, 54 insertions(+), 17 deletions(-)
diff --git a/arch/arm/
The patch adds LD9040 parallel RGB panel driver with SPI control interface.
The driver uses drm_panel framework.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/panel/Kconfig| 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-ld9040.c | 377 +++
The patch adds bindings for ld9040 panel.
Bindings describe panel resources, boot delays,
display timings and physical size.
Signed-off-by: Andrzej Hajda
---
.../devicetree/bindings/panel/samsung,ld9040.txt | 66 ++
1 file changed, 66 insertions(+)
create mode 100644 Docum
Hi,
This patchset adds LD9040 panel support with DT bindings.
It also adds support for this panel to Exynos4210-universal_c210 board.
Regards
Andrzej
Andrzej Hajda (3):
panel/ld9040: add DT bindings
drm/panel: add ld9040 driver
ARM: dts: exynos4210-universal_c210: add proper panel node
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/4f355a19/attachment.html>
On Mon, 24 Mar 2014, Daniel Vetter wrote:
> On Mon, Mar 24, 2014 at 12:06:21PM +, Dmitry Malkin wrote:
>>
>> Hello guys,
>>
>> I've been playing with reloading intel gfx driver (i915) in a cycle,
>> for a while, and at some point I've found a non-deterministic kernel
>> crash with a highly-v
Just about all of these have been converted to __func__,
so convert the last uses.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns
Outside of staging, there aren't any more uses of __FUNCTION__ now...
Joe Perches (5):
powerpc: Convert last uses of __FUNCTION__ to __func__
x86: Convert last uses of __FUNCTION__ to __func__
block: Convert last uses of __FUNCTION__ to __func__
i915: Convert last uses of __FUNCTION__ to _
The recently added PTN3460 device driver uses interfaces that
are provided by the KMS helper infrastructure, so we should
explicitly select that to avoid this linker error:
ERROR: "drm_helper_probe_single_connector_modes"
[drivers/gpu/drm/bridge/ptn3460.ko] undefined!
ERROR: "drm_helper_connector
The tda998x driver accepts only 3 chips from the TDA998x family.
To avoid confusion with the other TDA998x chips, this patch changes
the driver compatible string to "nxp,tda9989".
As the previous compatible string is not used in any DT,
no compatibility is offered.
Signed-off-by: Jean-Francois M
On Tue, Mar 25, 2014 at 10:40:45AM +0100, David Herrmann wrote:
> Hi
>
> On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter wrote:
> > Besides the issue at hand though I think drivers need to make sure
> > that the device they use for attaching does outlive the dma-buf. Which
> > for real hotpluggin
On Tue, Mar 25, 2014 at 06:21:34PM +0900, Seung-Woo Kim wrote:
> Hi all,
>
> On 2014? 03? 24? 16:35, Daniel Vetter wrote:
> > Hi all,
> >
> > Adding piles more people.
> >
> > For the first case of caching the iommu mapping there's different
> > answers, depening upon the exact case:
> >
> > 1) Yo
On Mon, 24 Mar 2014, Damien Lespiau wrote:
> In the logging code, we are currently checking is we need to output in
s/is/if/
> drm_ut_debug_printk(). This is too late. The problem is that when we write
> something like:
>
> DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>
On Tue, Mar 25, 2014 at 08:05:30PM +1000, Dave Airlie wrote:
> On Tue, Mar 25, 2014 at 6:24 PM, Daniel Vetter wrote:
> > On Tue, Mar 25, 2014 at 6:53 AM, Dave Airlie wrote:
> >> So with runtime pm on nouveau, if the card gets powered down, and then
> >> you access a connector via sysfs,
> >>
> >>
On Tue, Mar 25, 2014 at 11:56:24AM +0200, Jani Nikula wrote:
> On Mon, 24 Mar 2014, Damien Lespiau wrote:
> > In the logging code, we are currently checking is we need to output in
>
> s/is/if/
>
> > drm_ut_debug_printk(). This is too late. The problem is that when we write
> > something like:
>
On Tue, Mar 25, 2014 at 08:08:23AM +, Dmitry Malkin wrote:
> Hello, Daniel,
>
> Thank you for response. I've got a couple questions for you:
>
> 0. What do you think about making integration test with continuous reloading
> i915 driver and X server (with FLR between iteration)?
> Simplified
On Mon, Mar 24, 2014 at 06:20:35PM -0700, Matt Roper wrote:
> On Wed, Mar 19, 2014 at 12:57:21PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 18, 2014 at 05:22:53PM -0700, Matt Roper wrote:
> > > Now that CRTC's have a primary plane, there's no need to track the
> > > framebuffer in the CRTC. Repla
Hi,
will you accept bash scripts for reloading driver/X/FLR for intel-gpu-tools to
uncover exists and future bugs besides those patches?
From: Daniel Vetter on behalf of Daniel Vetter
Sent: Tuesday, March 25, 2014 2:43 PM
To: Dmitry Malkin
Cc: Daniel Vet
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/032bfee1/attachment.html>
bug visibly.
--
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/20140325/5533cf2b/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/837b7223/attachment.html>
Hi
On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter wrote:
> Besides the issue at hand though I think drivers need to make sure
> that the device they use for attaching does outlive the dma-buf. Which
> for real hotpluggin probably means that drivers need to drop all
> attachment on unplug (the dma
Here's a test program I just whipped up that demonstrates (some of)
the issues in the old code. This segfaults in either nouveau_bo_wrap
or nouveau_bo_new, or sometimes nouveau_bo_wrap fails to find the
handle. With the patch, it hasn't failed yet. Ben -- review please?
(Or someone else...) Admitte
Am Montag, den 24.03.2014, 15:53 + schrieb Damien Lespiau:
> There are only a few users of the DRM_LOG_KMS() macro. We can simplify
> the DRM code a bit by replacing them by DRM_DEBUG_KMS().
>
> Cc: Philipp Zabel
> Cc: Lucas Stach
> Signed-off-by: Damien Lespiau
Acked-by: Philipp Zabel
r
On Tue, Mar 25, 2014 at 12:11 AM, Andreas Mohr wrote:
> On Mon, Mar 24, 2014 at 10:46:49PM +0100, Daniel Vetter wrote:
>> On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka
>> wrote:
>> > If someone understands the locking issues I pointed out above, it could be
>> > easy to fix.
>>
>> The locking
On 03/25/2014 09:01 AM, Daniel Vetter wrote:
> On Tue, Mar 25, 2014 at 4:53 AM, Dave Airlie wrote:
>> So I've got a reproducable oops with udl sharing from i915,
>>
>> start X, connect UDL, randr it into position, rip out udl device, kill X,
>>
>> we get an oops when dma_unmap_sg in i915_gem_unmap
On Tue, Mar 25, 2014 at 6:53 AM, Dave Airlie wrote:
> So with runtime pm on nouveau, if the card gets powered down, and then
> you access a connector via sysfs,
>
> drm_sysfs.c:status_show locks the connector and calls into the driver,
> the driver then does a runtime_get_sync, which causes resume
On Tue, Mar 25, 2014 at 4:53 AM, Dave Airlie wrote:
> So I've got a reproducable oops with udl sharing from i915,
>
> start X, connect UDL, randr it into position, rip out udl device, kill X,
>
> we get an oops when dma_unmap_sg in i915_gem_unmap_dma_buf gets
> called, attachment->dev is pointing
Hello, Daniel,
Thank you for response. I've got a couple questions for you:
0. What do you think about making integration test with continuous reloading
i915 driver and X server (with FLR between iteration)?
Simplified example for ubuntu (root required):
#!/bin/bash
service lightdm stop
rmmod s
4 +++
> drivers/staging/imx-drm/ipuv3-plane.c | 2 +-
> include/drm/drmP.h| 106
> +++---
> 11 files changed, 98 insertions(+), 136 deletions(-)
>
> --
> 1.8.3.1
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/3ad2b851/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=66731
Eric Blackwell changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Other
Product|Drivers
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/c08010ff/attachment.html>
vel/attachments/20140325/18a5eede/attachment-0001.html>
'all-recursive' failed
make: *** [all-recursive] Error 1
*
I attached config.log. Any hints?
--
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/20140325/51919ef9/attachment.html>
If so the commit message in 11/12 is misleading.
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/20140
Hi,
On Mon, Mar 24, 2014 at 10:46:49PM +0100, Daniel Vetter wrote:
> On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka
> wrote:
> > If someone understands the locking issues I pointed out above, it could be
> > easy to fix.
>
> The locking issue isn't your problem, the real issue is that putting
"lacks any display hardware". In that case the comment here doesn't make
much sense.
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/20140325/1f743847/attachment.sig>
.
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/589a12af/attachment.sig>
90 matches
Mail list logo
