the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/45e5655c/attachment-0001.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/20130402/38a920c9/attachment.html>
vel/attachments/20130402/95ac228a/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #60 from Austin Lund ---
It does look like commit 547b52463 did introduce the problem (tho I didn't
finish bisecting).
The patch set does fix the issue for me.
--
You are receiving this mail because:
You are the assignee for the bu
On Tue, 2013-04-02 at 16:57 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Thanks for reviewing.
Only partway through so far :-)
> Op 02-04-13 13:00, Peter Zijlstra schreef:
> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +Reservation type mutexes
> >> +struct ticket_mutex {
> >
mutex_is_locked_by() checks the owner of the lock against current. This
is done by accessing a private member of struct mutex which works on
mainline but does not on RT.
I did not figure out, why this "lock-owner-check" and the "lock stealing
flag" is required. If the lock can not be acquire the lo
On Tuesday 26 of March 2013 16:49:30 Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb wrote:
> > I have IBM POS machine (4852-570 Truman) that has internal monitor
> > connected over display port. It reports to have 2 lanes, but only 1
> > lane works reliably. With 2 lanes used,
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> + Similar to mutex_reserve_lock, except it won't backoff with
> -EAGAIN.
> + This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> + unreserved all reservati
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is
> +quite simple. For each group of buffers (execbuf) that need to be
> +locked, the caller would be assigned a unique reservation_id, from a
> +global counter. In ca
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +Reservation type mutexes
> +struct ticket_mutex {
> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
That's two different names and two different forms of one (for a total
of 3 variants) for the same scheme.
F
Attached is a v2 of the patch, for reference. I would appreciate if the
original reporter or you tested it in lieu of your proposed patch and let me
know if it fixes your
issue.
The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as rmmod radeon do not end up in a crash anymore.
Hi Ilija,
Thanks for testing. Other issues are probably unrelated, so I'll send the last
version of the patch to Dave.
I came across another problem which seems related. rmmod radeon works, however,
modprobe radeon afterwards results in a crash (divide error), see attachment.
Best, Marco
O
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +struct ticket_mutex {
> + struct mutex base;
> + atomic_long_t reservation_id;
> +};
I'm not sure this is a good name, esp. due to the potential confusion
vs the ticket spinlocks we have.
_
Hi Rob,
On Monday, April 01, 2013 09:46:05 Rob Clark wrote:
> On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav wrote:
> >> -Original Message-
> >> From: devicetree-discuss [mailto:devicetree-discuss-
> >> bounces+hvaibhav=ti@lists.ozlabs.org] On Behalf Of Michal Bachraty
> >> Sent: T
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #59 from Alex Deucher ---
Possibly fixed by this patch set:
https://patchwork.kernel.org/patch/2344041/
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-de
Hi Linus,
two core fixes, both regressions, along with some intel and some nouveau
fixes for regressions and oopses.
Dave.
The following changes since commit 2dc958fa2fe6987e7ab106bd97029a09a82fcd8d:
ipc: set msg back to -EAGAIN if copy wasn't performed (2013-04-02 10:09:01
-0700)
are ava
e dri-devel list.
--
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/20130402/ff850a65/attachment.html>
600g still adds CF_ALU on its own which break CF_CLAUSE address natively
encoded by llvm.
--
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/at
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 ("Revert
"drm/i915: write backlight harder"") from Linus' tree and commit
31ad8ec6a614 ("drm/i915: group backlight related stuff into a struct")
from the drm-inte
On Tue, Apr 2, 2013 at 7:18 PM, Christian K?nig
wrote:
> Hi everyone,
>
> the following patchset implements the kernel side of UVD support for the
> radeon hardware generations RV710-SI.
>
> The R6xx and RS780/RS880 chipset generations are currently not supported, but
> might be added in the fu
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra
wrote:
>> > Also, is there anything in CS literature that comes close to this? I'd
>> > think the DBMS people would have something similar with their
>> > transactional systems. What do they call it?
>
>> I didn't study cs, but judging from your phra
https://bugs.freedesktop.org/show_bug.cgi?id=43655
Alexandre Demers changed:
What|Removed |Added
Attachment #77348|0 |1
is obsolete|
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra
wrote:
>> > Head hurts, needs more time to ponder. It would be good if someone else
>> > (this would probably be you maarten) would also consider this explore
>> > this 'interesting' problem space :-)
>
>> My head too, evil priority stuff!
>>
>> Hack
On Tue, 2013-04-02 at 16:57 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Thanks for reviewing.
Only partway through so far :-)
> Op 02-04-13 13:00, Peter Zijlstra schreef:
> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +Reservation type mutexes
> >> +struct ticket_mutex {
> >
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/16d93621/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/02efa3f4/attachment.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/e7ef2a79/attachment-0001.html>
guess I will have to build from source in that case?
--
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/20130402/3c3bf
n, never really changes.
>
> Alex
>
Still sounds like you likely want to update those given gap there is inside
them.
Patch set for solution 1:
http://people.freedesktop.org/~glisse/si2d-sol1/
Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/8bb67af7/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #58 from Austin Lund ---
This still doesn't work for 3.9-rc5.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskt
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/6eec7cc5/attachment.html>
return -ENXIO;
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/193b1c82/attachment.html>
On Tue, Apr 2, 2013 at 1:00 PM, Peter Zijlstra
wrote:
> Also, is there anything in CS literature that comes close to this? I'd
> think the DBMS people would have something similar with their
> transactional systems. What do they call it?
I've looked around a bit and in dbms row-locking land this
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/94d8f9e1/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/7c166c5f/attachment.html>
nts/20130402/d275a38c/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #28 from Alexandre Demers ---
Created attachment 77348
--> https://bugs.freedesktop.org/attachment.cgi?id=77348&action=edit
dmesg from 3.9-rc5 with patch
Et voilà, as asked
--
You are receiving this mail because:
You are the assi
nks for the reminder Johannes.
[ I read bug reports on the lists ]
--
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/20130402/776c9fc2/attachment.html>
Hey,
Thanks for reviewing.
Op 02-04-13 13:00, Peter Zijlstra schreef:
> On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
>> +Reservation type mutexes
>> +struct ticket_mutex {
>> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
> That's two different names and tw
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #27 from Alex Deucher ---
(In reply to comment #26)
> Applied on 3.9-rc5 and it doesn't help.
Can you attach your dmesg output with the patch applied?
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #26 from Alexandre Demers ---
(In reply to comment #25)
> Created attachment 77332 [details] [review]
> possible fix
>
> Does this patch help?
Applied on 3.9-rc5 and it doesn't help.
--
You are receiving this mail because:
You are
On Tue, Apr 2, 2013 at 7:18 PM, Christian König wrote:
> Hi everyone,
>
> the following patchset implements the kernel side of UVD support for the
> radeon hardware generations RV710-SI.
>
> The R6xx and RS780/RS880 chipset generations are currently not supported, but
> might be added in the fut
On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse wrote:
> So i am facing a dilema regarding tiling on radeonsi. Given that we now have
> a fixed table of tiling mode this put more pressure on the kernel userspace
> api. I see either 2 solutions.
>
> Enforce kernel to set at fixed index in the table b
v2: set UVD tiling config for rv730
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |3 +++
drivers/gpu/drm/radeon/evergreend.h |3 +++
drivers/gpu/drm/radeon/ni.c |3 +++
drivers/gpu/drm/radeon/nid.h|3 +++
driv
Just until we get proper DPM for that.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_uvd.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 8ab7bb9..768d8f5 100644
--- a/drivers/gpu/drm/ra
v2: avoid 64bit divide
v3: rv740 uses the evegreen upll configuration
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c |1 +
drivers/gpu/drm/radeon/radeon_asic.h |1 +
drivers/gpu/drm/radeon/rv770.c | 156
From: Alex Deucher
v2: remove unneeded register definitions
Signed-off-by: Alex Deucher
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c | 164 ++
drivers/gpu/drm/radeon/evergreend.h | 27 ++
drivers/gpu/drm/radeon/radeon_asic.c |
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_asic.c |1 +
drivers/gpu/drm/radeon/radeon_asic.h |1 +
drivers/gpu/drm/radeon/si.c | 167 ++
drivers/gpu/drm/radeon/sid.h | 29 ++
4 files changed, 198 insertions(+)
From: Alex Deucher
v2: write clk registers only once!
v3: update cg scratch register properly
v4: add TN support
Signed-off-by: Alex Deucher
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c | 47 ++
drivers/gpu/drm/radeon/evergreend.h
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |5 ++
drivers/gpu/drm/radeon/radeon_atombios.c | 107 ++
drivers/gpu/drm/radeon/radeon_mode.h | 23 +++
3 files changed, 135 insertions(+)
diff --git a/drivers/gpu/drm/radeon/r
From: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3f5572d..eafb66a6 100644
--- a/drivers/gpu/drm/rade
Hi everyone,
the following patchset implements the kernel side of UVD support for the radeon
hardware generations RV710-SI.
The R6xx and RS780/RS880 chipset generations are currently not supported, but
might be added in the future.
The newest firmware can be found here: from
http://people.fre
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 70d3824..7d66e01 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
++
https://bugs.freedesktop.org/show_bug.cgi?id=61182
Alex Deucher changed:
What|Removed |Added
CC||ranki...@googlemail.com
--- Comment #26 f
On Tuesday 26 of March 2013 16:49:30 Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb wrote:
> > I have IBM POS machine (4852-570 Truman) that has internal monitor
> > connected over display port. It reports to have 2 lanes, but only 1
> > lane works reliably. With 2 lanes used,
On Tue, Apr 02, 2013 at 03:30:58PM +0200, Sebastian Andrzej Siewior wrote:
> mutex_is_locked_by() checks the owner of the lock against current. This
> is done by accessing a private member of struct mutex which works on
> mainline but does not on RT.
> I did not figure out, why this "lock-owner-che
mutex_is_locked_by() checks the owner of the lock against current. This
is done by accessing a private member of struct mutex which works on
mainline but does not on RT.
I did not figure out, why this "lock-owner-check" and the "lock stealing
flag" is required. If the lock can not be acquire the lo
On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher wrote:
> On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse wrote:
> > So i am facing a dilema regarding tiling on radeonsi. Given that we now
> have
> > a fixed table of tiling mode this put more pressure on the kernel
> userspace
> > api. I see either 2
op.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2012-12-07
--
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/20130402/dd523865/attachment.html>
On Sun, Feb 24, 2013 at 11:31 PM, Syam Sidhardhan
wrote:
> The use of pointer sender should be after the NULL check.
>
> Signed-off-by: Syam Sidhardhan
> ---
> drivers/gpu/drm/gma500/mdfld_dsi_output.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu
On Mon, Mar 11, 2013 at 8:46 PM, Alexandru Gheorghiu
wrote:
> Replaced calls kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu
> ---
> drivers/gpu/drm/gma500/intel_bios.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletio
On Sun, Mar 31, 2013 at 1:38 PM, Kero wrote:
> From: Kero van Gelder
>
> Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
> This patch will cause output to be shown on either when plugged in.
> For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.
>
> Signed-off-by:
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/a86439ec/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=62756
--- Comment #6 from Andy Furniss ---
(In reply to comment #5)
> No, I don't receive mail from bugzilla until someone add me manually to the
> cc list (dont know what to do to fix that though)
drivers/gallium/r600 bugs get sent to the dri-devel l
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/4bad0378/attachment.html>
30167 Hannover, Germany Web: http://www.tnt.uni-hannover.de/~munderl
-- next part --
A non-text attachment was scrubbed...
Name: crash_modprobe_radeon.log
Type: text/x-log
Size: 12046 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-deve
Hi Linus,
two core fixes, both regressions, along with some intel and some nouveau
fixes for regressions and oopses.
Dave.
The following changes since commit 2dc958fa2fe6987e7ab106bd97029a09a82fcd8d:
ipc: set msg back to -EAGAIN if copy wasn't performed (2013-04-02 10:09:01
-0700)
are ava
ignature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/c1e13c2d/attachment.pgp>
On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse wrote:
> So i am facing a dilema regarding tiling on radeonsi. Given that we now have
> a fixed table of tiling mode this put more pressure on the kernel userspace
> api. I see either 2 solutions.
>
> Enforce kernel to set at fixed index in the table b
https://bugs.freedesktop.org/show_bug.cgi?id=62756
--- Comment #5 from vincent ---
No, I don't receive mail from bugzilla until someone add me manually to the cc
list (dont know what to do to fix that though)
I'm aware of the regression with latest HEAD, I'm working on a fix.
r600g still adds CF
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/20130402/22108f06/attachment-0001.html>
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is
> +quite simple. For each group of buffers (execbuf) that need to be
> +locked, the caller would be assigned a unique reservation_id, from a
> +global counter. In ca
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +Reservation type mutexes
> +struct ticket_mutex {
> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
That's two different names and two different forms of one (for a total
of 3 variants) for the same scheme.
F
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/587af819/attachment.html>
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +struct ticket_mutex {
> + struct mutex base;
> + atomic_long_t reservation_id;
> +};
I'm not sure this is a good name, esp. due to the potential confusion
vs the ticket spinlocks we have.
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> + Similar to mutex_reserve_lock, except it won't backoff with
> -EAGAIN.
> + This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> + unreserved all reservati
ext attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4523 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/36316fe3/attachment.bin>
On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse wrote:
> So i am facing a dilema regarding tiling on radeonsi. Given that we now
> have a fixed table of tiling mode this put more pressure on the kernel
> userspace api. I see either 2 solutions.
>
> Enforce kernel to set at fixed index in the table
https://bugs.freedesktop.org/show_bug.cgi?id=62889
--- Comment #10 from Alexander von Gluck ---
Created attachment 77336
--> https://bugs.freedesktop.org/attachment.cgi?id=77336&action=edit
gnome-session --debug output nocolortile
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=62889
--- Comment #9 from Alexander von Gluck ---
Created attachment 77335
--> https://bugs.freedesktop.org/attachment.cgi?id=77335&action=edit
glxinfo-nocolortile
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=62889
--- Comment #8 from Alexander von Gluck ---
Thanks for the input.
I disabled colortiling and installed xfce.. success!
It seems like Gnome 3.6 won't work unless color tiling is enabled. I double
checked the gnome session logs and don't see the
Hi Dave,
So I've figured we should get drm-next for 3.10 started ;-)
Highlights:
- Imre's for_each_sg_pages rework (now also with the stolen mem backed
case fixed with a hack) plus the drm prime sg list coalescing patch from
Rahul Sharma. I have some follow-up cleanups pending, already acked
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #25 from ogjers...@gmail.com ---
Not without some instructions, I have never done that before.
And, I must admit, I also downgraded llvm-libs, mesa-dri-filesystem and
mesa-libxatracker. I think I had to because of dependences.
I gues
So i am facing a dilema regarding tiling on radeonsi. Given that we now
have a fixed table of tiling mode this put more pressure on the kernel
userspace api. I see either 2 solutions.
Enforce kernel to set at fixed index in the table best tiling mode for
given gpu for given format, such as DEPTH32
https://bugs.freedesktop.org/show_bug.cgi?id=62976
--- Comment #5 from David Heidelberger ---
3.9.0-rc5, with patch. Boot successfull, first time :)
Thank you!
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel ma
Hi Mr. Inki Dae,
Can you please review this patch.?
On Wed, Mar 13, 2013 at 4:22 PM, Vikas Sajjan
wrote:
> Replaces the "platform_get_resource() for IORESOURCE_IRQ" with
> platform_get_resource_byname().
> Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order: "fifo",
> "vsync", an
Hi Rob,
On Monday, April 01, 2013 09:46:05 Rob Clark wrote:
> On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav wrote:
> >> -Original Message-
> >> From: devicetree-discuss [mailto:devicetree-discuss-
> >> bounces+hvaibhav=ti.com at lists.ozlabs.org] On Behalf Of Michal Bachraty
> >> Sent
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra wrote:
>> > Also, is there anything in CS literature that comes close to this? I'd
>> > think the DBMS people would have something similar with their
>> > transactional systems. What do they call it?
>
>> I didn't study cs, but judging from your phras
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #25 from Alex Deucher ---
Created attachment 77332
--> https://bugs.freedesktop.org/attachment.cgi?id=77332&action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=62976
--- Comment #4 from Alex Deucher ---
Created attachment 77331
--> https://bugs.freedesktop.org/attachment.cgi?id=77331&action=edit
Possible fix
Does this patch help?
--
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/20130402/19d678bb/attachment.html>
On Mon 01-04-13 13:14:50, Ilija Hadzic wrote:
>
>
> On Sun, 31 Mar 2013, Michal Hocko wrote:
>
> >On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> >>This looks a bit like a hack and it doesn't look right,
> >>conceptually. If the call fails, it should restore things as if
> >>nothing has ever hap
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra wrote:
>> > Head hurts, needs more time to ponder. It would be good if someone else
>> > (this would probably be you maarten) would also consider this explore
>> > this 'interesting' problem space :-)
>
>> My head too, evil priority stuff!
>>
>> Hacky
https://bugs.freedesktop.org/show_bug.cgi?id=62756
Michel Dänzer changed:
What|Removed |Added
CC||v...@ovi.com
--- Comment #4 from Michel
Still OK with R600_LLVM=0, and other games are not affected.
--
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/2013040
https://bugs.freedesktop.org/show_bug.cgi?id=62226
Michel Dänzer changed:
What|Removed |Added
CC|mic...@daenzer.net |
--- Comment #13 from Michel Dänzer ---
Commit 2e3b3c42f06ff6801b3d7839757bbdb231619083
(Add DRM KMS/FB CMA helper) add a kbuild entry,
config DRM_KMS_CMA_HELPER, in DRM's Kconfig without
dependence on DRM, it cause DRM's kconfig can't
be show in a submenu.
This patch fix it.
Signed-off-by: Wang YanQing
---
drivers/gpu/drm/Kconfig |
On Tue, Apr 2, 2013 at 4:45 AM, Michal Bachraty
wrote:
> Hi Rob,
>
> On Monday, April 01, 2013 09:46:05 Rob Clark wrote:
>> On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav wrote:
>> >> -Original Message-
>> >> From: devicetree-discuss [mailto:devicetree-discuss-
>> >> bounces+hvaibhav=t
If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.
Fixes: https://bugzilla
On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
wrote:
>
> Marco,
>
> What makes you think that the crash after second modprobe is related to the
> mappings pointers in DRM module? Can you actually establish the correlation
> between these patches and the crash or you are just suspecting because your
1 - 100 of 126 matches
Mail list logo
