On Tue, Jul 30, 2013 at 11:35:03AM +0300, Mikko Perttunen wrote:
> The debugfs register dumping function did not enable the HDMI clock.
> This led to a possible system hang when reading the debugfs entry
> while no HDMI cable was connected to the system. This patch makes
> sure that the clock is en
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)
>
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 Fri, Aug 23, 2013 at 01:18:25PM +0300, Dan Carpenter wrote:
> Tegra is a 32 bit arch. On 32 bit systems then size_t is 32 bits so
> "total" will never be higher than UINT_MAX because of integer overflows.
> We need cast to u64 first before doing the math.
>
> Also the addition earlier:
>
>
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
https://bugs.freedesktop.org/show_bug.cgi?id=62976
David "okias" Heidelberger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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 dri
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
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
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
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 =
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
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
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.
___
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
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 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 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=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
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.
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
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/
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
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
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
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
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
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
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 ++
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 |
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
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=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 #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
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=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=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://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
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
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
+
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/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
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
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
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
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
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.
___
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #11 from Brian Hall ---
Working the bisection now, may take me a day or two.
--
You are receiving this mail because:
You are watching the assignee of the bug.
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
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>
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
> -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
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
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
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/3a1803f5/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130827/c9adfdaf/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>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d237d5c4/attachment.html>
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
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
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
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/1d56bbf1/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/03a08587/attachment.html>
lable
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/f0e64604/attachment.pgp>
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)
>
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 @@
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>
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
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d6c82343/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
- 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
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/59a1dfa4/attachment-0001.pgp>
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>
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/3a641401/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d37f5ef2/attachment.html>
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
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 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 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
freedesktop.org/archives/dri-devel/attachments/20130827/91051e56/attachment.html>
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]
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/fbc3355a/attachment.html>
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
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
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/
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
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
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
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
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
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 ++
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 |
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/b776b1cc/attachment.html>
1 - 100 of 108 matches
Mail list logo
