Hi Rahul,
Could you add descriptions to dt document file? For this, you can
refer to the below link,
https://patchwork.kernel.org/patch/1948061/
Thanks,
Inki Dae
2013/1/25 Rahul Sharma :
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_ddc.c | 2 ++
> drivers/gpu
2013/1/30 Sean Paul :
> On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren wrote:
>> On 01/08/2013 01:16 PM, Sean Paul wrote:
>>> Add a property to the hdmi node so we can specify the HDMI version in
>>> the device tree instead of just defaulting to v1.4 with the existence of
>>> the dt node.
>>
>> I
Hello Sean,
This patch set will be abandoned and your comments will be addressed
in reply to
http://lists.freedesktop.org/archives/dri-devel/2013-January/034080.html
Thanks,
Leela Krishna Amudala.
On Tue, Jan 29, 2013 at 1:42 PM, Leela Krishna Amudala
wrote:
> This patch adds display-timing node
On Tue, Jan 29, 2013 at 08:35:28PM +0100, Marcus Lorentzon wrote:
> On 01/29/2013 04:50 PM, Daniel Vetter wrote:
> >On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter
> >wrote:
> >Ok, in the interest of pre-heating the discussion a bit I've written down
> >my thoughts about display slave drivers. Add
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/4b600e61/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/1ef44e6d/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/3ae24f9b/attachment.html>
Hi,
On 01/08/2013 11:56 PM, Stephen Warren wrote:
> On 01/08/2013 01:16 PM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>
> I guess this seems OK to me if requi
-
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/20130129/e0f29fef/attachment.html>
On 01/29/2013 04:50 PM, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter
> wrote:
> Ok, in the interest of pre-heating the discussion a bit I've written down
> my thoughts about display slave drivers. Adding a few more people and
> lists to make sure I haven't missed anyone .
ing 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/20130129/076470ae/attachment.html>
than max_rb_num zero
bits in the given disabled_rb_mask
-Mikko
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/c1a632a1/attachment-0001.html>
-- next part --
A non-text attac
||
--
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/20130129/e20812d6/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/b80c3e2f/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/fbc2000a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/3042dc44/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=49981
D. Hugh Redelmeier changed:
What|Removed |Added
CC||h...@mimosa.com
--- Comment #5 f
https://bugzilla.kernel.org/show_bug.cgi?id=53111
--- Comment #2 from cem.aydin at gmx.ch 2013-01-29 19:10:46 ---
Usually I use the current arch package. Looking at the Arch Rollback Machine
(http://arm.konnichi.com/search/index.php?a=64&q=^linux&core=1) shows that
there was made a jump from
On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst
wrote:
>
Hi Maarten,
This is a nice looking extension to avoid re-implementing a mutex in
TTM/reservation code.. ofc, probably someone more familiar with mutex
code should probably review, but probably a bit of explanation about
what and why wo
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/690e90ae/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/2788b63e/attachment.html>
On Tue, Jan 29, 2013 at 03:19:38PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
> wrote:
> >> DevRooms are also not supposed to open before 11:00 (which is already a
> >> massive improvement over 2011 and the years before, where i was happy
> >> to be able to put
https://bugzilla.kernel.org/show_bug.cgi?id=52121
--- Comment #20 from Fernando Chaves 2013-01-30
02:08:38 ---
Well...
Same thing with EFI boot. Video still slow.
I think I should use a VGA card for a while (or forever).
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?ta
Op 17-01-13 09:40, Daniel Vetter schreef:
> On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner
> wrote:
>> Can I consider this a Reviewed-by?
> Essentially it was just a drive-by bikeshed ;-) I think it'd be good
> if Maarten takes a look at this and checks whether it complies with
> his massive pr
GETFB ioctl request creates a new handle to only one gem object
so it should check if the given fb has one gem object.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/driv
On Tue, 2013-01-29 at 17:52 +0100, Maarten Lankhorst wrote:
> It looks like the original commit that copied the rom contents from efi
> always copied
> the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
> ("x86, efi: correct precedence of operators in setup_efi_pci") broke that.
It looks like the original commit that copied the rom contents from efi always
copied
the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
("x86, efi: correct precedence of operators in setup_efi_pci") broke that.
This resulted in macbook pro's no longer finding the rom images, a
From: Stephen Warren
Silence the following:
drivers/gpu/drm/drm_irq.c: In function 'drm_calc_vbltimestamp_from_scanoutpos':
drivers/gpu/drm/drm_irq.c:583:24: warning: 'mono_time_offset.tv64' may be used
uninitialized in this function
... by always initializing mono_time_offset to zero. In pract
On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst
wrote:
>
Hi Maarten,
This is a nice looking extension to avoid re-implementing a mutex in
TTM/reservation code.. ofc, probably someone more familiar with mutex
code should probably review, but probably a bit of explanation about
what and why wo
Signed-off-by: Aaron Plattner
---
Example output of dristat -C:
/dev/dri/card0
Device capabilities:
Dumb framebuffer: yes
VBlank high crtc: yes
Preferred depth: 24
Prefer shadow: yes
Prime: import export
tests/dristat.c | 69 +
Signed-off-by: Aaron Plattner
---
Example output of dristat -C:
/dev/dri/card0
Device capabilities:
Dumb framebuffer: yes
VBlank high crtc: yes
Preferred depth: 24
Prefer shadow: yes
Prime: import export
tests/dristat.c | 69 +
On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter
wrote:
> On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
> wrote:
>>> DevRooms are also not supposed to open before 11:00 (which is already a
>>> massive improvement over 2011 and the years before, where i was happy
>>> to be able to put the cabli
This patch modifies iommu address allocation order from 64k
to 4k. 64k order causes waste of the io space and this was
our mistakes.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_iommu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
di
Hi Linus,
from LCA request, intel, radeon and exynos fixes, nothing too major or
wierd, one dmar fix and a radeon cursor corruption, along with misc exynos
fixes.
Dave.
The following changes since commit 014b34409fb2015f63663b6cafdf557fdf289628:
ttm: on move memory failure don't leave a no
Mesa Git still leak?
--
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/20130129/4be6b620/attachment.html>
f you confirm/reproduce this memory leak on your own systems?
--
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/20130129/
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/5d257545/attachment.html>
memory.
--
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/20130129/9a4d8d9f/attachment.html>
From: Stephen Warren
Silence the following:
drivers/gpu/drm/drm_irq.c: In function 'drm_calc_vbltimestamp_from_scanoutpos':
drivers/gpu/drm/drm_irq.c:583:24: warning: 'mono_time_offset.tv64' may be used
uninitialized in this function
... by always initializing mono_time_offset to zero. In pract
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/5145f1b3/attachment-0001.html>
is 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/20130129/ed497ba8/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/14e5ff70/attachment.html>
[Can a developer rename this bug report for me, using your preferred naming
conventions?]
--
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/20130129/4a6bb57c/attachment.html>
On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
wrote:
>> DevRooms are also not supposed to open before 11:00 (which is already a
>> massive improvement over 2011 and the years before, where i was happy
>> to be able to put the cabling in at 12:00), and i tend to first get a
>> nod of approval f
Hi Dave,
The holiday pull fresh from QA. Not much in in, everyone was on vacation.
Highlights:
- Broadcast RBG improvements and reduced color range fixes from Ville
- Ben is on a "kill legacy gtt code for good" spree, first pile of patches
included.
- no relocs and lut improvements for faster ex
On Mon, Jan 14, 2013 at 3:37 PM, Paul Menzel
wrote:
> Am Montag, den 14.01.2013, 11:06 +0100 schrieb Daniel Vetter:
>> This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b.
>>
>> The quirk cause a regression, and it looks like the original bug was
>> simply a lack of FIFO bandwidth on the
My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam
every few seconds.
I get it the first time that the entire block is all 0xff..
Signed-off-by: Maarten Lankhorst
Cc: stable at vger.kernel.org [v3.7]
---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid
https://bugzilla.kernel.org/show_bug.cgi?id=53111
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
On Tue, Jan 29, 2013 at 08:35:28PM +0100, Marcus Lorentzon wrote:
> On 01/29/2013 04:50 PM, Daniel Vetter wrote:
> >On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter
> >wrote:
> >Ok, in the interest of pre-heating the discussion a bit I've written down
> >my thoughts about display slave drivers. Add
https://bugs.freedesktop.org/show_bug.cgi?id=59899
--- Comment #4 from aeriks...@fastmail.fm ---
Created attachment 73878
--> https://bugs.freedesktop.org/attachment.cgi?id=73878&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=59899
--- Comment #3 from aeriks...@fastmail.fm ---
Created attachment 73877
--> https://bugs.freedesktop.org/attachment.cgi?id=73877&action=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=59899
--- Comment #2 from aeriks...@fastmail.fm ---
Created attachment 73876
--> https://bugs.freedesktop.org/attachment.cgi?id=73876&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
___
Hi Luc,
On Tuesday 29 January 2013 12:47:16 Luc Verhaegen wrote:
> On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote:
> > On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
> > > I've sent a mail to the FOSDEM organizers to request a hacking room for
> > > a couple of hours
https://bugs.freedesktop.org/show_bug.cgi?id=59904
--- Comment #10 from maxi...@free.fr ---
OK, it looks like it only happens when I'm on linux 3.8, it's OK when running
linux 3.7.
Also when using 3.8 it does look like a memory leak too ! So I experience the
same symptoms.
--
You are receiving t
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/afbe4caf/attachment.html>
On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote:
> Hello,
>
> On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
> >
> > I've sent a mail to the FOSDEM organizers to request a hacking room for a
> > couple of hours Sunday. I'll let you know as soon as I get a reply.
>
>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/66b96fa8/attachment-0001.html>
Hello,
On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
> On Thursday 17 January 2013 13:29:27 Daniel Vetter wrote:
> > On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote:
> > > On Fri, 11 Jan 2013, Laurent Pinchart wrote:
> > >> Would anyone be interested in meeting at the FOSDEM to dis
https://bugs.freedesktop.org/show_bug.cgi?id=60034
--- Comment #3 from Andy Furniss ---
Comment on attachment 73868
--> https://bugs.freedesktop.org/attachment.cgi?id=73868
worse case from cold boot
Ignore low fps on this compared to other screen - the card was on low.
--
You are receiving t
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/6e7cf06a/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=60034
Andy Furniss changed:
What|Removed |Added
Attachment #73869|text/plain |image/png
mime type|
o /sys/module/drm/parameters/debug
and capture some debugging output from dmesg?
--
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
https://bugs.freedesktop.org/show_bug.cgi?id=60034
--- Comment #2 from Andy Furniss ---
Created attachment 73869
--> https://bugs.freedesktop.org/attachment.cgi?id=73869&action=edit
best case after repeated runs
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=60034
--- Comment #1 from Andy Furniss ---
Created attachment 73868
--> https://bugs.freedesktop.org/attachment.cgi?id=73868&action=edit
worse case from cold boot
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=60034
Priority: medium
Bug ID: 60034
Assignee: dri-devel@lists.freedesktop.org
Summary: rv790 etqw regression since r600g: add async for
staging buffer upload v2
Severity: normal
On 01/29/2013 04:50 PM, Daniel Vetter wrote:
On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter wrote:
Ok, in the interest of pre-heating the discussion a bit I've written down
my thoughts about display slave drivers. Adding a few more people and
lists to make sure I haven't missed anyone ...
Cheer
Add an output panel driver for LCD panels. Tested with LCD3 cape on
beaglebone.
v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
Antoniou
v3: add backlight support
v4: rebase to latest of video timing helpers
v5: remove some unneeded fields from panel-info struc
Add output panel driver for i2c encoder slaves.
v1: original
v2: add DT bindings docs, and minor updates for review comments
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
Tested-by: Koen Kooi
---
.../devicetree/bindings/drm/tilcdc/slave.txt | 19 ++
drivers/gpu/drm/tilcdc/Makefil
Driver for the NXP TDA998X i2c hdmi encoder slave.
v1: original
v2: fix npix/nline programming
v3: add Kconfig, fix dup'd MODULE_DESCRIPTION
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
Tested-by: Koen Kooi
---
drivers/gpu/drm/i2c/Kconfig | 6 +
drivers/gpu/drm/i2c/Makefile
A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
CMA helpers. Currently only the TFP410 DVI encoder is supported
(tested with beaglebone + DVI cape). There are also various LCD
displays, for which support can be add
One more iteration.. now with more cowbell!
The first patch adds the basic driver and TFP410 DVI output.
The second patch adds support for NXP TDA998x family of i2c connected
HDMI encoders. It is split out into an i2c encoder-slave in case someone
else has hw with the same HDMI encoder.
The fin
https://bugzilla.kernel.org/show_bug.cgi?id=53111
--- Comment #2 from cem.ay...@gmx.ch 2013-01-29 19:10:46 ---
Usually I use the current arch package. Looking at the Arch Rollback Machine
(http://arm.konnichi.com/search/index.php?a=64&q=^linux&core=1) shows that
there was made a jump from 3.6
On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren wrote:
> On 01/08/2013 01:16 PM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>
> I guess this seems OK to me if r
On Tue, Jan 29, 2013 at 10:57 AM, Takashi Iwai wrote:
> At Tue, 29 Jan 2013 10:53:50 +0100,
> Daniel Vetter wrote:
>>
>> On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
>> > Add a new option, bpp, to specify the default bpp value.
>> >
>> > Signed-off-by: Takashi Iwai
>> > ---
>> >
At Tue, 29 Jan 2013 10:53:50 +0100,
Daniel Vetter wrote:
>
> On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
> > Add a new option, bpp, to specify the default bpp value.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> >
> > This patch is applied on the top of previous two patches.
>
On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
> Add a new option, bpp, to specify the default bpp value.
>
> Signed-off-by: Takashi Iwai
> ---
>
> This patch is applied on the top of previous two patches.
> I couldn't find an easy way to specify the default bpp, so I cooked
> the
https://bugs.freedesktop.org/show_bug.cgi?id=59903
--- Comment #7 from Michael Lange ---
Created attachment 73865
--> https://bugs.freedesktop.org/attachment.cgi?id=73865&action=edit
dmesg_debug_1
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=59903
--- Comment #6 from Michael Lange ---
* today i recompiled mesa from master git (tree
d276e9294d1f1218e374d43c1320b376ee265ad4) and linux-3.8.0-rc5
* xbmc is starting and working fine again
* the flip errors still appears in /var/log/Xorg.0.lo
On Wed, 2013-01-09 at 12:45 +0100, Arend van Spriel wrote:
> Maybe this one is already known, but I did not find a post about it. So
> here it is.
>
> Regards,
> Arend
[snip]
> [9.589986] =
> [9.595365] [ INFO: possible recursive locking detect
Add a new option, bpp, to specify the default bpp value.
Signed-off-by: Takashi Iwai
---
This patch is applied on the top of previous two patches.
I couldn't find an easy way to specify the default bpp, so I cooked
the driver quickly. If there is any other convenient way to achieve
this, let me
Add an output panel driver for LCD panels. Tested with LCD3 cape on
beaglebone.
v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
Antoniou
v3: add backlight support
v4: rebase to latest of video timing helpers
v5: remove some unneeded fields from panel-info struc
Add output panel driver for i2c encoder slaves.
v1: original
v2: add DT bindings docs, and minor updates for review comments
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
Tested-by: Koen Kooi
---
.../devicetree/bindings/drm/tilcdc/slave.txt | 19 ++
drivers/gpu/drm/tilcdc/Makefil
Hi Dave,
any chance to take a look at this problem?
thanks,
Takashi
At Fri, 25 Jan 2013 17:21:54 +0100,
Takashi Iwai wrote:
>
> When the mode is set with 16bpp on QEMU, the output gets totally
> broken. The culprit is the bogus register values set for 16bpp,
> which was likely copied from fr
Driver for the NXP TDA998X i2c hdmi encoder slave.
v1: original
v2: fix npix/nline programming
v3: add Kconfig, fix dup'd MODULE_DESCRIPTION
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
Tested-by: Koen Kooi
---
drivers/gpu/drm/i2c/Kconfig | 6 +
drivers/gpu/drm/i2c/Makefile
One more iteration.. now with more cowbell!
The first patch adds the basic driver and TFP410 DVI output.
The second patch adds support for NXP TDA998x family of i2c connected
HDMI encoders. It is split out into an i2c encoder-slave in case someone
else has hw with the same HDMI encoder.
The fin
On 01/28/2013 05:38 AM, Rahul Sharma wrote:
It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
creating SG table for the buffers having more than 204 physical pages i.e.
equal to SG_MAX_SINGLE_ALLO
On 01/28/2013 05:38 AM, Rahul Sharma wrote:
> It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
> sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
> creating SG table for the buffers having more than 204 physical pages i.e.
> equal to SG_MAX_SINGL
Op 17-01-13 09:40, Daniel Vetter schreef:
> On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner wrote:
>> Can I consider this a Reviewed-by?
> Essentially it was just a drive-by bikeshed ;-) I think it'd be good
> if Maarten takes a look at this and checks whether it complies with
> his massive prime
It looks like the original commit that copied the rom contents from efi always
copied
the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
("x86, efi: correct precedence of operators in setup_efi_pci") broke that.
This resulted in macbook pro's no longer finding the rom images, a
https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #7 from Michel Dänzer ---
This is indeed more likely an issue in Mesa than in the kernel. The commit you
bisected also bumps KMS_DRIVER_MINOR in radeon_drv.c, which may cause the Mesa
code to use different code paths.
Does current Me
On Tue, Jan 29, 2013 at 03:19:38PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
> wrote:
> >> DevRooms are also not supposed to open before 11:00 (which is already a
> >> massive improvement over 2011 and the years before, where i was happy
> >> to be able to put
https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #6 from Dave Witbrodt ---
I do not know how to interpret these findings. I am not a developer, and work
with the few tools that I (sort of) know how to use much more slowly than
experienced developers would. I ran out of time over t
https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #5 from Dave Witbrodt ---
Created attachment 73844
--> https://bugs.freedesktop.org/attachment.cgi?id=73844&action=edit
diff of attempt to manually revert entire problem commit
Attempt to revert the entire commit
I then decided to
https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #4 from Dave Witbrodt ---
Created attachment 73843
--> https://bugs.freedesktop.org/attachment.cgi?id=73843&action=edit
diff of attempt to partially revert problem commit
Naive attempt to revert
My first attempt to revert the patc
On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren wrote:
> On 01/08/2013 01:16 PM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>
> I guess this seems OK to me if r
https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #3 from Dave Witbrodt ---
Bisecting
So far, I have only bisected using my local custom kernel branch. As described
above, I use stable kernel releases to avoid the massive breakage that
frequently occurs in -rc kernels, and I cherry
https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #2 from Dave Witbrodt ---
Created attachment 73842
--> https://bugs.freedesktop.org/attachment.cgi?id=73842&action=edit
Output from successive runs of 'top'
Running 'top' revealed the memory leak.
This attachment is (clipped) outp
https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #1 from Dave Witbrodt ---
Created attachment 73840
--> https://bugs.freedesktop.org/attachment.cgi?id=73840&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=60028
Priority: medium
Bug ID: 60028
Assignee: dri-devel@lists.freedesktop.org
Summary: Post-3.7.x memory leak, Radeon Evergreen, bisected
Severity: major
Classification: Unclassified
On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
> wrote:
>>> DevRooms are also not supposed to open before 11:00 (which is already a
>>> massive improvement over 2011 and the years before, where i was happy
>>> to be able to put the cablin
1 - 100 of 129 matches
Mail list logo
