https://bugs.freedesktop.org/show_bug.cgi?id=64091
Michel Dänzer changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #8 from Nick 2013-05-01 07:32:39 ---
According to powertop it saves about 0.5W or a little bit more. Not a
break-thru but still useful. Thanks!
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #9 from Michel Dänzer 2013-05-01 07:49:06 ---
(In reply to comment #8)
> According to powertop it saves about 0.5W or a little bit more.
That's just from not enabling backing store? Not bad, considering backing store
is basically
On Wed, May 1, 2013 at 6:37 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from the drm tree and commit
> 72419203cab9 ("drm
Prevents buffers from being pinned forever.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 13 +++--
include/drm/drmP.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/g
This allows importing bo's to own device to work without requiring that the
buffer is pinned in GART.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
d
Changes since v1:
- Fixup compiler warning in unpin function.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 ++
drivers/gpu/drm/radeon/radeon_prime.c | 18 +-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --g
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_gem.h | 1 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 9 -
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
ind
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 3b6dc88..9750bb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/dri
Add missing calls, and fix a leak from forgetting to call the unpin function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drive
Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
1 file changed, 2 insertions(+)
On Wed, May 1, 2013 at 6:30 AM, Dave Airlie wrote:
> Since we ask the dmabuf owner to map the dma-buf into our device
> address space, but for udl at present that is the CPU address space,
> since we don't DMA directly from the mapped buffer.
>
> However if we don't set a dma mask on the usb devic
On Wed, Apr 24, 2013 at 11:35 PM, Laura Abbott wrote:
> Hi all,
>
> I've been looking at a better way to do custom dma allocation algorithms in
> a similar style to Ion heaps. Most drivers/clients have come up with a
> series of semi-standard ways to get memory (CMA, memblock_reserve,
> discontigu
https://bugs.freedesktop.org/show_bug.cgi?id=38856
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Linus,
The 3.10 pull request for dma-buf framework updates: small one, could
you please pull?
Thanks and best regards,
~Sumit.
The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f:
Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700)
are available
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #2 from José Fonseca ---
I'm fine droping radeon from scons build.
Neither of the two build systems (scons / autotools) will go away any time
soon, so instead of trying to build evertyhing with both, it makes more sense
to focus on t
https://bugs.freedesktop.org/show_bug.cgi?id=64096
--- Comment #2 from vincent ---
Created attachment 78720
--> https://bugs.freedesktop.org/attachment.cgi?id=78720&action=edit
Disable bank_swizzle
Hi,
there is a bug that makes mesa change bank_swizzle if they are provided by
backend,
can you
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #3 from Marek Olšák ---
FWIW, I made patches which remove radeon drivers from the scons build 2 years
ago and some people weren't very happy about it. I think we shouldn't support 2
build systems for Linux-only drivers.
--
You are r
https://bugs.freedesktop.org/show_bug.cgi?id=64091
Jerome Glisse changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman wrote:
> On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 6be940e..2e44733 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #4 from Michel Dänzer ---
(In reply to comment #3)
> FWIW, I made patches which remove radeon drivers from the scons build 2
> years ago and some people weren't very happy about it.
At the time, the make based build system didn't sup
https://bugs.freedesktop.org/show_bug.cgi?id=64124
Priority: medium
Bug ID: 64124
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] aruba crash with 32bit applications on 64bit
kernel
Severity: normal
Classificat
https://bugs.freedesktop.org/show_bug.cgi?id=64124
--- Comment #1 from Alan Swanson ---
Created attachment 78730
--> https://bugs.freedesktop.org/attachment.cgi?id=78730&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Tue, Apr 30, 2013 at 7:22 PM, Sylvain BERTRAND wrote:
> Hi,
>
> In radeon_atombios.c file, radeon_atombios_parse_power_table_6
> function, the power state is selected using the state array index:
>
> power_state = (union pplib_power_state *)&state_array->states[i];
>
> The state array has varia
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Laurent Bonnaud changed:
What|Removed |Added
CC||laurent.bonn...@inpg.fr
--- Comment
From: Alex Deucher
The code was mis-handling variable sizes arrays.
Reported-by: Sylvain BERTRAND
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
Much of the code in Exynos DRM subsystem is generic enough to use
it for older (non-Exynos) Samsung SoCs as well, after minor modifications.
This series starts adding support for previous SoCs to Exynos DRM by
introducing S3C64xx support to exynos_drm_fimd driver.
Adding support for remaining SoC
This patch adds pointer to driver data to fimd_context structure, to
remove the need to call drm_fimd_get_driver_data() each time access to
driver data is necessary.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Some platforms that can be supported with this driver have PRTCON
register instead of SHADOWCON, which requires slightly different
handling.
This patch factors out all register shadow control code from the driver
and adds a function to control register shadowing appropriately,
depending on driver
Some platforms that can be supported this driver has additional clock
source selection bits in VIDCON0 register that allows to select which
clock should be used to drive the pixel clock: bus clock or special
clock.
Since this driver assumes that special clock always drives the pixel
clock, this pa
The FIMD block present on S3C6400/S3C6410 SoCs is compatible with this
driver, so it can be supported by it as well.
This patch adds appropriate device IDs and driver data to enable this
driver for S3C64xx SoCs.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
This patch modifies the driver to perform two stage parsing of video
timings from device tree, to get timing information as struct videomode,
which contains more data than struct fb_videomode.
Thanks to this change, information about polarity of control signals
(VSYNC, HSYNC, VDEN, VCLK) can be re
https://bugs.freedesktop.org/show_bug.cgi?id=61747
--- Comment #12 from Chris Rankin ---
Created attachment 78735
--> https://bugs.freedesktop.org/attachment.cgi?id=78735&action=edit
dmesg output showing GPU lockup
No, it doesn't appear to. I compiled this version of Mesa after recompiling
lib
On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Figa wrote:
> This patch modifies the driver to perform two stage parsing of video
> timings from device tree, to get timing information as struct videomode,
> which contains more data than struct fb_videomode.
>
> Thanks to this change, information
https://bugzilla.kernel.org/show_bug.cgi?id=50941
JP Pozzi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, May 2, 2013 at 2:02 AM, Borislav Petkov wrote:
> Hi,
>
> I'm seeing this when booting latest Linus tree + tip/master in kvm.
> Config is attached. Looks like it cannot find root fs and panics and
> calls the panic notifier which screams in drm_crtc.c because not all
> modeset locks are tak
On Thu, May 2, 2013 at 10:41 AM, Daniel Vetter wrote:
> On Thu, May 2, 2013 at 2:02 AM, Borislav Petkov wrote:
>> Hi,
>>
>> I'm seeing this when booting latest Linus tree + tip/master in kvm.
>> Config is attached. Looks like it cannot find root fs and panics and
>> calls the panic notifier which
Hi !
Yes, I'm a newbie, so to introduce myself. I have some programming
knowledge from long ago and have dealt with databases, C,
Assembler, Pascal and others.
I've noticed lately, as I'm sure as you all have, about the dramatic
increase in GPU processing capability. Cuda, openGL, openCL etc.
This stores up dirty updates to the fbdev until the next update after
the buffer has finished moving, otherwise you'd see a lot of failed
to reserve bo during bootup with plymouth was starting.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedeskto
From: Dave Airlie
On F19 testing, it was noticed we get a lot of errors in dmesg
about being unable to reserve the buffer when plymouth starts,
this is due to the buffer being in the process of migrating,
so it makes sense we can't reserve it.
In order to deal with it, this adds delayed updates
From: Dave Airlie
Port over the mgag200 fix to ast as it suffers the same issue.
On F19 testing, it was noticed we get a lot of errors in dmesg
about being unable to reserve the buffer when plymouth starts,
this is due to the buffer being in the process of migrating,
so it makes
From: Dave Airlie
Port over the mgag200 fix to cirrus as it suffers the same issue.
On F19 testing, it was noticed we get a lot of errors in dmesg
about being unable to reserve the buffer when plymouth starts,
this is due to the buffer being in the process of migrating,
so it mak
https://bugs.freedesktop.org/show_bug.cgi?id=63865
--- Comment #9 from Christian Heinz ---
(In reply to comment #8)
> It looks like you are using a bogus unposted vbios image. I think you'll
> need to bisect. If I had to guess, I'd say it's related to some change in
> how the pci rom images are
https://bugs.freedesktop.org/show_bug.cgi?id=63865
--- Comment #10 from Christian Heinz ---
Created attachment 78765
--> https://bugs.freedesktop.org/attachment.cgi?id=78765&action=edit
AMD E-450 APU video BIOS
--
You are receiving this mail because:
You are the assignee for the bug.
44 matches
Mail list logo
