[PATCH v2 2/2] drm/bridge: Add PTN3460 bridge driver

[Thierry Reding]

On Thu, Aug 15, 2013 at 03:32:58PM -0400, Sean Paul wrote:
> On Thu, Aug 15, 2013 at 11:28 AM, Thierry Reding
>  wrote:
> > On Wed, Aug 14, 2013 at 04:47:38PM -0400, Sean Paul wrote:
> > [...]
> >> +int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> >> + struct i2c_client *client, struct device_node *node)
> > [...]
> >> + ptn_bridge->gpio_pd_n = of_get_named_gpio(node, "powerdown-gpio", 0);
> >
> > of_get_named_gpio() can return -EPROBE_DEFER and I wonder how you handle
> > that in the driver that uses ptn3460_init(). Since you pass in an
> > initialized drm_device, you'd need to undo all of that in case of
> > -EPROBE_DEFER. Well I guess you'd have to do that in case of any error,
> > but it makes things difficult to handle for drivers.
> >
> > For instance on Tegra we pretty much delay DRM initialization until all
> > required subdevices (there are quite a few) have been probed, so if we
> > wanted to use this function we'd have to call it after all drivers have
> > been probed because only then do we have access to a struct drm_device.
> > That will cause other problems, however, because at that point we can't
> > defer probing anymore.
> >
> 
> I suppose I could add another init that performs the deferrable tasks
> (ptn3460_init_deferrable or something). This would be called before
> drm init has been started from one of the probe functions.
> Alternatively, I could set this up as a standalone i2c driver and do
> this stuff in the probe. Any other options?

My point was that in those cases you don't have access to the DRM device
yet since you haven't called drm_init() yet.

> Adding another init call adds yet another thing the drm driver has to
> do to use this bridge. Making the ptn driver standalone requires you
> to set things up such that drm init is dependent on ptn probe running
> successfully. I'm not sure which is more desirable.
> 
> Practically speaking, do you expect to call drm_init before the gpio
> is available?

No, not really, but I won't know that the GPIO is available until I
actually call of_get_named_gpio_flags().

But perhaps we should cross that bridge when we get to it.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/5c30c7be/attachment-0001.pgp>

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #32 from Christian Birchinger  ---
Yes, i did this:

xrandr --newmode "1600x1200_test" 229.5   1600 1664 1856 2160 1200 1201 1204
1250 +hsync +vsync

Puts my state to this:

uvdvclk: 0 dclk: 0
power level 0sclk: 15700 mclk: 3 vddc: 950 vddci: 1100

(so it's level 0 and single_disp)

The reason i was using obscure realtime testing with xvidtune is because now
the image is much
narrower and i get ugly crt stretching pillow effects when i compensate for it.

But yes, that's nothing the driver can take care of anymore. Maybe i find some
non-standard mode
that still gets accepted. But without a tool that displays tests in realtime
like xvidtune there
will be lots of tying around.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #31 from Alex Deucher  ---
(In reply to Christian Birchinger from comment #30)
> Maybe the same reason why Tobias is stuck at level 2.
> 

Right you both seem to be afflicted but the same issue.

> Since i'm no longer able to use tools like xvidtune and the online modeline
> calculator tells me 1600x1200 85hz requires >300Mhz pixel clock, so i'm
> probably
> stuck at trying out lots of predefined modes that got pasted online.

You can use gtf or cvt to generate modelines and add them manually with xrandr.

> 
> How would i calculate the vblank period from modelines? It would really help
> if i at least knew a mode is within the specs before trying it out.

See r600_dpm_get_vblank_time() in r600_dpm.c for the formula:

line_time_us = (mode.crtc_htotal * 1000) / mode.clock;
vblank_lines = mode.crtc_vblank_end - mode.crtc_vdisplay;
vblank_time_us = vblank_lines * line_time_us;

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #30 from Christian Birchinger  ---
Maybe the same reason why Tobias is stuck at level 2.

Since i'm no longer able to use tools like xvidtune and the online modeline
calculator tells me 1600x1200 85hz requires >300Mhz pixel clock, so i'm
probably
stuck at trying out lots of predefined modes that got pasted online.

How would i calculate the vblank period from modelines? It would really help
if i at least knew a mode is within the specs before trying it out.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 65254] opengl flicker in xbmc / glxgears

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

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

--- Comment #15 from Alex Deucher  ---
Does setting env var R600_DEBUG=nodma help?

-- 
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/20130815/0f21b7cb/attachment.html>

[Bug 65254] opengl flicker in xbmc / glxgears

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

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

--- Comment #14 from Vladi  ---
I am now seeing random lockup then reboot's when watching videos with xbmc. I
have latest 3.11-rc5 + mesa and ati driver from git. Any update on this?
Thanks!

-- 
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/20130815/069a6b5b/attachment.html>

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #29 from Alex Deucher  ---
Correct.  I'm not sure why that state sees to get stuck in the highest
performance level on your cards though.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #28 from Christian Birchinger  ---
Ok thanks.

I was just in the middle of posting this:

With 1280x1024 it switched to power level 0 but without "single_disp".
With the really low 640x400 mode it did also use "single_disp".

But i now see that's no longer relevant.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #27 from Tobias Droste  ---
Isn't this the reason why there is a multi-monitor power state? same mclk but
different sclk for each power level? So switching between them should be no
problem because there's no memory reclocking happening.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #26 from Alex Deucher  ---
In order to switch the mclk, the hw needs at least 450us.  The vblank period of
the 1600x1200 mode is 396us, so it's not long enough to switch.  The switch has
to happen during vblank to avoid seeing a flicker when the mclk changes.  As
such the driver picks a power state where the mclk doesn't change (the same
power state that is used for multi-head).  You could try specifying a 1600x1200
modeline with a longer vblank period if you want to use that mode and still
support mclk switching.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Might as well also send you a pull request and flush out the single
regression fixer I have here.

Cheers, Daniel


The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:

  Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-08-15

for you to fetch changes up to 63b66e5ba54b15a6592be00555d762db6db739ce:

  drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code (2013-08-14 
20:26:49 +0200)


Chris Wilson (1):
  drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code

 drivers/gpu/drm/i915/intel_display.c | 86 
 1 file changed, 57 insertions(+), 29 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #25 from Christian Birchinger  ---
So with the problem being the vblank i switched the resolutions using xrandr.
Using lower resolution modes makes it start switching.

~ $ xrandr
Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 8192 x 8192
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 416mm
x 312mm
   1600x1200  85.0*+
   1280x1024 100.0  
   1152x864   99.4  
   1024x768  100.0  
   800x600   100.0  
   640x480   100.0  
   640x40085.1  
   400x300   144.4  
   320x240   150.3  
   320x200   139.9  

"1280x1024" and "640x400" makes it switch to level 0. But my default working
mode "1600x1200" for the past 10+ years triggers the issue.

Modeline"1600x1200" 220.00 1600 1616 1808 2080 1200 1204 1207 1244
+hsync +vsync
Modeline"1280x1024" 181.75 1280 1312 1440 1696 1024 1031 1046 1072
-hsync -vsync
Modeline"1152x864"  137.65 1152 1184 1312 1536 864 866 885 902 -hsync
-vsync
Modeline"1024x768"  115.50 1024 1056 1248 1440 768 771 781 802 -hsync
-vsync
Modeline"800x600"69.65 800 864 928 1088 600 604 610 640 -hsync
-vsync
Modeline"640x480"45.80 640 672 768 864 480 488 494 530 -hsync
-vsync
Modeline"640x400"31.50 640 672 736 832 400 401 404 445 -hsync
+vsync
Modeline"400x300"25.00 400 424 488 520 300 319 322 333 doublescan
Modeline"320x240"15.75 320 336 384 400 240 244 246 262 doublescan
Modeline"320x200"12.59 320 336 384 400 200 204 205 225 doublescan

I only really use the 1600x1200 now the old stuff comes from a time where
scaling used the whole CPU ;)

The EDID file it uses on bootup contains the same modes. EDID was generated
with the same values because
the radone driver seems to ignore the values in xorg.conf and only uses EDID
from KMS etc.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #24 from Christian Birchinger  ---
Created attachment 107212
  --> https://bugzilla.kernel.org/attachment.cgi?id=107212=edit
debug drm output

Yes, i get lots of output. Log is attached

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #23 from Alex Deucher  ---
Ah, you have a system with gddr5 memory.  The blanking period is probably too
short on your monitor to support mclk switching.  Something like this will tell
you for sure:

diff --git a/drivers/gpu/drm/radeon/cypress_dpm.c
b/drivers/gpu/drm/radeon/cypress_dpm.c
index 95a66db..cfe8313 100644
--- a/drivers/gpu/drm/radeon/cypress_dpm.c
+++ b/drivers/gpu/drm/radeon/cypress_dpm.c
@@ -2169,6 +2169,8 @@ bool cypress_dpm_vblank_too_short(struct radeon_device
*rdev)
/* we never hit the non-gddr5 limit so disable it */
u32 switch_limit = pi->mem_gddr5 ? 450 : 0;

+   DRM_ERROR("vblank_time: %d switch_limit: %d", vblank_time,
switch_limit);
+
if (vblank_time < switch_limit)
return true;
else
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index a44ae9a..7b4c9db 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -648,10 +648,15 @@ static struct radeon_ps
*radeon_dpm_pick_power_state(struct radeon_device *rdev,

/* check if the vblank period is too short to adjust the mclk */
if (single_display && rdev->asic->dpm.vblank_too_short) {
-   if (radeon_dpm_vblank_too_short(rdev))
+   if (radeon_dpm_vblank_too_short(rdev)) {
+   DRM_ERROR("vblank too short\n");
single_display = false;
+   }
}

+   DRM_ERROR("single display = %d crtcs: %d", single_display,
+ rdev->pm.dpm.new_active_crtc_count);
+
/* certain older asics have a separare 3D performance state,
 * so try that first if the user selected performance
 */

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #22 from Christian Birchinger  ---
Created attachment 107211
  --> https://bugzilla.kernel.org/attachment.cgi?id=107211=edit
drm/radeon boot output

The relevant radeon and drm boot message output

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #21 from Christian Birchinger  ---
No change here at all with those 2 patches. I'm attaching my boot dmesg just in
case my maybe weird setup (CRT monitor) does not cause anything special.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 67994] Lockup with UVD and DPM on RV730

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

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

--- Comment #6 from Nikita  ---
Also on kernel 3.11rc5

-- 
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/20130815/ec484ece/attachment.html>

[Bug 68162] [radeonsi] texture rendering is broken in Source-Engine games

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

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

Laurent carlier  changed:

   What|Removed |Added

  Attachment #84112|text/plain  |image/jpeg
  mime type||

-- 
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/20130815/bf372856/attachment.html>

[Bug 68162] [radeonsi] texture rendering is broken in Source-Engine games

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

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

--- Comment #1 from Laurent carlier  ---
Created attachment 84113
  --> https://bugs.freedesktop.org/attachment.cgi?id=84113=edit
Portal broken rendering

-- 
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/20130815/61041f78/attachment.html>

[Bug 68162] New: [radeonsi] texture rendering is broken in Source-Engine games

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

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

  Priority: medium
Bug ID: 68162
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [radeonsi] texture rendering is broken in
Source-Engine games
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: lordheavym at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 84112
  --> https://bugs.freedesktop.org/attachment.cgi?id=84112=edit
Half Life 2 broken rendering

* OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
* OpenGL version string: 2.1 Mesa 9.3.0-devel (git-5626a84)
* LLVM-3.4svn

Rendering of textures are broken with Source-Engine based games, see attached
screenshots

-- 
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/20130815/4ec73046/attachment.html>

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #20 from Alex Deucher  ---
Christian,  Can you try this patch:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043464.html
I the vblank period on your monitor is short enough that it's causing the
driver to select the multi-head case to avoid mclk switching.  You should also
try the patch in comment 17.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Pali Rohár]

On Tuesday 13 August 2013 11:28:01 Pali Roh?r wrote:
> Hello,
> 
> in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
> introduced error which cause that on my Nvidia 6600GT card
> reclocking not working anymore. There is missing assigment of
> return value from pll_calc to ret.
> 
> After this patch reclocking on my card working fine again.
> Above broken commit was introduced in kernel 3.7, so consider
> backporting this patch to older kernels too.
> 
> Signed-off-by: Pali Roh?r 
> 
> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
> 100644
> --- a/drivers/gpu/drm/nouveau/nv40_pm.c
> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq)
>   pll->vco2.max_freq = 0;
> 
> - pclk->pll_calc(pclk, pll, clk, );
> + ret = pclk->pll_calc(pclk, pll, clk, );
>   if (ret == 0)
>   return -ERANGE;

Martin, can you look at another problem with my graphics card?

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/e28b45ab/attachment-0001.pgp>

[FIX][PATCH] drm/radeon: fix WREG32_OR macro setting bits in a register

[Rafał Miłecki]

This bug (introduced in 3.10) in WREG32_OR made
commit d3418eacad403033e95e49dc14afa37c2112c134
"drm/radeon/evergreen: setup HDMI before enabling it"
cause a regression. Sometimes audio over HDMI wasn't working, sometimes
display was corrupted.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60687
https://bugzilla.kernel.org/show_bug.cgi?id=60709
https://bugs.freedesktop.org/show_bug.cgi?id=67767

Signed-off-by: Rafa? Mi?ecki 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9fc9e71..289047e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2259,7 +2259,7 @@ void cik_mm_wdoorbell(struct radeon_device *rdev, u32 
offset, u32 v);
WREG32(reg, tmp_);  \
} while (0)
 #define WREG32_AND(reg, and) WREG32_P(reg, 0, and)
-#define WREG32_OR(reg, or) WREG32_P(reg, or, ~or)
+#define WREG32_OR(reg, or) WREG32_P(reg, or, ~(or))
 #define WREG32_PLL_P(reg, val, mask)   \
do {\
uint32_t tmp_ = RREG32_PLL(reg);\
-- 
1.7.10.4

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #19 from Christian Birchinger  ---
Just to be totaly clear. In my case i only have one monitor in use. I don't use
any multi-head setup at the moment.

The rest is identical. dpms standby puts it to level 0, when it wakes up it's
also level 0. After it switched to level 2 though it wont ever go back to 1 or
0 (except  when using dpms again or the video playback trick)

During dpms standby i see "caps: single_disp video" in the dmesg output
but when the monitor is on it is "caps: video". No idea if that is normal
but as i said, i'm only using one display.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Martin Peres]

On 15/08/2013 13:46, Pali Roh?r wrote:
> On Tuesday 13 August 2013 11:28:01 Pali Roh?r wrote:
>> Hello,
>>
>> in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> introduced error which cause that on my Nvidia 6600GT card
>> reclocking not working anymore. There is missing assigment of
>> return value from pll_calc to ret.
>>
>> After this patch reclocking on my card working fine again.
>> Above broken commit was introduced in kernel 3.7, so consider
>> backporting this patch to older kernels too.
>>
>> Signed-off-by: Pali Roh?r 
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
>> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
>> 100644
>> --- a/drivers/gpu/drm/nouveau/nv40_pm.c
>> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
>> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
>> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq)
>>  pll->vco2.max_freq = 0;
>>
>> -pclk->pll_calc(pclk, pll, clk, );
>> +ret = pclk->pll_calc(pclk, pll, clk, );
>>  if (ret == 0)
>>  return -ERANGE;
> Martin, can you look at another problem with my graphics card?
As I told you before, I'm away from my computers, so I cannot test the 
patch. However,
this one seems quite obvious and should be pushed. Thanks.

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Martin Peres]

On 15/08/2013 03:24, Pali Roh?r wrote:
> On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
>> On 14/08/2013 05:02, Pali Roh?r wrote:
>>> On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
>>>> On 13/08/2013 09:53, Pali Roh?r wrote:
>>>>> On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
>>> wrote:
>>>>>> On 13/08/2013 09:23, Pali Roh?r wrote:
>>>>>>> On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
>>>>>>...
>>>>>>
>>>>>> You can check the temperature by running nvidia-settings.
>>>>>> If you can't see the temperature in it, then nvidia
>>>>>> doesn't support it on your card and
>>>>>> I'm not sure we should :s
>>>>>>
>>>>>> Thanks for the vbios you sent me in private. For the
>>>>>> others, the reason why he doesn't have temperature
>>>>>> anymore is because his vbios lacks sensor calibration
>>>>>> values.
>>>>> In nvidia-settings tab "GPU 0 - (GeForce 6600 GT)" -->
>>>>> "Thermal Settings" is:
>>>>>
>>>>> Thermal Sensor Information:
>>>>> ID: 0
>>>>> Target: GPU
>>>>> Provider: GPU Internal
>>>>> Temperature: 70 C (now)
>>>>>
>>>>> I looked in Windows program SpeedFan. It found Nvidia PCI
>>>>> card and reported "GPU Temp" about 68-70 C. So it looks
>>>>> like both nvidia driver and windows SpeedFan program
>>>>> reading same values.
>>>> Great, I'll cook you a patch in a bit and you'll see what
>>>> the temperature is like. It won't be perfectly accurate
>>>> but there is some kind of default for nvidia cards of this
>>>> generation.
>>> Ok, send me patch and I can try it if it will work and
>>> report similar values as windows or nvidia driver.
>> Sorry for the late answer.
>>
>> Please test this patch. Be aware that temperature with nouveau
>> will be higher than with the blob.
>> I only want to see if nouveau reports a temperature.
>>
>> The only way to be sure if the values are good-enough would be
>> to use the blob and run:
>> nvapeek 0x15b0
>> Please send me the result along with the temperature reported
>> by nvidia at the time of the peek.
>>
>> Martin
>>
>> PS: This patch has only be compile-tested, I don't have access
>> to an nv4x right now.
> Hello,
>
> now after patch nouveau report temperature:
>
> $ sensors
> ...
> nouveau-pci-0500
> Adapter: PCI adapter
> temp1:+63.0?C  (high = +95.0?C, hyst =  +3.0?C)
> (crit = +145.0?C, hyst =  +2.0?C)
> (emerg = +135.0?C, hyst =  +5.0?C)

Ok, that was expected ;)
> ...
>
> I found that nvidia binary driver has command line utility
> nvidia-smi which report same temperature as X utility nvidia-
> settings. So I will use nvidia-smi (if it is OK).
>
> And after reboot nvidia report another temperature value:
>
> $ nvidia-smi -q -d TEMPERATURE
> ...
> GPU :05:00.0
>  Temperature
>  Gpu : 70 C
>
> Immediately I called nvapeek command:
>
> $ nvapeek 0x15b0
> 15b0: 108e
>
> So value reported by nouveau is lower than value reported by
> nvidia binary driver.
As you didn't run nvapeek 15b0 when running nouveau it is hard to tell 
if it is due to
calibration values or because the temperature was lower.

Could you please read the temperature + peek 15b0 when running nouveau?

Anyway, it is weird because I cannot find 70?C with 0x8e as an input 
temperature and with
the current default values :o
> I wait some some and started nvidia-smi and nvapeek again, here
> are results:
>
> $ nvidia-smi -q -d TEMPERATURE
> ...
> GPU :05:00.0
>  Temperature
>  Gpu : 67 C
>
> $ nvapeek 0x15b0
> 15b0: 108e
>
> So it looks like that nvapeek returning always same value and
> does not depends on temperature... It is OK?
Well, it looks like the temperature reading is very noisy!
Could you please get the temperature + peek when the card is as hot as 
possible?

There is a very effective solution to get a GPU hot, use a hair drier. 
If you could get your
GPU to at 110?C (or less, if you feel like it is too much), that could 
help me check the formula
and default values.

PS: I attached a new version of the patch that should improve the 
temperature accuracy for
nv43s. Could you test it and send me your kernel log?
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-nv40-therm-set-default-calibration-values-if-nee.patch
Type: text/x-patch
Size: 5239 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/cfbaacc3/attachment-0001.bin>

[Bug 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed!

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

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

--- Comment #3 from Laurent carlier  ---
I cannot reproduce this anymore with libvdpau 0.7, built with dri2proto support

-- 
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/20130815/b71441cb/attachment.html>

[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver

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

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

--- Comment #67 from Lars G  ---
Created attachment 84111
  --> https://bugs.freedesktop.org/attachment.cgi?id=84111=edit
Arch Linux PKGBUILD

Attached an Arch Linux PKGBUILD file for easy testing.

-- 
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/20130815/0f5a6649/attachment.html>

[Bug 66974] [radeonsi] rendering is broken in L4D2

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

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

Michel D?nzer  changed:

   What|Removed |Added

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

--- Comment #5 from Michel D?nzer  ---
commit b00269aa5887b88d2e037d6bfa374779902f8743
Author: Michel D?nzer 
Date:   Wed Aug 7 18:14:16 2013 +0200

radeonsi: Don't leave gaps between position exports from vertex shader

If the vertex shader exports clip distances but not point size, use
position exports 1/2 instead of 2/3 for the clip distances. Fixes
geometry corruption in that case.

-- 
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/20130815/83e978f5/attachment.html>

[PATCH v2 2/2] drm/bridge: Add PTN3460 bridge driver

[Thierry Reding]

On Wed, Aug 14, 2013 at 04:47:38PM -0400, Sean Paul wrote:
[...]
> +int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> + struct i2c_client *client, struct device_node *node)
[...]
> + ptn_bridge->gpio_pd_n = of_get_named_gpio(node, "powerdown-gpio", 0);

of_get_named_gpio() can return -EPROBE_DEFER and I wonder how you handle
that in the driver that uses ptn3460_init(). Since you pass in an
initialized drm_device, you'd need to undo all of that in case of
-EPROBE_DEFER. Well I guess you'd have to do that in case of any error,
but it makes things difficult to handle for drivers.

For instance on Tegra we pretty much delay DRM initialization until all
required subdevices (there are quite a few) have been probed, so if we
wanted to use this function we'd have to call it after all drivers have
been probed because only then do we have access to a struct drm_device.
That will cause other problems, however, because at that point we can't
defer probing anymore.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/d90a8641/attachment-0001.pgp>

[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver

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

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

--- Comment #66 from Lars G  ---
Ok, the missing-texture thing in my last comment was no bug, i only forgot to
apply the file-texture correctly in blender.

So after some more testing, hw_gl_select2 works great without any regressions.
Speedy selection of dense meshes, wire and shaded views ok, no selection
problems of other items like lights or cameras.

Verry nice work!
I vote for... upstream! :)

-- 
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/20130815/6d55e68f/attachment.html>

[PATCH 5/5] drm/radeon: set speaker allocation for DCE4/5

[Rafał Miłecki]

2013/8/15 Rafa? Mi?ecki :
> 2013/8/15 Alex Deucher :
>> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
>> +{
>> +   struct radeon_device *rdev = encoder->dev->dev_private;
>> +   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>> +   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>> +   struct drm_connector *connector;
>> +   struct radeon_connector *radeon_connector = NULL;
>> +   u32 offset, tmp;
>> +   u8 *sadb;
>> +   int sad_count;
>> +
>> +   if (!dig->afmt->pin)
>> +   return;
>> +
>> +   offset = dig->afmt->pin->offset;
>
> You don't want that (offset) :)

After that trivial fix
Acked-by: Rafa? Mi?ecki 

-- 
Rafa?

[PATCH 1/5] drm/edid: add a helper function to extract the speaker allocation data block (v3)

[Rafał Miłecki]

2013/8/15 Alex Deucher :
> This adds a helper function to extract the speaker allocation
> data block from the EDID.  This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrj?l?'s comments
> v3: fix copy/paste typo in memory allocation
>
> Signed-off-by: Alex Deucher 
> Reviewed-by: Ville Syrj?l? 

Tested-by: Rafa? Mi?ecki 

[PATCH 10/12] video/hdmi: Hook the HDMI vendor infoframe with the generic _pack()

[Thierry Reding]

On Wed, Aug 14, 2013 at 06:19:13PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
[...]
> +union hdmi_vendor_infoframe {
> + struct {
> + enum hdmi_infoframe_type type;
> + unsigned char version;
> + unsigned char length;
> + unsigned int oui;
> + } any;
> + struct hdmi_hdmi_infoframe hdmi;

Given the above, perhaps struct hdmi_vendor_hdmi_infoframe would
possibly be a good fit, albeit being rather long. But I'm obsessed with
namespaces...

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/207a9102/attachment.pgp>

[PATCH 09/12] drm/edid: Move HDMI_IDENTIFIER to hdmi.h

[Thierry Reding]

On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
[...]
> +#define HDMI_IDENTIFIER 0x000c03

HDMI_IDENTIFIER sounds really generic. Perhaps HDMI_INFOFRAME_OUI_HDMI?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/daf537bd/attachment.pgp>

[PATCH 3/5] drm/radeon: add audio support for DCE6/8 GPUs (v11)

[Rafał Miłecki]

> @@ -169,13 +169,17 @@ int r600_audio_init(struct radeon_device *rdev)
> if (!radeon_audio || !r600_audio_chipset_supported(rdev))
> return 0;
>
> -   r600_audio_engine_enable(rdev, true);
> +   rdev->audio.enabled = true;
> +
> +   rdev->audio.num_pins = 1;
> +   rdev->audio.pin[0].channels = -1;
> +   rdev->audio.pin[0].rate = -1;
> +   rdev->audio.pin[0].bits_per_sample = -1;
> +   rdev->audio.pin[0].status_bits = 0;
> +   rdev->audio.pin[0].category_code = 0;
> +   rdev->audio.pin[0].id = 0;
>
> -   rdev->audio_status.channels = -1;
> -   rdev->audio_status.rate = -1;
> -   rdev->audio_status.bits_per_sample = -1;
> -   rdev->audio_status.status_bits = 0;
> -   rdev->audio_status.category_code = 0;
> +   r600_audio_enable(rdev, >audio.pin[0], false);

I was really wondering why my audio was *DISABLED* during init :P Fix
this regression please ;)

[PATCH 07/12] video/hdmi: Introduce helpers for the HDMI vendor specific infoframe

[Thierry Reding]

On Wed, Aug 14, 2013 at 06:19:10PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index ac84215..59c4748 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -286,6 +286,94 @@ ssize_t hdmi_audio_infoframe_pack(struct 
> hdmi_audio_infoframe *frame,
>  EXPORT_SYMBOL(hdmi_audio_infoframe_pack);
>  
>  /**
> + * hdmi_hdmi_infoframe_init() - initialize an HDMI vendor infoframe
> + * @frame: HDMI vendor infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame)

The hdmi_hdmi_ prefix is weird. Can't we come up with a better prefix?
You refer to it as "HDMI vendor infoframe" in the comments, yet we
already have struct hdmi_vendor_infoframe. Perhaps hdmi_3d_infoframe or
hdmi_vendor_3d_infoframe would be better choices?

> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_VENDOR;
> + frame->version = 1;
> +
> + /* 0 is a valid value for s3d_struct, so we use a special "not set"
> +  * value */

Nit: The block comment style is inconsistent again.

> +/**
> + * hdmi_hdmi_infoframe_pack() - write a HDMI vendor infoframe to binary 
> buffer
> + * @frame: HDMI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.

I need to dig up that version of the specification. This infoframe
doesn't seem to exist in 1.3.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/f7714fb0/attachment.pgp>

[Bug 60709] With 3.10.3 / 3.10.5 screen output is "green" - looks like a green overlay

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

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

--- Comment #19 from Rafa? Mi?ecki  ---
This is a duplicate of #60687 (I'm afraid I don't have privileges to close
this)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60709] With 3.10.3 / 3.10.5 screen output is "green" - looks like a green overlay

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

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

--- Comment #18 from Rafa? Mi?ecki  ---
Fix posted:
[FIX][PATCH] drm/radeon: fix WREG32_OR macro setting bits in a register
http://lists.freedesktop.org/archives/dri-devel/2013-August/043835.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

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

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

--- Comment #12 from Rafa? Mi?ecki  ---
Fix posted:
[FIX][PATCH] drm/radeon: fix WREG32_OR macro setting bits in a register
http://lists.freedesktop.org/archives/dri-devel/2013-August/043835.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2 2/2] drm/bridge: Add PTN3460 bridge driver

[Sean Paul]

On Thu, Aug 15, 2013 at 4:42 PM, Thierry Reding
 wrote:
> On Thu, Aug 15, 2013 at 03:32:58PM -0400, Sean Paul wrote:
>> On Thu, Aug 15, 2013 at 11:28 AM, Thierry Reding
>>  wrote:
>> > On Wed, Aug 14, 2013 at 04:47:38PM -0400, Sean Paul wrote:
>> > [...]
>> >> +int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
>> >> + struct i2c_client *client, struct device_node *node)
>> > [...]
>> >> + ptn_bridge->gpio_pd_n = of_get_named_gpio(node, "powerdown-gpio", 
>> >> 0);
>> >
>> > of_get_named_gpio() can return -EPROBE_DEFER and I wonder how you handle
>> > that in the driver that uses ptn3460_init(). Since you pass in an
>> > initialized drm_device, you'd need to undo all of that in case of
>> > -EPROBE_DEFER. Well I guess you'd have to do that in case of any error,
>> > but it makes things difficult to handle for drivers.
>> >
>> > For instance on Tegra we pretty much delay DRM initialization until all
>> > required subdevices (there are quite a few) have been probed, so if we
>> > wanted to use this function we'd have to call it after all drivers have
>> > been probed because only then do we have access to a struct drm_device.
>> > That will cause other problems, however, because at that point we can't
>> > defer probing anymore.
>> >
>>
>> I suppose I could add another init that performs the deferrable tasks
>> (ptn3460_init_deferrable or something). This would be called before
>> drm init has been started from one of the probe functions.
>> Alternatively, I could set this up as a standalone i2c driver and do
>> this stuff in the probe. Any other options?
>
> My point was that in those cases you don't have access to the DRM device
> yet since you haven't called drm_init() yet.
>

Yep, I got that. I meant to say we could parse the dt and save the
gpio number for later use when ptn3460_init is called with a
drm_device (thus separating the deferable parts into a place that's
easier to defer). I'm not sure this is worth fixing, TBH.


>> Adding another init call adds yet another thing the drm driver has to
>> do to use this bridge. Making the ptn driver standalone requires you
>> to set things up such that drm init is dependent on ptn probe running
>> successfully. I'm not sure which is more desirable.
>>
>> Practically speaking, do you expect to call drm_init before the gpio
>> is available?
>
> No, not really, but I won't know that the GPIO is available until I
> actually call of_get_named_gpio_flags().
>
> But perhaps we should cross that bridge when we get to it.
>

Pun intended? ;-)

Sean


> Thierry

[PATCH 06/12] video/hdmi: Derive the bar data valid bit from the bar data fields

[Thierry Reding]

On Wed, Aug 14, 2013 at 06:19:09PM +0100, Damien Lespiau wrote:
> Just like:
> 
>   Author: Damien Lespiau 
>   Date:   Mon Aug 12 11:53:24 2013 +0100
> 
>   video/hdmi: Don't let the user of this API create invalid infoframes
> 
> But this time for the horizontal/vertical bar data present bits.
> 
> Signed-off-by: Damien Lespiau 
> Reviewed-by: Ville Syrj?l? 
> ---
>  drivers/video/hdmi.c | 5 +++--
>  include/linux/hdmi.h | 2 --
>  2 files changed, 3 insertions(+), 4 deletions(-)

Same comments as for patch 5. Although I begin to see some sense in
this. Perhaps not exposing these boolean fields is a good idea after
all. I wonder if we're excluding some particular use-case by not
exposing these fields.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/2bb64e7a/attachment.pgp>

[PATCH 05/12] video/hdmi: Don't let the user of this API create invalid infoframes

[Thierry Reding]

On Wed, Aug 14, 2013 at 06:19:08PM +0100, Damien Lespiau wrote:
> To set the active aspect ratio value in the AVI infoframe today, you not
> only have to set the active_aspect field, but also the active_info_valid
> bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
> _valid bit. This was fixed in:
> 
>   Author: Damien Lespiau 
>   Date:   Tue Aug 6 20:32:17 2013 +0100
> 
>   drm: Don't generate invalid AVI infoframes for CEA modes
> 
> We can do better and derive the _valid bit from the user wanting to set
> the active aspect ratio.
[...]
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
[...]
> @@ -96,7 +96,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe 
> *frame, void *buffer,
>  
>   ptr[0] = ((frame->colorspace & 0x3) << 5) | (frame->scan_mode & 0x3);
>  
> - if (frame->active_info_valid)
> + /* Data byte 1, bit 4 has to be set if we provide the active format
> +  * aspect ratio */

Nit: According to the coding style rules this should be:

/*
 * Data byte 1, ...
 * ... ratio.
 */

> + if (frame->active_aspect & 0xf)
>   ptr[0] |= BIT(4);
>  
>   if (frame->horizontal_bar_valid)
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index bc6743e..931474c6 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -109,7 +109,6 @@ struct hdmi_avi_infoframe {
>   unsigned char version;
>   unsigned char length;
>   enum hdmi_colorspace colorspace;
> - bool active_info_valid;

When I initially came up with these data structure I wanted them to
explicitly expose all the fields that CEA/HDMI specifies. The idea was
that a user would actually be allowed to generate invalid infoframes if
they chose to by modifying the hdmi_avi_infoframe structure directly.

Instead I'd prefer to see this handled by some higher level function.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/ff14bd64/attachment.pgp>

[PATCH 5/5] drm/radeon: set speaker allocation for DCE4/5

[Rafał Miłecki]

2013/8/15 Alex Deucher :
> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> +{
> +   struct radeon_device *rdev = encoder->dev->dev_private;
> +   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> +   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> +   struct drm_connector *connector;
> +   struct radeon_connector *radeon_connector = NULL;
> +   u32 offset, tmp;
> +   u8 *sadb;
> +   int sad_count;
> +
> +   if (!dig->afmt->pin)
> +   return;
> +
> +   offset = dig->afmt->pin->offset;

You don't want that (offset) :)

[RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Maarten Lankhorst]

Op 15-08-13 15:14, Rob Clark schreef:
> On Thu, Aug 15, 2013 at 7:16 AM, Maarten Lankhorst
>  wrote:
>> Op 12-08-13 17:43, Rob Clark schreef:
>>> On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
>>>  wrote:
 +
> [snip]
 +/**
 + * fence_add_callback - add a callback to be called when the fence
 + * is signaled
 + * @fence: [in]the fence to wait on
 + * @cb:[in]the callback to register
 + * @func:  [in]the function to call
 + * @priv:  [in]the argument to pass to function
 + *
 + * cb will be initialized by fence_add_callback, no initialization
 + * by the caller is required. Any number of callbacks can be registered
 + * to a fence, but a callback can only be registered to one fence at a 
 time.
 + *
 + * Note that the callback can be called from an atomic context.  If
 + * fence is already signaled, this function will return -ENOENT (and
 + * *not* call the callback)
 + *
 + * Add a software callback to the fence. Same restrictions apply to
 + * refcount as it does to fence_wait, however the caller doesn't need to
 + * keep a refcount to fence afterwards: when software access is enabled,
 + * the creator of the fence is required to keep the fence alive until
 + * after it signals with fence_signal. The callback itself can be called
 + * from irq context.
 + *
 + */
 +int fence_add_callback(struct fence *fence, struct fence_cb *cb,
 +  fence_func_t func, void *priv)
 +{
 +   unsigned long flags;
 +   int ret = 0;
 +   bool was_set;
 +
 +   if (WARN_ON(!fence || !func))
 +   return -EINVAL;
 +
 +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
 +   return -ENOENT;
 +
 +   spin_lock_irqsave(fence->lock, flags);
 +
 +   was_set = test_and_set_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, 
 >flags);
 +
 +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
 +   ret = -ENOENT;
 +   else if (!was_set && !fence->ops->enable_signaling(fence)) {
 +   __fence_signal(fence);
 +   ret = -ENOENT;
 +   }
 +
 +   if (!ret) {
 +   cb->func = func;
 +   cb->priv = priv;
 +   list_add_tail(>node, >cb_list);
>>> since the user is providing the 'struct fence_cb', why not drop the
>>> priv & func args, and have some cb-initialize macro, ie.
>>>
>>> INIT_FENCE_CB(>fence, cbfxn);
>>>
>>> and I guess we can just drop priv and let the user embed fence in
>>> whatever structure they like.  Ie. make it look a bit how work_struct
>>> works.
>> I don't mind killing priv. But a INIT_FENCE_CB macro is silly, when all it 
>> would do is set cb->func.
>> So passing it as  an argument to fence_add_callback is fine, unless you have 
>> a better reason to
>> do so.
>>
>> INIT_WORK seems to have a bit more initialization than us, it seems work can 
>> be more complicated
>> than callbacks, because the callbacks can only be called once and work can 
>> be rescheduled multiple times.
> yeah, INIT_WORK does more.. although maybe some day we want
> INIT_FENCE_CB to do more (ie. if we add some debug features to help
> catch misuse of fence/fence-cb's).  And if nothing else, having it
> look a bit like other constructs that we have in the kernel seems
> useful.  And with my point below, you'd want INIT_FENCE_CB to do a
> INIT_LIST_HEAD(), so it is (very) slightly more than just setting the
> fxn ptr.
I don't think list is a good idea for that.
>>> maybe also, if (!list_empty(>node) return -EBUSY?
>> I think checking for list_empty(cb->node) is a terrible idea. This is no 
>> different from any other list corruption,
>> and it's a programming error. Not a runtime error. :-)
> I was thinking for crtc and page-flip, embed the fence_cb in the crtc.
>  You should only use the cb once at a time, but in this case you might
> want to re-use it for the next page flip.  Having something to catch
> cb mis-use in this sort of scenario seems useful.
>
> maybe how I am thinking to use fence_cb is not quite what you had in
> mind.  I'm not sure.  I was trying to think how I could just directly
> use fence/fence_cb in msm for everything (imported dmabuf or just
> regular 'ol gem buffers).


>> cb->node.next/prev may be NULL, which would fail with this check. The 
>> contents of cb->node are undefined
>> before fence_add_callback is called. Calling fence_remove_callback on a 
>> fence that hasn't been added is
>> undefined too. Calling fence_remove_callback works, but I'm thinking of 
>> changing the list_del_init to list_del,
>> which would make calling fence_remove_callback twice a fatal error if 
>> CONFIG_DEBUG_LIST is enabled,
>> and a possible memory corruption otherwise.
 ...
 +
> [snip]
 +
 +/**
 + * fence context counter: each 

[PATCH] drm/ttm: kill unused functions

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 159 
 1 file changed, 159 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 3df9f16..87906c2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -304,162 +304,3 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct 
ttm_buffer_object *bo)
return 0;
 }
 EXPORT_SYMBOL(ttm_fbdev_mmap);
-
-
-ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp,
- const char __user *wbuf, char __user *rbuf, size_t count,
- loff_t *f_pos, bool write)
-{
-   struct ttm_buffer_object *bo;
-   struct ttm_bo_driver *driver;
-   struct ttm_bo_kmap_obj map;
-   unsigned long dev_offset = (*f_pos >> PAGE_SHIFT);
-   unsigned long kmap_offset;
-   unsigned long kmap_end;
-   unsigned long kmap_num;
-   size_t io_size;
-   unsigned int page_offset;
-   char *virtual;
-   int ret;
-   bool no_wait = false;
-   bool dummy;
-
-   read_lock(>vm_lock);
-   bo = ttm_bo_vm_lookup_rb(bdev, dev_offset, 1);
-   if (likely(bo != NULL))
-   ttm_bo_reference(bo);
-   read_unlock(>vm_lock);
-
-   if (unlikely(bo == NULL))
-   return -EFAULT;
-
-   driver = bo->bdev->driver;
-   if (unlikely(!driver->verify_access)) {
-   ret = -EPERM;
-   goto out_unref;
-   }
-
-   ret = driver->verify_access(bo, filp);
-   if (unlikely(ret != 0))
-   goto out_unref;
-
-   kmap_offset = dev_offset - bo->vm_node->start;
-   if (unlikely(kmap_offset >= bo->num_pages)) {
-   ret = -EFBIG;
-   goto out_unref;
-   }
-
-   page_offset = *f_pos & ~PAGE_MASK;
-   io_size = bo->num_pages - kmap_offset;
-   io_size = (io_size << PAGE_SHIFT) - page_offset;
-   if (count < io_size)
-   io_size = count;
-
-   kmap_end = (*f_pos + count - 1) >> PAGE_SHIFT;
-   kmap_num = kmap_end - kmap_offset + 1;
-
-   ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
-
-   switch (ret) {
-   case 0:
-   break;
-   case -EBUSY:
-   ret = -EAGAIN;
-   goto out_unref;
-   default:
-   goto out_unref;
-   }
-
-   ret = ttm_bo_kmap(bo, kmap_offset, kmap_num, );
-   if (unlikely(ret != 0)) {
-   ttm_bo_unreserve(bo);
-   goto out_unref;
-   }
-
-   virtual = ttm_kmap_obj_virtual(, );
-   virtual += page_offset;
-
-   if (write)
-   ret = copy_from_user(virtual, wbuf, io_size);
-   else
-   ret = copy_to_user(rbuf, virtual, io_size);
-
-   ttm_bo_kunmap();
-   ttm_bo_unreserve(bo);
-   ttm_bo_unref();
-
-   if (unlikely(ret != 0))
-   return -EFBIG;
-
-   *f_pos += io_size;
-
-   return io_size;
-out_unref:
-   ttm_bo_unref();
-   return ret;
-}
-
-ssize_t ttm_bo_fbdev_io(struct ttm_buffer_object *bo, const char __user *wbuf,
-   char __user *rbuf, size_t count, loff_t *f_pos,
-   bool write)
-{
-   struct ttm_bo_kmap_obj map;
-   unsigned long kmap_offset;
-   unsigned long kmap_end;
-   unsigned long kmap_num;
-   size_t io_size;
-   unsigned int page_offset;
-   char *virtual;
-   int ret;
-   bool no_wait = false;
-   bool dummy;
-
-   kmap_offset = (*f_pos >> PAGE_SHIFT);
-   if (unlikely(kmap_offset >= bo->num_pages))
-   return -EFBIG;
-
-   page_offset = *f_pos & ~PAGE_MASK;
-   io_size = bo->num_pages - kmap_offset;
-   io_size = (io_size << PAGE_SHIFT) - page_offset;
-   if (count < io_size)
-   io_size = count;
-
-   kmap_end = (*f_pos + count - 1) >> PAGE_SHIFT;
-   kmap_num = kmap_end - kmap_offset + 1;
-
-   ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
-
-   switch (ret) {
-   case 0:
-   break;
-   case -EBUSY:
-   return -EAGAIN;
-   default:
-   return ret;
-   }
-
-   ret = ttm_bo_kmap(bo, kmap_offset, kmap_num, );
-   if (unlikely(ret != 0)) {
-   ttm_bo_unreserve(bo);
-   return ret;
-   }
-
-   virtual = ttm_kmap_obj_virtual(, );
-   virtual += page_offset;
-
-   if (write)
-   ret = copy_from_user(virtual, wbuf, io_size);
-   else
-   ret = copy_to_user(rbuf, virtual, io_size);
-
-   ttm_bo_kunmap();
-   ttm_bo_unreserve(bo);
-   ttm_bo_unref();
-
-   if (unlikely(ret != 0))
-   return ret;
-
-   *f_pos += io_size;
-
-   return io_size;
-}
-- 
1.8.3.4

[PATCH] fence: dma-buf cross-device synchronization (v13)

[Maarten Lankhorst]

Op 15-08-13 14:45, Marcin ?lusarz schreef:
> 2013/8/15 Maarten Lankhorst :
>> A fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device.  For example, userspace can call page_flip ioctl to display the
>> next frame of graphics after kicking the GPU but while the GPU is still
>> rendering.  The display device sharing the buffer with the GPU would
>> attach a callback to get notified when the GPU's rendering-complete IRQ
>> fires, to update the scan-out address of the display, without having to
>> wake up userspace.
>>
>> A driver must allocate a fence context for each execution ring that can
>> run in parallel. The function for this takes an argument with how many
>> contexts to allocate:
>>   + fence_context_alloc()
>>
>> A fence is transient, one-shot deal.  It is allocated and attached
>> to one or more dma-buf's.  When the one that attached it is done, with
>> the pending operation, it can signal the fence:
>>   + fence_signal()
>>
>> To have a rough approximation whether a fence is fired, call:
>>   + fence_is_signaled()
>>
>> The dma-buf-mgr handles tracking, and waiting on, the fences associated
>> with a dma-buf.
>>
>> The one pending on the fence can add an async callback:
>>   + fence_add_callback()
>>
>> The callback can optionally be cancelled with:
>>   + fence_remove_callback()
>>
>> To wait synchronously, optionally with a timeout:
>>   + fence_wait()
>>   + fence_wait_timeout()
>>
>> A default software-only implementation is provided, which can be used
>> by drivers attaching a fence to a buffer when they have no other means
>> for hw sync.  But a memory backed fence is also envisioned, because it
>> is common that GPU's can write to, or poll on some memory location for
>> synchronization.  For example:
>>
>>   fence = custom_get_fence(...);
>>   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
>> dma_buf *fence_buf = fence->sync_buf;
>> get_dma_buf(fence_buf);
>>
>> ... tell the hw the memory location to wait ...
>> custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
>>   } else {
>> /* fall-back to sw sync * /
>> fence_add_callback(fence, my_cb);
>>   }
>>
>> On SoC platforms, if some other hw mechanism is provided for synchronizing
>> between IP blocks, it could be supported as an alternate implementation
>> with it's own fence ops in a similar way.
>>
>> enable_signaling callback is used to provide sw signaling in case a cpu
>> waiter is requested or no compatible hardware signaling could be used.
>>
>> The intention is to provide a userspace interface (presumably via eventfd)
>> later, to be used in conjunction with dma-buf's mmap support for sw access
>> to buffers (or for userspace apps that would prefer to do their own
>> synchronization).
>>
>> v1: Original
>> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
>> that dma-fence didn't need to care about the sw->hw signaling path
>> (it can be handled same as sw->sw case), and therefore the fence->ops
>> can be simplified and more handled in the core.  So remove the signal,
>> add_callback, cancel_callback, and wait ops, and replace with a simple
>> enable_signaling() op which can be used to inform a fence supporting
>> hw->hw signaling that one or more devices which do not support hw
>> signaling are waiting (and therefore it should enable an irq or do
>> whatever is necessary in order that the CPU is notified when the
>> fence is passed).
>> v3: Fix locking fail in attach_fence() and get_fence()
>> v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
>> we decided that we need to be able to attach one fence to N dma-buf's,
>> so using the list_head in dma-fence struct would be problematic.
>> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
>> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
>> comments
>> about checking if fence fired or not. This is broken by design.
>> waitqueue_active during destruction is now fatal, since the signaller
>> should be holding a reference in enable_signalling until it signalled
>> the fence. Pass the original dma_fence_cb along, and call __remove_wait
>> in the dma_fence_callback handler, so that no cleanup needs to be
>> performed.
>> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
>> fence wasn't signaled yet, for example for hardware fences that may
>> choose to signal blindly.
>> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
>> header and fixed include mess. dma-fence.h now includes dma-buf.h
>> All members are now initialized, so kmalloc can be used for
>> allocating a dma-fence. More documentation added.
>> v9: Change compiler bitfields to flags, change return type of
>> enable_signaling to bool. Rework dma_fence_wait. Added
>> 

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #18 from Tobias Droste  ---
Doesn't help here.

But I can confirm that it works as soon as dpms is active and dpm switches to
power level 0. It stays at power level 0 after the monitors are active again
and I can echo things to power_dpm_force_performance_level. But as soon as it
goes back to power level 2 it stays there and echoing to
power_dpm_force_performance_level fails again.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2 2/2] drm/bridge: Add PTN3460 bridge driver

[Sean Paul]

On Thu, Aug 15, 2013 at 11:28 AM, Thierry Reding
 wrote:
> On Wed, Aug 14, 2013 at 04:47:38PM -0400, Sean Paul wrote:
> [...]
>> +int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
>> + struct i2c_client *client, struct device_node *node)
> [...]
>> + ptn_bridge->gpio_pd_n = of_get_named_gpio(node, "powerdown-gpio", 0);
>
> of_get_named_gpio() can return -EPROBE_DEFER and I wonder how you handle
> that in the driver that uses ptn3460_init(). Since you pass in an
> initialized drm_device, you'd need to undo all of that in case of
> -EPROBE_DEFER. Well I guess you'd have to do that in case of any error,
> but it makes things difficult to handle for drivers.
>
> For instance on Tegra we pretty much delay DRM initialization until all
> required subdevices (there are quite a few) have been probed, so if we
> wanted to use this function we'd have to call it after all drivers have
> been probed because only then do we have access to a struct drm_device.
> That will cause other problems, however, because at that point we can't
> defer probing anymore.
>

I suppose I could add another init that performs the deferrable tasks
(ptn3460_init_deferrable or something). This would be called before
drm init has been started from one of the probe functions.
Alternatively, I could set this up as a standalone i2c driver and do
this stuff in the probe. Any other options?

Adding another init call adds yet another thing the drm driver has to
do to use this bridge. Making the ptn driver standalone requires you
to set things up such that drm init is dependent on ptn probe running
successfully. I'm not sure which is more desirable.

Practically speaking, do you expect to call drm_init before the gpio
is available?

Sean



> Thierry

Moving a bug upstream per downstream request, emailing the maintainers

[John Hupp]

[1.] One line summary of the problem:
Flash 11.2 content displays in shades of green and purple only, and in a 
horizontally compressed space

[2.] Full description of the problem/report:
The full downstream bug report is at 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455 , but my 
description from there:

In my testing with the Intel driver using its default acceleration:
- Flash 11.2 works on Quantal with the 3.5 kernel
- Flash 11.2 works on Raring with the 3.5.0-17 kernel (though it boots 
to a low-res desktop with a frozen pointer)
- Flash 11.2 works on Raring also with the 3.6.11-030611 or 
3.7.10-030710 mainline kernels
- Flash 11.8 works on Raring with the 3.8 kernel (in Chrome)
- Flash 11.2 fails on Raring with the 3.8 kernel
- Flash 11.2 fails on Raring with the latest mainline kernel, 
3.11.0-031100rc5
- Flash 11.2 fails on Saucy alpha 2 with its default kernel

Disabling Flash *hardware* acceleration altogether (via R-click in the 
Flash display window: Settings: General tab) did not fix the problem.

WORKAROUND: Setting the Intel driver's acceleration method to UXA rather 
than its default SNA *always* fixes the Flash problem, but causes a 
garbled login screen under LightDM that so far has no workaround.

I also tried one possible fix for the default Intel SNA acceleration 
using the TearFree option. I created /etc/X11/xorg.conf.d/20-intel.conf 
with contents:
 Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
Option "TearFree" "true"
 EndSection
But this had no effect.

[3.] Keywords (i.e., modules, networking, kernel):
I'm a newbie hanging on by my fingernails here -- I have no idea about 
appropriate keywords.

[4.] Kernel version (from /proc/version):
Linux version 3.11.0-031100rc5-generic (apw at gomeisa) (gcc version 4.6.3 
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201308112135 SMP Mon Aug 12 01:44:44 
UTC 2013

[5.] Output of Oops.. message (if applicable) with symbolic information 
resolved (see Documentation/oops-tracing.txt)

[6.] A small shell script or example program which triggers the problem 
(if possible)

[7.] Environment
Description:Ubuntu 13.04
Release:13.04

[7.1.] Software (add the output of the ver_linux script here)
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux Dimension 3.11.0-031100rc5-generic #201308112135 SMP Mon Aug 12 
01:44:44 UTC 2013 i686 i686 i686 GNU/Linux

Gnu C /usr/src/linux-headers-3.11.0-031100rc5-generic/scripts/ver_linux:
binutils
util-linux 2.20.1
mount  support
module-init-tools  9
e2fsprogs  1.42.5
PPP2.4.5
Linux C Library2.17
Dynamic linker (ldd)   2.17
Procps 3.3.3
Net-tools  1.60
Kbd1.15.5
Sh-utils   8.20
wireless-tools 30
Modules Loaded nls_iso8859_1 usb_storage snd_intel8x0 
snd_ac97_codec ac97_bus bnep snd_pcm rfcomm bluetooth ppdev 
snd_page_alloc gpio_ich snd_seq_midi snd_seq_midi_event snd_rawmidi 
snd_seq dcdbas snd_seq_device i915 snd_timer video snd psmouse 
drm_kms_helper serio_raw soundcore drm i2c_algo_bit parport_pc lpc_ich 
shpchp lp mac_hid parport b44 ssb mii floppy

[7.2.] Processor information (from /proc/cpuinfo):
processor: 0
vendor_id: GenuineIntel
cpu family: 15
model: 2
model name: Intel(R) Celeron(R) CPU 2.40GHz
stepping: 9
microcode: 0x17
cpu MHz: 2392.420
cache size: 128 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu: yes
fpu_exception: yes
cpuid level: 2
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts 
cid xtpr
bogomips: 4784.84
clflush size: 64
cache_alignment: 128
address sizes: 36 bits physical, 32 bits virtual
power management:

[7.3.] Module information (from /proc/modules):
nls_iso8859_1 12617 1 - Live 0x
usb_storage 48631 1 - Live 0x
snd_intel8x0 33458 1 - Live 0x
snd_ac97_codec 110295 1 snd_intel8x0, Live 0x
ac97_bus 12642 1 snd_ac97_codec, Live 0x
bnep 19143 2 - Live 0x
snd_pcm 94597 2 snd_intel8x0,snd_ac97_codec, Live 0x
rfcomm 58965 0 - Live 0x
bluetooth 337841 10 bnep,rfcomm, Live 0x
ppdev 17423 0 - Live 0x
snd_page_alloc 18398 2 snd_intel8x0,snd_pcm, Live 0x
gpio_ich 13278 0 - Live 0x
snd_seq_midi 13132 0 - Live 0x
snd_seq_midi_event 14475 1 snd_seq_midi, Live 0x
snd_rawmidi 25157 1 snd_seq_midi, Live 0x
snd_seq 55716 2 snd_seq_midi,snd_seq_midi_event, Live 0x
dcdbas 14456 0 - Live 0x
snd_seq_device 14137 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x
i915 606994 2 - Live 0x
snd_timer 28930 2 snd_pcm,snd_seq, Live 0x
video 

[PATCH 6/7] drm/nouveau: embed gem object in nouveau_bo

[Maarten Lankhorst]

Op 15-08-13 14:44, Daniel Vetter schreef:
> On Thu, Aug 15, 2013 at 2:32 PM, David Herrmann  
> wrote:
>>> This would allow ttm to do kref_put((kref_t*)(bo +1), driver->releasefn), 
>>> where driver->releasefn has to call ttm_bo_release again.
>>> Unfortunately unless drm is fixed dma-buf is still going to be as buggy as 
>>> before, not much I can do about that. :/
>>> But this is something for a future where dma-buf in drm doesn't suck..
>> This same issue came up with the vma-access-management patches. I
>> dislike adding hacks to TTM to allow accessing the surrounding GEM
>> object only to keep TTM gem-agnostic. We could fix all this with a
>> simple gem_object* pointer in the ttm-bo (or a flag indicating
>> container_of is valid).
>>
>> Or we make gem TTM-aware by optionally embedding either a ttm_bo or a
>> kref object. Hm. Ideas welcome!
Oh original patch:

Acked-by: Maarten Lankhorst 

I think with this series the normal ttm refcount could be removed entirely. The 
only place in ttm that
uses it is ttm_bo_mmap and ttm_bo_init. If struct vm_operations_struct is set 
by the driver the refcount
isn't required in ttm any more at all. The other places in core ttm that use 
refcount now can be cleaned up.

Radeon was already overriding the mmap ops for ttm, so this could now be done 
in a cleaner way. :-)

That leaves vmwgfx of course, I'll probably kill ttm_bo_create because that 
will no longer work without refcount,
and fixup their code.

ttm_bo_io and ttm_bo_fbdev_io can be removed entirely, nothing uses it (I'll 
send a patch for it).
> Imo embedding a gem bo into a ttm bo should be too harmful. I think we
> already have funny lifetime issues around
> ttm_bo->presistent_swap_storage, so this would imo be a win. Four
> downsides afaik:
> - gem shows up in drm/ttm/ ;-)
> - i915 gem crap like the read/write domains get splattered even more
> around. We could just move them to the i915 gem object struct and call
> it a day I think.
> - vmwgfx doesn't expose a gem interface. Imo this doesn't apply any
> more since we have support for driver private gem objects since a
> while. So shouldn't be too hard to do the final untangling and allow
> non-gem drivers to init gem objects, but not link them up anywhere.
> - gem_object_unref uses dev->struct_mutex. The last reason for that is
> the vma manager (which can be fixed to use the same
> kref_get_unless_zero trick ttm uses) and then the locking pushed down
> into drivers (probably needs a deferred free list to get going).
It's not required to move ttm to gem to kill the refcount. :-)

~Maarten

[Bug 67276] kernel-3.11 [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)

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

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

Joshua Cov.  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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/20130815/a703b231/attachment.html>

[Bug 67276] kernel-3.11 [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)

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

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

Joshua Cov.  changed:

   What|Removed |Added

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

-- 
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/20130815/d9e29ffe/attachment-0001.html>

[Bug 67276] kernel-3.11 [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)

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

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

--- Comment #27 from Joshua Cov.  ---
I think I can close this. After applying the latest drm-fixes-3.11 as well as
drm-next-3.12 I haven't seen the issue. I'll reopen this bug if the problem
occurs again

-- 
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/20130815/ef6c75bf/attachment.html>

[PATCH] fence: dma-buf cross-device synchronization (v13)

[Marcin Ślusarz]

2013/8/15 Maarten Lankhorst :
> A fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device.  For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering.  The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A driver must allocate a fence context for each execution ring that can
> run in parallel. The function for this takes an argument with how many
> contexts to allocate:
>   + fence_context_alloc()
>
> A fence is transient, one-shot deal.  It is allocated and attached
> to one or more dma-buf's.  When the one that attached it is done, with
> the pending operation, it can signal the fence:
>   + fence_signal()
>
> To have a rough approximation whether a fence is fired, call:
>   + fence_is_signaled()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> The one pending on the fence can add an async callback:
>   + fence_add_callback()
>
> The callback can optionally be cancelled with:
>   + fence_remove_callback()
>
> To wait synchronously, optionally with a timeout:
>   + fence_wait()
>   + fence_wait_timeout()
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync.  But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization.  For example:
>
>   fence = custom_get_fence(...);
>   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
> dma_buf *fence_buf = fence->sync_buf;
> get_dma_buf(fence_buf);
>
> ... tell the hw the memory location to wait ...
> custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
>   } else {
> /* fall-back to sw sync * /
> fence_add_callback(fence, my_cb);
>   }
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> enable_signaling callback is used to provide sw signaling in case a cpu
> waiter is requested or no compatible hardware signaling could be used.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
>
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core.  So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed include mess. dma-fence.h now includes dma-buf.h
> All members are now initialized, so kmalloc can be used for
> allocating a dma-fence. More documentation added.
> v9: Change compiler bitfields to flags, change return type of
> enable_signaling to bool. Rework dma_fence_wait. Added
> dma_fence_is_signaled and dma_fence_wait_timeout.
> s/dma// and change exports to non GPL. Added fence_is_signaled and
> 

[PATCH 6/7] drm/nouveau: embed gem object in nouveau_bo

[Daniel Vetter]

On Thu, Aug 15, 2013 at 2:32 PM, David Herrmann  
wrote:
>> This would allow ttm to do kref_put((kref_t*)(bo +1), driver->releasefn), 
>> where driver->releasefn has to call ttm_bo_release again.
>> Unfortunately unless drm is fixed dma-buf is still going to be as buggy as 
>> before, not much I can do about that. :/
>> But this is something for a future where dma-buf in drm doesn't suck..
>
> This same issue came up with the vma-access-management patches. I
> dislike adding hacks to TTM to allow accessing the surrounding GEM
> object only to keep TTM gem-agnostic. We could fix all this with a
> simple gem_object* pointer in the ttm-bo (or a flag indicating
> container_of is valid).
>
> Or we make gem TTM-aware by optionally embedding either a ttm_bo or a
> kref object. Hm. Ideas welcome!

Imo embedding a gem bo into a ttm bo should be too harmful. I think we
already have funny lifetime issues around
ttm_bo->presistent_swap_storage, so this would imo be a win. Four
downsides afaik:
- gem shows up in drm/ttm/ ;-)
- i915 gem crap like the read/write domains get splattered even more
around. We could just move them to the i915 gem object struct and call
it a day I think.
- vmwgfx doesn't expose a gem interface. Imo this doesn't apply any
more since we have support for driver private gem objects since a
while. So shouldn't be too hard to do the final untangling and allow
non-gem drivers to init gem objects, but not link them up anywhere.
- gem_object_unref uses dev->struct_mutex. The last reason for that is
the vma manager (which can be fixed to use the same
kref_get_unless_zero trick ttm uses) and then the locking pushed down
into drivers (probably needs a deferred free list to get going).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 17/25] drm: rip out drm_core_has_MTRR checks

[David Herrmann]

Hi

On Thu, Aug 8, 2013 at 3:41 PM, Daniel Vetter  wrote:
> The new arch_phys_wc_add/del functions do the right thing both with
> and without MTRR support in the kernel. So we can drop these
> additional checks.
>
> David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
> it's now unused, which spurred me to do a bit a better audit of the
> affected drivers. David helped a lot in that. Quoting our mail
> discussion:
>
> On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann  
> wrote:
>> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter  
>> wrote:
>>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann  
>>> wrote:
> -#if __OS_HAS_MTRR
> -static inline int drm_core_has_MTRR(struct drm_device *dev)
> -{
> -   return drm_core_check_feature(dev, DRIVER_USE_MTRR);
> -}
> -#else
> -#define drm_core_has_MTRR(dev) (0)
> -#endif
> -

 That was the last user of DRIVER_USE_MTRR (apart from drivers setting
 it in .driver_features). Any reason to keep it around?
>>>
>>> Yeah, I guess we could rip things out. Which will also force me to
>>> properly audit drivers for the eventual behaviour change this could
>>> entail (in case there's an x86 driver which did not ask for an mtrr,
>>> but iirc there isn't).
>>
>> david at david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
>> test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
>> fi ; done
>> drivers/gpu/drm/exynos
>> drivers/gpu/drm/gma500
>> drivers/gpu/drm/i2c
>> drivers/gpu/drm/nouveau
>> drivers/gpu/drm/omapdrm
>> drivers/gpu/drm/qxl
>> drivers/gpu/drm/rcar-du
>> drivers/gpu/drm/shmobile
>> drivers/gpu/drm/tilcdc
>> drivers/gpu/drm/ttm
>> drivers/gpu/drm/udl
>> drivers/gpu/drm/vmwgfx
>> david at david-mb ~/dev/kernel/linux $
>>
>> So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
>> But I cannot tell whether they break if we call arch_phys_wc_add/del,
>> anyway. At least nouveau seemed to work here, but it doesn't use AGP
>> or drm_bufs, I guess.
>
> Cool, thanks a lot for stitching together the list of drivers to look
> at. So for real KMS drivers it's the drives responsibility to add an
> mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
> already. Somehow the savage driver also ends up doing that, I have no
> idea why.
>
> Note that gma500 as a pure KMS driver doesn't need MTRR setup since
> the platforms that it supports all support PAT. So no MTRRs needed to
> get wc iomappings.
>
> The mtrr support in the drm core is all for legacy mappings of garts,
> framebuffers and registers. All legacy drivers set the USE_MTRR flag,
> so we're good there.
>
> All in all I think we can really just ditch this
>
> /endquote
>
> v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann
>
> v3: Rebase on top of David Herrmann's agp setup/cleanup changes.
>
> Cc: David Herrmann 
> Cc: Andy Lutomirski 
> Signed-off-by: Daniel Vetter 

Reviewed-by: David Herrmann 

Regards
David

> ---
>  drivers/gpu/drm/ast/ast_drv.c |  2 +-
>  drivers/gpu/drm/cirrus/cirrus_drv.c   |  2 +-
>  drivers/gpu/drm/drm_bufs.c| 13 +
>  drivers/gpu/drm/drm_pci.c | 14 ++
>  drivers/gpu/drm/drm_vm.c  |  3 +--
>  drivers/gpu/drm/i810/i810_drv.c   |  2 +-
>  drivers/gpu/drm/i915/i915_drv.c   |  2 +-
>  drivers/gpu/drm/mga/mga_drv.c |  2 +-
>  drivers/gpu/drm/mgag200/mgag200_drv.c |  2 +-
>  drivers/gpu/drm/r128/r128_drv.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c   |  4 ++--
>  drivers/gpu/drm/savage/savage_drv.c   |  2 +-
>  drivers/gpu/drm/sis/sis_drv.c |  2 +-
>  drivers/gpu/drm/tdfx/tdfx_drv.c   |  1 -
>  drivers/gpu/drm/via/via_drv.c |  2 +-
>  include/drm/drmP.h| 11 ---
>  16 files changed, 24 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index 60f1ce3..32e270d 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -197,7 +197,7 @@ static const struct file_operations ast_fops = {
>  };
>
>  static struct drm_driver driver = {
> -   .driver_features = DRIVER_USE_MTRR | DRIVER_MODESET | DRIVER_GEM,
> +   .driver_features = DRIVER_MODESET | DRIVER_GEM,
> .dev_priv_size = 0,
>
> .load = ast_driver_load,
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
> b/drivers/gpu/drm/cirrus/cirrus_drv.c
> index dd9c908..138364d 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> @@ -87,7 +87,7 @@ static const struct file_operations cirrus_driver_fops = {
>  #endif
>  };
>  static struct drm_driver driver = {
> -   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_USE_MTRR,
> +   .driver_features = DRIVER_MODESET | DRIVER_GEM,
> .load = cirrus_driver_load,
> .unload = cirrus_driver_unload,
> .fops = _driver_fops,
> diff --git 

[PATCH] fence: dma-buf cross-device synchronization (v14)

[Maarten Lankhorst]

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence->sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
scheduler. Remove fence lock and use a global spinlock instead,
this 

[PATCH 6/7] drm/nouveau: embed gem object in nouveau_bo

[David Herrmann]

Hi

On Wed, Aug 14, 2013 at 4:31 PM, Maarten Lankhorst
 wrote:
> Op 14-08-13 15:07, David Herrmann schreef:
>> There is no reason to keep the gem object separately allocated. nouveau is
>> the last user of gem_obj->driver_private, so if we embed it, we can get
>> rid of 8bytes per gem-object.
>>
>> The implementation follows the radeon driver. bo->gem is only valid, iff
>> the bo was created via the gem helpers _and_ iff the user holds a valid
>> gem reference. That is, as the gem object holds a reference to the
>> nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
>> guaranteed to also hold a gem reference. The gem object might get
>> destroyed after the last user drops the gem-ref via
>> drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
>> gem-reference.
>>
>> For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
>> valid. However, this shouldn't be used for real functionality to avoid
>> gem-internal dependencies.
>>
>> Note that the implementation follows the previous style. However, we no
>> longer can check for bo->gem != NULL to test for a valid gem object. This
>> wasn't done before, so we should be safe now.
> I'm all for getting rid of it, but I think it's not thorough enough. :P

Does that mean you are in favor of this patch? Or do you want me to
rework it right now for v2? Because I'd like to see this cleanup
applied first so all TTM drivers work the same way. On top of that we
can then do whatever we want regarding TTM refcounts. I am willing to
spend some time on this.

> There's still a separate refcount in ttm for the bo, and I think it doesn't 
> make sense to keep it like that.
> Instead of having that refcount in ttm, could it be put entirely in gem?
>
> ttm_buffer_object_transfer is the only time ttm creates a bo, and it's 
> immediately destroyed, so instead
> of calling ttm_bo_unref it could call ttm_bo_release directly, in which case 
> it doesn't matter that refcount
> is managed by gem.

The bo_vm code also takes bo references.

> Oh except for vmwgfx of course, I always forget that 'special' case.
>
> Maybe something like this in memory?
>
> struct {
>   struct ttm_buffer_object bo;
>   struct drm_gem_object gem; // Can be anything, as long as first member is a 
> refcount, and no hole between ttm and this..
> };

Ugh.. This won't particularly win any beauty contest..

> This would allow ttm to do kref_put((kref_t*)(bo +1), driver->releasefn), 
> where driver->releasefn has to call ttm_bo_release again.
> Unfortunately unless drm is fixed dma-buf is still going to be as buggy as 
> before, not much I can do about that. :/
> But this is something for a future where dma-buf in drm doesn't suck..

This same issue came up with the vma-access-management patches. I
dislike adding hacks to TTM to allow accessing the surrounding GEM
object only to keep TTM gem-agnostic. We could fix all this with a
simple gem_object* pointer in the ttm-bo (or a flag indicating
container_of is valid).

Or we make gem TTM-aware by optionally embedding either a ttm_bo or a
kref object. Hm. Ideas welcome!

Regards
David

[PATCH] dma-buf: Expose buffer size to userspace

[Daniel Vetter]

On Mon, Aug 05, 2013 at 04:22:00PM +1000, Christopher James Halse Rogers wrote:
> Each dma-buf has an associated size and it's reasonable for userspace
> to want to know what it is.
> 
> Since userspace already has an fd, expose the size using the
> size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
> idiom.
> 
> Signed-off-by: Christopher James Halse Rogers  canonical.com>

Yeah, loosk good to me and rather useful, so (with the dma-buf docs
improved as suggested below):

Reviewed-by: Daniel Vetter 

I've also written some small prime tests in igt, so also:

Tested-by: Daniel Vetter 

> ---
> 
> I've run into a point in the radeon DRM userspace where I need the
> size of a dma-buf. I could add a radeon-specific mechanism to get that,
> but this seems like something that would be more generally useful.
> 
> I'm not entirely sure about supporting both SEEK_END and SEEK_CUR; this
> is somewhat of an abuse of lseek, as seeking obviously doesn't make sense.
> It's the obivous idiom for getting the size of what's on the other end of a
> file descriptor, though.
> 
> I didn't notice anywhere to document this; Documentation/dma-buf-api didn't
> seem like the right place. Is there somewhere I've overlooked?

I think adding a section about various other userspace interfaces exposed
below the mmap support section would be good. Feel free to squash in the
belo diff for v2.

Cheers, Daniel

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 0b23261..b3a8aa2 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
interesting ways depending upong the exporter (if userspace starts depending
upon this implicit synchronization).

+Other Interfaces Exposed to Userspace on the dma-buf FD
+--
+
+- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only
+  with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allowe
+  the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
+  llseek operation will report -EINVAL.
+
+  If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
+  cases. Userspace can use this to detect support for discovering the dma-buf
+  size using llsee.
+
 Miscellaneous notes
 ---
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH] i915: Add a Kconfig option to turn on i915.preliminary_hw_support by default

[Daniel Vetter]

On Thu, Aug 15, 2013 at 11:55:33AM +0100, Damien Lespiau wrote:
> On Tue, Aug 13, 2013 at 04:23:17PM -0700, Josh Triplett wrote:
> > When building kernels for a preliminary hardware target, having to add a
> > kernel command-line option can prove inconvenient.  Add a Kconfig option
> > that changes the default of this option to 1.
> 
> FWIW, I like it (and had something similar in mind for this on other
> little parameters/debug features). 
> 
> Reviewed-by: Damien Lespiau 
> 
> It doesn't apply cleanly to drm-intel/drm-intel-nightly which is the
> preferred branch to base patches on. Daniel might fix this himself as
> this is rather trivial to solve.

Yeah, -nightly is the preferred branch for everything. Queued for -next,
thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] fence: dma-buf cross-device synchronization (v13)

[Maarten Lankhorst]

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence->sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
scheduler. Remove fence lock and use a global spinlock instead,
this 

[RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Maarten Lankhorst]

Op 12-08-13 17:43, Rob Clark schreef:
> On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
>  wrote:
>> A fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device.  For example, userspace can call page_flip ioctl to display the
>> next frame of graphics after kicking the GPU but while the GPU is still
>> rendering.  The display device sharing the buffer with the GPU would
>> attach a callback to get notified when the GPU's rendering-complete IRQ
>> fires, to update the scan-out address of the display, without having to
>> wake up userspace.
>>
>> A driver must allocate a fence context for each execution ring that can
>> run in parallel. The function for this takes an argument with how many
>> contexts to allocate:
>>   + fence_context_alloc()
>>
>> A fence is transient, one-shot deal.  It is allocated and attached
>> to one or more dma-buf's.  When the one that attached it is done, with
>> the pending operation, it can signal the fence:
>>   + fence_signal()
>>
>> To have a rough approximation whether a fence is fired, call:
>>   + fence_is_signaled()
>>
>> The dma-buf-mgr handles tracking, and waiting on, the fences associated
>> with a dma-buf.
>>
>> The one pending on the fence can add an async callback:
>>   + fence_add_callback()
>>
>> The callback can optionally be cancelled with:
>>   + fence_remove_callback()
>>
>> To wait synchronously, optionally with a timeout:
>>   + fence_wait()
>>   + fence_wait_timeout()
>>
>> A default software-only implementation is provided, which can be used
>> by drivers attaching a fence to a buffer when they have no other means
>> for hw sync.  But a memory backed fence is also envisioned, because it
>> is common that GPU's can write to, or poll on some memory location for
>> synchronization.  For example:
>>
>>   fence = custom_get_fence(...);
>>   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
>> dma_buf *fence_buf = fence->sync_buf;
>> get_dma_buf(fence_buf);
>>
>> ... tell the hw the memory location to wait ...
>> custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
>>   } else {
>> /* fall-back to sw sync * /
>> fence_add_callback(fence, my_cb);
>>   }
>>
>> On SoC platforms, if some other hw mechanism is provided for synchronizing
>> between IP blocks, it could be supported as an alternate implementation
>> with it's own fence ops in a similar way.
>>
>> enable_signaling callback is used to provide sw signaling in case a cpu
>> waiter is requested or no compatible hardware signaling could be used.
>>
>> The intention is to provide a userspace interface (presumably via eventfd)
>> later, to be used in conjunction with dma-buf's mmap support for sw access
>> to buffers (or for userspace apps that would prefer to do their own
>> synchronization).
>>
>> v1: Original
>> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
>> that dma-fence didn't need to care about the sw->hw signaling path
>> (it can be handled same as sw->sw case), and therefore the fence->ops
>> can be simplified and more handled in the core.  So remove the signal,
>> add_callback, cancel_callback, and wait ops, and replace with a simple
>> enable_signaling() op which can be used to inform a fence supporting
>> hw->hw signaling that one or more devices which do not support hw
>> signaling are waiting (and therefore it should enable an irq or do
>> whatever is necessary in order that the CPU is notified when the
>> fence is passed).
>> v3: Fix locking fail in attach_fence() and get_fence()
>> v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
>> we decided that we need to be able to attach one fence to N dma-buf's,
>> so using the list_head in dma-fence struct would be problematic.
>> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
>> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
>> comments
>> about checking if fence fired or not. This is broken by design.
>> waitqueue_active during destruction is now fatal, since the signaller
>> should be holding a reference in enable_signalling until it signalled
>> the fence. Pass the original dma_fence_cb along, and call __remove_wait
>> in the dma_fence_callback handler, so that no cleanup needs to be
>> performed.
>> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
>> fence wasn't signaled yet, for example for hardware fences that may
>> choose to signal blindly.
>> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
>> header and fixed include mess. dma-fence.h now includes dma-buf.h
>> All members are now initialized, so kmalloc can be used for
>> allocating a dma-fence. More documentation added.
>> v9: Change compiler bitfields to flags, change return type of
>> enable_signaling to bool. Rework 

[pull] radeon drm-fixes-3.11

[Alex Deucher]

Hi Dave,

This just adds one more regression fix to my previous pull request.

Rafa? Mi?ecki (1):
  drm/radeon: fix WREG32_OR macro setting bits in a register

 drivers/gpu/drm/radeon/radeon.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.8.3.1

The following changes since commit 022374c02e357ac82e98dd2689fb2efe05723d69:

  drm/radeon/r7xx: fix copy paste typo in golden register setup (2013-08-14 
18:03:40 -0400)

are available in the git repository at:

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

for you to fetch changes up to d43a93c8d9bc4e0dc0293b6458c077c3c797594f:

  drm/radeon: fix WREG32_OR macro setting bits in a register (2013-08-15 
12:59:45 -0400)


Rafa? Mi?ecki (1):
  drm/radeon: fix WREG32_OR macro setting bits in a register

 drivers/gpu/drm/radeon/radeon.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[FIX][PATCH] drm/radeon: fix WREG32_OR macro setting bits in a register

[Alex Deucher]

On Thu, Aug 15, 2013 at 12:55 PM, Rafa? Mi?ecki  wrote:
> This bug (introduced in 3.10) in WREG32_OR made
> commit d3418eacad403033e95e49dc14afa37c2112c134
> "drm/radeon/evergreen: setup HDMI before enabling it"
> cause a regression. Sometimes audio over HDMI wasn't working, sometimes
> display was corrupted.
>
> This fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=60687
> https://bugzilla.kernel.org/show_bug.cgi?id=60709
> https://bugs.freedesktop.org/show_bug.cgi?id=67767
>
> Signed-off-by: Rafa? Mi?ecki 
> Cc: stable at vger.kernel.org

Added to my -fixes queue.

Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 9fc9e71..289047e 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2259,7 +2259,7 @@ void cik_mm_wdoorbell(struct radeon_device *rdev, u32 
> offset, u32 v);
> WREG32(reg, tmp_);  \
> } while (0)
>  #define WREG32_AND(reg, and) WREG32_P(reg, 0, and)
> -#define WREG32_OR(reg, or) WREG32_P(reg, or, ~or)
> +#define WREG32_OR(reg, or) WREG32_P(reg, or, ~(or))
>  #define WREG32_PLL_P(reg, val, mask)   \
> do {\
> uint32_t tmp_ = RREG32_PLL(reg);\
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem

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

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

--- Comment #10 from nucrap at hotmail.com ---
Hey Alex, I was able to resolve my Xorg issue (it was due to no disk space
being left on the partition :s) and could fully test your patch.
I can gladly confirm that it fully fixes the issue!

Thanks for your great work at the Radeon open source drivers!

regards,
Philip

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40

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

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

--- Comment #10 from Stefan Schmidt  ---
Oh bummer, any other ideas?

-- 
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/20130815/48d4eb87/attachment.html>

[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40

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

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

--- Comment #9 from Roland Scheidegger  ---
(In reply to comment #6)
> The patch touched code that is shared by both r100 and r200 so it's relevant
> to and applies to both.

Actually it shouldn't do anything on r100, since it always should have used the
same format there anyway. So this bug seems to be something else entirely
unfortunately.

-- 
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/20130815/9c49b8c8/attachment-0001.html>

[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40

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

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

--- Comment #8 from Stefan Schmidt  ---
Great, then I'll give it a try and report the result.

-- 
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/20130815/9b11b039/attachment.html>

[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40

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

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

--- Comment #7 from Alex Deucher  ---
In regards to this bug does the patch fix the issue you are seeing?

-- 
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/20130815/693d3fc8/attachment.html>

[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40

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

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

--- Comment #6 from Alex Deucher  ---
The patch touched code that is shared by both r100 and r200 so it's relevant to
and applies to both.

-- 
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/20130815/bee58c06/attachment.html>

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #17 from Alex Deucher  ---
Does this patch help?

diff --git a/drivers/gpu/drm/radeon/cypress_dpm.c
b/drivers/gpu/drm/radeon/cypress_dpm.c
index 95a66db..a1d2503 100644
--- a/drivers/gpu/drm/radeon/cypress_dpm.c
+++ b/drivers/gpu/drm/radeon/cypress_dpm.c
@@ -1898,10 +1898,10 @@ int cypress_dpm_enable(struct radeon_device *rdev)
cypress_start_dpm(rdev);

if (pi->gfx_clock_gating)
-   cypress_gfx_clock_gating_enable(rdev, true);
+   cypress_gfx_clock_gating_enable(rdev, false);

if (pi->mg_clock_gating)
-   cypress_mg_clock_gating_enable(rdev, true);
+   cypress_mg_clock_gating_enable(rdev, false);

if (rdev->irq.installed &&
r600_is_internal_thermal_sensor(rdev->pm.int_thermal_type)) {

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 6/6] drm/radeon: set speaker allocation for DCE3.2

[Alex Deucher]

This updates the audio driver to the speaker allocation
block from the EDID.  A similar change was just implemented
for DCE4-8.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 42 ++
 drivers/gpu/drm/radeon/r600d.h |  7 +++
 2 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index e1dec13..6d7128d 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -283,6 +283,45 @@ void r600_audio_set_dto(struct drm_encoder *encoder, u32 
clock)
}
 }

+static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 tmp;
+   u8 *sadb;
+   int sad_count;
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
 /*
  * update the info frames with the data from the current display mode
  */
@@ -327,6 +366,9 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
   HDMI0_60958_CS_UPDATE); /* allow 60958 channel status 
fields to be updated */
}

+   if (ASIC_IS_DCE32(rdev))
+   dce3_2_afmt_write_speaker_allocation(encoder);
+
WREG32(HDMI0_ACR_PACKET_CONTROL + offset,
   HDMI0_ACR_AUTO_SEND | /* allow hw to sent ACR packets when 
required */
   HDMI0_ACR_SOURCE); /* select SW CTS value */
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 7c78083..44ec7a1 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -960,6 +960,13 @@
 #   define DIG_MODE_SDVO 4
 #define DIG1_CNTL0x79a0

+#define AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER  0x71bc
+#defineSPEAKER_ALLOCATION(x)   (((x) & 0x7f) 
<< 0)
+#defineSPEAKER_ALLOCATION_MASK (0x7f << 0)
+#defineSPEAKER_ALLOCATION_SHIFT0
+#defineHDMI_CONNECTION (1 << 16)
+#defineDP_CONNECTION   (1 << 17)
+
 /* rs6xx/rs740 and r6xx share the same HDMI blocks, however, rs6xx has only one
  * instance of the blocks while r6xx has 2.  DCE 3.0 cards are slightly
  * different due to the new DIG blocks, but also have 2 instances.
-- 
1.8.3.1

[PATCH 5/6] drm/radeon: set speaker allocation for DCE4/5 (v2)

[Alex Deucher]

This updates the audio driver to the speaker allocation
block from the EDID.  A similar change was just implemented
for DCE6/8.

v2: remove unused variables

Signed-off-by: Alex Deucher 
Acked-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/evergreen_hdmi.c | 41 -
 drivers/gpu/drm/radeon/evergreend.h |  7 ++
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 2cb0f90..f71ce39 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -58,6 +58,45 @@ static void evergreen_hdmi_update_ACR(struct drm_encoder 
*encoder, uint32_t cloc
WREG32(HDMI_ACR_48_1 + offset, acr.n_48khz);
 }

+static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 tmp;
+   u8 *sadb;
+   int sad_count;
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
 static void evergreen_hdmi_write_sad_regs(struct drm_encoder *encoder)
 {
struct radeon_device *rdev = encoder->dev->dev_private;
@@ -271,7 +310,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
if (ASIC_IS_DCE6(rdev)) {
dce6_afmt_write_speaker_allocation(encoder);
} else {
-   /* fglrx sets 0x0001005f | (x & 0x00fc) in 0x5f78 here */
+   dce4_afmt_write_speaker_allocation(encoder);
}

WREG32(AFMT_AUDIO_PACKET_CONTROL2 + offset,
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index 0d582ac..430997a 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -714,6 +714,13 @@
 #define AFMT_GENERIC0_7  0x7138

 /* DCE4/5 ELD audio interface */
+#define AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER  0x5f78
+#defineSPEAKER_ALLOCATION(x)   (((x) & 0x7f) 
<< 0)
+#defineSPEAKER_ALLOCATION_MASK (0x7f << 0)
+#defineSPEAKER_ALLOCATION_SHIFT0
+#defineHDMI_CONNECTION (1 << 16)
+#defineDP_CONNECTION   (1 << 17)
+
 #define AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR00x5f84 /* LPCM */
 #define AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10x5f88 /* AC3 */
 #define AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR20x5f8c /* MPEG1 */
-- 
1.8.3.1

[PATCH 3/6] drm/radeon: add audio support for DCE6/8 GPUs (v12)

[Alex Deucher]

Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.

v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on Rafa?'s changes
v9: integrated Rafa?'s comments, update to latest
drm_edid_to_speaker_allocation API
v10: add missing line break in error message
v11: add back audio enabled messages
v12: fix copy paste typo in r600_audio_enable

Signed-off-by: Alex Deucher 
Signed-off-by: Christian K?nig 
Acked-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/Makefile|   2 +-
 drivers/gpu/drm/radeon/atombios_encoders.c |  11 +-
 drivers/gpu/drm/radeon/cik.c   |   5 +
 drivers/gpu/drm/radeon/dce6_afmt.c | 251 +
 drivers/gpu/drm/radeon/evergreen_hdmi.c|  54 +--
 drivers/gpu/drm/radeon/ni.c|  17 +-
 drivers/gpu/drm/radeon/r600_audio.c|  60 ---
 drivers/gpu/drm/radeon/r600_hdmi.c |   7 +-
 drivers/gpu/drm/radeon/radeon.h|  18 ++-
 drivers/gpu/drm/radeon/radeon_asic.c   |   8 +
 drivers/gpu/drm/radeon/radeon_asic.h   |   4 +-
 drivers/gpu/drm/radeon/radeon_display.c|  13 +-
 drivers/gpu/drm/radeon/radeon_mode.h   |   3 +-
 drivers/gpu/drm/radeon/si.c|   5 +
 drivers/gpu/drm/radeon/sid.h   |  59 +++
 15 files changed, 455 insertions(+), 62 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index da2a8e9..306364a 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
-   ci_dpm.o
+   ci_dpm.o dce6_afmt.o

 # add async DMA block
 radeon-y += \
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 092275d..dfac796 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -682,8 +682,6 @@ atombios_digital_setup(struct drm_encoder *encoder, int 
action)
 int
 atombios_get_encoder_mode(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder->dev;
-   struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct drm_connector *connector;
struct radeon_connector *radeon_connector;
@@ -710,8 +708,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog 
works fine */
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-   radeon_audio &&
-   !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+   radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
return ATOM_ENCODER_MODE_DVI;
@@ -722,8 +719,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_HDMIA:
default:
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-   radeon_audio &&
-   !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+   radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
@@ -737,8 +733,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-radeon_audio &&
-!ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 183c164..53d60b4 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7117,6 +7117,10 @@ static int cik_startup(struct radeon_device *rdev)
return r;
}

+   r = dce6_audio_init(rdev);
+   if (r)
+   return r;
+
return 0;
 }

@@ -7162,6 +7166,7 @@ int cik_resume(struct radeon_device *rdev)
  */
 int cik_suspend(struct radeon_device *rdev)
 {
+   dce6_audio_fini(rdev);

[Intel-gfx] [PATCH] i915: Add a Kconfig option to turn on i915.preliminary_hw_support by default

[Damien Lespiau]

On Tue, Aug 13, 2013 at 04:23:17PM -0700, Josh Triplett wrote:
> When building kernels for a preliminary hardware target, having to add a
> kernel command-line option can prove inconvenient.  Add a Kconfig option
> that changes the default of this option to 1.

FWIW, I like it (and had something similar in mind for this on other
little parameters/debug features). 

Reviewed-by: Damien Lespiau 

It doesn't apply cleanly to drm-intel/drm-intel-nightly which is the
preferred branch to base patches on. Daniel might fix this himself as
this is rather trivial to solve.

-- 
Damien

> Signed-off-by: Josh Triplett 
> ---
> 
> I dropped the indication of the default in the module parameter
> documentation, but I could also change it to show the default for the
> current kernel via ifdef.
> 
>  drivers/gpu/drm/Kconfig | 9 +
>  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index a7c54c8..35d57ed 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -168,6 +168,15 @@ config DRM_I915_KMS
> the driver to bind to PCI devices, which precludes loading things
> like intelfb.
>  
> +config DRM_I915_PRELIMINARY_HW_SUPPORT
> + bool "Enable preliminary support for prerelease Intel hardware by 
> default"
> + depends on DRM_I915
> + help
> +   Choose this option if you have prerelease Intel hardware and want the
> +   i915 driver to support it by default.  You can enable such support at
> +   runtime with the module option i915.preliminary_hw_support=1; this
> +   option changes the default for that module option.
> +
>  config DRM_MGA
>   tristate "Matrox g200/g400"
>   depends on DRM && PCI
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 45b3c03..594e06c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -118,10 +118,10 @@ module_param_named(i915_enable_ppgtt, 
> i915_enable_ppgtt, int, 0600);
>  MODULE_PARM_DESC(i915_enable_ppgtt,
>   "Enable PPGTT (default: true)");
>  
> -unsigned int i915_preliminary_hw_support __read_mostly = 0;
> +unsigned int i915_preliminary_hw_support __read_mostly = 
> IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT);
>  module_param_named(preliminary_hw_support, i915_preliminary_hw_support, int, 
> 0600);
>  MODULE_PARM_DESC(preliminary_hw_support,
> - "Enable preliminary hardware support. (default: false)");
> + "Enable preliminary hardware support.");
>  
>  int i915_disable_power_well __read_mostly = 1;
>  module_param_named(disable_power_well, i915_disable_power_well, int, 0600);
> -- 
> 1.8.4.rc2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/edid: compare actual vrefresh for all modes for quirks

[Alex Deucher]

The vrefresh field of the mode is 0 for most modes
fetched from the EDID (e.g., established timings).
When dealing with monitors that have a bogus preferred
mode, we may not always select the mode we want because
we compare the target refresh to the mode's vrefresh which
is 0 in a lot of cases.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/drm_edid.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 58b4882..c3095e0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1278,7 +1278,7 @@ static u32 edid_get_quirks(struct edid *edid)
 }

 #define MODE_SIZE(m) ((m)->hdisplay * (m)->vdisplay)
-#define MODE_REFRESH_DIFF(m,r) (abs((m)->vrefresh - target_refresh))
+#define MODE_REFRESH_DIFF(c,t) (abs((c) - (t)))

 /**
  * edid_fixup_preferred - set preferred modes based on quirk list
@@ -1293,6 +1293,7 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
 {
struct drm_display_mode *t, *cur_mode, *preferred_mode;
int target_refresh = 0;
+   int cur_vrefresh, preferred_vrefresh;

if (list_empty(>probed_modes))
return;
@@ -1315,10 +1316,14 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
if (MODE_SIZE(cur_mode) > MODE_SIZE(preferred_mode))
preferred_mode = cur_mode;

+   cur_vrefresh = cur_mode->vrefresh ?
+   cur_mode->vrefresh : drm_mode_vrefresh(cur_mode);
+   preferred_vrefresh = preferred_mode->vrefresh ?
+   preferred_mode->vrefresh : 
drm_mode_vrefresh(preferred_mode);
/* At a given size, try to get closest to target refresh */
if ((MODE_SIZE(cur_mode) == MODE_SIZE(preferred_mode)) &&
-   MODE_REFRESH_DIFF(cur_mode, target_refresh) <
-   MODE_REFRESH_DIFF(preferred_mode, target_refresh)) {
+   MODE_REFRESH_DIFF(cur_vrefresh, target_refresh) <
+   MODE_REFRESH_DIFF(preferred_vrefresh, target_refresh)) {
preferred_mode = cur_mode;
}
}
-- 
1.8.3.1

[PATCH] drm/radeon: set speakers allocation earlier

[Rafał Miłecki]

Do it before enabling audio channels (in AFMT_AUDIO_PACKET_CONTROL2
register).

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/dce6_afmt.c  |   69 +--
 drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++-
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
index 630df96..34392ec 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -94,17 +94,62 @@ void dce6_afmt_select_pin(struct drm_encoder *encoder)
WREG32(AFMT_AUDIO_SRC_CONTROL + offset, AFMT_AUDIO_SRC_SELECT(id));
 }

-void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder)
 {
struct radeon_device *rdev = encoder->dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
u32 offset, tmp;
+   u8 *sadb;
+   int sad_count;
+
+   if (!dig->afmt->pin)
+   return;
+
+   offset = dig->afmt->pin->offset;
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   u32 offset;
struct drm_connector *connector;
struct radeon_connector *radeon_connector = NULL;
struct cea_sad *sads;
-   int i, sad_count, sadb_count;
-   u8 *sadb;
+   int i, sad_count;

static const u16 eld_reg_to_type[][2] = {
{ AZ_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
@@ -143,23 +188,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}
BUG_ON(!sads);

-   sadb_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
-   if (sadb_count < 0) {
-   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sadb_count);
-   return;
-   }
-
-   /* program the speaker allocation */
-   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
-   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
-   /* set HDMI mode */
-   tmp |= HDMI_CONNECTION;
-   if (sadb_count)
-   tmp |= SPEAKER_ALLOCATION(sadb[0]);
-   else
-   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
-   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
-
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
u32 value = 0;
int j;
@@ -180,7 +208,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}

kfree(sads);
-   kfree(sadb);
 }

 static int dce6_audio_chipset_supported(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index c5acdf0..2cb0f90 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -32,6 +32,7 @@
 #include "evergreend.h"
 #include "atom.h"

+extern void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder);
 extern void dce6_afmt_write_sad_regs(struct drm_encoder *encoder);
 extern void dce6_afmt_select_pin(struct drm_encoder *encoder);

@@ -267,7 +268,11 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
   AFMT_60958_CS_CHANNEL_NUMBER_6(7) |
   AFMT_60958_CS_CHANNEL_NUMBER_7(8));

-   /* fglrx sets 0x0001005f | (x & 0x00fc) in 0x5f78 here */
+   if (ASIC_IS_DCE6(rdev)) {
+   

[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40

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

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

--- Comment #5 from Stefan Schmidt  ---
Nice! Would this patch also be meaningful for a R100? I'm not firm in this
topic, but to my understanding a RV200 is (confusingly) part of the R100
family.

-- 
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/20130815/64d24528/attachment.html>

[PATCH 3/3] [VPG HSW-A] drm/i915: Populate all fields of AVI infoframe

[Ville Syrjälä]

On Thu, Aug 15, 2013 at 10:29:03AM +0530, vandana.kannan at intel.com wrote:
> From: vkannan 
> 
> Populate bar information, colorimetry, IT content, quantization range fields
> of AVI infoframe based on CEA 861-D spec.
> 
> Signed-off-by: Vandana Kannan 
> ---
>  drivers/gpu/drm/i915/intel_drv.h  |4 
>  drivers/gpu/drm/i915/intel_hdmi.c |   39 
> +++--
>  2 files changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 97df85d..e02c442 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -412,6 +412,10 @@ struct cxsr_latency {
>  #define DIP_AVI_RGB_QUANT_RANGE_DEFAULT  (0 << 2)
>  #define DIP_AVI_RGB_QUANT_RANGE_LIMITED  (1 << 2)
>  #define DIP_AVI_RGB_QUANT_RANGE_FULL (2 << 2)
> +#define DIP_AVI_IT_CONTENT (1 << 7)
> +#define DIP_AVI_BAR_BOTH   (3 << 2)
> +#define DIP_AVI_COLOR_ITU601   (1 << 6)
> +#define DIP_AVI_COLOR_ITU709   (2 << 6)
>  
>  #define DIP_TYPE_SPD 0x83
>  #define DIP_VERSION_SPD  0x1
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 7cf6fc5..dbbc02b 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -340,9 +340,22 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>   .type = DIP_TYPE_AVI,
>   .ver = DIP_VERSION_AVI,
>   .len = DIP_LEN_AVI,
> + .body.avi.Y_A_B_S = 0,
>   .body.avi.C_M_R = 8,
> + .body.avi.ITC_EC_Q_SC = 0,
> + .body.avi.VIC = 0,
> + .body.avi.YQ_CN_PR = 0,
> + .body.avi.top_bar_end = 0,
> + .body.avi.bottom_bar_start = 0,
> + .body.avi.left_bar_end = 0,
> + .body.avi.right_bar_start = 0,

This is not needed. All the members not explicitly initialized are
initialized to 0 implicitly.

>   };
>  
> + /* Bar information */
> + avi_if.body.avi.Y_A_B_S |= DIP_AVI_BAR_BOTH;

Now you're sending bars left/right/top/bottom=0 bars. AFAICS that
would indicate that the entire picture is made of of the bottom and
right bars, ie. no actual content in the picture.

> +
> + avi_if.body.avi.VIC = drm_match_cea_mode(adjusted_mode);
> +
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
>   avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
>  
> @@ -351,10 +364,17 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>   avi_if.body.avi.ITC_EC_Q_SC |= 
> DIP_AVI_RGB_QUANT_RANGE_LIMITED;
>   else
>   avi_if.body.avi.ITC_EC_Q_SC |= 
> DIP_AVI_RGB_QUANT_RANGE_FULL;
> + } else {
> + /* Set full range quantization for non-CEA modes
> + and 640x480 */
> + if ((avi_if.body.avi.VIC == 0) || (avi_if.body.avi.VIC == 1))
> + avi_if.body.avi.ITC_EC_Q_SC |=
> + DIP_AVI_RGB_QUANT_RANGE_FULL;
> + else
> + avi_if.body.avi.ITC_EC_Q_SC |=
> + DIP_AVI_RGB_QUANT_RANGE_LIMITED;
>   }

The spec says we shouldn't send the quantization range unless the QS bit
in EDID CEA block is 1. Now you're sending it anyway. What's the deal?

>  
> - avi_if.body.avi.VIC = drm_match_cea_mode(adjusted_mode);
> -
>   /*If picture aspect ratio (PAR) is set to custom value, then use that,
>   else if VIC > 1, then get PAR from CEA mode list, else, calculate
>   PAR based on resolution */
> @@ -377,6 +397,21 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>   avi_if.body.avi.C_M_R |= HDMI_PICTURE_ASPECT_16_9 << 4;
>   }
>  
> + if (avi_if.body.avi.VIC) {
> + /* colorimetry: Sections 5.1 and 5.2 of CEA 861-D spec */
> + if ((adjusted_mode->vdisplay == 480) ||
> + (adjusted_mode->vdisplay == 576) ||
> + (adjusted_mode->vdisplay == 240) ||
> + (adjusted_mode->vdisplay == 288)) {
> + avi_if.body.avi.C_M_R |= DIP_AVI_COLOR_ITU601;
> + } else if ((adjusted_mode->vdisplay == 720) ||
> + (adjusted_mode->vdisplay == 1080)) {
> + avi_if.body.avi.C_M_R |= DIP_AVI_COLOR_ITU709;
> + }
> + }

We're outputting RGB data only, so we should not set the colorimetry bits.
When we decide to implement better colorspace support, we're again going
to need some new properties to let the user set the colorimetry
appropriately.

> +
> + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_IT_CONTENT;
> +
>   intel_set_infoframe(encoder, _if);
>  }
>  
> -- 
> 1.7.9.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 

[PATCH 2/3] [VPG HSW-A] drm/i915: Add PAR support in AVI infoframe

[Ville Syrjälä]

On Thu, Aug 15, 2013 at 10:29:02AM +0530, vandana.kannan at intel.com wrote:
> From: vkannan 
> 
> Populate picture aspect ratio field of AVI infoframe.
> If there is a custom value to be set for aspect ratio, it takes highest
> priority, followed by a check in the CEA mode list. If the mode is not
> found in the standard mode list, aspect ratio is calculated based on aspect
> ratio.
> 
> Priority of PAR value: 1. custom value, 2. based on CEA mode list,
> 3. calculate from resolution

There's been a lot of change to the infoframe code lately. We're
using the generic infoframe helpers these days, so this thing will need
to be rebased.

> 
> Signed-off-by: Vandana Kannan 
> ---
>  drivers/gpu/drm/drm_edid.c|7 +++
>  drivers/gpu/drm/i915/intel_hdmi.c |   25 +
>  include/drm/drm_crtc.h|1 +
>  3 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 83e2fda..110a56f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2427,6 +2427,13 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match)
>  }
>  EXPORT_SYMBOL(drm_match_cea_mode);
>  
> +enum hdmi_picture_aspect drm_get_cea_aspect_ratio(u8 vic)
> +{
> + /*return Aspect Ratio for VIC-1 to access the right array element*/
> + return edid_cea_modes[vic-1].picture_aspect_ratio;
> +}
> +EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
> +
>  static int
>  add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1e6b5cf..7cf6fc5 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -334,10 +335,12 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>  {
>   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
>   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> + enum hdmi_picture_aspect PAR;
>   struct dip_infoframe avi_if = {
>   .type = DIP_TYPE_AVI,
>   .ver = DIP_VERSION_AVI,
>   .len = DIP_LEN_AVI,
> + .body.avi.C_M_R = 8,
>   };
>  
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> @@ -352,6 +355,28 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>  
>   avi_if.body.avi.VIC = drm_match_cea_mode(adjusted_mode);
>  
> + /*If picture aspect ratio (PAR) is set to custom value, then use that,
> + else if VIC > 1, then get PAR from CEA mode list, else, calculate
> + PAR based on resolution */
> + if (adjusted_mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
> + adjusted_mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) {
> + avi_if.body.avi.C_M_R |=
> + adjusted_mode->picture_aspect_ratio << 4;
> + /*PAR is bit 5:4 of data byte 2 of AVI infoframe */
> + } else if (avi_if.body.avi.VIC) {
> + PAR = drm_get_cea_aspect_ratio(avi_if.body.avi.VIC);
> + avi_if.body.avi.C_M_R |= PAR << 4;
> + } else {
> + if (!(adjusted_mode->vdisplay % 3) &&
> + ((adjusted_mode->vdisplay * 4 / 3) ==
> + adjusted_mode->hdisplay))
> + avi_if.body.avi.C_M_R |= HDMI_PICTURE_ASPECT_4_3 << 4;
> + else if (!(adjusted_mode->vdisplay % 9) &&
> + ((adjusted_mode->vdisplay * 16 / 9) ==
> + adjusted_mode->hdisplay))
> + avi_if.body.avi.C_M_R |= HDMI_PICTURE_ASPECT_16_9 << 4;
> + }

I think what we need is a new property to control the aspect ratio.

I'm thinking something like this:
enum {
"Automatic",
"Preferred", /* M=0 /*
"4:3",  /* M=1 */
"16:9", /* M=2 */
}

If the user selects anything but "Automatic" we just directly set the M
bits to the appropriate value. Also we should probably extend
drm_match_cea_mode() so that it will also compare the user provided
aspect ratio w/ the VIC aspect ratio. That way we would send a VIC which
matches (in the 4:3 and 16:9 cases) the user selected aspect ratio. 
Although the spec does say that the M bits will take precendence over
the VIC, but given how badly this stuff is generally implemented in
displays, I have a feeling that some displays might only look at the VIC.

For the "Automatic" case we should just pick the first VIC that
otherwise matches the display mode. If there's no VIC for the mode, we
could just send M=0, or we could try to determine the aspect ratio from
the resolution like in your patch.


> +
>   intel_set_infoframe(encoder, _if);
>  }
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 07c0d58..e215bcc 100644
> --- a/include/drm/drm_crtc.h
> +++ 

[PATCH 3/3] [VPG HSW-A] drm/i915: Populate all fields of AVI infoframe

[vandana.kan...@intel.com]

From: vkannan 

Populate bar information, colorimetry, IT content, quantization range fields
of AVI infoframe based on CEA 861-D spec.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/intel_drv.h  |4 
 drivers/gpu/drm/i915/intel_hdmi.c |   39 +++--
 2 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 97df85d..e02c442 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -412,6 +412,10 @@ struct cxsr_latency {
 #define DIP_AVI_RGB_QUANT_RANGE_DEFAULT(0 << 2)
 #define DIP_AVI_RGB_QUANT_RANGE_LIMITED(1 << 2)
 #define DIP_AVI_RGB_QUANT_RANGE_FULL   (2 << 2)
+#define DIP_AVI_IT_CONTENT (1 << 7)
+#define DIP_AVI_BAR_BOTH   (3 << 2)
+#define DIP_AVI_COLOR_ITU601   (1 << 6)
+#define DIP_AVI_COLOR_ITU709   (2 << 6)

 #define DIP_TYPE_SPD   0x83
 #define DIP_VERSION_SPD0x1
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 7cf6fc5..dbbc02b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -340,9 +340,22 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
.type = DIP_TYPE_AVI,
.ver = DIP_VERSION_AVI,
.len = DIP_LEN_AVI,
+   .body.avi.Y_A_B_S = 0,
.body.avi.C_M_R = 8,
+   .body.avi.ITC_EC_Q_SC = 0,
+   .body.avi.VIC = 0,
+   .body.avi.YQ_CN_PR = 0,
+   .body.avi.top_bar_end = 0,
+   .body.avi.bottom_bar_start = 0,
+   .body.avi.left_bar_end = 0,
+   .body.avi.right_bar_start = 0,
};

+   /* Bar information */
+   avi_if.body.avi.Y_A_B_S |= DIP_AVI_BAR_BOTH;
+
+   avi_if.body.avi.VIC = drm_match_cea_mode(adjusted_mode);
+
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;

@@ -351,10 +364,17 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
avi_if.body.avi.ITC_EC_Q_SC |= 
DIP_AVI_RGB_QUANT_RANGE_LIMITED;
else
avi_if.body.avi.ITC_EC_Q_SC |= 
DIP_AVI_RGB_QUANT_RANGE_FULL;
+   } else {
+   /* Set full range quantization for non-CEA modes
+   and 640x480 */
+   if ((avi_if.body.avi.VIC == 0) || (avi_if.body.avi.VIC == 1))
+   avi_if.body.avi.ITC_EC_Q_SC |=
+   DIP_AVI_RGB_QUANT_RANGE_FULL;
+   else
+   avi_if.body.avi.ITC_EC_Q_SC |=
+   DIP_AVI_RGB_QUANT_RANGE_LIMITED;
}

-   avi_if.body.avi.VIC = drm_match_cea_mode(adjusted_mode);
-
/*If picture aspect ratio (PAR) is set to custom value, then use that,
else if VIC > 1, then get PAR from CEA mode list, else, calculate
PAR based on resolution */
@@ -377,6 +397,21 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
avi_if.body.avi.C_M_R |= HDMI_PICTURE_ASPECT_16_9 << 4;
}

+   if (avi_if.body.avi.VIC) {
+   /* colorimetry: Sections 5.1 and 5.2 of CEA 861-D spec */
+   if ((adjusted_mode->vdisplay == 480) ||
+   (adjusted_mode->vdisplay == 576) ||
+   (adjusted_mode->vdisplay == 240) ||
+   (adjusted_mode->vdisplay == 288)) {
+   avi_if.body.avi.C_M_R |= DIP_AVI_COLOR_ITU601;
+   } else if ((adjusted_mode->vdisplay == 720) ||
+   (adjusted_mode->vdisplay == 1080)) {
+   avi_if.body.avi.C_M_R |= DIP_AVI_COLOR_ITU709;
+   }
+   }
+
+   avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_IT_CONTENT;
+
intel_set_infoframe(encoder, _if);
 }

-- 
1.7.9.5

[PATCH 2/3] [VPG HSW-A] drm/i915: Add PAR support in AVI infoframe

[vandana.kan...@intel.com]

From: vkannan 

Populate picture aspect ratio field of AVI infoframe.
If there is a custom value to be set for aspect ratio, it takes highest
priority, followed by a check in the CEA mode list. If the mode is not
found in the standard mode list, aspect ratio is calculated based on aspect
ratio.

Priority of PAR value: 1. custom value, 2. based on CEA mode list,
3. calculate from resolution

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/drm_edid.c|7 +++
 drivers/gpu/drm/i915/intel_hdmi.c |   25 +
 include/drm/drm_crtc.h|1 +
 3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83e2fda..110a56f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2427,6 +2427,13 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);

+enum hdmi_picture_aspect drm_get_cea_aspect_ratio(u8 vic)
+{
+   /*return Aspect Ratio for VIC-1 to access the right array element*/
+   return edid_cea_modes[vic-1].picture_aspect_ratio;
+}
+EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
+
 static int
 add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
 {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1e6b5cf..7cf6fc5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -334,10 +335,12 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
 {
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+   enum hdmi_picture_aspect PAR;
struct dip_infoframe avi_if = {
.type = DIP_TYPE_AVI,
.ver = DIP_VERSION_AVI,
.len = DIP_LEN_AVI,
+   .body.avi.C_M_R = 8,
};

if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
@@ -352,6 +355,28 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,

avi_if.body.avi.VIC = drm_match_cea_mode(adjusted_mode);

+   /*If picture aspect ratio (PAR) is set to custom value, then use that,
+   else if VIC > 1, then get PAR from CEA mode list, else, calculate
+   PAR based on resolution */
+   if (adjusted_mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
+   adjusted_mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) {
+   avi_if.body.avi.C_M_R |=
+   adjusted_mode->picture_aspect_ratio << 4;
+   /*PAR is bit 5:4 of data byte 2 of AVI infoframe */
+   } else if (avi_if.body.avi.VIC) {
+   PAR = drm_get_cea_aspect_ratio(avi_if.body.avi.VIC);
+   avi_if.body.avi.C_M_R |= PAR << 4;
+   } else {
+   if (!(adjusted_mode->vdisplay % 3) &&
+   ((adjusted_mode->vdisplay * 4 / 3) ==
+   adjusted_mode->hdisplay))
+   avi_if.body.avi.C_M_R |= HDMI_PICTURE_ASPECT_4_3 << 4;
+   else if (!(adjusted_mode->vdisplay % 9) &&
+   ((adjusted_mode->vdisplay * 16 / 9) ==
+   adjusted_mode->hdisplay))
+   avi_if.body.avi.C_M_R |= HDMI_PICTURE_ASPECT_16_9 << 4;
+   }
+
intel_set_infoframe(encoder, _if);
 }

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 07c0d58..e215bcc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1048,6 +1048,7 @@ extern int drm_mode_gamma_set_ioctl(struct drm_device 
*dev,
void *data, struct drm_file *file_priv);
 extern u8 *drm_find_cea_extension(struct edid *edid);
 extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
+extern enum hdmi_picture_aspect drm_get_cea_aspect_ratio(u8 vic);
 extern bool drm_detect_hdmi_monitor(struct edid *edid);
 extern bool drm_detect_monitor_audio(struct edid *edid);
 extern bool drm_rgb_quant_range_selectable(struct edid *edid);
-- 
1.7.9.5

[PATCH 1/3] [VPG HSW-A] drm/i915: Add aspect ratio in drm_display_mode

[vandana.kan...@intel.com]

From: vkannan 

Mode is the video format, which is the information the sink needs to
properly display an image. a complete definition of video format includes
video timing, picture aspect ratio, color space, quantization range,
component depth.

video format timing may be associated with more than 1 video format
for example, 720x480p formatted in the 4:3 Picture Aspect Ratio or a
720x480p formatted in the 16:9 Picture Aspect Ratio.

For HDMI compliance, a set of CEA modes are tested (CEA 861-D table 3).
This list has 64 modes. When one of the modes are set, the corresponding
fields should show up correctly (as mentioned in Table 3 of CEA spec).
For picture aspect ratio, if the mode is found from the CEA mode list,
the corresponding PAR is sent as part of infoframe. If the mode to be set
is not part of the CEA mode list, PAR is calculated from resolution.

CEA modes have a specific picture aspect ratio. Adding this field
as part of drm_display_mode. This is required to be sent as part of AVI
infoframe for HDMI compliance.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/drm_edid.c  |  374 ++-
 drivers/gpu/drm/gma500/oaktrail_lvds.c  |   14 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |   38 ++--
 drivers/gpu/drm/i915/intel_display.c|3 +-
 drivers/gpu/drm/i915/intel_sdvo.c   |   38 ++--
 include/drm/drm_crtc.h  |7 +-
 6 files changed, 265 insertions(+), 209 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e8d17ee..83e2fda 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -135,378 +135,379 @@ static const struct drm_display_mode drm_dmt_modes[] = {
/* 640x350 at 85Hz */
{ DRM_MODE("640x350", DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
   736, 832, 0, 350, 382, 385, 445, 0,
-  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC, 0) },
/* 640x400 at 85Hz */
{ DRM_MODE("640x400", DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
   736, 832, 0, 400, 401, 404, 445, 0,
-  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC, 0) },
/* 720x400 at 85Hz */
{ DRM_MODE("720x400", DRM_MODE_TYPE_DRIVER, 35500, 720, 756,
   828, 936, 0, 400, 401, 404, 446, 0,
-  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC, 0) },
/* 640x480 at 60Hz */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
   752, 800, 0, 480, 489, 492, 525, 0,
-  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, 0) },
/* 640x480 at 72Hz */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
   704, 832, 0, 480, 489, 492, 520, 0,
-  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, 0) },
/* 640x480 at 75Hz */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 656,
   720, 840, 0, 480, 481, 484, 500, 0,
-  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, 0) },
/* 640x480 at 85Hz */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 36000, 640, 696,
   752, 832, 0, 480, 481, 484, 509, 0,
-  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, 0) },
/* 800x600 at 56Hz */
{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 36000, 800, 824,
   896, 1024, 0, 600, 601, 603, 625, 0,
-  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC, 0) },
/* 800x600 at 60Hz */
{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 4, 800, 840,
   968, 1056, 0, 600, 601, 605, 628, 0,
-  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC, 0) },
/* 800x600 at 72Hz */
{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 5, 800, 856,
   976, 1040, 0, 600, 637, 643, 666, 0,
-  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC, 0) },
/* 800x600 at 75Hz */
{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 49500, 800, 816,
   896, 1056, 0, 600, 601, 604, 625, 0,
-  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC, 0) },
/* 800x600 at 85Hz */
{ 

[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> +   /* program the speaker allocation */
> +   tmp = RREG32_ENDPOINT(offset, 
> AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
> +   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
> +   /* set HDMI mode */
> +   tmp |= HDMI_CONNECTION;
> +   if (sadb_count)
> +   tmp |= SPEAKER_ALLOCATION(sadb[0]);
> +   else
> +   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
> +   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
> +
> +   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> +   u32 value = 0;
> +   int j;
> +
> +   for (j = 0; j < sad_count; j++) {
> +   struct cea_sad *sad = [j];
> +
> +   if (sad->format == eld_reg_to_type[i][1]) {
> +   value = MAX_CHANNELS(sad->channels) |
> +   DESCRIPTOR_BYTE_2(sad->byte2) |
> +   SUPPORTED_FREQUENCIES(sad->freq);
> +   if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
> +   value |= 
> SUPPORTED_FREQUENCIES_STEREO(sad->freq);
> +   break;
> +   }
> +   }
> +   WREG32_ENDPOINT(offset, eld_reg_to_type[i][0], value);
> +   }

I hope this is my last questions I'm bothering you with... This is how
fglrx does that part:

WREG32(0x5e00, 0x0125);PIN_CONTROL_CHANNEL_SPEAKER
WREG32(0x5e04, 0x00c1005f);PIN_CONTROL_CHANNEL_SPEAKER

RREG32(0x000..05c); -> 0xAFMT_AUDIO_PACKET_CONTROL2
WREG32(0x000..05c, 0xff00);AFMT_AUDIO_PACKET_CONTROL2

WREG32(0x5e00, 0x0027);0x27 was 0x5f80 on Evergreen
RREG32(0x5e04); -> 0x0x27 was 0x5f80 on Evergreen

WREG32(0x5e00, 0x0127);0x27 was 0x5f80
WREG32(0x5e04, 0x0040);0x27 was 0x5f80

WREG32(0x5e00, 0x000c3128);DESCRIPTOR0
WREG32(0x5e04, 0x7f077f07);DESCRIPTOR0

The difference is that between setting PIN_CONTROL_CHANNEL_SPEAKER and
DESCRIPTOR0 fglrx enables audio channels (see
AFMT_AUDIO_PACKET_CONTROL2 and 0xff00).

Do you think it does matter? Or can we ignore the order and do it your way?

[PATCH 1/3] [VPG HSW-A] drm/i915: Add aspect ratio in drm_display_mode

[Daniel Vetter]

On Thu, Aug 15, 2013 at 10:06:42AM +0300, Ville Syrj?l? wrote:
> On Thu, Aug 15, 2013 at 10:29:01AM +0530, vandana.kannan at intel.com wrote:
> > From: vkannan 
> > 
> > Mode is the video format, which is the information the sink needs to
> > properly display an image. a complete definition of video format includes
> > video timing, picture aspect ratio, color space, quantization range,
> > component depth.
> > 
> > video format timing may be associated with more than 1 video format
> > for example, 720x480p formatted in the 4:3 Picture Aspect Ratio or a
> > 720x480p formatted in the 16:9 Picture Aspect Ratio.
> > 
> > For HDMI compliance, a set of CEA modes are tested (CEA 861-D table 3).
> > This list has 64 modes. When one of the modes are set, the corresponding
> > fields should show up correctly (as mentioned in Table 3 of CEA spec).
> > For picture aspect ratio, if the mode is found from the CEA mode list,
> > the corresponding PAR is sent as part of infoframe. If the mode to be set
> > is not part of the CEA mode list, PAR is calculated from resolution.
> > 
> > CEA modes have a specific picture aspect ratio. Adding this field
> > as part of drm_display_mode. This is required to be sent as part of AVI
> > infoframe for HDMI compliance.
> 
> > 
> > Signed-off-by: Vandana Kannan 

Slight meta comment: When doing patches which also change code outside of
drm/i915 Please try really hard to split it up into a drm core patch to
prepare things. That patch needs a drm/: prefix so that people
on the mailing list notice that it's not just for drm/i915. Then roll out
the change accross all drivers in a set of drm/: patches.

Also drm core patches always need to be cc'ed to the dri-devel mailing
list, but drm/i915 should also be cc'ed to the intel-gfx mailing list.

And like Ville mentioned we've recently switched to the shared hdmi
infoframe helpers, so this needs to be rebased on top of
drm-intel-nightly.

Thanks, Daniel

> > ---
> >  drivers/gpu/drm/drm_edid.c  |  374 
> > ++-
> >  drivers/gpu/drm/gma500/oaktrail_lvds.c  |   14 +-
> >  drivers/gpu/drm/gma500/psb_intel_sdvo.c |   38 ++--
> >  drivers/gpu/drm/i915/intel_display.c|3 +-
> >  drivers/gpu/drm/i915/intel_sdvo.c   |   38 ++--
> >  include/drm/drm_crtc.h  |7 +-
> >  6 files changed, 265 insertions(+), 209 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index e8d17ee..83e2fda 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -135,378 +135,379 @@ static const struct drm_display_mode 
> > drm_dmt_modes[] = {
> > /* 640x350 at 85Hz */
> > { DRM_MODE("640x350", DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
> >736, 832, 0, 350, 382, 385, 445, 0,
> > -  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> > +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC, 0) },
> 
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 9779ea1..07c0d58 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -115,12 +116,14 @@ enum drm_mode_status {
> >  #define DRM_MODE_TYPE_CLOCK_CRTC_C (DRM_MODE_TYPE_CLOCK_C | \
> > DRM_MODE_TYPE_CRTC_C)
> >  
> > -#define DRM_MODE(nm, t, c, hd, hss, hse, ht, hsk, vd, vss, vse, vt, vs, f) 
> > \
> > +#define DRM_MODE(nm, t, c, hd, hss, hse, ht, hsk, vd, vss, vse, vt, vs, f, 
> > \
> > +   ar) \
> > .name = nm, .status = 0, .type = (t), .clock = (c), \
> > .hdisplay = (hd), .hsync_start = (hss), .hsync_end = (hse), \
> > .htotal = (ht), .hskew = (hsk), .vdisplay = (vd), \
> > .vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
> > .vscan = (vs), .flags = (f), \
> > +   .picture_aspect_ratio = (ar), \
> > .base.type = DRM_MODE_OBJECT_MODE
> >  
> >  #define CRTC_INTERLACE_HALVE_V 0x1 /* halve V values for interlacing */
> > @@ -177,6 +180,8 @@ struct drm_display_mode {
> >  
> > int vrefresh;   /* in Hz */
> > int hsync;  /* in kHz */
> > +
> > +   enum hdmi_picture_aspect picture_aspect_ratio;
> >  };
> 
> I'm not sure we want to bloat drm_display_mode with additional
> junk for the sake of CEA modes. We could perhaps just have a
> separate VIC indexed array for the aspect ratio information.
> 
> At the very least we don't want to modify DRM_MODE() since that makes
> this patch needlessly large, and makes DRM_MODE() even harder to decode
> for humans. Instead you can just use c99 initializers and do it like so:
> 
>   { DRM_MODE(...),
> .picture_aspect_ratio = x },
> 
> >  
> >  enum drm_connector_status {
> > -- 
> > 1.7.9.5
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > 

[PATCH 1/3] [VPG HSW-A] drm/i915: Add aspect ratio in drm_display_mode

[Ville Syrjälä]

On Thu, Aug 15, 2013 at 10:29:01AM +0530, vandana.kannan at intel.com wrote:
> From: vkannan 
> 
> Mode is the video format, which is the information the sink needs to
> properly display an image. a complete definition of video format includes
> video timing, picture aspect ratio, color space, quantization range,
> component depth.
> 
> video format timing may be associated with more than 1 video format
> for example, 720x480p formatted in the 4:3 Picture Aspect Ratio or a
> 720x480p formatted in the 16:9 Picture Aspect Ratio.
> 
> For HDMI compliance, a set of CEA modes are tested (CEA 861-D table 3).
> This list has 64 modes. When one of the modes are set, the corresponding
> fields should show up correctly (as mentioned in Table 3 of CEA spec).
> For picture aspect ratio, if the mode is found from the CEA mode list,
> the corresponding PAR is sent as part of infoframe. If the mode to be set
> is not part of the CEA mode list, PAR is calculated from resolution.
> 
> CEA modes have a specific picture aspect ratio. Adding this field
> as part of drm_display_mode. This is required to be sent as part of AVI
> infoframe for HDMI compliance.

> 
> Signed-off-by: Vandana Kannan 
> ---
>  drivers/gpu/drm/drm_edid.c  |  374 
> ++-
>  drivers/gpu/drm/gma500/oaktrail_lvds.c  |   14 +-
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c |   38 ++--
>  drivers/gpu/drm/i915/intel_display.c|3 +-
>  drivers/gpu/drm/i915/intel_sdvo.c   |   38 ++--
>  include/drm/drm_crtc.h  |7 +-
>  6 files changed, 265 insertions(+), 209 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e8d17ee..83e2fda 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -135,378 +135,379 @@ static const struct drm_display_mode drm_dmt_modes[] 
> = {
>   /* 640x350 at 85Hz */
>   { DRM_MODE("640x350", DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
>  736, 832, 0, 350, 382, 385, 445, 0,
> -DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC, 0) },

> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 9779ea1..07c0d58 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -115,12 +116,14 @@ enum drm_mode_status {
>  #define DRM_MODE_TYPE_CLOCK_CRTC_C (DRM_MODE_TYPE_CLOCK_C | \
>   DRM_MODE_TYPE_CRTC_C)
>  
> -#define DRM_MODE(nm, t, c, hd, hss, hse, ht, hsk, vd, vss, vse, vt, vs, f) \
> +#define DRM_MODE(nm, t, c, hd, hss, hse, ht, hsk, vd, vss, vse, vt, vs, f, \
> + ar) \
>   .name = nm, .status = 0, .type = (t), .clock = (c), \
>   .hdisplay = (hd), .hsync_start = (hss), .hsync_end = (hse), \
>   .htotal = (ht), .hskew = (hsk), .vdisplay = (vd), \
>   .vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
>   .vscan = (vs), .flags = (f), \
> + .picture_aspect_ratio = (ar), \
>   .base.type = DRM_MODE_OBJECT_MODE
>  
>  #define CRTC_INTERLACE_HALVE_V 0x1 /* halve V values for interlacing */
> @@ -177,6 +180,8 @@ struct drm_display_mode {
>  
>   int vrefresh;   /* in Hz */
>   int hsync;  /* in kHz */
> +
> + enum hdmi_picture_aspect picture_aspect_ratio;
>  };

I'm not sure we want to bloat drm_display_mode with additional
junk for the sake of CEA modes. We could perhaps just have a
separate VIC indexed array for the aspect ratio information.

At the very least we don't want to modify DRM_MODE() since that makes
this patch needlessly large, and makes DRM_MODE() even harder to decode
for humans. Instead you can just use c99 initializers and do it like so:

  { DRM_MODE(...),
.picture_aspect_ratio = x },

>  
>  enum drm_connector_status {
> -- 
> 1.7.9.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Intel-gfx] [PATCH 11/20] drm/gem: create drm_gem_dumb_destroy

[Daniel Vetter]

On Thu, Aug 15, 2013 at 9:24 AM, Chris Wilson  
wrote:
> On Thu, Aug 15, 2013 at 12:02:40AM +0200, Daniel Vetter wrote:
>> All the gem based kms drivers really want the same function to
>> destroy a dumb framebuffer backing storage object.
>>
>> So give it to them and roll it out in all drivers.
>>
>> This still leaves the option open for kms drivers which don't use GEM
>> for backing storage, but it does decently simplify matters for gem
>> drivers.
>
> You only add a header here, is there a chunk missing from the code or
> was it exported already and just not declared?

The patch is merged already, but somehow rebase thought that chunk is
missing. This patch can be savely ignored ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> Similar to DCE4/5, but supports multiple audio pins
> which can be assigned per afmt block.

Acked-by: Rafa? Mi?ecki 

Tested successfully on my HD7750.


> +static void r600_audio_enable(struct radeon_device *rdev,
> + struct r600_audio_pin *pin,
> + bool enable)
>  {
> u32 value = 0;
> -   DRM_INFO("%s audio support\n", enable ? "Enabling" : "Disabling");

Whoops, that confused me at the beginning. Don't you think it's nice
to know from somebody's dmesg if he uses radeon.audio or now? For
debugging purposes.


> +#define AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER  0x25
> +#defineSPEAKER_ALLOCATION(x)   (((x) & 0x7f) 
> << 0)
> +#defineSPEAKER_ALLOCATION_MASK (0x7f << 0)
> +#defineSPEAKER_ALLOCATION_SHIFT0
> +#defineHDMI_CONNECTION (1 << 16)
> +#defineDP_CONNECTION   (1 << 17)

Could you share a meaning of 0x00c0 bit? I noticed it's set when
fglrx reads this register:
WREG32(0x5e00, 0x0025);
RREG32(0x5e04); -> 0x00c0

WREG32(0x5e00, 0x0125);
WREG32(0x5e04, 0x00c1005f);

but it's not set with radeon reads it for the first time. Maybe fglrx
sets that at some other stage (earlier)?

-- 
Rafa?

[PATCH 5/5] drm/radeon: set speaker allocation for DCE4/5

[Alex Deucher]

This updates the audio driver to the speaker allocation
block from the EDID.  A similar change was just implemented
for DCE6/8.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_hdmi.c | 48 -
 drivers/gpu/drm/radeon/evergreend.h |  7 +
 2 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 2cb0f90..efb67ed 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -58,6 +58,52 @@ static void evergreen_hdmi_update_ACR(struct drm_encoder 
*encoder, uint32_t cloc
WREG32(HDMI_ACR_48_1 + offset, acr.n_48khz);
 }

+static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 offset, tmp;
+   u8 *sadb;
+   int sad_count;
+
+   if (!dig->afmt->pin)
+   return;
+
+   offset = dig->afmt->pin->offset;
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
 static void evergreen_hdmi_write_sad_regs(struct drm_encoder *encoder)
 {
struct radeon_device *rdev = encoder->dev->dev_private;
@@ -271,7 +317,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
if (ASIC_IS_DCE6(rdev)) {
dce6_afmt_write_speaker_allocation(encoder);
} else {
-   /* fglrx sets 0x0001005f | (x & 0x00fc) in 0x5f78 here */
+   dce4_afmt_write_speaker_allocation(encoder);
}

WREG32(AFMT_AUDIO_PACKET_CONTROL2 + offset,
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index 0d582ac..430997a 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -714,6 +714,13 @@
 #define AFMT_GENERIC0_7  0x7138

 /* DCE4/5 ELD audio interface */
+#define AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER  0x5f78
+#defineSPEAKER_ALLOCATION(x)   (((x) & 0x7f) 
<< 0)
+#defineSPEAKER_ALLOCATION_MASK (0x7f << 0)
+#defineSPEAKER_ALLOCATION_SHIFT0
+#defineHDMI_CONNECTION (1 << 16)
+#defineDP_CONNECTION   (1 << 17)
+
 #define AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR00x5f84 /* LPCM */
 #define AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10x5f88 /* AC3 */
 #define AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR20x5f8c /* MPEG1 */
-- 
1.8.3.1

[PATCH 4/5] drm/radeon: set speakers allocation earlier

[Alex Deucher]

From: Rafa? Mi?ecki 

Do it before enabling audio channels (in AFMT_AUDIO_PACKET_CONTROL2
register).

Signed-off-by: Rafa? Mi?ecki 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/dce6_afmt.c  | 69 +++--
 drivers/gpu/drm/radeon/evergreen_hdmi.c |  7 +++-
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
index 0d9a6a2..8953255e 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -94,17 +94,62 @@ void dce6_afmt_select_pin(struct drm_encoder *encoder)
WREG32(AFMT_AUDIO_SRC_CONTROL + offset, AFMT_AUDIO_SRC_SELECT(id));
 }

-void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder)
 {
struct radeon_device *rdev = encoder->dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
u32 offset, tmp;
+   u8 *sadb;
+   int sad_count;
+
+   if (!dig->afmt->pin)
+   return;
+
+   offset = dig->afmt->pin->offset;
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   u32 offset;
struct drm_connector *connector;
struct radeon_connector *radeon_connector = NULL;
struct cea_sad *sads;
-   int i, sad_count, sadb_count;
-   u8 *sadb;
+   int i, sad_count;

static const u16 eld_reg_to_type[][2] = {
{ AZ_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
@@ -143,23 +188,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}
BUG_ON(!sads);

-   sadb_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
-   if (sadb_count < 0) {
-   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sadb_count);
-   return;
-   }
-
-   /* program the speaker allocation */
-   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
-   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
-   /* set HDMI mode */
-   tmp |= HDMI_CONNECTION;
-   if (sadb_count)
-   tmp |= SPEAKER_ALLOCATION(sadb[0]);
-   else
-   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
-   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
-
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
u32 value = 0;
int j;
@@ -180,7 +208,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}

kfree(sads);
-   kfree(sadb);
 }

 static int dce6_audio_chipset_supported(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index c5acdf0..2cb0f90 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -32,6 +32,7 @@
 #include "evergreend.h"
 #include "atom.h"

+extern void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder);
 extern void dce6_afmt_write_sad_regs(struct drm_encoder *encoder);
 extern void dce6_afmt_select_pin(struct drm_encoder *encoder);

@@ -267,7 +268,11 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
   AFMT_60958_CS_CHANNEL_NUMBER_6(7) |
   AFMT_60958_CS_CHANNEL_NUMBER_7(8));

-   /* fglrx sets 0x0001005f | (x & 0x00fc) in 0x5f78 here */
+   if 

[PATCH 3/5] drm/radeon: add audio support for DCE6/8 GPUs (v11)

[Alex Deucher]

Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.

v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on Rafa?'s changes
v9: integrated Rafa?'s comments, update to latest
drm_edid_to_speaker_allocation API
v10: add missing line break in error message
v11: add back audio enabled messages

Signed-off-by: Alex Deucher 
Signed-off-by: Christian K?nig 
Acked-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/Makefile|   2 +-
 drivers/gpu/drm/radeon/atombios_encoders.c |  11 +-
 drivers/gpu/drm/radeon/cik.c   |   5 +
 drivers/gpu/drm/radeon/dce6_afmt.c | 251 +
 drivers/gpu/drm/radeon/evergreen_hdmi.c|  54 +--
 drivers/gpu/drm/radeon/ni.c|  17 +-
 drivers/gpu/drm/radeon/r600_audio.c|  60 ---
 drivers/gpu/drm/radeon/r600_hdmi.c |   7 +-
 drivers/gpu/drm/radeon/radeon.h|  18 ++-
 drivers/gpu/drm/radeon/radeon_asic.c   |   8 +
 drivers/gpu/drm/radeon/radeon_asic.h   |   4 +-
 drivers/gpu/drm/radeon/radeon_display.c|  13 +-
 drivers/gpu/drm/radeon/radeon_mode.h   |   3 +-
 drivers/gpu/drm/radeon/si.c|   5 +
 drivers/gpu/drm/radeon/sid.h   |  59 +++
 15 files changed, 455 insertions(+), 62 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index da2a8e9..306364a 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
-   ci_dpm.o
+   ci_dpm.o dce6_afmt.o

 # add async DMA block
 radeon-y += \
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 092275d..dfac796 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -682,8 +682,6 @@ atombios_digital_setup(struct drm_encoder *encoder, int 
action)
 int
 atombios_get_encoder_mode(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = encoder->dev;
-   struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct drm_connector *connector;
struct radeon_connector *radeon_connector;
@@ -710,8 +708,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog 
works fine */
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-   radeon_audio &&
-   !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+   radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
return ATOM_ENCODER_MODE_DVI;
@@ -722,8 +719,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_HDMIA:
default:
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-   radeon_audio &&
-   !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+   radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
@@ -737,8 +733,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-radeon_audio &&
-!ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 183c164..53d60b4 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7117,6 +7117,10 @@ static int cik_startup(struct radeon_device *rdev)
return r;
}

+   r = dce6_audio_init(rdev);
+   if (r)
+   return r;
+
return 0;
 }

@@ -7162,6 +7166,7 @@ int cik_resume(struct radeon_device *rdev)
  */
 int cik_suspend(struct radeon_device *rdev)
 {
+   dce6_audio_fini(rdev);
radeon_vm_manager_fini(rdev);
cik_cp_enable(rdev, 

[PATCH 2/5] drm/radeon: use loop for initializing AFMT blocks

[Alex Deucher]

From: Rafa? Mi?ecki 

Signed-off-by: Rafa? Mi?ecki 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_display.c | 53 ++---
 1 file changed, 23 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index c2b67b4..31d9fbe 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1257,38 +1257,31 @@ static void radeon_afmt_init(struct radeon_device *rdev)
if (ASIC_IS_DCE6(rdev)) {
/* todo */
} else if (ASIC_IS_DCE4(rdev)) {
+   static uint32_t eg_offsets[] = {
+   EVERGREEN_CRTC0_REGISTER_OFFSET,
+   EVERGREEN_CRTC1_REGISTER_OFFSET,
+   EVERGREEN_CRTC2_REGISTER_OFFSET,
+   EVERGREEN_CRTC3_REGISTER_OFFSET,
+   EVERGREEN_CRTC4_REGISTER_OFFSET,
+   EVERGREEN_CRTC5_REGISTER_OFFSET,
+   };
+   int num_afmt;
+
/* DCE4/5 has 6 audio blocks tied to DIG encoders */
/* DCE4.1 has 2 audio blocks tied to DIG encoders */
-   rdev->mode_info.afmt[0] = kzalloc(sizeof(struct radeon_afmt), 
GFP_KERNEL);
-   if (rdev->mode_info.afmt[0]) {
-   rdev->mode_info.afmt[0]->offset = 
EVERGREEN_CRTC0_REGISTER_OFFSET;
-   rdev->mode_info.afmt[0]->id = 0;
-   }
-   rdev->mode_info.afmt[1] = kzalloc(sizeof(struct radeon_afmt), 
GFP_KERNEL);
-   if (rdev->mode_info.afmt[1]) {
-   rdev->mode_info.afmt[1]->offset = 
EVERGREEN_CRTC1_REGISTER_OFFSET;
-   rdev->mode_info.afmt[1]->id = 1;
-   }
-   if (!ASIC_IS_DCE41(rdev)) {
-   rdev->mode_info.afmt[2] = kzalloc(sizeof(struct 
radeon_afmt), GFP_KERNEL);
-   if (rdev->mode_info.afmt[2]) {
-   rdev->mode_info.afmt[2]->offset = 
EVERGREEN_CRTC2_REGISTER_OFFSET;
-   rdev->mode_info.afmt[2]->id = 2;
-   }
-   rdev->mode_info.afmt[3] = kzalloc(sizeof(struct 
radeon_afmt), GFP_KERNEL);
-   if (rdev->mode_info.afmt[3]) {
-   rdev->mode_info.afmt[3]->offset = 
EVERGREEN_CRTC3_REGISTER_OFFSET;
-   rdev->mode_info.afmt[3]->id = 3;
-   }
-   rdev->mode_info.afmt[4] = kzalloc(sizeof(struct 
radeon_afmt), GFP_KERNEL);
-   if (rdev->mode_info.afmt[4]) {
-   rdev->mode_info.afmt[4]->offset = 
EVERGREEN_CRTC4_REGISTER_OFFSET;
-   rdev->mode_info.afmt[4]->id = 4;
-   }
-   rdev->mode_info.afmt[5] = kzalloc(sizeof(struct 
radeon_afmt), GFP_KERNEL);
-   if (rdev->mode_info.afmt[5]) {
-   rdev->mode_info.afmt[5]->offset = 
EVERGREEN_CRTC5_REGISTER_OFFSET;
-   rdev->mode_info.afmt[5]->id = 5;
+   if (ASIC_IS_DCE5(rdev))
+   num_afmt = 6;
+   else if (ASIC_IS_DCE41(rdev))
+   num_afmt = 2;
+   else /* DCE4 */
+   num_afmt = 6;
+
+   BUG_ON(num_afmt > ARRAY_SIZE(eg_offsets));
+   for (i = 0; i < num_afmt; i++) {
+   rdev->mode_info.afmt[i] = kzalloc(sizeof(struct 
radeon_afmt), GFP_KERNEL);
+   if (rdev->mode_info.afmt[i]) {
+   rdev->mode_info.afmt[i]->offset = eg_offsets[i];
+   rdev->mode_info.afmt[i]->id = i;
}
}
} else if (ASIC_IS_DCE3(rdev)) {
-- 
1.8.3.1

[PATCH 1/5] drm/edid: add a helper function to extract the speaker allocation data block (v3)

[Alex Deucher]

This adds a helper function to extract the speaker allocation
data block from the EDID.  This data block describes what speakers
are present on the display device.

v2: update per Ville Syrj?l?'s comments
v3: fix copy/paste typo in memory allocation

Signed-off-by: Alex Deucher 
Reviewed-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_edid.c | 52 ++
 include/drm/drm_edid.h |  1 +
 2 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 70fc133..58b4882 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2735,6 +2735,58 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
**sads)
 EXPORT_SYMBOL(drm_edid_to_sad);

 /**
+ * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks 
from EDID
+ * @edid: EDID to parse
+ * @sadb: pointer to the speaker block
+ *
+ * Looks for CEA EDID block and extracts the Speaker Allocation Data Block 
from it.
+ * Note: returned pointer needs to be kfreed
+ *
+ * Return number of found Speaker Allocation Blocks or negative number on 
error.
+ */
+int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb)
+{
+   int count = 0;
+   int i, start, end, dbl;
+   const u8 *cea;
+
+   cea = drm_find_cea_extension(edid);
+   if (!cea) {
+   DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
+   return -ENOENT;
+   }
+
+   if (cea_revision(cea) < 3) {
+   DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
+   return -ENOTSUPP;
+   }
+
+   if (cea_db_offsets(cea, , )) {
+   DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
+   return -EPROTO;
+   }
+
+   for_each_cea_db(cea, i, start, end) {
+   const u8 *db = [i];
+
+   if (cea_db_tag(db) == SPEAKER_BLOCK) {
+   dbl = cea_db_payload_len(db);
+
+   /* Speaker Allocation Data Block */
+   if (dbl == 3) {
+   *sadb = kmalloc(dbl, GFP_KERNEL);
+   memcpy(*sadb, [1], dbl);
+   count = dbl;
+   break;
+   }
+   }
+   }
+
+   return count;
+}
+EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
+
+/**
  * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
  * @connector: connector associated with the HDMI/DP sink
  * @mode: the display mode
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index fc481fc..c76a129 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;

 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
+int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
 int drm_av_sync_delay(struct drm_connector *connector,
  struct drm_display_mode *mode);
 struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
-- 
1.8.3.1

[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)

[Alex Deucher]

On Thu, Aug 15, 2013 at 4:23 AM, Rafa? Mi?ecki  wrote:
> 2013/8/14 Alex Deucher :
>> +   /* program the speaker allocation */
>> +   tmp = RREG32_ENDPOINT(offset, 
>> AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
>> +   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
>> +   /* set HDMI mode */
>> +   tmp |= HDMI_CONNECTION;
>> +   if (sadb_count)
>> +   tmp |= SPEAKER_ALLOCATION(sadb[0]);
>> +   else
>> +   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
>> +   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, 
>> tmp);
>> +
>> +   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
>> +   u32 value = 0;
>> +   int j;
>> +
>> +   for (j = 0; j < sad_count; j++) {
>> +   struct cea_sad *sad = [j];
>> +
>> +   if (sad->format == eld_reg_to_type[i][1]) {
>> +   value = MAX_CHANNELS(sad->channels) |
>> +   DESCRIPTOR_BYTE_2(sad->byte2) |
>> +   SUPPORTED_FREQUENCIES(sad->freq);
>> +   if (sad->format == 
>> HDMI_AUDIO_CODING_TYPE_PCM)
>> +   value |= 
>> SUPPORTED_FREQUENCIES_STEREO(sad->freq);
>> +   break;
>> +   }
>> +   }
>> +   WREG32_ENDPOINT(offset, eld_reg_to_type[i][0], value);
>> +   }
>
> I hope this is my last questions I'm bothering you with... This is how
> fglrx does that part:
>
> WREG32(0x5e00, 0x0125);PIN_CONTROL_CHANNEL_SPEAKER
> WREG32(0x5e04, 0x00c1005f);PIN_CONTROL_CHANNEL_SPEAKER
>
> RREG32(0x000..05c); -> 0xAFMT_AUDIO_PACKET_CONTROL2
> WREG32(0x000..05c, 0xff00);AFMT_AUDIO_PACKET_CONTROL2
>
> WREG32(0x5e00, 0x0027);0x27 was 0x5f80 on Evergreen
> RREG32(0x5e04); -> 0x0x27 was 0x5f80 on Evergreen
>
> WREG32(0x5e00, 0x0127);0x27 was 0x5f80
> WREG32(0x5e04, 0x0040);0x27 was 0x5f80
>
> WREG32(0x5e00, 0x000c3128);DESCRIPTOR0
> WREG32(0x5e04, 0x7f077f07);DESCRIPTOR0
>
> The difference is that between setting PIN_CONTROL_CHANNEL_SPEAKER and
> DESCRIPTOR0 fglrx enables audio channels (see
> AFMT_AUDIO_PACKET_CONTROL2 and 0xff00).
>
> Do you think it does matter? Or can we ignore the order and do it your way?

Not sure.  I'll go ahead and apply your patch.

Alex

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
> On 14/08/2013 05:02, Pali Roh?r wrote:
> > On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
> >> On 13/08/2013 09:53, Pali Roh?r wrote:
> >>> On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
> > 
> > wrote:
> >>>> On 13/08/2013 09:23, Pali Roh?r wrote:
> >>>>> On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
> >>>>   ...
> >>>> 
> >>>> You can check the temperature by running nvidia-settings.
> >>>> If you can't see the temperature in it, then nvidia
> >>>> doesn't support it on your card and
> >>>> I'm not sure we should :s
> >>>> 
> >>>> Thanks for the vbios you sent me in private. For the
> >>>> others, the reason why he doesn't have temperature
> >>>> anymore is because his vbios lacks sensor calibration
> >>>> values.
> >>> 
> >>> In nvidia-settings tab "GPU 0 - (GeForce 6600 GT)" -->
> >>> "Thermal Settings" is:
> >>> 
> >>> Thermal Sensor Information:
> >>> ID: 0
> >>> Target: GPU
> >>> Provider: GPU Internal
> >>> Temperature: 70 C (now)
> >>> 
> >>> I looked in Windows program SpeedFan. It found Nvidia PCI
> >>> card and reported "GPU Temp" about 68-70 C. So it looks
> >>> like both nvidia driver and windows SpeedFan program
> >>> reading same values.
> >> 
> >> Great, I'll cook you a patch in a bit and you'll see what
> >> the temperature is like. It won't be perfectly accurate
> >> but there is some kind of default for nvidia cards of this
> >> generation.
> > 
> > Ok, send me patch and I can try it if it will work and
> > report similar values as windows or nvidia driver.
> 
> Sorry for the late answer.
> 
> Please test this patch. Be aware that temperature with nouveau
> will be higher than with the blob.
> I only want to see if nouveau reports a temperature.
> 
> The only way to be sure if the values are good-enough would be
> to use the blob and run:
> nvapeek 0x15b0
> Please send me the result along with the temperature reported
> by nvidia at the time of the peek.
> 
> Martin
> 
> PS: This patch has only be compile-tested, I don't have access
> to an nv4x right now.

Hello,

now after patch nouveau report temperature:

$ sensors
...
nouveau-pci-0500
Adapter: PCI adapter
temp1:+63.0?C  (high = +95.0?C, hyst =  +3.0?C)
   (crit = +145.0?C, hyst =  +2.0?C)
   (emerg = +135.0?C, hyst =  +5.0?C)
...

I found that nvidia binary driver has command line utility 
nvidia-smi which report same temperature as X utility nvidia-
settings. So I will use nvidia-smi (if it is OK).

And after reboot nvidia report another temperature value:

$ nvidia-smi -q -d TEMPERATURE
...
GPU :05:00.0
Temperature
Gpu : 70 C

Immediately I called nvapeek command:

$ nvapeek 0x15b0
15b0: 108e

So value reported by nouveau is lower than value reported by 
nvidia binary driver.

I wait some some and started nvidia-smi and nvapeek again, here 
are results:

$ nvidia-smi -q -d TEMPERATURE
...
GPU :05:00.0
Temperature
Gpu : 67 C

$ nvapeek 0x15b0
15b0: 108e

So it looks like that nvapeek returning always same value and 
does not depends on temperature... It is OK?

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130815/b6603cce/attachment-0001.pgp>

[RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Rob Clark]

On Thu, Aug 15, 2013 at 7:16 AM, Maarten Lankhorst
 wrote:
> Op 12-08-13 17:43, Rob Clark schreef:
>> On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
>>  wrote:
>>> +
[snip]
>>> +/**
>>> + * fence_add_callback - add a callback to be called when the fence
>>> + * is signaled
>>> + * @fence: [in]the fence to wait on
>>> + * @cb:[in]the callback to register
>>> + * @func:  [in]the function to call
>>> + * @priv:  [in]the argument to pass to function
>>> + *
>>> + * cb will be initialized by fence_add_callback, no initialization
>>> + * by the caller is required. Any number of callbacks can be registered
>>> + * to a fence, but a callback can only be registered to one fence at a 
>>> time.
>>> + *
>>> + * Note that the callback can be called from an atomic context.  If
>>> + * fence is already signaled, this function will return -ENOENT (and
>>> + * *not* call the callback)
>>> + *
>>> + * Add a software callback to the fence. Same restrictions apply to
>>> + * refcount as it does to fence_wait, however the caller doesn't need to
>>> + * keep a refcount to fence afterwards: when software access is enabled,
>>> + * the creator of the fence is required to keep the fence alive until
>>> + * after it signals with fence_signal. The callback itself can be called
>>> + * from irq context.
>>> + *
>>> + */
>>> +int fence_add_callback(struct fence *fence, struct fence_cb *cb,
>>> +  fence_func_t func, void *priv)
>>> +{
>>> +   unsigned long flags;
>>> +   int ret = 0;
>>> +   bool was_set;
>>> +
>>> +   if (WARN_ON(!fence || !func))
>>> +   return -EINVAL;
>>> +
>>> +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
>>> +   return -ENOENT;
>>> +
>>> +   spin_lock_irqsave(fence->lock, flags);
>>> +
>>> +   was_set = test_and_set_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, 
>>> >flags);
>>> +
>>> +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
>>> +   ret = -ENOENT;
>>> +   else if (!was_set && !fence->ops->enable_signaling(fence)) {
>>> +   __fence_signal(fence);
>>> +   ret = -ENOENT;
>>> +   }
>>> +
>>> +   if (!ret) {
>>> +   cb->func = func;
>>> +   cb->priv = priv;
>>> +   list_add_tail(>node, >cb_list);
>> since the user is providing the 'struct fence_cb', why not drop the
>> priv & func args, and have some cb-initialize macro, ie.
>>
>> INIT_FENCE_CB(>fence, cbfxn);
>>
>> and I guess we can just drop priv and let the user embed fence in
>> whatever structure they like.  Ie. make it look a bit how work_struct
>> works.
> I don't mind killing priv. But a INIT_FENCE_CB macro is silly, when all it 
> would do is set cb->func.
> So passing it as  an argument to fence_add_callback is fine, unless you have 
> a better reason to
> do so.
>
> INIT_WORK seems to have a bit more initialization than us, it seems work can 
> be more complicated
> than callbacks, because the callbacks can only be called once and work can be 
> rescheduled multiple times.

yeah, INIT_WORK does more.. although maybe some day we want
INIT_FENCE_CB to do more (ie. if we add some debug features to help
catch misuse of fence/fence-cb's).  And if nothing else, having it
look a bit like other constructs that we have in the kernel seems
useful.  And with my point below, you'd want INIT_FENCE_CB to do a
INIT_LIST_HEAD(), so it is (very) slightly more than just setting the
fxn ptr.

>> maybe also, if (!list_empty(>node) return -EBUSY?
> I think checking for list_empty(cb->node) is a terrible idea. This is no 
> different from any other list corruption,
> and it's a programming error. Not a runtime error. :-)

I was thinking for crtc and page-flip, embed the fence_cb in the crtc.
 You should only use the cb once at a time, but in this case you might
want to re-use it for the next page flip.  Having something to catch
cb mis-use in this sort of scenario seems useful.

maybe how I am thinking to use fence_cb is not quite what you had in
mind.  I'm not sure.  I was trying to think how I could just directly
use fence/fence_cb in msm for everything (imported dmabuf or just
regular 'ol gem buffers).

> cb->node.next/prev may be NULL, which would fail with this check. The 
> contents of cb->node are undefined
> before fence_add_callback is called. Calling fence_remove_callback on a fence 
> that hasn't been added is
> undefined too. Calling fence_remove_callback works, but I'm thinking of 
> changing the list_del_init to list_del,
> which would make calling fence_remove_callback twice a fatal error if 
> CONFIG_DEBUG_LIST is enabled,
> and a possible memory corruption otherwise.
>>> ...
>>> +
[snip]
>>> +
>>> +/**
>>> + * fence context counter: each execution context should have its own
>>> + * fence context, this allows checking if fences belong to the same
>>> + * context or not. One device can have multiple separate contexts,
>>> + * and they're used if some 

[Bug 66805] [radeonsi] half life 2 base games are segfaulting

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

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

Laurent carlier  changed:

   What|Removed |Added

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

--- Comment #25 from Laurent carlier  ---
(In reply to comment #24)
> This should be fixed now.  Can you try they latest versions of llvm and mesa?

Yes, that's fixing the problem, so 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/20130815/5cb57524/attachment.html>

[PATCH 3/3] drm: exynos: hdmi: Add dt support for hdmiphy settings

[Shirish S]

This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.

Signed-off-by: Shirish S 
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |   18 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  191 +++-
 2 files changed, 80 insertions(+), 129 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983b..fb8a643 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -12,7 +12,11 @@ Required properties:
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
-
+- hdmiphy-confs: following information about the hdmiphy conf settings.
+a) "nr-confs" specifies the number of pixel clocks supported.
+   b) "confX: confX" specifies the phy configuration settings,
+   "clock-frequency" specifies the pixel clock
+   "conf" specifies the setting for the corresponding pixel clock
 Example:

hdmi {
@@ -20,4 +24,16 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = < 7 1>;
+   hdmiphy-confs {
+   nr-confs = <1>;
+   conf0: conf0 {
+   clock-frequency = <2520>;
+   conf =  /bits/ 8 <
+   0x01 0x51 0x2A 0x75 0x40 0x01 0x00 0x08
+   0x82 0x80 0xfc 0xd8 0x45 0xa0 0xac 0x80
+   0x08 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xf4 0x24 0x00 0x00 0x00 0x01 0x80
+   >;
+   };
+   }
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2f5c694..cb929ff 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -179,6 +179,11 @@ struct hdmi_conf_regs {
} conf;
 };

+struct hdmiphy_config {
+   int pixel_clock;
+   u8 conf[32];
+};
+
 struct hdmi_context {
struct device   *dev;
struct drm_device   *drm_dev;
@@ -199,16 +204,14 @@ struct hdmi_context {

struct hdmi_resources   res;

+   struct hdmiphy_config   *confs;
+   int nr_confs;
+
int hpd_gpio;

enum hdmi_type  type;
 };

-struct hdmiphy_config {
-   int pixel_clock;
-   u8 conf[32];
-};
-
 /* list of phy config settings */
 static const struct hdmiphy_config hdmiphy_v13_configs[] = {
{
@@ -258,126 +261,6 @@ static const struct hdmiphy_config hdmiphy_v13_configs[] 
= {
},
 };

-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
-   {
-   .pixel_clock = 2520,
-   .conf = {
-   0x01, 0x51, 0x2A, 0x75, 0x40, 0x01, 0x00, 0x08,
-   0x82, 0x80, 0xfc, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xf4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
-   },
-   },
-   {
-   .pixel_clock = 2700,
-   .conf = {
-   0x01, 0xd1, 0x22, 0x51, 0x40, 0x08, 0xfc, 0x20,
-   0x98, 0xa0, 0xcb, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xe4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
-   },
-   },
-   {
-   .pixel_clock = 27027000,
-   .conf = {
-   0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
-   0x43, 0xa0, 0x0e, 0xd9, 0x45, 0xa0, 0xac, 0x80,
-   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xe3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x00,
-   },
-   },
-   {
-   .pixel_clock = 3600,
-   .conf = {
-   0x01, 0x51, 0x2d, 0x55, 0x40, 0x01, 0x00, 0x08,
-   0x82, 0x80, 0x0e, 0xd9, 0x45, 0xa0, 0xac, 0x80,
-   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xab, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
-   },
-   },
-   {
-   .pixel_clock = 4000,
-   .conf = {
-   0x01, 0x51, 0x32, 0x55, 0x40, 0x01, 0x00, 0x08,
-   0x82, 0x80, 0x2c, 0xd9, 0x45, 0xa0, 0xac, 0x80,
-   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0x9a, 0x24, 

[PATCH 2/3] ARM: dts: arndale: Add hdmi phy settings

[Shirish S]

This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.

Signed-off-by: Shirish S 
---
 arch/arm/boot/dts/exynos5250-arndale.dts |  120 ++
 1 file changed, 120 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index abc7272..59db48a 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -424,6 +424,126 @@

hdmi {
hpd-gpio = < 7 2>;
+   hdmiphy-confs {
+   nr-confs = <13>;
+   conf0: conf0 {
+   clock-frequency = <2520>;
+   conf =  /bits/ 8 <
+   0x01 0x51 0x2A 0x75 0x40 0x01 0x00 0x08
+   0x82 0x80 0xfc 0xd8 0x45 0xa0 0xac 0x80
+   0x08 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xf4 0x24 0x00 0x00 0x00 0x01 0x80
+   >;
+   };
+   conf1: conf1 {
+   clock-frequency = <2700>;
+   conf = /bits/ 8  <
+   0x01 0xd1 0x22 0x51 0x40 0x08 0xfc 0x20
+   0x98 0xa0 0xcb 0xd8 0x45 0xa0 0xac 0x80
+   0x06 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xe4 0x24 0x00 0x00 0x00 0x01 0x80
+   >;
+   };
+   conf2: conf2 {
+   clock-frequency = <27027000>;
+   conf = /bits/ 8  <
+   0x01 0xd1 0x2d 0x72 0x40 0x64 0x12 0x08
+   0x43 0xa0 0x0e 0xd9 0x45 0xa0 0xac 0x80
+   0x08 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xe3 0x24 0x00 0x00 0x00 0x01 0x00
+   >;
+   };
+   conf3: conf3 {
+   clock-frequency = <3600>;
+   conf =  /bits/ 8 <
+   0x01 0x51 0x2d 0x55 0x40 0x01 0x00 0x08
+   0x82 0x80 0x0e 0xd9 0x45 0xa0 0xac 0x80
+   0x08 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xab 0x24 0x00 0x00 0x00 0x01 0x80
+   >;
+   };
+   conf4: conf4 {
+   clock-frequency = <4000>;
+   conf = /bits/ 8  <
+   0x01 0x51 0x32 0x55 0x40 0x01 0x00 0x08
+   0x82 0x80 0x2c 0xd9 0x45 0xa0 0xac 0x80
+   0x08 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0x9a 0x24 0x00 0x00 0x00 0x01 0x80
+   >;
+   };
+   conf5: conf5 {
+   clock-frequency = <6500>;
+   conf = /bits/ 8  <
+   0x01 0xd1 0x36 0x34 0x40 0x1e 0x0a 0x08
+   0x82 0xa0 0x45 0xd9 0x45 0xa0 0xac 0x80
+   0x08 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xbd 0x24 0x01 0x00 0x00 0x01 0x80
+   >;
+   };
+   conf6: conf6 {
+   clock-frequency = <74176000>;
+   conf = /bits/ 8  <
+   0x01 0xd1 0x3e 0x35 0x40 0x5b 0xde 0x08
+   0x82 0xa0 0x73 0xd9 0x45 0xa0 0xac 0x80
+   0x56 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xa6 0x24 0x01 0x00 0x00 0x01 0x80
+   >;
+   };
+   conf7: conf7 {
+   clock-frequency = <7425>;
+   conf = /bits/ 8  <
+   0x01 0xd1 0x1f 0x10 0x40 0x40 0xf8 0x08
+   0x81 0xa0 0xba 0xd8 0x45 0xa0 0xac 0x80
+   0x3c 0x80 0x11 0x04 0x02 0x22 0x44 0x86
+   0x54 0xa5 0x24 0x01 0x00 0x00 0x01 0x00
+   >;
+   };
+   conf8: conf8 {
+