> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Thursday, September 19, 2013 1:15 PM
>
> On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter wrote:
> > On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote:
> >> > From: Paul Zimmerman
> >> > Sent: Thursday, September 19, 2013 11:21 AM
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
From: Santosh Shilimkar
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_ma
From: Santosh Shilimkar
The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.
No functional change.
The idea is to fix the bad assumptions about dma_mas
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> Provide a helper to set both the DMA and coherent DMA masks to the
> same value - this avoids duplicated code in a number of drivers,
> sometimes with buggy error handling, and also allows us identify
> which drivers do things differently.
>
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #21 from Alexandre Demers ---
(In reply to comment #20)
> Hello,
> I wont be able to test it until October. Will update then, unless someone
> else can test it instead.
> Peter
I may give it a try this weekend, but I'm using a HD6950
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
17.09.2013, в 23:33, Alex Ivanov написал(а):
> 17.09.2013, в 18:24, Alex Deucher написал(а):
>
>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov wrote:
>>> Alex,
>>>
>>> 10.09.2013, в 16:37, Alex Deucher написал(а):
>>>
The dummy page isn't really going to help much. That page is just
>
On Tue, 17 Sep 2013, Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows 8 doesn't use the ACPI interface, including
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #34 from Michel Dänzer ---
(In reply to comment #33)
> (which AFAIK is normal, but didn't happen before).
Yes, that's normal and not related to this problem.
Note that the 'Attempted to destroy previously destroyed buffer.' messages
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #15 from Andrew Stubbs ---
I fixed the problem now! (At least, for my own needs.)
The patch turns out to be very simple.
1. Disregard the mode setting (why does the PPLL care?)
2. Allow a little leeway in the frequency matching. I'v
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #16 from Andrew Stubbs ---
Created attachment 108951
--> https://bugzilla.kernel.org/attachment.cgi?id=108951&action=edit
Proposed patch
--
You are receiving this mail because:
You are watching the assignee of the bug.
Signed-off-by: Damien Lespiau
---
edid-decode.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index bf0c3da..d3e3118 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -829,12 +829,26 @@ cea_hdmi_block(unsigned char *x)
The lower layers of sysfs will not allow an "offset" of more than
GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But
it's a little easier to audit if we don't have to worry that the
subtraction will result in negative values.
Signed-off-by: Dan Carpenter
diff --git a/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=69463
--- Comment #7 from samit vats ---
The Debug output with EGL_DRIVER=egl_dri2
II) [KMS] Kernel modesetting enabled.
libEGL debug: Native platform type: drm (environment overwrite)
libEGL debug: ignore EGL_DRIVERS_PATH for setuid/setgid binaries
Am 19.09.2013 04:07, schrieb Dave Airlie:
Hi Linus,
mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
for AST driver.
Dave.
The following changes since commit
01172772c7c973debf5b4881fcb9463891ea97ec:
drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53
On Fri, Sep 20, 2013 at 8:01 AM, Dieter Nützel wrote:
> Am 19.09.2013 04:07, schrieb Dave Airlie:
>
>> Hi Linus,
>>
>> mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
>> for AST driver.
>>
>> Dave.
>>
>> The following changes since commit
>> 01172772c7c973debf5b4881fcb9463891
Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.
Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a
KP if ring buffer was deallocated, e.g. on failed ring test.
Seen on PA-RISC machine having "radeon: ring test failed
(scratch(0x8504)=0
On Thu, Sep 19, 2013 at 05:40:29PM +0100, Damien Lespiau wrote:
> When using the frame packing and a single big framebuffer, some hardware
> requires that we do everything like if we were scanning out the big
> buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
> this adjustem
https://bugs.freedesktop.org/show_bug.cgi?id=69463
--- Comment #8 from Michel Dänzer ---
(In reply to comment #7)
> The Debug output with EGL_DRIVER=egl_dri2
Yet another crash... Can you get a backtrace for this one with gdb? You'll need
to do that from a remote shell, e.g. via ssh.
--
You ar
This code appears to be calling psb_gtt_free_range twice with the same args.
(The second call didn't appear in the diff output, it's right after the
mutex_unlock)
Spotted with Coverity, not tested due to lack of hardware.
Signed-off-by: Dave Jones
diff --git a/drivers/gpu/drm/gma500/framebuffe
On Don, 2013-09-19 at 18:37 +0200, Marek Olšák wrote:
> On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
> > On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
> >> This fixes VM protection faults.
> >>
> >> I have a new piglit test which can iterate over all possible widths,
> >> heights
On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> When booting with i915.fastboot=1, we always take tha code path and end
> up undoing what we're trying to do with adjusted_mode.
>
> Hopefully, as the fastboot hardware readout code is using adjusted_mode
> as well, it should be equ
On Fri, Sep 20, 2013 at 05:54:55PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> > When booting with i915.fastboot=1, we always take tha code path and end
> > up undoing what we're trying to do with adjusted_mode.
> >
> > Hopefully, as the fastboot
I agree we should make npix_x/y/z more useful, but at the same time
it's a public interface and current and old Mesa depends on the
seemingly incorrect values we set there. This wouldn't be an issue if
we merged the allocator to Mesa, along with xf86-video-ati. Who's with
me? :)
In particular, I t
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #27 from Rafael Castillo ---
many thanks for your hard work, ill test it tonight and report back
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mai
On Thu, Sep 19, 2013 at 05:40:15PM +0100, Damien Lespiau wrote:
> v4 was:
> http://lists.freedesktop.org/archives/dri-devel/2013-September/045340.html
>
> Changes from v4:
>
> - The kernel is now in charge of adjusting the stereo mode timings.
> - There is a per-connector opt-in boolean to ex
On Fri, 20 Sep 2013 16:33:47 +0100
Damien Lespiau wrote:
> On Fri, Sep 20, 2013 at 05:54:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> > > When booting with i915.fastboot=1, we always take tha code path and end
> > > up undoing what we're t
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
^--- copy and paste error - should of course
https://bugs.freedesktop.org/show_bug.cgi?id=69623
Laurent carlier changed:
What|Removed |Added
Attachment #86224|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #35 from Jose P. ---
(In reply to comment #34)
> (In reply to comment #33)
> > (which AFAIK is normal, but didn't happen before).
>
> Yes, that's normal and not related to this problem.
>
> Note that the 'Attempted to destroy previo
On Fri, Sep 20, 2013 at 9:36 AM, Alex Ivanov wrote:
> Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.
>
> Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to
> a KP if ring buffer was deallocated, e.g. on failed ring test.
> Seen on PA-RISC
This is a minor cleanup of Dave's initial patches to
add runtime PM to radeon powerxpress laptops. It
seems to work well on PX laptop I have access to at
the moment. This patch set requires kernel 3.12.
Dave Airlie (2):
drm/radeon: convert to pmops
drm/radeon: add runtime PM support (v2)
d
From: Dave Airlie
This is a pre-requisite for runtime pm on powerxpress systems.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h| 4 +--
drivers/gpu/drm/radeon/radeon_device.c | 27 +--
drivers/gpu/drm/radeon/radeon_drv.c| 48 +++
On Fri, Sep 20, 2013 at 3:56 PM, Dave Jones wrote:
> This code appears to be calling psb_gtt_free_range twice with the same args.
> (The second call didn't appear in the diff output, it's right after the
> mutex_unlock)
>
> Spotted with Coverity, not tested due to lack of hardware.
>
> Signed-off
On Fri, Sep 20, 2013 at 02:20:18PM +0300, Dan Carpenter wrote:
> The lower layers of sysfs will not allow an "offset" of more than
> GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But
> it's a little easier to audit if we don't have to worry that the
> subtraction will result in
https://bugs.freedesktop.org/show_bug.cgi?id=66738
--- Comment #14 from lh ---
problem still exist in kernel git 20130918
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.
On Fri, Sep 20, 2013 at 4:25 PM, Mike Lothian wrote:
> Hi
>
> Is there an easy way to check this is on?
It's on by default if your system is a powerxpress system (hybrid laptop).
>
> I have radeon.dynpm=1 in grub but usually when I use switcheroo I see
> messages saying the card if now off at th
On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov wrote:
> 17.09.2013, в 18:24, Alex Deucher написал(а):
>
>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov wrote:
>>> Alex,
>>>
>>> 10.09.2013, в 16:37, Alex Deucher написал(а):
>>>
The dummy page isn't really going to help much. That page is jus
From: Dave Airlie
This hooks radeon up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and powerxpress laptops.
v2: agd5f: clean up, add module parameter
Signed-off-by: Dave Airlie
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h
https://bugs.freedesktop.org/show_bug.cgi?id=69623
Priority: medium
Bug ID: 69623
Assignee: dri-devel@lists.freedesktop.org
Summary: Pink Pony misrenders - - shader requires 126 registers
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=55951
--- Comment #1 from Sven Arvidsson ---
This is still a problem with Mesa 9.2 and the game build from 2013-05-21, but
something has changed, now I get a BadDrawable error and the game exits so
there's no crash or backtrace to get:
X Error of fail
On Fri, Sep 20, 2013 at 6:10 PM, Mike Lothian wrote:
> Sorry that was a typo on my part. I'm using radeon.runpm=1
>
> I can see audio is switched off
>
> [drm] Disabling audio 0 support
>
> When I use DRI_PRIME=1 I see the DRM initialisation for my card each time I
> fire up an application or run
On Sat, Sep 21, 2013 at 8:30 AM, Mike Lothian wrote:
> It's probably easier if I just show you this:
>
> http://pastebin.com/xpBJkZDw
>
> Is that expected behaviour? I'm used to seeing something more definite when
> echoing OFF into /sys/kernel/debug/vgaswitcheroo/switch
>
> I've just confirmed wi
On Thu, Aug 15, 2013 at 11:48 AM, Alex Deucher wrote:
> The vrefresh field of the mode is 0 for most modes
> fetched from the EDID (e.g., established timings).
> When dealing with monitors that have a bogus preferred
> mode, we may not always select the mode we want because
> we compare the target
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #28 from Rafael Castillo ---
Sadly this patch breaks mesa to the point glamor/xinit/weston hangs my 7770
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=37117
--- Comment #2 from Antonio Alecrim Jr ---
Just for records:
Check the the comment bug 57018#c3
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #22 from Alexandre Demers ---
Doesn't seem to fix anything over here.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=66067
--- Comment #13 from Roland Scheidegger ---
(In reply to comment #12)
> (In reply to comment #11)
> > > ARB_fragment_program_shadow may leave it undefined, but the GL spec ...
> >
> > Which spec exactly? GL specifications only cover GLSL shaders
21.09.2013, в 1:27, Alex Deucher написал(а):
> On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov wrote:
>> 17.09.2013, в 18:24, Alex Deucher написал(а):
>>
>>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov wrote:
Alex,
10.09.2013, в 16:37, Alex Deucher написал(а):
> The d
https://bugs.freedesktop.org/show_bug.cgi?id=68802
--- Comment #2 from russianneuroman...@ya.ru ---
Probably should be solved by this:
http://cgit.freedesktop.org/~deathsimple/mesa/commit/?id=9334f7d0f16738b4817e853d6d8cb1432953abfb
--
You are receiving this mail because:
You are the assignee fo
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Thursday, September 19, 2013 1:15 PM
>
> On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter wrote:
> > On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote:
> >> > From: Paul Zimmerman
> >> > Sent: Thursday, September 19, 2013 11:21 AM
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
From: Santosh Shilimkar
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_ma
From: Santosh Shilimkar
The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.
No functional change.
The idea is to fix the bad assumptions about dma_mas
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> Provide a helper to set both the DMA and coherent DMA masks to the
> same value - this avoids duplicated code in a number of drivers,
> sometimes with buggy error handling, and also allows us identify
> which drivers do things differently.
>
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #21 from Alexandre Demers ---
(In reply to comment #20)
> Hello,
> I wont be able to test it until October. Will update then, unless someone
> else can test it instead.
> Peter
I may give it a try this weekend, but I'm using a HD6950
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
17.09.2013, в 23:33, Alex Ivanov написал(а):
> 17.09.2013, в 18:24, Alex Deucher написал(а):
>
>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov wrote:
>>> Alex,
>>>
>>> 10.09.2013, в 16:37, Alex Deucher написал(а):
>>>
The dummy page isn't really going to help much. That page is just
>
On Tue, 17 Sep 2013, Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows 8 doesn't use the ACPI interface, including
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #34 from Michel Dänzer ---
(In reply to comment #33)
> (which AFAIK is normal, but didn't happen before).
Yes, that's normal and not related to this problem.
Note that the 'Attempted to destroy previously destroyed buffer.' messages
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #15 from Andrew Stubbs ---
I fixed the problem now! (At least, for my own needs.)
The patch turns out to be very simple.
1. Disregard the mode setting (why does the PPLL care?)
2. Allow a little leeway in the frequency matching. I'v
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #16 from Andrew Stubbs ---
Created attachment 108951
--> https://bugzilla.kernel.org/attachment.cgi?id=108951&action=edit
Proposed patch
--
You are receiving this mail because:
You are watching the assignee of the bug.
Signed-off-by: Damien Lespiau
---
edid-decode.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index bf0c3da..d3e3118 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -829,12 +829,26 @@ cea_hdmi_block(unsigned char *x)
The lower layers of sysfs will not allow an "offset" of more than
GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But
it's a little easier to audit if we don't have to worry that the
subtraction will result in negative values.
Signed-off-by: Dan Carpenter
diff --git a/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=69463
--- Comment #7 from samit vats ---
The Debug output with EGL_DRIVER=egl_dri2
II) [KMS] Kernel modesetting enabled.
libEGL debug: Native platform type: drm (environment overwrite)
libEGL debug: ignore EGL_DRIVERS_PATH for setuid/setgid binaries
Am 19.09.2013 04:07, schrieb Dave Airlie:
Hi Linus,
mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
for AST driver.
Dave.
The following changes since commit
01172772c7c973debf5b4881fcb9463891ea97ec:
drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53
On Fri, Sep 20, 2013 at 8:01 AM, Dieter Nützel wrote:
> Am 19.09.2013 04:07, schrieb Dave Airlie:
>
>> Hi Linus,
>>
>> mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
>> for AST driver.
>>
>> Dave.
>>
>> The following changes since commit
>> 01172772c7c973debf5b4881fcb9463891
Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.
Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a
KP if ring buffer was deallocated, e.g. on failed ring test.
Seen on PA-RISC machine having "radeon: ring test failed
(scratch(0x8504)=0
On Thu, Sep 19, 2013 at 05:40:29PM +0100, Damien Lespiau wrote:
> When using the frame packing and a single big framebuffer, some hardware
> requires that we do everything like if we were scanning out the big
> buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
> this adjustem
https://bugs.freedesktop.org/show_bug.cgi?id=69463
--- Comment #8 from Michel Dänzer ---
(In reply to comment #7)
> The Debug output with EGL_DRIVER=egl_dri2
Yet another crash... Can you get a backtrace for this one with gdb? You'll need
to do that from a remote shell, e.g. via ssh.
--
You ar
This code appears to be calling psb_gtt_free_range twice with the same args.
(The second call didn't appear in the diff output, it's right after the
mutex_unlock)
Spotted with Coverity, not tested due to lack of hardware.
Signed-off-by: Dave Jones
diff --git a/drivers/gpu/drm/gma500/framebuffe
On Don, 2013-09-19 at 18:37 +0200, Marek Olšák wrote:
> On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
> > On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
> >> This fixes VM protection faults.
> >>
> >> I have a new piglit test which can iterate over all possible widths,
> >> heights
On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> When booting with i915.fastboot=1, we always take tha code path and end
> up undoing what we're trying to do with adjusted_mode.
>
> Hopefully, as the fastboot hardware readout code is using adjusted_mode
> as well, it should be equ
On Fri, Sep 20, 2013 at 05:54:55PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> > When booting with i915.fastboot=1, we always take tha code path and end
> > up undoing what we're trying to do with adjusted_mode.
> >
> > Hopefully, as the fastboot
I agree we should make npix_x/y/z more useful, but at the same time
it's a public interface and current and old Mesa depends on the
seemingly incorrect values we set there. This wouldn't be an issue if
we merged the allocator to Mesa, along with xf86-video-ati. Who's with
me? :)
In particular, I t
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #27 from Rafael Castillo ---
many thanks for your hard work, ill test it tonight and report back
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mai
On Thu, Sep 19, 2013 at 05:40:15PM +0100, Damien Lespiau wrote:
> v4 was:
> http://lists.freedesktop.org/archives/dri-devel/2013-September/045340.html
>
> Changes from v4:
>
> - The kernel is now in charge of adjusting the stereo mode timings.
> - There is a per-connector opt-in boolean to ex
On Fri, 20 Sep 2013 16:33:47 +0100
Damien Lespiau wrote:
> On Fri, Sep 20, 2013 at 05:54:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> > > When booting with i915.fastboot=1, we always take tha code path and end
> > > up undoing what we're t
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
^--- copy and paste error - should of course
https://bugs.freedesktop.org/show_bug.cgi?id=69623
Laurent carlier changed:
What|Removed |Added
Attachment #86224|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #35 from Jose P. ---
(In reply to comment #34)
> (In reply to comment #33)
> > (which AFAIK is normal, but didn't happen before).
>
> Yes, that's normal and not related to this problem.
>
> Note that the 'Attempted to destroy previo
On Fri, Sep 20, 2013 at 9:36 AM, Alex Ivanov wrote:
> Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.
>
> Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to
> a KP if ring buffer was deallocated, e.g. on failed ring test.
> Seen on PA-RISC
This is a minor cleanup of Dave's initial patches to
add runtime PM to radeon powerxpress laptops. It
seems to work well on PX laptop I have access to at
the moment. This patch set requires kernel 3.12.
Dave Airlie (2):
drm/radeon: convert to pmops
drm/radeon: add runtime PM support (v2)
d
From: Dave Airlie
This is a pre-requisite for runtime pm on powerxpress systems.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h| 4 +--
drivers/gpu/drm/radeon/radeon_device.c | 27 +--
drivers/gpu/drm/radeon/radeon_drv.c| 48 +++
On Fri, Sep 20, 2013 at 3:56 PM, Dave Jones wrote:
> This code appears to be calling psb_gtt_free_range twice with the same args.
> (The second call didn't appear in the diff output, it's right after the
> mutex_unlock)
>
> Spotted with Coverity, not tested due to lack of hardware.
>
> Signed-off
On Fri, Sep 20, 2013 at 02:20:18PM +0300, Dan Carpenter wrote:
> The lower layers of sysfs will not allow an "offset" of more than
> GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But
> it's a little easier to audit if we don't have to worry that the
> subtraction will result in
https://bugs.freedesktop.org/show_bug.cgi?id=66738
--- Comment #14 from lh ---
problem still exist in kernel git 20130918
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.
On Fri, Sep 20, 2013 at 4:25 PM, Mike Lothian wrote:
> Hi
>
> Is there an easy way to check this is on?
It's on by default if your system is a powerxpress system (hybrid laptop).
>
> I have radeon.dynpm=1 in grub but usually when I use switcheroo I see
> messages saying the card if now off at th
On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov wrote:
> 17.09.2013, в 18:24, Alex Deucher написал(а):
>
>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov wrote:
>>> Alex,
>>>
>>> 10.09.2013, в 16:37, Alex Deucher написал(а):
>>>
The dummy page isn't really going to help much. That page is jus
1 - 100 of 336 matches
Mail list logo
