[ adding Ben Skeggs and Dave Airlie ]
On Tue, 2013-03-19 at 21:24 +0100, Borislav Petkov wrote:
> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> > Dropping Tegra ML, it's not the place where Nouveau mails should go.
> > Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouv
On Mon, Mar 18, 2013 at 09:32:51AM +0100, Daniel Vetter wrote:
>
> Another pesky BIOS which changes the display state behind our back on lid
> closing! Should be duct-tapped over with
>
> commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
> Author: Daniel Vetter
> Date: Fri Nov 23 18:16:34 2012 +
On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
the user X session is coming up:
BUG: unable to handle kernel NULL pointer dereference at 0001
IP: [<0001>] 0x0
PGD 0
Oops: 0010 [#1] PREEMPT SMP
Modules linked in: ip6table_filter ip6_tables ebtable_
On 2013-03-19 08:45, Archit Taneja wrote:
> I was trying to come up with a macro which could add default ops to the
> omap_dss_driver. It isn't straight forward as I thought, because you
> need to choose either the default op, or the panel driver's op if it
> exists. For example, I can't create a
On Wed, 2013-03-20 at 02:24 -0300, Lucas Kannebley Tavares wrote:
> Implementation of a architecture-specific pcibios_get_speed_cap_mask.
> This implementation detects bus capabilities based on OF
> ibm,pcie-link-speed-stats property.
The problem with your approach is that it's not a runtime detec
Added function to gather the speed cap for a device and return a mask to
supported speeds. The function is divided into an interface and a weak
implementation so that architecture-specific functions can be called.
This is the first step in moving function drm_pcie_get_speed_cap_mask
from the drm s
Implementation of a architecture-specific pcibios_get_speed_cap_mask.
This implementation detects bus capabilities based on OF
ibm,pcie-link-speed-stats property.
Signed-off-by: Lucas Kannebley Tavares
---
arch/powerpc/platforms/pseries/pci.c | 35 ++
1 files ch
This patch series first implements a function called pcie_get_speed_cap_mask
in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then
it removes the latter and fixes all references to it. And ultimately, it
implements an architecture-specific version of the same function for p
This function was moved to the pci subsystem where it fits better, as
this is much more of a generic pci task, than a drm specific one. All
references to the function (all in the radeon driver) are updated.
This is the second step in moving function drm_pcie_get_speed_cap_mask
from the drm subsyst
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's
On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
> The drmSetMaster call is needed, but the spinning is really just waiting for
> the workqueue to run.
>
> bryce's patch never worked, it just caused it to try drmsetinterfaceversion
> for a few seconds before timing out. That ca
>
> Because of the delayed fput in recent kernels, it is possible for plymouth to
> exit and not drop master right away.
> It's put onto a workqueue to be freed slightly later. Xorg-server starts in
> the meantime, opens a fd, but because the fd
> hasn't been closed by plymouth yet, it didn't get
https://bugs.freedesktop.org/show_bug.cgi?id=60963
--- Comment #1 from Tom Stellard ---
Could you post a dump with RADEON_DEBUG=noopt,vp,fp
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=60503
Tom Stellard changed:
What|Removed |Added
Attachment #74520|0 |1
is obsolete|
On Mon, Mar 18, 2013 at 09:32:51AM +0100, Daniel Vetter wrote:
>
> Another pesky BIOS which changes the display state behind our back on lid
> closing! Should be duct-tapped over with
>
> commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
> Author: Daniel Vetter
> Date: Fri Nov 23 18:16:34 2012 +
On 15.03.2013 14:13, Thierry Reding wrote:
> Also you now create a lookup table (or bitfield actually) as we
> discussed but you still pass around a function to check the lookup table
> against. What I originally intended was to not pass a function around at
> all but directly use the lookup table/
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern
wrote:
> On Tue, 19 Mar 2013, Daniel Vetter wrote:
>
>> For reference below the updated commit message.
>>
>> Cheers, Daniel
>>
>> Author: Jiri Kosina
>> Date: Tue Mar 19 09:56:57 2013 +0100
>
>>
>> drm/i915: stop using GMBUS IRQs on Gen4 chips
>
help?
Just tried both, but nothing changed...
--
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/20130319/0f9b8149/attachment.html>
On 19 March 2013 15:29, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prep
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/1bade028/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/2601989c/attachment.html>
[ adding Ben Skeggs and Dave Airlie ]
On Tue, 2013-03-19 at 21:24 +0100, Borislav Petkov wrote:
> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> > Dropping Tegra ML, it's not the place where Nouveau mails should go.
> > Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouv
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/28a9ab90/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/f92afece/attachment-0001.html>
On Tue, Mar 19, 2013 at 10:03 AM, Chris Wilson
wrote:
>> > How about just using:
>> > if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
>> > and the existing wait loop?
>>
>> I explicitly wanted to avoid touching GMBUS4 register, as the real cause
>> of the failure is not clear.
>>
>> But,
When building the pipeline, instead of using only the encoders attached
to a connector, take all possible encoders into account to locate a
CRTC.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions
The -s argument can now take a list of connectors. Configure all of them
in cloned mode using a single CRTC.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 211 ++
1 file changed, 157 insertions(+), 54 deletions(-)
diff --git a/tests/
This prepares the code for handling multiple connectors in a single
pipeline in a cloned configuration.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 164 --
1 file changed, 86 insertions(+), 78 deletions(-)
diff --git a/tests/modete
There's not reason to require setting a mode to test planes. Split the
two operations.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 105 +++---
1 file changed, 72 insertions(+), 33 deletions(-)
diff --git a/tests/modetest/modetest.c b/t
Planes are associated with CRTCs, not connectors. Don't try to be too
clever, use the CRTC ID in the -P option. This prepares for splitting
CRTC and planes setup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 32 +---
1 file changed, 17 insertions(+)
This prepares the code for the split in separate functions of CRTC and
planes setup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 74e82ef..0
This prepares the code for the split in separate functions of CRTC and
planes setup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 58 ++-
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git a/tests/modetest/modetest.c b/tes
The field is no needed, make it a local variable where used.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 70fa262..ba025d6 100644
--- a/test
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 164e7e1..70fa262 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetes
Instead of passing the device fd and resources as global variables group
them in a device structure and pass it explictly to all functions that
need it.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 199 --
1 file changed, 102 inserti
The argument isn't used, remove it.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ffdb0aa..d6eed4a 100644
--- a/tests/modetest/modetest.c
+++
As modetest automatically selects an unused plan, providing the plane ID
allows modifying plane properties for the selected planes.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c
Extend the -P option to allow specifying the plane x and y offsets. The
position is optional, if not specified the plane will be positioned at
the center of the screen as before.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 72 +--
1
The -w parameter can be used to set a property value from the command
line, using the target object ID and the property name.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 108 +-
1 file changed, 106 insertions(+), 2 deletions(-)
dif
Configuring mode on more than two connectors or two planes is perfectly
valid. Support it.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
Instead of retrieving resources as they are needed, retrieve them all
(except property blobs) in one go at startup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 406 +-
1 file changed, 259 insertions(+), 147 deletions(-)
diff --git
If the -d parameter is specified, modetest will drop master permissions
after setting the mode.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 91
If the -M parameter is specified, modetest will use the requested device
name instead of trying its builtin list of device names.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jani Nikula
---
tests/modetest/modetest.c | 41 -
1 file changed, 28 insertions(
The current mostly random sort order hinders code readability. Sort the
options alphabetically in the code, and by group in the help message.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jani Nikula
---
tests/modetest/modetest.c | 49 ++-
1 file chang
Those variables are declared in unistd.h, there's no need to redeclare
them here.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jani Nikula
---
tests/modetest/modetest.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1081c78..92c7
Enable all standard automake warnings except for -Wpointer-arith (as the
test pattern generation code uses void pointer arithmetics) and fix
them.
Signed-off-by: Laurent Pinchart
---
tests/modetest/Makefile.am | 4 +++-
tests/modetest/buffers.c | 13 +++--
tests/modetest/buffers.h |
Hello,
Here's the fourth version of my modetest enhancements patch set.
The third version only contained patches 01/21 to 04/21. I then felt the need
for a test tool that allows testing more driver features and ended up extending
modetest accordingly.
Beside various cleanups, these patches allow
Added in detection/support for DMM devices when booting with device
tree.
Signed-off-by: Andy Gross
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/
Hi Rob,
2013/3/19 Rob Clark :
> On Mon, Mar 18, 2013 at 9:32 PM, YoungJun Cho wrote:
>>
>> On Mar 19, 2013 9:55 AM, "Rob Clark" wrote:
>>>
>>> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho
>>> wrote:
>>> >
>>> > On Mar 19, 2013 3:01 AM, "Rob Clark" wrote:
>>> >>
>>> >> Btw, what is the hw res
On 19 March 2013 15:29, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prep
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
Signed-of
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/4a6d5a4a/attachment.pgp>
On Tue, Mar 19, 2013 at 03:15:14PM -0400, Christopher Harvey wrote:
> Does the Linux kernel have functions to convert images to palleted
> images? I want to display a 4bit palleted cursor, not too sure how to
> handle that in DRM. Some ideas I have:
>
> * change DRM to handle palleted cursors
>
Does the Linux kernel have functions to convert images to palleted
images? I want to display a 4bit palleted cursor, not too sure how to
handle that in DRM. Some ideas I have:
* change DRM to handle palleted cursors
* convert 32bit images in drivers
* write library functions do convert
* requi
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/f95023ab/attachment-0001.html>
orTiling" "False" in the device section of your
xorg.conf)
4. Try mesa 9.1 or newer.
--
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/20130319/da46c6a5/attachment.html>
On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart
wrote:
> Planes are associated with CRTCs, not connectors. Don't try to be too
> clever, use the CRTC ID in the -P option. This prepares for splitting
> CRTC and planes setup.
hmm, I was thinking that it would be nice to someday make modetest
cle
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> > That might be misleading. It's possible that the erroneous IRQs _are_
> > being issued but you're simply not aware of them. If the kernel thinks
> > that no device is using IRQ 16 then it will leave that IRQ disabled.
>
> I guess I should have phras
On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
> The drmSetMaster call is needed, but the spinning is really just waiting for
> the workqueue to run.
>
> bryce's patch never worked, it just caused it to try drmsetinterfaceversion
> for a few seconds before timing out. That ca
> Just a bit of cleanup from me (resubmitted). The important patch comes
> from Julia. Julia's patch conflicts with the following:
> 1363594270-22137-1-git-send-email-airlied at gmail.com
>
Yeah I was going to leave the cleanups until -next opens, I'll push
the fix though and get it to stable.
Da
iving 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/20130319/c57add13/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/2e447a17/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/ede469de/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/6a4153c9/attachment.html>
7;m hoping that CDF in some form would realize soon, and then copying
omapdss would be at least somewhwat easier, as there's no need to drag
the panel drivers along.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/589289af/attachment.pgp>
org/archives/dri-devel/attachments/20130319/1cde7150/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/062c3076/attachment.html>
u explain this question please (if it was to me)?
--
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/20130319/3efb8220/attachment-0001.html>
Added in detection/support for DMM devices when booting with device
tree.
Signed-off-by: Andy Gross
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's
Op 19-03-13 12:10, Dave Airlie schreef:
>> Because of the delayed fput in recent kernels, it is possible for plymouth
>> to exit and not drop master right away.
>> It's put onto a workqueue to be freed slightly later. Xorg-server starts in
>> the meantime, opens a fd, but because the fd
>> hasn't
I'll give
it a try.
--
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/20130319/4b1e1ff1/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/71d8f112/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/92125db4/attachment.html>
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter wrote:
> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disabled
On Tue, Mar 19, 2013 at 03:15:14PM -0400, Christopher Harvey wrote:
> Does the Linux kernel have functions to convert images to palleted
> images? I want to display a 4bit palleted cursor, not too sure how to
> handle that in DRM. Some ideas I have:
>
> * change DRM to handle palleted cursors
>
On Tuesday 12 March 2013 08:23 PM, Tomi Valkeinen wrote:
> On 2013-03-12 16:38, Archit Taneja wrote:
>
>>> memcmp on two structs is often not a good idea. There could be padding
>>> bytes there, with uninitialized data. I'm not sure if that's the case
>>> here, though, but it could well change any
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter
wrote:
> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disable
Does the Linux kernel have functions to convert images to palleted
images? I want to display a 4bit palleted cursor, not too sure how to
handle that in DRM. Some ideas I have:
* change DRM to handle palleted cursors
* convert 32bit images in drivers
* write library functions do convert
* requi
Hey,
Op 19-03-13 11:27, Chris Wilson schreef:
> On Tue, Mar 19, 2013 at 11:02:14AM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 19-03-13 10:21, Chris Wilson schreef:
>>> On Mon, Mar 18, 2013 at 01:51:44PM -0700, Bryce Harrington wrote:
Update: Squashes a couple commits to avoid potential
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> For reference below the updated commit message.
>
> Cheers, Daniel
>
> Author: Jiri Kosina
> Date: Tue Mar 19 09:56:57 2013 +0100
>
> drm/i915: stop using GMBUS IRQs on Gen4 chips
>
> Commit 28c70f162 ("drm/i915: use the gmbus irq for wai
his 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/20130319/d0af2d69/attachment.html>
On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart
wrote:
> Planes are associated with CRTCs, not connectors. Don't try to be too
> clever, use the CRTC ID in the -P option. This prepares for splitting
> CRTC and planes setup.
hmm, I was thinking that it would be nice to someday make modetest
cle
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> > That might be misleading. It's possible that the erroneous IRQs _are_
> > being issued but you're simply not aware of them. If the kernel thinks
> > that no device is using IRQ 16 then it will leave that IRQ disabled.
>
> I guess I should have phras
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/6b4d6d85/attachment.html>
Kernel driver in use: nouveau
Kernel modules: nouveau, nvidiafb
-- next part --
A non-text attachment was scrubbed...
Name: nouveau_crash_3.9.0-rc3.log
Type: text/x-log
Size: 15201 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel
list:
http://lists.freedesktop.org/archives/mesa-dev/2013-March/036423.html
--
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/20130319/6f762dca/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #14 from Michael Mair-Keimberger ---
(In reply to comment #12)
> I think these are actually several bugs at play here.
>
> 1. CPU only has a 256 MB window into vram. If the window is full due to
> fragmentation or other mapped buffe
_
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> 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/20130319/44176a3a/attachment.html>
9.0.2-34.3.1
I have ATI Radeon HD 2400 XT (RV610).
--
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/20130319/2bbc4
On Tue, Jan 29, 2013 at 09:10:40AM -0800, Aaron Plattner wrote:
> 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 buf
On Mon, Feb 18, 2013 at 07:28:04PM +0200, Imre Deak wrote:
> The existing gtt setup code is correct - and so doesn't need to be fixed to
> handle compact dma scatter lists similarly to the previous patches. Still,
> take the for_each_sg_page macro into use, to get somewhat simpler code.
>
> Signed
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #13 from Michel Dänzer ---
Eugene and Knut, in the future please always include information about which
signal was generated, at least if it's not SIGSEGV (which is the most common).
--
You are receiving this mail because:
You are t
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/b6631296/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #12 from Alex Deucher ---
I think these are actually several bugs at play here.
1. CPU only has a 256 MB window into vram. If the window is full due to
fragmentation or other mapped buffers, we fail. Does disabling hyperz help?
se
On Mon, 18 Mar 2013, Chris Wilson wrote:
> > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > void
> > intel_i2c_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> > - I915_WR
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Daniel Vetter wrote:
>
>> For reference below the updated commit message.
>>
>> Cheers, Daniel
>>
>> Author: Jiri Kosina
>> Date: Tue Mar 19 09:56:57 2013 +0100
>
>>
>> drm/i915: stop using GMBUS IRQs on Gen4 chips
>>
On 15.03.2013 14:13, Thierry Reding wrote:
> Also you now create a lookup table (or bitfield actually) as we
> discussed but you still pass around a function to check the lookup table
> against. What I originally intended was to not pass a function around at
> all but directly use the lookup table/
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #15 from Alex Deucher ---
(In reply to comment #14)
> Is possible to add these options when using KMS? Modifying
> /etc/X11/xorg.conf.d/*.conf is enough?
yes.
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #11 from Michael Mair-Keimberger ---
I don't know if its the same but i can confirm similar crashes.
First of all, i have a triple head setup, 2 screens with 1920x1200 (left and
right) and one with 2560x1600 (middle). Those crashes h
1 - 100 of 154 matches
Mail list logo
