[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #15 from Andy Furniss  ---
(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > I've now recompiled everything from upstream - kwin now renders however 
> > > > it
> > > > has a pinkish hugh to the bottom right - this didn't happen when I 
> > > > tested
> > > > the patches separately
> > > 
> > > It's possible that the recent scheduling changes have caused an unrelated
> > > regression.  Does kwin render correctly if you use the LLVM 3.3 branch?
> > 
> > No time currently to test my rv670 or bisect, but on current heads my rv790
> > is rendering Unigine heaven with various incorrect hues.
> 
> Does a similar regression happens on less complex application ? (ie mesa
> demo)

Demos look OK, and a quick run of openarena and nexuix looked OK.

etqw is showing some transient corruptions.

-- 
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/20130520/8d90aca2/attachment.html>

[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64801

--- Comment #3 from Philip Prindeville  ---
Created attachment 79594
  --> https://bugs.freedesktop.org/attachment.cgi?id=79594=edit
Output from journalctl -a --no-pager

-- 
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/20130520/d9c389f3/attachment.html>

[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64801

Alex Deucher  changed:

   What|Removed |Added

Summary|KMS/R100 -  |KMS/R7xx -
   |[drm:radeon_cs_ioctl]   |[drm:radeon_cs_ioctl]
   |*ERROR* Failed to parse |*ERROR* Failed to parse
   |relocation -12! |relocation -12!

-- 
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/20130520/f6fa09be/attachment.html>

[Bug 64801] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64801

--- Comment #2 from Philip Prindeville  ---
Created attachment 79593
  --> https://bugs.freedesktop.org/attachment.cgi?id=79593=edit
Xorg.2.log from builder

-- 
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/20130520/fe165407/attachment.html>

[Bug 64801] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64801

Philip Prindeville  changed:

   What|Removed |Added

Summary|Seeing repeatable DRM   |KMS/R100 -
   |relocation error messages   |[drm:radeon_cs_ioctl]
   |with RV710 board|*ERROR* Failed to parse
   ||relocation -12!

-- 
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/20130520/1856f80c/attachment.html>

[Bug 64801] Seeing repeatable DRM relocation error messages with RV710 board

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64801

Alex Deucher  changed:

   What|Removed |Added

   Assignee|eich at pdx.freedesktop.org|dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
Version|7.0.0   |DRI CVS
  Component|Driver/radeonhd |DRM/Radeon

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.

-- 
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/20130520/cfbb8a8f/attachment.html>

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32006

--- Comment #16 from Philip Prindeville  ---
(In reply to comment #15)
> Please file a different bug.  The original report was for R1xx asics.  You
> have an R7xx asic.  Also, in the future, please attach files.  The link you
> provided doesn't work.

I tried to attach a screenshot but it was 12MB and the limit is 3MB.

-- 
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/20130520/0ec5c1a1/attachment.html>

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32006

--- Comment #15 from Alex Deucher  ---
Please file a different bug.  The original report was for R1xx asics.  You have
an R7xx asic.  Also, in the future, please attach files.  The link you provided
doesn't work.

-- 
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/20130520/32f88589/attachment.html>

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32006

--- Comment #14 from Philip Prindeville  ---
Here's a screenshot showing RGB 'snow' as the background and random bits of
backing store buffer at the bottom of both screens.

Note that both screens (HDMI-0 on the left and DVI-0 on the right) are on the
Radeon 4350 card.

ftp://ftp.redfish-solutions.com/pub/Screenshot from 2013-05-20 14:42:55.png

-- 
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/20130520/acf0de25/attachment.html>

[RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

[Russell King - ARM Linux]

On Mon, May 20, 2013 at 09:36:02AM -0400, Alex Deucher wrote:
> You can tell the xserver what size cursor you support when you call
> xf86_cursors_init() in the ddx.  Just expose a 32x64 or 64x32 ARGB
> cursor.  Most apps don't use a 64x64 cursor anyway.  I've used
> hardware with non-64x64 cursors and haven't run into any problems yet.

I guess the xf86 backend will fall back to software cursors if it gets
a cursor larger than the hardware supports, so maybe 64x32 will be
fine.

However, my comments concerning the less-than-64x64 size come from
David Airlie who said "X and userside programs expect 64x64 to work.
so its possibly pointless supporting anything less, as in you'd write
code but nobody would end up using it".

Note also that the generic DRM KMS code assumes cursor support at
64x64, and there's no generic way for a driver at present (that I know
of) to inform it of anything different.

[PATCH] drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()

[Lars-Peter Clausen]

free_irq() expects the same pointer that was passed to request_threaded_irq(),
otherwise the IRQ is not freed.

The issue was found using the following coccinelle script:


@r1@
type T;
T devid;
@@
request_threaded_irq(..., devid)

@r2@
type r1.T;
T devid;
position p;
@@
free_irq at p(..., devid)

@@
position p != r2.p;
@@
*free_irq at p(...)


Signed-off-by: Lars-Peter Clausen 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bbfc384..7e99853 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2082,7 +2082,7 @@ static int hdmi_remove(struct platform_device *pdev)

pm_runtime_disable(dev);

-   free_irq(hdata->irq, hdata);
+   free_irq(hdata->irq, ctx);


/* hdmiphy i2c driver */
-- 
1.8.0

[PATCH] drm/nouveau/nv84: Fix HDMI audio regression

[Alexander Stein]

Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
(drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
nv84 by removing too much old code without adding it in the new one.
This patch adds the missing code within the new code layout resulting in
HDMI audio working again.
It should work on any HDMI head, but due to lacking ahrdware I could
only test the (1st) one.
It also might be possible that similar code is needed for nva3, which I
can't test.

Signed-off-by: Alexander Stein 
---
This patch should also be added to stable kernels.

 drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
index 0d36bdc..7fdade6 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
@@ -55,6 +55,10 @@ nv84_hdmi_ctrl(struct nv50_disp_priv *priv, int head, int 
or, u32 data)
nv_wr32(priv, 0x616510 + hoff, 0x);
nv_mask(priv, 0x616500 + hoff, 0x0001, 0x0001);

+   nv_mask(priv, 0x6165d0 + hoff, 0x00070001, 0x00010001); /* SPARE, 
HW_CTS */
+   nv_mask(priv, 0x616568 + hoff, 0x00010101, 0x); /* ACR_CTRL, ?? 
*/
+   nv_mask(priv, 0x616578 + hoff, 0x8000, 0x8000); /* 
ACR_0441_ENABLE */
+
/* ??? */
nv_mask(priv, 0x61733c, 0x0010, 0x0010); /* RESETF */
nv_mask(priv, 0x61733c, 0x1000, 0x1000); /* LOOKUP_EN */
-- 
1.8.2.1

[RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

[Alex Deucher]

On Mon, May 20, 2013 at 4:15 PM, Russell King - ARM Linux
 wrote:
> On Mon, May 20, 2013 at 09:36:02AM -0400, Alex Deucher wrote:
>> You can tell the xserver what size cursor you support when you call
>> xf86_cursors_init() in the ddx.  Just expose a 32x64 or 64x32 ARGB
>> cursor.  Most apps don't use a 64x64 cursor anyway.  I've used
>> hardware with non-64x64 cursors and haven't run into any problems yet.
>
> I guess the xf86 backend will fall back to software cursors if it gets
> a cursor larger than the hardware supports, so maybe 64x32 will be
> fine.
>
> However, my comments concerning the less-than-64x64 size come from
> David Airlie who said "X and userside programs expect 64x64 to work.
> so its possibly pointless supporting anything less, as in you'd write
> code but nobody would end up using it".
>
> Note also that the generic DRM KMS code assumes cursor support at
> 64x64, and there's no generic way for a driver at present (that I know
> of) to inform it of anything different.

It shouldn't be too hard to add a new cap for querying the cursor size
to the drm cap interface.

Alex

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63520

--- Comment #18 from Tom Stellard  ---
Created attachment 79572
  --> https://bugs.freedesktop.org/attachment.cgi?id=79572=edit
Possible Fix

Does this patch fix the bug?  If not can you post the output of
RADEON_DEBUG=fp,vp with this patch applied.

-- 
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/20130520/9c1dc96c/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #14 from vincent  ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > I've now recompiled everything from upstream - kwin now renders however it
> > > has a pinkish hugh to the bottom right - this didn't happen when I tested
> > > the patches separately
> > 
> > It's possible that the recent scheduling changes have caused an unrelated
> > regression.  Does kwin render correctly if you use the LLVM 3.3 branch?
> 
> No time currently to test my rv670 or bisect, but on current heads my rv790
> is rendering Unigine heaven with various incorrect hues.

Does a similar regression happens on less complex application ? (ie mesa demo)

-- 
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/20130520/cc9f4ad4/attachment.html>

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63520

--- Comment #17 from Tom Stellard  ---
Thanks for identifying the bad shaders, this saved me a lot of work.  I spotted
a bug in the "pc=8" shader:

6: TEX temp[1].x, temp[1].z___, 1D[3] SEM_WAIT SEM_ACQUIRE;

This instruction is wrong because TEX instructions can't swizzle their source
operands.  For 1D textures, the coordinate is always read from the x component.

-- 
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/20130520/a0e64dbe/attachment-0001.html>

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #10 from Guram Savinov   2013-05-20 
14:48:17 ---
>>@Guram: what about ACPI? Did you investigate why Linux doesn't export thermal
info from it?

Maybe Asus M50Sa laptop have no hardware ACPI thermal sensors.
If it exist I think Asus include any monitor software tool with laptop CD's.

99% that ATI internal sensor only one way to get GPU themperature.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61747

Jerome Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Jerome Glisse  ---
Closing

-- 
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/20130520/8904f136/attachment.html>

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #5 from mombelli.mauro at gmail.com ---
ok, never heard of this git's feature, really nice and useful!
I'll try to bisect when i'll have some spare time.


2013/5/20 

>   *Comment # 4 <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c4> on bug
> 64776 <https://bugs.freedesktop.org/show_bug.cgi?id=64776> from Alex
> Deucher  *
>
> (In reply to comment #3 
> <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c3>)
> > I have no idea where to start.
> > I know how to compile code and debug program, but i have no clue on the
> > mesa's code structure, and how it works.
> > I don't know what CB6 is, i'm not sure about page meaning (is it similar to
> > "classic" RAM page?) etc..
> > can you tell me at least witch bunch of file/operation i have to debug, and
> > how?
>
>
> CB6 is the 6th color buffer and the GPU has a VM page table just like the CPU.
> That info is not really important for you, I mentioned it for other 
> developers.
>  If you could bisect mesa using git, that would be great.  There are a lot of
> howtos for using git to bisect.  E.g.,https://wiki.ubuntu.com/X/BisectingMesa
>
> In your case, it would be something like:
> git bisect start
> git bisect bad mesa-9.1.2
> git bisect good mesa-9.1.1
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
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/20130520/cab070a1/attachment.html>

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Rafa? Mi?ecki  changed:

   What|Removed |Added

 CC||zajec5 at gmail.com




--- Comment #9 from Rafa? Mi?ecki   2013-05-20 14:05:32 ---
(In reply to comment #8)
> I'd prefer not to.  These sort of options tend to be abused.  Users and
> possibly some distros will start forcing the option on, and then we'll get
> swamped with bug reports about garbage temperatures where the reporter will
> fail to note that they forced the option on.

Sounds sane.

@Guram: what about ACPI? Did you investigate why Linux doesn't export thermal
info from it?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #8 from Alex Deucher   2013-05-20 
13:59:06 ---
I'd prefer not to.  These sort of options tend to be abused.  Users and
possibly some distros will start forcing the option on, and then we'll get
swamped with bug reports about garbage temperatures where the reporter will
fail to note that they forced the option on.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #7 from Guram Savinov   2013-05-20 
13:52:21 ---
Ok, but how about comment#4, is it possible?

By default sensor will be initialized as it implemented now, but it will be
possible to override OEM configuration that disable internal sensor.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #6 from Alex Deucher   2013-05-20 
13:47:01 ---
The OEM designs the thermal solution for the laptop.  If they choose not to use
the internal thermal sensor, there is no guarantee that it's calibrated
correctly for their specific system.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #4 from Alex Deucher  ---
(In reply to comment #3)
> I have no idea where to start.
> I know how to compile code and debug program, but i have no clue on the
> mesa's code structure, and how it works.
> I don't know what CB6 is, i'm not sure about page meaning (is it similar to
> "classic" RAM page?) etc..
> can you tell me at least witch bunch of file/operation i have to debug, and
> how?

CB6 is the 6th color buffer and the GPU has a VM page table just like the CPU. 
That info is not really important for you, I mentioned it for other developers.
 If you could bisect mesa using git, that would be great.  There are a lot of
howtos for using git to bisect.  E.g.,
https://wiki.ubuntu.com/X/BisectingMesa

In your case, it would be something like:
git bisect start
git bisect bad mesa-9.1.2
git bisect good mesa-9.1.1

-- 
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/20130520/4a5cfa68/attachment.html>

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #5 from Guram Savinov   2013-05-20 
13:38:48 ---
>>It might produce garbage results depending on the thermal solution from the
OEM.

OEM? I talk about ATI on-chip thermal sensor, it's not OEM, right?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #4 from Guram Savinov   2013-05-20 
13:32:03 ---
Is it possible to implement force enabling internal sensor configuration by
conf file?
Because OEM's disable thermal sensor info in AtomBIOS we haven't sensor for
GPU.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #3 from mombelli.mauro at gmail.com ---
I have no idea where to start.
I know how to compile code and debug program, but i have no clue on the
mesa's code structure, and how it works.
I don't know what CB6 is, i'm not sure about page meaning (is it similar to
"classic" RAM page?) etc..
can you tell me at least witch bunch of file/operation i have to debug, and
how?


2013/5/20 

>   *Comment # 2 <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c2> on bug
> 64776 <https://bugs.freedesktop.org/show_bug.cgi?id=64776> from Alex
> Deucher  *
>
> What you are seeing is a GPU reset.  CB6 is writing to an invalid mapping at
> GPU page 0x00014EDB.  Can you bisect the mesa 9.1 branch between 9.1.1 and
> 9.1.2 to identify the commit that broke it?
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
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/20130520/fc8a100f/attachment-0001.html>

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #3 from Alex Deucher   2013-05-20 
13:22:00 ---
It might produce garbage results depending on the thermal solution from the
OEM.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #2 from Alex Deucher  ---
What you are seeing is a GPU reset.  CB6 is writing to an invalid mapping at
GPU page 0x00014EDB.  Can you bisect the mesa 9.1 branch between 9.1.1 and
9.1.2 to identify the commit that broke it?

-- 
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/20130520/c19c6318/attachment.html>

[Bug 62967] Game Dungeon Defenders crash my whole system.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62967

--- Comment #3 from Thomas Lindroth  ---
This game is now fully playable for me with the latest git drivers.

-- 
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/20130520/6800ae56/attachment.html>

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #2 from Guram Savinov   2013-05-20 
13:11:13 ---
In this case it will be better to setup internal thermal sensor without
checking AtomBIOS thermal sensor info value, isn't it?

It's no a lot chanses to have acpi sensors support in linux kernel.
I think if we know that chip have internal sensor, we should setup it.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #1 from Alex Deucher   2013-05-20 
13:02:30 ---
A lot of laptop OEMs don't use the internal thermal sensor.  In most cases they
use a platform specific thermal sensor since they often cover multiple
components with the same thermal zone.  It's usually exposed via a platform
specific acpi thermal zone or acpi temperature sensor.  It's not a bios bug;
very few r6xx/r7xx laptops expose the internal thermal sensor.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[RFC] drm: i2c: add irq handler for tda998x slave encoder

[Sebastian Hesselbarth]

On 05/19/2013 10:45 PM, Russell King - ARM Linux wrote:
> On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
>> This adds an irq handler for HPD to the tda998x slave encoder driver
>> to trigger HPD change instead of polling. The gpio connected to int
>> pin of tda998x is passed through platform_data of the i2c client. As
>> HPD will ultimately cause EDID read and that will raise an
>> EDID_READ_DONE interrupt, the irq handling is done threaded with a
>> workqueue to notify drm backend of HPD events.
>>
>> Signed-off-by: Sebastian Hesselbarth
>
> Okay, I think I get this..  Some comments:
>
>> +static irqreturn_t tda998x_irq_thread(int irq, void *data)
>> +{
>> +struct drm_encoder *encoder = data;
>> +struct tda998x_priv *priv;
>> +uint8_t sta, cec, hdmi, lev;
>> +
>> +if (!encoder)
>> +return IRQ_HANDLED;
>
> This won't ever be NULL.  The IRQ layer stores the pointer you passed
> in request_threaded_irq() and that pointer will continue to point at
> that memory until the IRQ is freed.  The only way it could be NULL is
> if you register using a NULL pointer.

Russell,

thanks for the comments. Of course, encoder can't be NULL here and I'll
remove that check.

> ...
>> +if (priv->irq<  0) {
>> +for (i = 100; i>  0; i--) {
>> +uint8_t val = reg_read(encoder, REG_INT_FLAGS_2);
>
> IRQ 0 is the cross-arch "no interrupt" number.  So just use !priv->irq
> here and encourage anyone who uses -1 or NO_IRQ to fix their stuff. :)

Ok, but gpio 0 still is a cross-arch valid gpio? ;)

>> +struct tda998x_priv *priv = to_tda998x_priv(encoder);
>> +
>> +/* announce polling if no irq is available */
>> +if (priv->irq<  0)
>
> Same here.
>
>> @@ -1122,7 +1197,9 @@ tda998x_encoder_init(struct i2c_client *client,
>>
>>  priv->current_page = 0;
>>  priv->cec = i2c_new_dummy(client->adapter, 0x34);
>> +priv->irq = -EINVAL;
>
> And just initialize to zero.  (it's allocated by kzalloc already right?
> So that shouldn't be necessary.)
>
>> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
>> index 41f799f..1838703 100644
>> --- a/include/drm/i2c/tda998x.h
>> +++ b/include/drm/i2c/tda998x.h
>> @@ -20,4 +20,8 @@ struct tda998x_encoder_params {
>>  int swap_f, mirr_f;
>>   };
>>
>> +struct tda998x_platform_data {
>> +int int_gpio;
>> +};
>> +
>
> Should be combined with tda998x_encoder_params - the platform data is
> really supposed to be passed to set_config - see this in drm_encoder_slave.c:
>
>   * If @info->platform_data is non-NULL it will be used as the initial
>   * slave config.
> ...
>  err = encoder_drv->encoder_init(client, dev, encoder);
>  if (err)
>  goto fail_unregister;
>
>  if (info->platform_data)
>  encoder->slave_funcs->set_config(>base,
>   info->platform_data);
>
> So any platform data set will be passed into the set_config function...

Sure, I'll put that into params. Will rebase my v1 PATCH on v3.10-rc1
and that will create tda998x.h.

But actually, this all raises the ultimate "how to deal with DT in drm"
question: Currently, drm i2c slave encoders are registered within drm
API which doesn't work well with DT nodes for those encoders.

DT i2c adapters will register an i2c client and drm will try again in
drm_i2c_encoder_init. Registering the i2c client again will cause it
to fail because the i2c address is busy.

Now, in drm_i2c_encoder_init we have access to the board_info struct
that already offers .of_node which we could exploit here to not
register another i2c client but try to get that already registered
client or fall back to current behavior if NULL. of_node then could
be set by the master encoder from e.g.
"marvell,slave-encoder = <>;".

Or (and that is what I'd prefer) make use of the always empty i2c
slave encoder _probe() as for any other i2c client. And hook up drm
to a probed i2c client. That will also allow for the i2c client
provide functions for other APIs, e.g. alsa.

I am willing to dig into this, but would like to have a general
opinion of David, Rob, and you.

Sebastian

[PATCH 3/3] drm/gma500: Fix mem leak of cursor objects on Cedarview

[Patrik Jakobsson]

All dumb allocated buffers are now automatically pinned so no extra
pinning is needed. Also properly unreference gem objects so they can be
freed up properly. This only affects Cedarview chips.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/cdv_intel_display.c | 39 --
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 3cfd093..a85b9a1 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -1462,7 +1462,7 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
size_t addr = 0;
struct gtt_range *gt;
struct drm_gem_object *obj;
-   int ret;
+   int ret = 0;

/* if we want to turn of the cursor ignore width and height */
if (!handle) {
@@ -1475,15 +1475,7 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
gma_power_end(dev);
}

-   /* unpin the old GEM object */
-   if (psb_intel_crtc->cursor_obj) {
-   gt = container_of(psb_intel_crtc->cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc->cursor_obj);
-   psb_intel_crtc->cursor_obj = NULL;
-   }
-
+   psb_intel_crtc->cursor_obj = NULL;
return 0;
}

@@ -1499,20 +1491,13 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,

if (obj->size < width * height * 4) {
dev_dbg(dev->dev, "buffer is to small\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto unref_cursor;
}

gt = container_of(obj, struct gtt_range, gem);
-
-   /* Pin the memory into the GTT */
-   ret = psb_gtt_pin(gt);
-   if (ret) {
-   dev_err(dev->dev, "Can not pin down handle 0x%x\n", handle);
-   return ret;
-   }
-
+   WARN_ON(gt->in_gart < 1);
addr = gt->offset;  /* Or resource.start ??? */
-
psb_intel_crtc->cursor_addr = addr;

temp = 0;
@@ -1526,15 +1511,11 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
gma_power_end(dev);
}

-   /* unpin the old GEM object */
-   if (psb_intel_crtc->cursor_obj) {
-   gt = container_of(psb_intel_crtc->cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc->cursor_obj);
-   psb_intel_crtc->cursor_obj = obj;
-   }
-   return 0;
+   psb_intel_crtc->cursor_obj = obj;
+
+unref_cursor:
+   drm_gem_object_unreference(psb_intel_crtc->cursor_obj);
+   return ret;
 }

 static int cdv_intel_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
-- 
1.8.1.2

[PATCH 2/3] drm/gma500: Fix mem leak of cursor objects on Poulsbo

[Patrik Jakobsson]

All dumb allocated buffers are now automatically pinned so no extra
pinning is needed. Also properly unreference gem objects so they can be
freed up properly. This only affects Poulsbo chips.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c | 49 --
 1 file changed, 12 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index a768c98..efc4cd6 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -838,7 +838,7 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc *crtc,
struct gtt_range *cursor_gt = psb_intel_crtc->cursor_gt;
struct drm_gem_object *obj;
void *tmp_dst, *tmp_src;
-   int ret, i, cursor_pages;
+   int ret = 0, i, cursor_pages;

/* if we want to turn of the cursor ignore width and height */
if (!handle) {
@@ -851,15 +851,7 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc *crtc,
gma_power_end(dev);
}

-   /* Unpin the old GEM object */
-   if (psb_intel_crtc->cursor_obj) {
-   gt = container_of(psb_intel_crtc->cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc->cursor_obj);
-   psb_intel_crtc->cursor_obj = NULL;
-   }
-
+   psb_intel_crtc->cursor_obj = NULL;
return 0;
}

@@ -875,22 +867,19 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc 
*crtc,

if (obj->size < width * height * 4) {
dev_dbg(dev->dev, "buffer is to small\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto unref_cursor;
}

gt = container_of(obj, struct gtt_range, gem);

-   /* Pin the memory into the GTT */
-   ret = psb_gtt_pin(gt);
-   if (ret) {
-   dev_err(dev->dev, "Can not pin down handle 0x%x\n", handle);
-   return ret;
-   }
+   WARN_ON(gt->in_gart < 1);

if (dev_priv->ops->cursor_needs_phys) {
if (cursor_gt == NULL) {
dev_err(dev->dev, "No hardware cursor mem available");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto unref_cursor;
}

/* Prevent overflow */
@@ -925,15 +914,11 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
gma_power_end(dev);
}

-   /* unpin the old bo */
-   if (psb_intel_crtc->cursor_obj) {
-   gt = container_of(psb_intel_crtc->cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc->cursor_obj);
-   psb_intel_crtc->cursor_obj = obj;
-   }
-   return 0;
+   psb_intel_crtc->cursor_obj = obj;
+
+unref_cursor:
+   drm_gem_object_unreference(psb_intel_crtc->cursor_obj);
+   return ret;
 }

 static int psb_intel_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
@@ -1127,16 +1112,6 @@ struct drm_display_mode *psb_intel_crtc_mode_get(struct 
drm_device *dev,
 static void psb_intel_crtc_destroy(struct drm_crtc *crtc)
 {
struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
-   struct gtt_range *gt;
-
-   /* Unpin the old GEM object */
-   if (psb_intel_crtc->cursor_obj) {
-   gt = container_of(psb_intel_crtc->cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc->cursor_obj);
-   psb_intel_crtc->cursor_obj = NULL;
-   }

if (psb_intel_crtc->cursor_gt != NULL)
psb_gtt_free_range(crtc->dev, psb_intel_crtc->cursor_gt);
-- 
1.8.1.2

[PATCH 1/3] drm/gma500: Rework pin/unpin to prevent memory leak

[Patrik Jakobsson]

We had an unmatching pin/unpin count because psb_intel_pipe_set_base was
pinning the framebuffer before use. This caused psb_gtt_free_range to
leak memory and trigger a warning (see bug reports).

Pinning / Unpinning is now done at dumb buffer alloc / destroy and at
vm fault time if needed by non-dumb non-stolen buffers (no use case yet)

Now whenever we call psb_gtt_free_range() it is assumed that the buffer
is fully unpinned. It is also assumed that a framebuffer used when
setting a pipe base is already pinned.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/gem.c   | 44 ++
 drivers/gpu/drm/gma500/gtt.c   |  5 
 drivers/gpu/drm/gma500/psb_intel_display.c | 17 
 3 files changed, 45 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index eefd6cc..d2d11bd 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -159,9 +159,32 @@ static int psb_gem_create(struct drm_file *file,
 int psb_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
 {
+   struct drm_gem_object *obj = NULL;
+   struct gtt_range *gt;
+   int ret;
+
args->pitch = ALIGN(args->width * ((args->bpp + 7) / 8), 64);
args->size = args->pitch * args->height;
-   return psb_gem_create(file, dev, args->size, >handle);
+   ret = psb_gem_create(file, dev, args->size, >handle);
+
+   /* Pin all dumb allocated buffers since they're all supposed to be used
+  for scanout anyways */
+   if (ret == 0) {
+   obj = drm_gem_object_lookup(dev, file, args->handle);
+   if (obj == NULL)
+   return -ENOENT;
+
+   gt = container_of(obj, struct gtt_range, gem);
+   if (psb_gtt_pin(gt) < 0) {
+   ret = -ENOMEM;
+   goto unref;
+   }
+   }
+
+unref:
+   if (obj)
+   drm_gem_object_unreference(obj);
+   return ret;
 }

 /**
@@ -177,6 +200,17 @@ int psb_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
 int psb_gem_dumb_destroy(struct drm_file *file, struct drm_device *dev,
uint32_t handle)
 {
+   struct drm_gem_object *obj;
+   struct gtt_range *gt;
+
+   obj = drm_gem_object_lookup(dev, file, handle);
+   if (obj == NULL)
+   return -ENOENT;
+
+   gt = container_of(obj, struct gtt_range, gem);
+   psb_gtt_unpin(gt);
+   drm_gem_object_unreference(obj);
+
/* No special work needed, drop the reference and see what falls out */
return drm_gem_handle_delete(file, handle);
 }
@@ -218,16 +252,16 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
   something from beneath our feet */
mutex_lock(>struct_mutex);

-   /* For now the mmap pins the object and it stays pinned. As things
-  stand that will do us no harm */
-   if (r->mmapping == 0) {
+   /* Pin the object if it's not already in gart. Dumb buffers should
+  already be pinned at this point */
+   if (r->in_gart == 0) {
ret = psb_gtt_pin(r);
if (ret < 0) {
dev_err(dev->dev, "gma500: pin failed: %d\n", ret);
goto fail;
}
-   r->mmapping = 1;
}
+   r->mmapping = 1;

/* Page relative to the VMA start - we must calculate this ourselves
   because vmf->pgoff is the fake GEM offset */
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 1f82183..0d62cd7 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -378,11 +378,6 @@ struct gtt_range *psb_gtt_alloc_range(struct drm_device 
*dev, int len,
  */
 void psb_gtt_free_range(struct drm_device *dev, struct gtt_range *gt)
 {
-   /* Undo the mmap pin if we are destroying the object */
-   if (gt->mmapping) {
-   psb_gtt_unpin(gt);
-   gt->mmapping = 0;
-   }
WARN_ON(gt->in_gart && !gt->stolen);
release_resource(>resource);
kfree(gt);
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 6e8f42b..a768c98 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -237,6 +237,7 @@ void psb_intel_wait_for_vblank(struct drm_device *dev)
mdelay(20);
 }

+/* Framebuffer must be pinned before setting it as pipe base */
 static int psb_intel_pipe_set_base(struct drm_crtc *crtc,
int x, int y, struct drm_framebuffer *old_fb)
 {
@@ -256,14 +257,14 @@ static int psb_intel_pipe_set_base(struct drm_crtc *crtc,
   

[PATCH] drm/gma500: Add fb gtt offset to fb base

[Patrik Jakobsson]

Old code assumed framebuffer starts at base of stolen memory. Since the
addition of hardware cursors, this might not be true anymore so add the
gtt offset to the calculation.

Reported-by: Holger Schurig 
Tested-by: Holger Schurig 
CC: Holger Schurig 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/framebuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 1534e22..8b1b6d9 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -121,8 +121,8 @@ static int psbfb_vm_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
unsigned long address;
int ret;
unsigned long pfn;
-   /* FIXME: assumes fb at stolen base which may not be true */
-   unsigned long phys_addr = (unsigned long)dev_priv->stolen_base;
+   unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
+ psbfb->gtt->offset;

page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
address = (unsigned long)vmf->virtual_address - (vmf->pgoff << 
PAGE_SHIFT);
-- 
1.8.1.2

[Bug 64788] Mono Games hang on start

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64788

Laurent carlier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Laurent carlier  ---


*** This bug has been marked as a duplicate of bug 60929 ***

-- 
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/20130520/ec26f49b/attachment.html>

[Bug 60929] [r600-llvm] mono games with opengl are blocking on start

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=60929

Laurent carlier  changed:

   What|Removed |Added

 CC||hadack at gmx.de

--- Comment #2 from Laurent carlier  ---
*** Bug 64788 has been marked as a duplicate of this bug. ***

-- 
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/20130520/a1f3538f/attachment.html>

[pull] radeon drm-fixes-3.10-sun

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

   This is the pull request for AMD Sun/Hainan support.  I've
split it out separately from my regular fixes stream.  Hainan
is a new SI asic with no UVD or DCE hardware.  The patches are
minimally invasive; basically just pci ids and skipping UVD and
DCE init for this family.  Most of the changes to si.c are just
the golden register tables for the family.

The following changes since commit 731da21b7b205efb388481f7a9731c4c1ca3b48c:

  drm/radeon/dce2: use 10khz units for audio dto calculation (2013-05-20 
10:44:58 -0400)

are available in the git repository at:
  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.10-sun

Alex Deucher (9):
  drm/radeon: add chip family for Hainan
  drm/radeon: fill in GPU init for Hainan (v2)
  drm/radeon: don't touch DCE or VGA regs on Hainan (v3)
  drm/radeon: fill in ucode loading support for Hainan
  drm/radeon: radeon-asic updates for Hainan
  drm/radeon: track which asics have UVD
  drm/radeon: sun/hainan chips do not have UVD (v2)
  drm/radeon: add golden register settings for Hainan (v2)
  drm/radeon: add Hainan pci ids

 drivers/gpu/drm/radeon/evergreen.c |   27 ++-
 drivers/gpu/drm/radeon/radeon.h|2 +
 drivers/gpu/drm/radeon/radeon_asic.c   |   22 ++-
 drivers/gpu/drm/radeon/radeon_bios.c   |   28 ++-
 drivers/gpu/drm/radeon/radeon_device.c |1 +
 drivers/gpu/drm/radeon/radeon_family.h |1 +
 drivers/gpu/drm/radeon/si.c|  366 ++--
 drivers/gpu/drm/radeon/sid.h   |1 +
 include/drm/drm_pciids.h   |6 +
 9 files changed, 362 insertions(+), 92 deletions(-)

[Bug 64788] Mono Games hang on start

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64788

--- Comment #1 from hadack at gmx.de ---
Created attachment 79570
  --> https://bugs.freedesktop.org/attachment.cgi?id=79570=edit
dmesg output

-- 
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/20130520/8a1963a8/attachment-0001.html>

[Bug 64788] New: Mono Games hang on start

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64788

  Priority: medium
Bug ID: 64788
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Mono Games hang on start
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: hadack at gmx.de
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 79568
  --> https://bugs.freedesktop.org/attachment.cgi?id=79568=edit
Xorg log

Mono based games just stop after opening a window.

AMD HD7750 Cape Verde
Kernel 3.9 with drm-next-3.10-2
mesa from git
llvm from svn
32bit versions as well

Can be seen in Bastion, Rochard, Kestrel Space Program, or in the linux version
of this free game: http://www.desura.com/games/battlemass

looks just like https://bugs.freedesktop.org/show_bug.cgi?id=60929, but llvm
shared or not doesn't make a difference.

-- 
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/20130520/ba2436e1/attachment.html>

[pull] radeon drm-fixes-3.10

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

   Just some minor bug fixes.

The following changes since commit b7cb1c50c828adaee95e8ada0e55918686245992:

  Merge branch 'drm-nouveau-fixes-3.10' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-05-20 
13:31:36 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.10

Alex Deucher (1):
  drm/radeon/dce2: use 10khz units for audio dto calculation

Niels Ole Salscheider (2):
  drm/radeon: Remove superfluous variable
  drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

 drivers/gpu/drm/radeon/atombios_crtc.c  |6 --
 drivers/gpu/drm/radeon/evergreen.c  |4 ++--
 drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++
 drivers/gpu/drm/radeon/r600_hdmi.c  |9 -
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4 
 drivers/gpu/drm/radeon/radeon_mode.h|1 -
 drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
 drivers/gpu/drm/radeon/si.c |4 ++--
 8 files changed, 12 insertions(+), 25 deletions(-)

[RFC 3/4] DRM: add OF support for Dove DRM driver

[Russell King - ARM Linux]

On Sat, May 18, 2013 at 09:18:46PM +0200, Jean-Francois Moine wrote:
> The general hardware code of both drivers is close enough for merging
> may be done starting from anyone. But the general layout is not:
> 
> - my driver is DT driven and has one card with 2 CTRC's and 2 connectors.
> 
> - Russell's is non-DT, so, with some extra code I am not aware of, with
>   any number of cards each one with one CRTC and one connector (no, I

Utter shit, and I've told you before.  I'm not going to repeat it again,
and I warned you that we would have a falling out.  As you seem to be
immune to my comments provided in a sane manner, I'm now just going to
ignore you in the future because you're clearly not bothering to read
anything I'm telling you.  That makes further discussion with you utterly
pointless.

>   tried it, you cannot clone a connector of one card to the connector
>   of another card).
> 
> So, for me, merging means enhance my code from Russell's, but I will
> not go to a non-DT kernel.

You seem to see DT setups vs non-DT setups as two entirely separate things.
They are not.  We have plenty of drivers which work in both setups just
fine.

So really all of your points above are utter trash to me - really.

As to illustrate the point, my TDA19988 backend is now _just_ a slave
encoder backend, it has nothing TDA19988 specific, nor does it have
anything cubox specific there; the cubox specific part has been moved
up into dove_drv.c as pure data, and that data can be constructed
either from platform data or from OF properties parsed by dove_drv.c.

But why did I just bother to type that.  You're just going to ignore it
and keep repeating your same old claptrap.

[RFC] drm: i2c: add irq handler for tda998x slave encoder

[Rob Clark]

On Mon, May 20, 2013 at 6:53 AM, Sebastian Hesselbarth
 wrote:
> On 05/19/2013 10:45 PM, Russell King - ARM Linux wrote:
>>
>> On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
>>>
>>> This adds an irq handler for HPD to the tda998x slave encoder driver
>>> to trigger HPD change instead of polling. The gpio connected to int
>>> pin of tda998x is passed through platform_data of the i2c client. As
>>> HPD will ultimately cause EDID read and that will raise an
>>> EDID_READ_DONE interrupt, the irq handling is done threaded with a
>>> workqueue to notify drm backend of HPD events.
>>>
>>> Signed-off-by: Sebastian Hesselbarth
>>
>>
>> Okay, I think I get this..  Some comments:
>>
>>> +static irqreturn_t tda998x_irq_thread(int irq, void *data)
>>> +{
>>> +   struct drm_encoder *encoder = data;
>>> +   struct tda998x_priv *priv;
>>> +   uint8_t sta, cec, hdmi, lev;
>>> +
>>> +   if (!encoder)
>>> +   return IRQ_HANDLED;
>>
>>
>> This won't ever be NULL.  The IRQ layer stores the pointer you passed
>> in request_threaded_irq() and that pointer will continue to point at
>> that memory until the IRQ is freed.  The only way it could be NULL is
>> if you register using a NULL pointer.
>
>
> Russell,
>
> thanks for the comments. Of course, encoder can't be NULL here and I'll
> remove that check.
>
>
>> ...
>>>
>>> +   if (priv->irq<  0) {
>>> +   for (i = 100; i>  0; i--) {
>>> +   uint8_t val = reg_read(encoder, REG_INT_FLAGS_2);
>>
>>
>> IRQ 0 is the cross-arch "no interrupt" number.  So just use !priv->irq
>> here and encourage anyone who uses -1 or NO_IRQ to fix their stuff. :)
>
>
> Ok, but gpio 0 still is a cross-arch valid gpio? ;)
>
>
>>> +   struct tda998x_priv *priv = to_tda998x_priv(encoder);
>>> +
>>> +   /* announce polling if no irq is available */
>>> +   if (priv->irq<  0)
>>
>>
>> Same here.
>>
>>> @@ -1122,7 +1197,9 @@ tda998x_encoder_init(struct i2c_client *client,
>>>
>>> priv->current_page = 0;
>>> priv->cec = i2c_new_dummy(client->adapter, 0x34);
>>> +   priv->irq = -EINVAL;
>>
>>
>> And just initialize to zero.  (it's allocated by kzalloc already right?
>> So that shouldn't be necessary.)
>>
>>> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
>>> index 41f799f..1838703 100644
>>> --- a/include/drm/i2c/tda998x.h
>>> +++ b/include/drm/i2c/tda998x.h
>>> @@ -20,4 +20,8 @@ struct tda998x_encoder_params {
>>> int swap_f, mirr_f;
>>>   };
>>>
>>> +struct tda998x_platform_data {
>>> +   int int_gpio;
>>> +};
>>> +
>>
>>
>> Should be combined with tda998x_encoder_params - the platform data is
>> really supposed to be passed to set_config - see this in
>> drm_encoder_slave.c:
>>
>>   * If @info->platform_data is non-NULL it will be used as the initial
>>   * slave config.
>> ...
>>  err = encoder_drv->encoder_init(client, dev, encoder);
>>  if (err)
>>  goto fail_unregister;
>>
>>  if (info->platform_data)
>>  encoder->slave_funcs->set_config(>base,
>>   info->platform_data);
>>
>> So any platform data set will be passed into the set_config function...
>
>
> Sure, I'll put that into params. Will rebase my v1 PATCH on v3.10-rc1
> and that will create tda998x.h.
>
> But actually, this all raises the ultimate "how to deal with DT in drm"
> question: Currently, drm i2c slave encoders are registered within drm
> API which doesn't work well with DT nodes for those encoders.
>
> DT i2c adapters will register an i2c client and drm will try again in
> drm_i2c_encoder_init. Registering the i2c client again will cause it
> to fail because the i2c address is busy.
>
> Now, in drm_i2c_encoder_init we have access to the board_info struct
> that already offers .of_node which we could exploit here to not
> register another i2c client but try to get that already registered
> client or fall back to current behavior if NULL. of_node then could
> be set by the master encoder from e.g.
> "marvell,slave-encoder = <>;".
>
> Or (and that is what I'd prefer) make use of the always empty i2c
> slave encoder _probe() as for any other i2c client. And hook up drm
> to a probed i2c client. That will also allow for the i2c client
> provide functions for other APIs, e.g. alsa.
>
> I am willing to dig into this, but would like to have a general
> opinion of David, Rob, and you.

I thing we probably want to re-visit the current way the i2c encoder
slave stuff works, to make for easier support of other sorts of
encoders, and possibly a starting point for shared panel drivers.
I've kinda been waiting to see how the common display/panel framework
stuff plays out, it's also possible that this would replace the i2c
encoder slave stuff.

BR,
-R

> Sebastian

[PATCH] drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

[Alex Deucher]

On Sat, May 18, 2013 at 3:19 PM, Niels Ole Salscheider
 wrote:
> Add ULL prefix to avoid overflow.
>
> Signed-off-by: Niels Ole Salscheider 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/evergreen.c  | 4 ++--
>  drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
>  drivers/gpu/drm/radeon/si.c | 4 ++--
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 105bafb..06c261b 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3405,8 +3405,8 @@ int evergreen_mc_init(struct radeon_device *rdev)
> rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
> } else {
> /* size in MB on evergreen/cayman/tn */
> -   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
> -   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 
> 1024;
> +   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
> 1024ULL;
> +   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
> 1024ULL;
> }
> rdev->mc.visible_vram_size = rdev->mc.aper_size;
> r700_vram_gtt_location(rdev, >mc);
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 93f760e..6c0ce89 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -726,7 +726,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
> return r;
> }
> DRM_INFO("radeon: %uM of VRAM memory ready\n",
> -(unsigned)rdev->mc.real_vram_size / (1024 * 1024));
> +(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
> r = ttm_bo_init_mm(>mman.bdev, TTM_PL_TT,
> rdev->mc.gtt_size >> PAGE_SHIFT);
> if (r) {
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index f0b6c2f..113ed9f 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -3397,8 +3397,8 @@ static int si_mc_init(struct radeon_device *rdev)
> rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0);
> rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0);
> /* size in MB on si */
> -   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
> -   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
> +   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> +   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> rdev->mc.visible_vram_size = rdev->mc.aper_size;
> si_vram_gtt_location(rdev, >mc);
> radeon_update_bandwidth_info(rdev);
> --
> 1.8.2.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

[Alex Deucher]

On Sun, May 19, 2013 at 4:59 AM, Russell King - ARM Linux
 wrote:
> On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
>> Maybe I did not explain correctly: the colored cursor maybe RGB888 +
>> transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
>> case. And, yes, I better like a hardware cursor: it asks for less
>> computation, and I get it immediately at graphic starting time!
>
> Having looked at this now, using the RGB+transparency is less than ideal
> because we're having to reduce an alpha channel down to a simple on/off
> transparency.  X cursors really are alphablended components!
>
> So, the options here are:
> (a) use "software" rendered cursor
> + correct and expected cursor size
> + correct rendering
> + possible to use the GPU (I believe mine does)
> - maybe time consuming as it has to be removed/replaced on the screen
> (b) use RGB+transparency for 64x64 hardware cursor
> + correct and expected cursor size
> + does not have to be removed/replaced when screen contents change
> - incorrect rendering due to reducing the alpha channel to a simple
>   on/off transparency mask
> - has to be reloaded when the pointer is close to the edges of the
>   screen which is CPU intensive
> - cursor image data passed into DRM is required to be ARGB (I've
>   discussed this with David Airlie last night.)  This means we have
>   to do translation to RGB+T in the kernel which is *not* nice.
> (c) use ARGB 32x64 or 64x32 hardware cursor
> + does not have to be removed/replaced when screen contents change
> + correct rendering of cursor
> - unexpected cursor size; user clients do not expect to be restricted
>   to 32 rows or 32 lines of cursor
> - can only select maximum cursor size on initialization of hardware
>   cursor; can't dynamically switch between 32x64 and 64x32 sizes
> - has to be reloaded when the pointer is close to the edges of the
>   screen which is CPU intensive

You can tell the xserver what size cursor you support when you call
xf86_cursors_init() in the ddx.  Just expose a 32x64 or 64x32 ARGB
cursor.  Most apps don't use a 64x64 cursor anyway.  I've used
hardware with non-64x64 cursors and haven't run into any problems yet.

Alex

BUG: drm_mm head_node gets broken?

[Chris Wilson]

On Sun, May 19, 2013 at 06:22:01PM +0100, Russell King - ARM Linux wrote:
> So, while tinkering with my Dove DRM driver, I tripped over a BUG_ON()
> in drm_mm_hole_node_start(), which was called from drm_mm_dump_table():

It's just a bug in the dumper that I missed when making the helpers more
strict in sanity checking their supposed invariants. Already fixed
upstream.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635 chip

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Guram Savinov  changed:

   What|Removed |Added

Summary|Radeon ATOM BIOS have wrong |Radeon ATOM BIOS have wrong
   |value in controller->ucType |value in controller->ucType
   |for RV635   |for RV635 chip




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 58521] Radeon ATOM BIOS have wrong value in controller->ucType for RV635

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Guram Savinov  changed:

   What|Removed |Added

 CC||guram.savinov at gmail.com
   Platform|All |x86-64




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32006

--- Comment #13 from Philip Prindeville  ---
Oh, and the hardware, if it matters:

02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV710
[Radeon HD 4350] (prog-if 00 [VGA controller])
Subsystem: Hightech Information System Ltd. Device 2008
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at fbdf (64-bit, non-prefetchable) [size=64K]
I/O ports at c000 [size=256]
Expansion ROM at fbdc [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 
Kernel driver in use: radeon

-- 
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/20130520/82a20b29/attachment.html>

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32006

Philip Prindeville  changed:

   What|Removed |Added

 CC||philipp at redfish-solutions.c
   ||om

--- Comment #12 from Philip Prindeville  ---
Is this issue still unresolved?

I'm running Fedora 18, with 3.8.11-200.fc18.x86_64 as the kernel, and:

xorg-x11-drivers-7.4-9.fc18.x86_64
xorg-x11-server-common-1.13.3-3.fc18.x86_64
xorg-x11-server-utils-7.5-16.fc18.x86_64
xorg-x11-server-Xephyr-1.13.3-3.fc18.x86_64
xorg-x11-server-Xorg-1.13.3-3.fc18.x86_64
xorg-x11-server-Xvfb-1.13.3-3.fc18.x86_64
xorg-x11-utils-7.5-7.fc18.x86_64
xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18.x86_64

I'm using an IOGear GCS1764 KVM. Don't know if that makes a difference.

-- 
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/20130520/ed3079a0/attachment.html>

[Bug 58521] New: Radeon ATOM BIOS have wrong value in controller->ucType for RV635

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58521

   Summary: Radeon ATOM BIOS have wrong value in
controller->ucType for RV635
   Product: Drivers
   Version: 2.5
Kernel Version: 3.5.0
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: guram.savinov at gmail.com
Regression: No


I have Asus M50Sa laptop with ATI Radeon Mobility HD3650(RV635 chip) graphics.
RV635 chip have internal thermal sensor, but for my graphics it's no hwmon
entry in /sys/class/hwmon.

I found that in radeon_atombios.c it's checking for thermal sensor from ATOM
BIOS structure:

##
static void radeon_atombios_add_pplib_thermal_controller(struct radeon_device
*rdev,

ATOM_PPLIB_THERMALCONTROLLER *controller)
{
struct radeon_i2c_bus_rec i2c_bus;

/* add the i2c bus for thermal/fan chip */
if (controller->ucType > 0) {
if (controller->ucType == ATOM_PP_THERMALCONTROLLER_RV6xx) {
DRM_INFO("Internal thermal controller %s fan
control\n",
 (controller->ucFanParameters &
  ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
rdev->pm.int_thermal_type = THERMAL_TYPE_RV6XX;
} else if (controller->ucType ==
ATOM_PP_THERMALCONTROLLER_RV770) {

...
###

But for my graphics controller->ucType have 0, that mean 
ATOM_PP_THERMALCONTROLLER_NONE.
I try to set THERMAL_TYPE_RV6XX to controller->ucType, hwmon was added and I
have thermal sensor for my RV635 chip, all works great.

May be it's Asus M50Sa ATOM BIOS bug, but why you check thermal sensor for
RV635?
Is it possible to have RV635 chip without internal thermal sensor?

It'll be great to not check thermal sensor type for RV635 chip, because AMD say
that it shipped with internal thermal sensor.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #1 from mombelli.mauro at gmail.com ---
Created attachment 79558
  --> https://bugs.freedesktop.org/attachment.cgi?id=79558=edit
log of corg.. doesn't seems to catch something

-- 
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/20130520/cb1b1ad1/attachment.html>

[Bug 64776] New: [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

  Priority: medium
Bug ID: 64776
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [9.1.2]"GPU fault detected" whit "eclipse juno" crash
system
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: mombelli.mauro at gmail.com
  Hardware: Other
Status: NEW
   Version: 9.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 79557
  --> https://bugs.freedesktop.org/attachment.cgi?id=79557=edit
dmesg with a nice error log

hi,
after updating to mesa, ati-dri and mesa-libgl 9.1.2, everything work but when
launching "eclipse juno" (even a fresh install) the monitor turn off, sometimes
the system doesn't respond, sometimes the montor keep turning on and off, GUI
in freezed but i can still use virtual consolle. No problem with steam, bzflag,
flash, older version of eclipse or other java program. Also GPU extensive test
have been done on windows system with no fault.

Work-around is falling back to 9.1.1

my board:

$ lspci | grep -i VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Pitcairn PRO [Radeon HD 7850]

here you will find attached dmesg and xorg log during one of the (rare) times
when monitor was going on and off. Xorg seems to stop just before the system
goes in this "loop state"
anyway dmesg seems to catch the problem

-- 
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/20130520/157e95ef/attachment-0001.html>

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32006

Philip Prindeville phil...@redfish-solutions.com changed:

   What|Removed |Added

 CC||philipp@redfish-solutions.c
   ||om

--- Comment #12 from Philip Prindeville phil...@redfish-solutions.com ---
Is this issue still unresolved?

I'm running Fedora 18, with 3.8.11-200.fc18.x86_64 as the kernel, and:

xorg-x11-drivers-7.4-9.fc18.x86_64
xorg-x11-server-common-1.13.3-3.fc18.x86_64
xorg-x11-server-utils-7.5-16.fc18.x86_64
xorg-x11-server-Xephyr-1.13.3-3.fc18.x86_64
xorg-x11-server-Xorg-1.13.3-3.fc18.x86_64
xorg-x11-server-Xvfb-1.13.3-3.fc18.x86_64
xorg-x11-utils-7.5-7.fc18.x86_64
xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18.x86_64

I'm using an IOGear GCS1764 KVM. Don't know if that makes a difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32006

--- Comment #13 from Philip Prindeville phil...@redfish-solutions.com ---
Oh, and the hardware, if it matters:

02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV710
[Radeon HD 4350] (prog-if 00 [VGA controller])
Subsystem: Hightech Information System Ltd. Device 2008
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at fbdf (64-bit, non-prefetchable) [size=64K]
I/O ports at c000 [size=256]
Expansion ROM at fbdc [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ?
Kernel driver in use: radeon

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Guram Savinov guram.savi...@gmail.com changed:

   What|Removed |Added

 CC||guram.savi...@gmail.com
   Platform|All |x86-64




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Guram Savinov guram.savi...@gmail.com changed:

   What|Removed |Added

Summary|Radeon ATOM BIOS have wrong |Radeon ATOM BIOS have wrong
   |value in controller-ucType |value in controller-ucType
   |for RV635   |for RV635 chip




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: BUG: drm_mm head_node gets broken?

[Chris Wilson]

On Sun, May 19, 2013 at 06:22:01PM +0100, Russell King - ARM Linux wrote:
 So, while tinkering with my Dove DRM driver, I tripped over a BUG_ON()
 in drm_mm_hole_node_start(), which was called from drm_mm_dump_table():

It's just a bug in the dumper that I missed when making the helpers more
strict in sanity checking their supposed invariants. Already fixed
upstream.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/gma500: Add fb gtt offset to fb base

[Patrik Jakobsson]

Old code assumed framebuffer starts at base of stolen memory. Since the
addition of hardware cursors, this might not be true anymore so add the
gtt offset to the calculation.

Reported-by: Holger Schurig holgerschu...@gmail.com
Tested-by: Holger Schurig holgerschu...@gmail.com
CC: Holger Schurig holgerschu...@gmail.com
Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
---
 drivers/gpu/drm/gma500/framebuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 1534e22..8b1b6d9 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -121,8 +121,8 @@ static int psbfb_vm_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
unsigned long address;
int ret;
unsigned long pfn;
-   /* FIXME: assumes fb at stolen base which may not be true */
-   unsigned long phys_addr = (unsigned long)dev_priv-stolen_base;
+   unsigned long phys_addr = (unsigned long)dev_priv-stolen_base +
+ psbfb-gtt-offset;
 
page_num = (vma-vm_end - vma-vm_start)  PAGE_SHIFT;
address = (unsigned long)vmf-virtual_address - (vmf-pgoff  
PAGE_SHIFT);
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/gma500: Rework pin/unpin to prevent memory leak

[Patrik Jakobsson]

We had an unmatching pin/unpin count because psb_intel_pipe_set_base was
pinning the framebuffer before use. This caused psb_gtt_free_range to
leak memory and trigger a warning (see bug reports).

Pinning / Unpinning is now done at dumb buffer alloc / destroy and at
vm fault time if needed by non-dumb non-stolen buffers (no use case yet)

Now whenever we call psb_gtt_free_range() it is assumed that the buffer
is fully unpinned. It is also assumed that a framebuffer used when
setting a pipe base is already pinned.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
---
 drivers/gpu/drm/gma500/gem.c   | 44 ++
 drivers/gpu/drm/gma500/gtt.c   |  5 
 drivers/gpu/drm/gma500/psb_intel_display.c | 17 
 3 files changed, 45 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index eefd6cc..d2d11bd 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -159,9 +159,32 @@ static int psb_gem_create(struct drm_file *file,
 int psb_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
 {
+   struct drm_gem_object *obj = NULL;
+   struct gtt_range *gt;
+   int ret;
+
args-pitch = ALIGN(args-width * ((args-bpp + 7) / 8), 64);
args-size = args-pitch * args-height;
-   return psb_gem_create(file, dev, args-size, args-handle);
+   ret = psb_gem_create(file, dev, args-size, args-handle);
+
+   /* Pin all dumb allocated buffers since they're all supposed to be used
+  for scanout anyways */
+   if (ret == 0) {
+   obj = drm_gem_object_lookup(dev, file, args-handle);
+   if (obj == NULL)
+   return -ENOENT;
+
+   gt = container_of(obj, struct gtt_range, gem);
+   if (psb_gtt_pin(gt)  0) {
+   ret = -ENOMEM;
+   goto unref;
+   }
+   }
+
+unref:
+   if (obj)
+   drm_gem_object_unreference(obj);
+   return ret;
 }
 
 /**
@@ -177,6 +200,17 @@ int psb_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
 int psb_gem_dumb_destroy(struct drm_file *file, struct drm_device *dev,
uint32_t handle)
 {
+   struct drm_gem_object *obj;
+   struct gtt_range *gt;
+
+   obj = drm_gem_object_lookup(dev, file, handle);
+   if (obj == NULL)
+   return -ENOENT;
+
+   gt = container_of(obj, struct gtt_range, gem);
+   psb_gtt_unpin(gt);
+   drm_gem_object_unreference(obj);
+
/* No special work needed, drop the reference and see what falls out */
return drm_gem_handle_delete(file, handle);
 }
@@ -218,16 +252,16 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
   something from beneath our feet */
mutex_lock(dev-struct_mutex);
 
-   /* For now the mmap pins the object and it stays pinned. As things
-  stand that will do us no harm */
-   if (r-mmapping == 0) {
+   /* Pin the object if it's not already in gart. Dumb buffers should
+  already be pinned at this point */
+   if (r-in_gart == 0) {
ret = psb_gtt_pin(r);
if (ret  0) {
dev_err(dev-dev, gma500: pin failed: %d\n, ret);
goto fail;
}
-   r-mmapping = 1;
}
+   r-mmapping = 1;
 
/* Page relative to the VMA start - we must calculate this ourselves
   because vmf-pgoff is the fake GEM offset */
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 1f82183..0d62cd7 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -378,11 +378,6 @@ struct gtt_range *psb_gtt_alloc_range(struct drm_device 
*dev, int len,
  */
 void psb_gtt_free_range(struct drm_device *dev, struct gtt_range *gt)
 {
-   /* Undo the mmap pin if we are destroying the object */
-   if (gt-mmapping) {
-   psb_gtt_unpin(gt);
-   gt-mmapping = 0;
-   }
WARN_ON(gt-in_gart  !gt-stolen);
release_resource(gt-resource);
kfree(gt);
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 6e8f42b..a768c98 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -237,6 +237,7 @@ void psb_intel_wait_for_vblank(struct drm_device *dev)
mdelay(20);
 }
 
+/* Framebuffer must be pinned before setting it as pipe base */
 static int psb_intel_pipe_set_base(struct drm_crtc *crtc,
int x, int y, struct drm_framebuffer *old_fb)
 {
@@ -256,14 +257,14 @@ static int 

[PATCH 2/3] drm/gma500: Fix mem leak of cursor objects on Poulsbo

[Patrik Jakobsson]

All dumb allocated buffers are now automatically pinned so no extra
pinning is needed. Also properly unreference gem objects so they can be
freed up properly. This only affects Poulsbo chips.

Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
---
 drivers/gpu/drm/gma500/psb_intel_display.c | 49 --
 1 file changed, 12 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index a768c98..efc4cd6 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -838,7 +838,7 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc *crtc,
struct gtt_range *cursor_gt = psb_intel_crtc-cursor_gt;
struct drm_gem_object *obj;
void *tmp_dst, *tmp_src;
-   int ret, i, cursor_pages;
+   int ret = 0, i, cursor_pages;
 
/* if we want to turn of the cursor ignore width and height */
if (!handle) {
@@ -851,15 +851,7 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc *crtc,
gma_power_end(dev);
}
 
-   /* Unpin the old GEM object */
-   if (psb_intel_crtc-cursor_obj) {
-   gt = container_of(psb_intel_crtc-cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc-cursor_obj);
-   psb_intel_crtc-cursor_obj = NULL;
-   }
-
+   psb_intel_crtc-cursor_obj = NULL;
return 0;
}
 
@@ -875,22 +867,19 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
 
if (obj-size  width * height * 4) {
dev_dbg(dev-dev, buffer is to small\n);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto unref_cursor;
}
 
gt = container_of(obj, struct gtt_range, gem);
 
-   /* Pin the memory into the GTT */
-   ret = psb_gtt_pin(gt);
-   if (ret) {
-   dev_err(dev-dev, Can not pin down handle 0x%x\n, handle);
-   return ret;
-   }
+   WARN_ON(gt-in_gart  1);
 
if (dev_priv-ops-cursor_needs_phys) {
if (cursor_gt == NULL) {
dev_err(dev-dev, No hardware cursor mem available);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto unref_cursor;
}
 
/* Prevent overflow */
@@ -925,15 +914,11 @@ static int psb_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
gma_power_end(dev);
}
 
-   /* unpin the old bo */
-   if (psb_intel_crtc-cursor_obj) {
-   gt = container_of(psb_intel_crtc-cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc-cursor_obj);
-   psb_intel_crtc-cursor_obj = obj;
-   }
-   return 0;
+   psb_intel_crtc-cursor_obj = obj;
+
+unref_cursor:
+   drm_gem_object_unreference(psb_intel_crtc-cursor_obj);
+   return ret;
 }
 
 static int psb_intel_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
@@ -1127,16 +1112,6 @@ struct drm_display_mode *psb_intel_crtc_mode_get(struct 
drm_device *dev,
 static void psb_intel_crtc_destroy(struct drm_crtc *crtc)
 {
struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
-   struct gtt_range *gt;
-
-   /* Unpin the old GEM object */
-   if (psb_intel_crtc-cursor_obj) {
-   gt = container_of(psb_intel_crtc-cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc-cursor_obj);
-   psb_intel_crtc-cursor_obj = NULL;
-   }
 
if (psb_intel_crtc-cursor_gt != NULL)
psb_gtt_free_range(crtc-dev, psb_intel_crtc-cursor_gt);
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/gma500: Fix mem leak of cursor objects on Cedarview

[Patrik Jakobsson]

All dumb allocated buffers are now automatically pinned so no extra
pinning is needed. Also properly unreference gem objects so they can be
freed up properly. This only affects Cedarview chips.

Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
---
 drivers/gpu/drm/gma500/cdv_intel_display.c | 39 --
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 3cfd093..a85b9a1 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -1462,7 +1462,7 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
size_t addr = 0;
struct gtt_range *gt;
struct drm_gem_object *obj;
-   int ret;
+   int ret = 0;
 
/* if we want to turn of the cursor ignore width and height */
if (!handle) {
@@ -1475,15 +1475,7 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
gma_power_end(dev);
}
 
-   /* unpin the old GEM object */
-   if (psb_intel_crtc-cursor_obj) {
-   gt = container_of(psb_intel_crtc-cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc-cursor_obj);
-   psb_intel_crtc-cursor_obj = NULL;
-   }
-
+   psb_intel_crtc-cursor_obj = NULL;
return 0;
}
 
@@ -1499,20 +1491,13 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
 
if (obj-size  width * height * 4) {
dev_dbg(dev-dev, buffer is to small\n);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto unref_cursor;
}
 
gt = container_of(obj, struct gtt_range, gem);
-
-   /* Pin the memory into the GTT */
-   ret = psb_gtt_pin(gt);
-   if (ret) {
-   dev_err(dev-dev, Can not pin down handle 0x%x\n, handle);
-   return ret;
-   }
-
+   WARN_ON(gt-in_gart  1);
addr = gt-offset;  /* Or resource.start ??? */
-
psb_intel_crtc-cursor_addr = addr;
 
temp = 0;
@@ -1526,15 +1511,11 @@ static int cdv_intel_crtc_cursor_set(struct drm_crtc 
*crtc,
gma_power_end(dev);
}
 
-   /* unpin the old GEM object */
-   if (psb_intel_crtc-cursor_obj) {
-   gt = container_of(psb_intel_crtc-cursor_obj,
-   struct gtt_range, gem);
-   psb_gtt_unpin(gt);
-   drm_gem_object_unreference(psb_intel_crtc-cursor_obj);
-   psb_intel_crtc-cursor_obj = obj;
-   }
-   return 0;
+   psb_intel_crtc-cursor_obj = obj;
+
+unref_cursor:
+   drm_gem_object_unreference(psb_intel_crtc-cursor_obj);
+   return ret;
 }
 
 static int cdv_intel_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64788] New: Mono Games hang on start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64788

  Priority: medium
Bug ID: 64788
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Mono Games hang on start
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: had...@gmx.de
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 79568
  -- https://bugs.freedesktop.org/attachment.cgi?id=79568action=edit
Xorg log

Mono based games just stop after opening a window.

AMD HD7750 Cape Verde
Kernel 3.9 with drm-next-3.10-2
mesa from git
llvm from svn
32bit versions as well

Can be seen in Bastion, Rochard, Kestrel Space Program, or in the linux version
of this free game: http://www.desura.com/games/battlemass

looks just like https://bugs.freedesktop.org/show_bug.cgi?id=60929, but llvm
shared or not doesn't make a difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 4/4] DRM: tda998x: add missing include

[Jean-Francois Moine]

On Sun, 19 May 2013 10:30:00 +0200
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote:
  /* --- test (not cubox)  *
  dcon { status = okay; };
  
  lcd1 {
  status = okay;
  clocks =core_clk 3,0,lcdclk,0;
  marvell,port-type =1;
  display-timings {
  mode {
  hactive =1920;
  vactive =1080;
  hfront-porch =88;
  hsync-len =44;
  hback-porch =148;
  vfront-porch =4;
  vsync-len =5;
  vback-porch =36;
  clock =148500;
  };
  };  
 
 I would be surprised if, lcd1 will ever be capable of driving
 1080p60 on a *VGA port*!

As you may see, this sequence is preceded by an open comment: test.

Now, as the port B of the display controller is only VGA (this is
checked in my driver), as there is no VGA connector on the Cubox, as
there is no VGA DAC code in my driver, and as I had to test the display
controller, I:

- defined the port B as VGA,

- set the timings of the mode I use for my HDMI display.

This does not mean the example must be used in the real word. It is
just a working example for test purpose.

 Seriously, start _reading_ what we say. I want all those
 features I already told you for your driver, in mainline driver
 too. All I told you was to prevent you from doing dirty little
 Cubox specific hacks that I would have to remove for e.g. D2Plug.

There is _NO_ Cubox specific stuff in my driver (I don't even use any
cubox-setup as Russell) and it should work without any change (except
the DT) in your D2plug. Remember, all my drm driver work is in
http://moinejf.free.fr/cubox/ as a big kernel patch (I will add the
I2C: mv64xxx which work fine - thanks Russell).

 *But* if you ask me if we should take Russell's or your driver
 as a basis, the answer is Russell's. Colon.

OK. Do what you want. My driver works fine enough for my usage:
software development. For video, my ISP gives us for free a Atom based
multimedia player with a Blue-Ray reader, and I have a AMD64 double
core on my family TV set for internet video (it will be a long time
till there will be VP8 decoding with vMeta). The only interest I see
in the Cubox is its low power consumption.

Now, I will switch back to my favorite long-distance development...

See you.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

BUG: drm_mm head_node gets broken?

[Russell King - ARM Linux]

So, while tinkering with my Dove DRM driver, I tripped over a BUG_ON()
in drm_mm_hole_node_start(), which was called from drm_mm_dump_table():

int drm_mm_dump_table(struct seq_file *m, struct drm_mm *mm)
{
struct drm_mm_node *entry;
unsigned long total_used = 0, total_free = 0, total = 0;
unsigned long hole_start, hole_end, hole_size;

hole_start = drm_mm_hole_node_start(mm-head_node);
hole_end = drm_mm_hole_node_end(mm-head_node);

drm_mm_hole_node_start() does this:

static inline unsigned long drm_mm_hole_node_start(struct drm_mm_node 
*hole_node)
{
BUG_ON(!hole_node-hole_follows);
return __drm_mm_hole_node_start(hole_node);
}

This appears to indicate that it is required that the head node should
always have a hole following it.

As this used to work, I dug in the git history, and found commit 6b9d89b4
(drm: Add colouring to the range allocator), in particular this change:

 static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
 struct drm_mm_node *node,
-unsigned long size, unsigned alignment)
+unsigned long size, unsigned alignment,
+unsigned long color)
 {
...
-   if (!tmp) {
+   if (alignment) {
+   unsigned tmp = adj_start % alignment;
+   if (tmp)
+   adj_start += alignment - tmp;
+   }
+
+   if (adj_start == hole_start) {
hole_node-hole_follows = 0;
-   list_del_init(hole_node-hole_stack);
-   } else
-   wasted = alignment - tmp;
+   list_del(hole_node-hole_stack);
+   }


Now, when we do an allocation, it is typically done as follows:

free = drm_mm_search_free(mm, size, align, 0);
if (free)
linear = drm_mm_get_block(free, size, align);

If nothing has been allocated in the mm, 'free' will be mm-head_node.
The result is that drm_mm_get_block calls down into drm_mm_insert_helper
with hole_node == mm-head_node.  This I confirmed via:

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index db1e2d6..7241be8 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -125,6 +125,7 @@ static void drm_mm_insert_helper(struct drm_mm_node 
*hole_node,
}
 
if (adj_start == hole_start) {
+   BUG_ON(hole_node == mm-head_node);
hole_node-hole_follows = 0;
list_del(hole_node-hole_stack);
}

which triggers during booting.  Hence, we end up setting the head_node
to indicate no hole following - which violates the conditions of other
parts of the code in drm_mm.c.

It looks like this change was made quite a while ago - back in July
2012, so I assume that while the rest of the allocator is fine with this,
it's just the debugging code which is now broken.  However, I suspect
that DRM people may wish to either back out the coloring change or
carefully review the change for correctness throughout the drm_mm
code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: i2c: add irq handler for tda998x slave encoder

[Russell King - ARM Linux]

On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
 This adds an irq handler for HPD to the tda998x slave encoder driver
 to trigger HPD change instead of polling. The gpio connected to int
 pin of tda998x is passed through platform_data of the i2c client. As
 HPD will ultimately cause EDID read and that will raise an
 EDID_READ_DONE interrupt, the irq handling is done threaded with a
 workqueue to notify drm backend of HPD events.
 
 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

Okay, I think I get this..  Some comments:

 +static irqreturn_t tda998x_irq_thread(int irq, void *data)
 +{
 + struct drm_encoder *encoder = data;
 + struct tda998x_priv *priv;
 + uint8_t sta, cec, hdmi, lev;
 +
 + if (!encoder)
 + return IRQ_HANDLED;

This won't ever be NULL.  The IRQ layer stores the pointer you passed
in request_threaded_irq() and that pointer will continue to point at
that memory until the IRQ is freed.  The only way it could be NULL is
if you register using a NULL pointer.

...
 + if (priv-irq  0) {
 + for (i = 100; i  0; i--) {
 + uint8_t val = reg_read(encoder, REG_INT_FLAGS_2);

IRQ 0 is the cross-arch no interrupt number.  So just use !priv-irq
here and encourage anyone who uses -1 or NO_IRQ to fix their stuff. :)

 + struct tda998x_priv *priv = to_tda998x_priv(encoder);
 +
 + /* announce polling if no irq is available */
 + if (priv-irq  0)

Same here.

 @@ -1122,7 +1197,9 @@ tda998x_encoder_init(struct i2c_client *client,
  
   priv-current_page = 0;
   priv-cec = i2c_new_dummy(client-adapter, 0x34);
 + priv-irq = -EINVAL;

And just initialize to zero.  (it's allocated by kzalloc already right?
So that shouldn't be necessary.)

 diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
 index 41f799f..1838703 100644
 --- a/include/drm/i2c/tda998x.h
 +++ b/include/drm/i2c/tda998x.h
 @@ -20,4 +20,8 @@ struct tda998x_encoder_params {
   int swap_f, mirr_f;
  };
  
 +struct tda998x_platform_data {
 + int int_gpio;
 +};
 +

Should be combined with tda998x_encoder_params - the platform data is
really supposed to be passed to set_config - see this in drm_encoder_slave.c:

 * If @info-platform_data is non-NULL it will be used as the initial
 * slave config.
...
err = encoder_drv-encoder_init(client, dev, encoder);
if (err)
goto fail_unregister;

if (info-platform_data)
encoder-slave_funcs-set_config(encoder-base,
 info-platform_data);

So any platform data set will be passed into the set_config function...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/4] DRM: add OF support for Dove DRM driver

[Russell King - ARM Linux]

On Sat, May 18, 2013 at 09:18:46PM +0200, Jean-Francois Moine wrote:
 The general hardware code of both drivers is close enough for merging
 may be done starting from anyone. But the general layout is not:
 
 - my driver is DT driven and has one card with 2 CTRC's and 2 connectors.
 
 - Russell's is non-DT, so, with some extra code I am not aware of, with
   any number of cards each one with one CRTC and one connector (no, I

Utter shit, and I've told you before.  I'm not going to repeat it again,
and I warned you that we would have a falling out.  As you seem to be
immune to my comments provided in a sane manner, I'm now just going to
ignore you in the future because you're clearly not bothering to read
anything I'm telling you.  That makes further discussion with you utterly
pointless.

   tried it, you cannot clone a connector of one card to the connector
   of another card).
 
 So, for me, merging means enhance my code from Russell's, but I will
 not go to a non-DT kernel.

You seem to see DT setups vs non-DT setups as two entirely separate things.
They are not.  We have plenty of drivers which work in both setups just
fine.

So really all of your points above are utter trash to me - really.

As to illustrate the point, my TDA19988 backend is now _just_ a slave
encoder backend, it has nothing TDA19988 specific, nor does it have
anything cubox specific there; the cubox specific part has been moved
up into dove_drv.c as pure data, and that data can be constructed
either from platform data or from OF properties parsed by dove_drv.c.

But why did I just bother to type that.  You're just going to ignore it
and keep repeating your same old claptrap.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: i2c: add irq handler for tda998x slave encoder

[Sebastian Hesselbarth]

On 05/19/2013 10:45 PM, Russell King - ARM Linux wrote:

On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:

This adds an irq handler for HPD to the tda998x slave encoder driver
to trigger HPD change instead of polling. The gpio connected to int
pin of tda998x is passed through platform_data of the i2c client. As
HPD will ultimately cause EDID read and that will raise an
EDID_READ_DONE interrupt, the irq handling is done threaded with a
workqueue to notify drm backend of HPD events.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com


Okay, I think I get this..  Some comments:


+static irqreturn_t tda998x_irq_thread(int irq, void *data)
+{
+   struct drm_encoder *encoder = data;
+   struct tda998x_priv *priv;
+   uint8_t sta, cec, hdmi, lev;
+
+   if (!encoder)
+   return IRQ_HANDLED;


This won't ever be NULL.  The IRQ layer stores the pointer you passed
in request_threaded_irq() and that pointer will continue to point at
that memory until the IRQ is freed.  The only way it could be NULL is
if you register using a NULL pointer.


Russell,

thanks for the comments. Of course, encoder can't be NULL here and I'll
remove that check.


...

+   if (priv-irq  0) {
+   for (i = 100; i  0; i--) {
+   uint8_t val = reg_read(encoder, REG_INT_FLAGS_2);


IRQ 0 is the cross-arch no interrupt number.  So just use !priv-irq
here and encourage anyone who uses -1 or NO_IRQ to fix their stuff. :)


Ok, but gpio 0 still is a cross-arch valid gpio? ;)


+   struct tda998x_priv *priv = to_tda998x_priv(encoder);
+
+   /* announce polling if no irq is available */
+   if (priv-irq  0)


Same here.


@@ -1122,7 +1197,9 @@ tda998x_encoder_init(struct i2c_client *client,

priv-current_page = 0;
priv-cec = i2c_new_dummy(client-adapter, 0x34);
+   priv-irq = -EINVAL;


And just initialize to zero.  (it's allocated by kzalloc already right?
So that shouldn't be necessary.)


diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
index 41f799f..1838703 100644
--- a/include/drm/i2c/tda998x.h
+++ b/include/drm/i2c/tda998x.h
@@ -20,4 +20,8 @@ struct tda998x_encoder_params {
int swap_f, mirr_f;
  };

+struct tda998x_platform_data {
+   int int_gpio;
+};
+


Should be combined with tda998x_encoder_params - the platform data is
really supposed to be passed to set_config - see this in drm_encoder_slave.c:

  * If @info-platform_data is non-NULL it will be used as the initial
  * slave config.
...
 err = encoder_drv-encoder_init(client, dev, encoder);
 if (err)
 goto fail_unregister;

 if (info-platform_data)
 encoder-slave_funcs-set_config(encoder-base,
  info-platform_data);

So any platform data set will be passed into the set_config function...


Sure, I'll put that into params. Will rebase my v1 PATCH on v3.10-rc1
and that will create tda998x.h.

But actually, this all raises the ultimate how to deal with DT in drm
question: Currently, drm i2c slave encoders are registered within drm
API which doesn't work well with DT nodes for those encoders.

DT i2c adapters will register an i2c client and drm will try again in
drm_i2c_encoder_init. Registering the i2c client again will cause it
to fail because the i2c address is busy.

Now, in drm_i2c_encoder_init we have access to the board_info struct
that already offers .of_node which we could exploit here to not
register another i2c client but try to get that already registered
client or fall back to current behavior if NULL. of_node then could
be set by the master encoder from e.g.
marvell,slave-encoder = tda998x;.

Or (and that is what I'd prefer) make use of the always empty i2c
slave encoder _probe() as for any other i2c client. And hook up drm
to a probed i2c client. That will also allow for the i2c client
provide functions for other APIs, e.g. alsa.

I am willing to dig into this, but would like to have a general
opinion of David, Rob, and you.

Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64788] Mono Games hang on start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64788

--- Comment #1 from had...@gmx.de ---
Created attachment 79570
  -- https://bugs.freedesktop.org/attachment.cgi?id=79570action=edit
dmesg output

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64788] Mono Games hang on start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64788

Laurent carlier lordhea...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Laurent carlier lordhea...@gmail.com ---


*** This bug has been marked as a duplicate of bug 60929 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60929] [r600-llvm] mono games with opengl are blocking on start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=60929

Laurent carlier lordhea...@gmail.com changed:

   What|Removed |Added

 CC||had...@gmx.de

--- Comment #2 from Laurent carlier lordhea...@gmail.com ---
*** Bug 64788 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Alex Deucher alexdeuc...@gmail.com changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #1 from Alex Deucher alexdeuc...@gmail.com  2013-05-20 13:02:30 
---
A lot of laptop OEMs don't use the internal thermal sensor.  In most cases they
use a platform specific thermal sensor since they often cover multiple
components with the same thermal zone.  It's usually exposed via a platform
specific acpi thermal zone or acpi temperature sensor.  It's not a bios bug;
very few r6xx/r7xx laptops expose the internal thermal sensor.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #2 from Guram Savinov guram.savi...@gmail.com  2013-05-20 
13:11:13 ---
In this case it will be better to setup internal thermal sensor without
checking AtomBIOS thermal sensor info value, isn't it?

It's no a lot chanses to have acpi sensors support in linux kernel.
I think if we know that chip have internal sensor, we should setup it.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62967] Game Dungeon Defenders crash my whole system.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62967

--- Comment #3 from Thomas Lindroth thomas.lindr...@gmail.com ---
This game is now fully playable for me with the latest git drivers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64776] [9.1.2]GPU fault detected whit eclipse juno crash system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #2 from Alex Deucher ag...@yahoo.com ---
What you are seeing is a GPU reset.  CB6 is writing to an invalid mapping at
GPU page 0x00014EDB.  Can you bisect the mesa 9.1 branch between 9.1.1 and
9.1.2 to identify the commit that broke it?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #3 from Alex Deucher alexdeuc...@gmail.com  2013-05-20 13:22:00 
---
It might produce garbage results depending on the thermal solution from the
OEM.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64776] [9.1.2]GPU fault detected whit eclipse juno crash system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #3 from mombelli.ma...@gmail.com ---
I have no idea where to start.
I know how to compile code and debug program, but i have no clue on the
mesa's code structure, and how it works.
I don't know what CB6 is, i'm not sure about page meaning (is it similar to
classic RAM page?) etc..
can you tell me at least witch bunch of file/operation i have to debug, and
how?


2013/5/20 bugzilla-dae...@freedesktop.org

   *Comment # 2 https://bugs.freedesktop.org/show_bug.cgi?id=64776#c2 on bug
 64776 https://bugs.freedesktop.org/show_bug.cgi?id=64776 from Alex
 Deucher ag...@yahoo.com *

 What you are seeing is a GPU reset.  CB6 is writing to an invalid mapping at
 GPU page 0x00014EDB.  Can you bisect the mesa 9.1 branch between 9.1.1 and
 9.1.2 to identify the commit that broke it?

  --
 You are receiving this mail because:

- You reported the bug.



-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #4 from Guram Savinov guram.savi...@gmail.com  2013-05-20 
13:32:03 ---
Is it possible to implement force enabling internal sensor configuration by
conf file?
Because OEM's disable thermal sensor info in AtomBIOS we haven't sensor for
GPU.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

[Alex Deucher]

On Sun, May 19, 2013 at 4:59 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
 Maybe I did not explain correctly: the colored cursor maybe RGB888 +
 transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
 case. And, yes, I better like a hardware cursor: it asks for less
 computation, and I get it immediately at graphic starting time!

 Having looked at this now, using the RGB+transparency is less than ideal
 because we're having to reduce an alpha channel down to a simple on/off
 transparency.  X cursors really are alphablended components!

 So, the options here are:
 (a) use software rendered cursor
 + correct and expected cursor size
 + correct rendering
 + possible to use the GPU (I believe mine does)
 - maybe time consuming as it has to be removed/replaced on the screen
 (b) use RGB+transparency for 64x64 hardware cursor
 + correct and expected cursor size
 + does not have to be removed/replaced when screen contents change
 - incorrect rendering due to reducing the alpha channel to a simple
   on/off transparency mask
 - has to be reloaded when the pointer is close to the edges of the
   screen which is CPU intensive
 - cursor image data passed into DRM is required to be ARGB (I've
   discussed this with David Airlie last night.)  This means we have
   to do translation to RGB+T in the kernel which is *not* nice.
 (c) use ARGB 32x64 or 64x32 hardware cursor
 + does not have to be removed/replaced when screen contents change
 + correct rendering of cursor
 - unexpected cursor size; user clients do not expect to be restricted
   to 32 rows or 32 lines of cursor
 - can only select maximum cursor size on initialization of hardware
   cursor; can't dynamically switch between 32x64 and 64x32 sizes
 - has to be reloaded when the pointer is close to the edges of the
   screen which is CPU intensive

You can tell the xserver what size cursor you support when you call
xf86_cursors_init() in the ddx.  Just expose a 32x64 or 64x32 ARGB
cursor.  Most apps don't use a 64x64 cursor anyway.  I've used
hardware with non-64x64 cursors and haven't run into any problems yet.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #5 from Guram Savinov guram.savi...@gmail.com  2013-05-20 
13:38:48 ---
It might produce garbage results depending on the thermal solution from the
OEM.

OEM? I talk about ATI on-chip thermal sensor, it's not OEM, right?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64776] [9.1.2]GPU fault detected whit eclipse juno crash system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #4 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #3)
 I have no idea where to start.
 I know how to compile code and debug program, but i have no clue on the
 mesa's code structure, and how it works.
 I don't know what CB6 is, i'm not sure about page meaning (is it similar to
 classic RAM page?) etc..
 can you tell me at least witch bunch of file/operation i have to debug, and
 how?

CB6 is the 6th color buffer and the GPU has a VM page table just like the CPU. 
That info is not really important for you, I mentioned it for other developers.
 If you could bisect mesa using git, that would be great.  There are a lot of
howtos for using git to bisect.  E.g.,
https://wiki.ubuntu.com/X/BisectingMesa

In your case, it would be something like:
git bisect start
git bisect bad mesa-9.1.2
git bisect good mesa-9.1.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #6 from Alex Deucher alexdeuc...@gmail.com  2013-05-20 13:47:01 
---
The OEM designs the thermal solution for the laptop.  If they choose not to use
the internal thermal sensor, there is no guarantee that it's calibrated
correctly for their specific system.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #7 from Guram Savinov guram.savi...@gmail.com  2013-05-20 
13:52:21 ---
Ok, but how about comment#4, is it possible?

By default sensor will be initialized as it implemented now, but it will be
possible to override OEM configuration that disable internal sensor.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #8 from Alex Deucher alexdeuc...@gmail.com  2013-05-20 13:59:06 
---
I'd prefer not to.  These sort of options tend to be abused.  Users and
possibly some distros will start forcing the option on, and then we'll get
swamped with bug reports about garbage temperatures where the reporter will
fail to note that they forced the option on.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: Fix VRAM size calculation for VRAM = 4GB

[Alex Deucher]

On Sat, May 18, 2013 at 3:19 PM, Niels Ole Salscheider
niels_...@salscheider-online.de wrote:
 Add ULL prefix to avoid overflow.

 Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de

Applied.  thanks!

Alex

 ---
  drivers/gpu/drm/radeon/evergreen.c  | 4 ++--
  drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
  drivers/gpu/drm/radeon/si.c | 4 ++--
  3 files changed, 5 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen.c 
 b/drivers/gpu/drm/radeon/evergreen.c
 index 105bafb..06c261b 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -3405,8 +3405,8 @@ int evergreen_mc_init(struct radeon_device *rdev)
 rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
 } else {
 /* size in MB on evergreen/cayman/tn */
 -   rdev-mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
 -   rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 
 1024;
 +   rdev-mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
 1024ULL;
 +   rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
 1024ULL;
 }
 rdev-mc.visible_vram_size = rdev-mc.aper_size;
 r700_vram_gtt_location(rdev, rdev-mc);
 diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
 b/drivers/gpu/drm/radeon/radeon_ttm.c
 index 93f760e..6c0ce89 100644
 --- a/drivers/gpu/drm/radeon/radeon_ttm.c
 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
 @@ -726,7 +726,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
 return r;
 }
 DRM_INFO(radeon: %uM of VRAM memory ready\n,
 -(unsigned)rdev-mc.real_vram_size / (1024 * 1024));
 +(unsigned) (rdev-mc.real_vram_size / (1024 * 1024)));
 r = ttm_bo_init_mm(rdev-mman.bdev, TTM_PL_TT,
 rdev-mc.gtt_size  PAGE_SHIFT);
 if (r) {
 diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
 index f0b6c2f..113ed9f 100644
 --- a/drivers/gpu/drm/radeon/si.c
 +++ b/drivers/gpu/drm/radeon/si.c
 @@ -3397,8 +3397,8 @@ static int si_mc_init(struct radeon_device *rdev)
 rdev-mc.aper_base = pci_resource_start(rdev-pdev, 0);
 rdev-mc.aper_size = pci_resource_len(rdev-pdev, 0);
 /* size in MB on si */
 -   rdev-mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
 -   rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
 +   rdev-mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
 +   rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
 rdev-mc.visible_vram_size = rdev-mc.aper_size;
 si_vram_gtt_location(rdev, rdev-mc);
 radeon_update_bandwidth_info(rdev);
 --
 1.8.2.3

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521


Rafał Miłecki zaj...@gmail.com changed:

   What|Removed |Added

 CC||zaj...@gmail.com




--- Comment #9 from Rafał Miłecki zaj...@gmail.com  2013-05-20 14:05:32 ---
(In reply to comment #8)
 I'd prefer not to.  These sort of options tend to be abused.  Users and
 possibly some distros will start forcing the option on, and then we'll get
 swamped with bug reports about garbage temperatures where the reporter will
 fail to note that they forced the option on.

Sounds sane.

@Guram: what about ACPI? Did you investigate why Linux doesn't export thermal
info from it?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64776] [9.1.2]GPU fault detected whit eclipse juno crash system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #5 from mombelli.ma...@gmail.com ---
ok, never heard of this git's feature, really nice and useful!
I'll try to bisect when i'll have some spare time.


2013/5/20 bugzilla-dae...@freedesktop.org

   *Comment # 4 https://bugs.freedesktop.org/show_bug.cgi?id=64776#c4 on bug
 64776 https://bugs.freedesktop.org/show_bug.cgi?id=64776 from Alex
 Deucher ag...@yahoo.com *

 (In reply to comment #3 
 https://bugs.freedesktop.org/show_bug.cgi?id=64776#c3)
  I have no idea where to start.
  I know how to compile code and debug program, but i have no clue on the
  mesa's code structure, and how it works.
  I don't know what CB6 is, i'm not sure about page meaning (is it similar to
  classic RAM page?) etc..
  can you tell me at least witch bunch of file/operation i have to debug, and
  how?


 CB6 is the 6th color buffer and the GPU has a VM page table just like the CPU.
 That info is not really important for you, I mentioned it for other 
 developers.
  If you could bisect mesa using git, that would be great.  There are a lot of
 howtos for using git to bisect.  E.g.,https://wiki.ubuntu.com/X/BisectingMesa

 In your case, it would be something like:
 git bisect start
 git bisect bad mesa-9.1.2
 git bisect good mesa-9.1.1

  --
 You are receiving this mail because:

- You reported the bug.



-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: i2c: add irq handler for tda998x slave encoder

[Rob Clark]

On Mon, May 20, 2013 at 6:53 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
 On 05/19/2013 10:45 PM, Russell King - ARM Linux wrote:

 On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:

 This adds an irq handler for HPD to the tda998x slave encoder driver
 to trigger HPD change instead of polling. The gpio connected to int
 pin of tda998x is passed through platform_data of the i2c client. As
 HPD will ultimately cause EDID read and that will raise an
 EDID_READ_DONE interrupt, the irq handling is done threaded with a
 workqueue to notify drm backend of HPD events.

 Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com


 Okay, I think I get this..  Some comments:

 +static irqreturn_t tda998x_irq_thread(int irq, void *data)
 +{
 +   struct drm_encoder *encoder = data;
 +   struct tda998x_priv *priv;
 +   uint8_t sta, cec, hdmi, lev;
 +
 +   if (!encoder)
 +   return IRQ_HANDLED;


 This won't ever be NULL.  The IRQ layer stores the pointer you passed
 in request_threaded_irq() and that pointer will continue to point at
 that memory until the IRQ is freed.  The only way it could be NULL is
 if you register using a NULL pointer.


 Russell,

 thanks for the comments. Of course, encoder can't be NULL here and I'll
 remove that check.


 ...

 +   if (priv-irq  0) {
 +   for (i = 100; i  0; i--) {
 +   uint8_t val = reg_read(encoder, REG_INT_FLAGS_2);


 IRQ 0 is the cross-arch no interrupt number.  So just use !priv-irq
 here and encourage anyone who uses -1 or NO_IRQ to fix their stuff. :)


 Ok, but gpio 0 still is a cross-arch valid gpio? ;)


 +   struct tda998x_priv *priv = to_tda998x_priv(encoder);
 +
 +   /* announce polling if no irq is available */
 +   if (priv-irq  0)


 Same here.

 @@ -1122,7 +1197,9 @@ tda998x_encoder_init(struct i2c_client *client,

 priv-current_page = 0;
 priv-cec = i2c_new_dummy(client-adapter, 0x34);
 +   priv-irq = -EINVAL;


 And just initialize to zero.  (it's allocated by kzalloc already right?
 So that shouldn't be necessary.)

 diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
 index 41f799f..1838703 100644
 --- a/include/drm/i2c/tda998x.h
 +++ b/include/drm/i2c/tda998x.h
 @@ -20,4 +20,8 @@ struct tda998x_encoder_params {
 int swap_f, mirr_f;
   };

 +struct tda998x_platform_data {
 +   int int_gpio;
 +};
 +


 Should be combined with tda998x_encoder_params - the platform data is
 really supposed to be passed to set_config - see this in
 drm_encoder_slave.c:

   * If @info-platform_data is non-NULL it will be used as the initial
   * slave config.
 ...
  err = encoder_drv-encoder_init(client, dev, encoder);
  if (err)
  goto fail_unregister;

  if (info-platform_data)
  encoder-slave_funcs-set_config(encoder-base,
   info-platform_data);

 So any platform data set will be passed into the set_config function...


 Sure, I'll put that into params. Will rebase my v1 PATCH on v3.10-rc1
 and that will create tda998x.h.

 But actually, this all raises the ultimate how to deal with DT in drm
 question: Currently, drm i2c slave encoders are registered within drm
 API which doesn't work well with DT nodes for those encoders.

 DT i2c adapters will register an i2c client and drm will try again in
 drm_i2c_encoder_init. Registering the i2c client again will cause it
 to fail because the i2c address is busy.

 Now, in drm_i2c_encoder_init we have access to the board_info struct
 that already offers .of_node which we could exploit here to not
 register another i2c client but try to get that already registered
 client or fall back to current behavior if NULL. of_node then could
 be set by the master encoder from e.g.
 marvell,slave-encoder = tda998x;.

 Or (and that is what I'd prefer) make use of the always empty i2c
 slave encoder _probe() as for any other i2c client. And hook up drm
 to a probed i2c client. That will also allow for the i2c client
 provide functions for other APIs, e.g. alsa.

 I am willing to dig into this, but would like to have a general
 opinion of David, Rob, and you.

I thing we probably want to re-visit the current way the i2c encoder
slave stuff works, to make for easier support of other sorts of
encoders, and possibly a starting point for shared panel drivers.
I've kinda been waiting to see how the common display/panel framework
stuff plays out, it's also possible that this would replace the i2c
encoder slave stuff.

BR,
-R

 Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61747

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Jerome Glisse gli...@freedesktop.org ---
Closing

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58521] Radeon ATOM BIOS have wrong value in controller-ucType for RV635 chip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=58521





--- Comment #10 from Guram Savinov guram.savi...@gmail.com  2013-05-20 
14:48:17 ---
@Guram: what about ACPI? Did you investigate why Linux doesn't export thermal
info from it?

Maybe Asus M50Sa laptop have no hardware ACPI thermal sensors.
If it exist I think Asus include any monitor software tool with laptop CD's.

99% that ATI internal sensor only one way to get GPU themperature.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63520

--- Comment #17 from Tom Stellard tstel...@gmail.com ---
Thanks for identifying the bad shaders, this saved me a lot of work.  I spotted
a bug in the pc=8 shader:

6: TEX temp[1].x, temp[1].z___, 1D[3] SEM_WAIT SEM_ACQUIRE;

This instruction is wrong because TEX instructions can't swizzle their source
operands.  For 1D textures, the coordinate is always read from the x component.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #14 from vincent v...@ovi.com ---
(In reply to comment #12)
 (In reply to comment #11)
  (In reply to comment #10)
   I've now recompiled everything from upstream - kwin now renders however it
   has a pinkish hugh to the bottom right - this didn't happen when I tested
   the patches separately
  
  It's possible that the recent scheduling changes have caused an unrelated
  regression.  Does kwin render correctly if you use the LLVM 3.3 branch?
 
 No time currently to test my rv670 or bisect, but on current heads my rv790
 is rendering Unigine heaven with various incorrect hues.

Does a similar regression happens on less complex application ? (ie mesa demo)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63520

--- Comment #18 from Tom Stellard tstel...@gmail.com ---
Created attachment 79572
  -- https://bugs.freedesktop.org/attachment.cgi?id=79572action=edit
Possible Fix

Does this patch fix the bug?  If not can you post the output of
RADEON_DEBUG=fp,vp with this patch applied.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.10

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Hi Dave,

   Just some minor bug fixes.

The following changes since commit b7cb1c50c828adaee95e8ada0e55918686245992:

  Merge branch 'drm-nouveau-fixes-3.10' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-05-20 
13:31:36 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.10

Alex Deucher (1):
  drm/radeon/dce2: use 10khz units for audio dto calculation

Niels Ole Salscheider (2):
  drm/radeon: Remove superfluous variable
  drm/radeon: Fix VRAM size calculation for VRAM = 4GB

 drivers/gpu/drm/radeon/atombios_crtc.c  |6 --
 drivers/gpu/drm/radeon/evergreen.c  |4 ++--
 drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++
 drivers/gpu/drm/radeon/r600_hdmi.c  |9 -
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4 
 drivers/gpu/drm/radeon/radeon_mode.h|1 -
 drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
 drivers/gpu/drm/radeon/si.c |4 ++--
 8 files changed, 12 insertions(+), 25 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.10-sun

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Hi Dave,

   This is the pull request for AMD Sun/Hainan support.  I've
split it out separately from my regular fixes stream.  Hainan
is a new SI asic with no UVD or DCE hardware.  The patches are
minimally invasive; basically just pci ids and skipping UVD and
DCE init for this family.  Most of the changes to si.c are just
the golden register tables for the family.

The following changes since commit 731da21b7b205efb388481f7a9731c4c1ca3b48c:

  drm/radeon/dce2: use 10khz units for audio dto calculation (2013-05-20 
10:44:58 -0400)

are available in the git repository at:
  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.10-sun

Alex Deucher (9):
  drm/radeon: add chip family for Hainan
  drm/radeon: fill in GPU init for Hainan (v2)
  drm/radeon: don't touch DCE or VGA regs on Hainan (v3)
  drm/radeon: fill in ucode loading support for Hainan
  drm/radeon: radeon-asic updates for Hainan
  drm/radeon: track which asics have UVD
  drm/radeon: sun/hainan chips do not have UVD (v2)
  drm/radeon: add golden register settings for Hainan (v2)
  drm/radeon: add Hainan pci ids

 drivers/gpu/drm/radeon/evergreen.c |   27 ++-
 drivers/gpu/drm/radeon/radeon.h|2 +
 drivers/gpu/drm/radeon/radeon_asic.c   |   22 ++-
 drivers/gpu/drm/radeon/radeon_bios.c   |   28 ++-
 drivers/gpu/drm/radeon/radeon_device.c |1 +
 drivers/gpu/drm/radeon/radeon_family.h |1 +
 drivers/gpu/drm/radeon/si.c|  366 ++--
 drivers/gpu/drm/radeon/sid.h   |1 +
 include/drm/drm_pciids.h   |6 +
 9 files changed, 362 insertions(+), 92 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()

[Lars-Peter Clausen]

free_irq() expects the same pointer that was passed to request_threaded_irq(),
otherwise the IRQ is not freed.

The issue was found using the following coccinelle script:

smpl
@r1@
type T;
T devid;
@@
request_threaded_irq(..., devid)

@r2@
type r1.T;
T devid;
position p;
@@
free_irq@p(..., devid)

@@
position p != r2.p;
@@
*free_irq@p(...)
/smpl

Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bbfc384..7e99853 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2082,7 +2082,7 @@ static int hdmi_remove(struct platform_device *pdev)
 
pm_runtime_disable(dev);
 
-   free_irq(hdata-irq, hdata);
+   free_irq(hdata-irq, ctx);
 
 
/* hdmiphy i2c driver */
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/nv84: Fix HDMI audio regression

[Alexander Stein]

Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
(drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
nv84 by removing too much old code without adding it in the new one.
This patch adds the missing code within the new code layout resulting in
HDMI audio working again.
It should work on any HDMI head, but due to lacking ahrdware I could
only test the (1st) one.
It also might be possible that similar code is needed for nva3, which I
can't test.

Signed-off-by: Alexander Stein alexander.st...@informatik.tu-chemnitz.de
---
This patch should also be added to stable kernels.

 drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
index 0d36bdc..7fdade6 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
@@ -55,6 +55,10 @@ nv84_hdmi_ctrl(struct nv50_disp_priv *priv, int head, int 
or, u32 data)
nv_wr32(priv, 0x616510 + hoff, 0x);
nv_mask(priv, 0x616500 + hoff, 0x0001, 0x0001);
 
+   nv_mask(priv, 0x6165d0 + hoff, 0x00070001, 0x00010001); /* SPARE, 
HW_CTS */
+   nv_mask(priv, 0x616568 + hoff, 0x00010101, 0x); /* ACR_CTRL, ?? 
*/
+   nv_mask(priv, 0x616578 + hoff, 0x8000, 0x8000); /* 
ACR_0441_ENABLE */
+
/* ??? */
nv_mask(priv, 0x61733c, 0x0010, 0x0010); /* RESETF */
nv_mask(priv, 0x61733c, 0x1000, 0x1000); /* LOOKUP_EN */
-- 
1.8.2.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

[Alex Deucher]

On Mon, May 20, 2013 at 4:15 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, May 20, 2013 at 09:36:02AM -0400, Alex Deucher wrote:
 You can tell the xserver what size cursor you support when you call
 xf86_cursors_init() in the ddx.  Just expose a 32x64 or 64x32 ARGB
 cursor.  Most apps don't use a 64x64 cursor anyway.  I've used
 hardware with non-64x64 cursors and haven't run into any problems yet.

 I guess the xf86 backend will fall back to software cursors if it gets
 a cursor larger than the hardware supports, so maybe 64x32 will be
 fine.

 However, my comments concerning the less-than-64x64 size come from
 David Airlie who said X and userside programs expect 64x64 to work.
 so its possibly pointless supporting anything less, as in you'd write
 code but nobody would end up using it.

 Note also that the generic DRM KMS code assumes cursor support at
 64x64, and there's no generic way for a driver at present (that I know
 of) to inform it of anything different.

It shouldn't be too hard to add a new cap for querying the cursor size
to the drm cap interface.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel