https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #12 from Brian Hall ---
Bisect results below. According to my Xorg.0.log, my board is a
"ATI Radeon HD 4200" (ChipID = 0x9710) and lspci calls it a RS880.
6f8bbaf568c7f2c497558bfd04654c0b9841ad57 is the first bad commit
commit 6f8bba
Hi Takashi,
I've put two branches in my repo,
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down-snd-merge
git://people.freedesktop.org/~airlied/linux is the tree.
The second tree is just the vga swit
On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> > Op 22-08-13 02:10, Ilia Mirkin schreef:
> > > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > > set, it will do a null deref down the
https://bugs.freedesktop.org/show_bug.cgi?id=52952
--- Comment #20 from Daniel T. ---
Hi Alex,
I with the patch you have posted (commnet #19) against 3.10.9 , I have so far
been able to suspend and resume about 8 times without issue! Before the first
try would always fail. This part seems to be
anon_inode_getfile might fail, so check its return value.
Signed-off-by: Tuomas Tynkkynen
---
drivers/base/dma-buf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1219ab7..2d5ac1a 100644
--- a/drivers/base/dma-buf.c
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/76163d01/attachment.html>
e might be some extra stuff at the bottom.
--
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/20130827/fc930e39/attachment.html>
is null ( 0x0 ), please, can you fix that?
i hope this helps.
--
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/20130827/aa2114d5/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/eb825322/attachment.html>
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/20130827/fc7230e4/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/251a3443/attachment-0001.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/b776b1cc/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #11 from tux_mind ---
Created attachment 84756
--> https://bugs.freedesktop.org/attachment.cgi?id=84756&action=edit
fix multiple symbols bug
--
You are receiving this mail because:
You are the assignee for the bug.
___
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/fbc3355a/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #10 from tux_mind ---
(In reply to comment #3)
> I think the problem is that egl_gallium.so links both radeonsi and r600g,
> which have some conflicting symbols.
you're right!
http://pastebin.com/Zq3NDDeX
i'm patching mesa 9.2.0_rc
This flag allows userspace to give the kernel a hint that it should use
a non-snooped resource. To guarantee coherency at all times mappings
into userspace are done write combined, so userspace should avoid
reading back from those resources.
Signed-off-by: Lucas Stach
---
On x86 an optimized user
On arches with non-coherent PCI, we need to flush caches ourselfes at
the appropriate places. Introduce two small helpers to make things easy
for TTM based drivers.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/ttm/ttm_tt.c| 25 +
include/drm/ttm/ttm_bo_driver.h | 28
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index af20fba..f4a2eb9 100644
--- a/drivers/g
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 319cf41..db15687 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/t
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subd
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e84f4c3..3b54e8f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+
This is the first set of patches to make Nouveau work
on Tegra. Those are only the obvious correctness fixes,
a lot of optimization work remains to be done, but at least
it's enough to get accel working and let the machine survive
a piglit run.
A new BO flag is introduced to allow userspace to hin
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #12 from Brian Hall ---
Bisect results below. According to my Xorg.0.log, my board is a
"ATI Radeon HD 4200" (ChipID = 0x9710) and lspci calls it a RS880.
6f8bbaf568c7f2c497558bfd04654c0b9841ad57 is the first bad commit
commit 6f8bba
anon_inode_getfile might fail, so check its return value.
Signed-off-by: Tuomas Tynkkynen
---
drivers/base/dma-buf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1219ab7..2d5ac1a 100644
--- a/drivers/base/dma-buf.c
Remove index parameter; access index via handler->index instead.
Dissociate handler from related container; use handler->priv to
access container.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 6 +++---
drivers/gpu/drm/nouveau/core/engine/software/nv50.c |
Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 36 +-
.../gpu/drm/nouveau/core/engine/software/nv50.c| 11 ++
nouveau_event_put_locked() only has 1 call site; fold into caller.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouve
Lockdep report [1] correctly identifies a potential deadlock between
nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due
to inverted lock order of event->lock with drm core's
dev->vblank_time_lock.
Fix vblank event deadlock by converting event handler list to RCU.
List updates remain
Complete migration of nouveau_event_get/_put from add/remove
semantics to enable/disable semantics.
Introduce nouveau_event_handler_install/_remove interface to
add/remove non-local-scope event handlers (ie., those stored in
parent containers). This change in semantics makes explicit the
handler l
Most nouveau event handlers have storage in 'static' containers
(structures with lifetimes nearly equivalent to the drm_device),
but are dangerously reused via nouveau_event_get/_put. For
example, if nouveau_event_get is called more than once for a
given handler, the event handler list will be corr
Prepare for transition to RCU-based event handler list;
since RCU list traversal may have stale pointers, local
storage may go out of scope before handler completes.
Introduce nouveau_event_handler_create/_destroy which provides
suitable semantics for multiple, temporary event handlers.
Signed-of
The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/
Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau/nouveau_fence.c
This series was originally motivated by a deadlock, introduced in
commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
'drm/nouveau/disp: port vblank handling to event interface',
due to inverted lock order between nouveau_drm_vblank_enable()
and nouveau_drm_vblank_handler() (the complete
lockdep report
freedesktop.org/archives/dri-devel/attachments/20130827/91051e56/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #8 from Christopher Chmielewski ---
Created attachment 84754
--> https://bugs.freedesktop.org/attachment.cgi?id=84754&action=edit
xorg log
Both the dmesg and xorg log are from rc7
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #7 from Christopher Chmielewski ---
Created attachment 84753
--> https://bugs.freedesktop.org/attachment.cgi?id=84753&action=edit
dmesg
Like I said it freezes up my computer so I had to restart in single user mode
so there might be
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #9 from tux_mind ---
hello there, i'm having the same issue and i recompiled mesa with debugging
symbols.
i'm using mesa-9.2.0_rc1 on gentoo.
i attached gdb and i found that the issue is at
src/gallium/drivers/r600/r600_query.c:743.
https://bugs.freedesktop.org/show_bug.cgi?id=68585
--- Comment #8 from Richard Van Den Boom ---
I did a git pull to be as possible up to date and applied the patch.
It does indeed seem to fix Kwin crash at startup.
Congratulations!
--
You are receiving this mail because:
You are the assignee fo
On Tue, Aug 27, 2013 at 01:26:32PM +0200, Daniel Vetter wrote:
> On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote:
> >> right, but the cores on the SoC, and even any external encoder chips,
> >> are not actually hot-pluggable. I have a similar scenario w/ msm drm,
> >
> > oh, and come to think of
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #12 from Peter Kraus ---
Hello,
I guess I'm just really unlucky. Compilation of "required merge" according to
git bisect fails with:
CXXLDlibOSMesa.la
/usr/bin/ld: i386:x86-64 architecture of input file
`../../../../src/mesa/.lib
https://bugs.freedesktop.org/show_bug.cgi?id=68585
--- Comment #7 from Richard Van Den Boom ---
I'll see what I can do.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=68585
--- Comment #6 from Marek Olšák ---
Created attachment 84748
--> https://bugs.freedesktop.org/attachment.cgi?id=84748&action=edit
possible fix
Could you please test this patch?
--
You are receiving this mail because:
You are the assignee for
Remove index parameter; access index via handler->index instead.
Dissociate handler from related container; use handler->priv to
access container.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 6 +++---
drivers/gpu/drm/nouveau/core/engine/software/nv50.c |
Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 36 +-
.../gpu/drm/nouveau/core/engine/software/nv50.c| 11 ++
nouveau_event_put_locked() only has 1 call site; fold into caller.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouve
Lockdep report [1] correctly identifies a potential deadlock between
nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due
to inverted lock order of event->lock with drm core's
dev->vblank_time_lock.
Fix vblank event deadlock by converting event handler list to RCU.
List updates remain
On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote:
>> right, but the cores on the SoC, and even any external encoder chips,
>> are not actually hot-pluggable. I have a similar scenario w/ msm drm,
>
> oh, and come to think of it, same approach it tilcdc. And I'm sure
> there are other drivers wit
Complete migration of nouveau_event_get/_put from add/remove
semantics to enable/disable semantics.
Introduce nouveau_event_handler_install/_remove interface to
add/remove non-local-scope event handlers (ie., those stored in
parent containers). This change in semantics makes explicit the
handler l
Most nouveau event handlers have storage in 'static' containers
(structures with lifetimes nearly equivalent to the drm_device),
but are dangerously reused via nouveau_event_get/_put. For
example, if nouveau_event_get is called more than once for a
given handler, the event handler list will be corr
Prepare for transition to RCU-based event handler list;
since RCU list traversal may have stale pointers, local
storage may go out of scope before handler completes.
Introduce nouveau_event_handler_create/_destroy which provides
suitable semantics for multiple, temporary event handlers.
Signed-of
This series was originally motivated by a deadlock, introduced in
commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
'drm/nouveau/disp: port vblank handling to event interface',
due to inverted lock order between nouveau_drm_vblank_enable()
and nouveau_drm_vblank_handler() (the complete
lockdep report
The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/
Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau/nouveau_fence.c
One more thing, changed the subject to "Consider fallback option to
allocation fail". The subject is too long :)
Thanks,
Inki Dae
> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Vikas Sajjan
> Se
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset
pointing to this structure
{
UCHAR ucNumberOfSrc;
USHORT usSrcObjectID[1];
UCHAR ucNumberOfDst;
USHORT usDstObjectID[1]
https://bugs.freedesktop.org/show_bug.cgi?id=52952
--- Comment #19 from Alex Deucher ---
Created attachment 84747
--> https://bugs.freedesktop.org/attachment.cgi?id=84747&action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
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/20130827/2767d9a3/attachment.pgp>
- 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/20130827/59a1dfa4/attachment-0001.pgp>
Hi Sachin,
Could you rebase your patch set to the below patch series?
[PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree
Your patch set is conflicted.
Thanks,
Inki Dae
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Thursda
> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Andrzej Hajda
> Sent: Wednesday, August 21, 2013 11:22 PM
> To: open list:DRM DRIVERS FOR E...
> Cc: Andrzej Hajda; Inki Dae; Joonyoung Shim; Seung-W
Applied.
Thanks,
Inki Dae
> -Original Message-
> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
> Sent: Friday, August 23, 2013 3:35 PM
> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at
> gmai
Hi Laurent,
I have another small issue with the graph helpers below:
Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
[...]
> +/*
> -
> * Graph Helpers
> */
>
> @@ -420,6 +599,161 @@ int display_en
- 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/20130827/8f7b12f5/attachment.pgp>
Am Dienstag, den 27.08.2013, 10:41 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach
> wrote:
> >> If I understand stuff correctly you have a main driver plus a bunch of
> >> encoder/crtc modules and you expect that everything gets loaded and then
> >> only when the kms
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d37f5ef2/attachment.html>
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/3a641401/attachment.html>
On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach
> wrote:
> >> If I understand stuff correctly you have a main driver plus a bunch of
> >> encoder/crtc modules and you expect that everything gets loaded and then
> >> only when the kms
On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote:
>> If I understand stuff correctly you have a main driver plus a bunch of
>> encoder/crtc modules and you expect that everything gets loaded and then
>> only when the kms driver is first opened. The current drm core just
>> doesn't support hotpl
chment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/bf6a6e9c/attachment.pgp>
Hi Daniel,
Am Dienstag, den 27.08.2013, 10:08 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 9:46 AM, Lothar Wa?mann
> wrote:
> > the function imx_drm_driver_load() must have been called before
> > calling imx_drm_add_crtc(), but the following hunk in the commit:
> > @@ -446,6 +434,9 @@
On Tue, Aug 27, 2013 at 9:46 AM, Lothar Wa?mann
wrote:
> the function imx_drm_driver_load() must have been called before
> calling imx_drm_add_crtc(), but the following hunk in the commit:
> @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm,
> unsigned long flags)
>
lable
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/f0e64604/attachment.pgp>
OK.
On 27 August 2013 09:44, Inki Dae wrote:
>
> One more thing, changed the subject to "Consider fallback option to
> allocation fail". The subject is too long :)
>
> Thanks,
> Inki Dae
>
>
>> -Original Message-
>> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-so
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset
pointing to this structure
{
UCHAR ucNumberOfSrc;
USHORT usSrcObjectID[1];
UCHAR ucNumberOfDst;
USHORT usDstObjectID[1]
https://bugs.freedesktop.org/show_bug.cgi?id=68468
--- Comment #4 from adam...@gmail.com ---
Well, the digging phase is over, I pretty much hit a wall.
As stated above, the general bisecting idea is clear, but I'm having problem
actually building mesa.
Here what I've done:
I downloaded the PKGBUI
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d6c82343/attachment.html>
Thanks.
On 27 August 2013 08:14, Inki Dae wrote:
> Applied.
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
>> Sent: Friday, August 23, 2013 3:35 PM
>> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>> Cc: kgene.kim
Hi Inki,
Sure, I will rebase and send tomorrow.
Thanks
On 27 August 2013 08:18, Inki Dae wrote:
> Hi Sachin,
>
> Could you rebase your patch set to the below patch series?
> [PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree
>
> Your patch set is conflicted.
>
> Thanks
On Tue, Aug 27, 2013 at 7:19 AM, Rob Clark wrote:
> On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer
> wrote:
>> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
>>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach
>>> wrote:
>>> >> If I understand stuff correctly you have a main drive
On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer wrote:
> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach
>> wrote:
>> >> If I understand stuff correctly you have a main driver plus a bunch of
>> >> encoder/crtc modules and you expect
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/03a08587/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/1d56bbf1/attachment.html>
On Tue, Aug 27, 2013 at 01:26:32PM +0200, Daniel Vetter wrote:
> On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote:
> >> right, but the cores on the SoC, and even any external encoder chips,
> >> are not actually hot-pluggable. I have a similar scenario w/ msm drm,
> >
> > oh, and come to think of
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d237d5c4/attachment.html>
and shouldn't be a global variable.
--
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/20130827/b765e6a2/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130827/c9adfdaf/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/3a1803f5/attachment.html>
On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote:
>> right, but the cores on the SoC, and even any external encoder chips,
>> are not actually hot-pluggable. I have a similar scenario w/ msm drm,
>
> oh, and come to think of it, same approach it tilcdc. And I'm sure
> there are other drivers wit
On Tue, Aug 27, 2013 at 7:19 AM, Rob Clark wrote:
> On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer wrote:
>> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
>>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach
>>> wrote:
>>> >> If I understand stuff correctly you have a main driver p
On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer wrote:
> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote:
>> >> If I understand stuff correctly you have a main driver plus a bunch of
>> >> encoder/crtc modules and you expect that
https://bugs.freedesktop.org/show_bug.cgi?id=68585
--- Comment #5 from Richard Van Den Boom ---
Created attachment 84696
--> https://bugs.freedesktop.org/attachment.cgi?id=84696&action=edit
Git bisect log output
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=68585
--- Comment #4 from Richard Van Den Boom ---
According to bisect, the commit that cause the crashes is this one :
git bisect good 98d2498404ba69a3efc1c765b1a1885d151181ed
# first bad commit: [a3ae5dc7dd5c2f8893f86a920247e690e550ebd4] draw: make
On Mon, Aug 19, 2013 at 04:58:51PM +0100, Damien Lespiau wrote:
> Follow up on v3:
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043696.html
>
> Changes between v3 and v4:
> - Future proof the sending of 3D_Ext_Data
> - Renamed struct hdmi_hdmi_infoframe to hdmi_vendor_infofr
On Mon, Aug 19, 2013 at 04:58:54PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
[...]
> +static int
> +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> +{
[...]
> + u8 vic;
> +
> + vic =
signal handlers of applications?
--
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/20130827/43bbac3a/attachment.html>
Hi Laurent,
I have another small issue with the graph helpers below:
Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
[...]
> +/*
> -
> * Graph Helpers
> */
>
> @@ -420,6 +599,161 @@ int display_en
https://bugzilla.kernel.org/show_bug.cgi?id=60639
--- Comment #11 from douglas_peale at yahoo.com ---
Created attachment 107330
--> https://bugzilla.kernel.org/attachment.cgi?id=107330&action=edit
Requested rom dump
Requested file.
--
You are receiving this mail because:
You are watching the
Am Dienstag, den 27.08.2013, 10:41 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote:
> >> If I understand stuff correctly you have a main driver plus a bunch of
> >> encoder/crtc modules and you expect that everything gets loaded and then
> >> only when the kms dr
On Fri, Aug 23, 2013 at 01:19:11PM +0300, Dan Carpenter wrote:
> There is a mistake here so it returns PTR_ERR(NULL) which is success
> instead of -ENOMEM.
>
> Signed-off-by: Dan Carpenter
> ---
> I can't compile this.
Good catch! Applied, thanks.
Thierry
pgpe9f5h46uC2.pgp
Description: PGP si
1 - 100 of 108 matches
Mail list logo
