[bisected] nouveau: "Failed to idle channel x" after resume

[Martin Nyhus]

Hi,
after resuming from suspend nouveau starts writing Failed to idle
channel x (where x is 2 or 3) to the log and X appears to stop and then
restart only to stop again. Starting Firefox after resuming triggers the
bugs every time, and bisecting leads to 03bd6efa ("drm/nv50/fifo: use
hardware channel kickoff functionality").

$ grep -i nouveau .config
CONFIG_DRM_NOUVEAU=y
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
# CONFIG_DRM_NOUVEAU_DEBUG is not set

Relevant part of the log (running v3.5-rc2-15-g4e3c8a1):
[   79.040710] PM: resume of devices complete after 1952.375 msecs
[   79.041735] PM: Finishing wakeup.
[   79.064052] Restarting tasks ... done.
[   79.064064] video LNXVIDEO:00: Restoring backlight state
[   79.645442] tg3 :09:00.0: irq 47 for MSI/MSI-X
[   79.707851] IPv6: ADDRCONF(NETDEV_UP): p3p1: link is not ready
[   81.288510] tg3 :09:00.0: p3p1: Link is up at 100 Mbps, full duplex
[   81.288510] tg3 :09:00.0: p3p1: Flow control is on for TX and on for RX
[   81.289824] IPv6: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
[  376.646417] [drm] nouveau :01:00.0: PFIFO: channel 4 unload timeout
[  378.649010] [sched_delayed] sched: RT throttling activated
[  384.677024] [drm] nouveau :01:00.0: Failed to idle channel 2.
[  384.678012] [drm] nouveau :01:00.0: PFIFO: channel 2 unload timeout
[  389.685024] [drm] nouveau :01:00.0: Failed to idle channel 3.
[  389.686012] [drm] nouveau :01:00.0: PFIFO: channel 3 unload timeout
[  401.534024] [drm] nouveau :01:00.0: Failed to idle channel 2.
[  401.535012] [drm] nouveau :01:00.0: PFIFO: channel 2 unload timeout
...
[  456.688024] [drm] nouveau :01:00.0: Failed to idle channel 3.
[  456.689013] [drm] nouveau :01:00.0: PFIFO: channel 3 unload timeout
[  468.372025] [drm] nouveau :01:00.0: Failed to idle channel 2.
[  468.373013] [drm] nouveau :01:00.0: PFIFO: channel 2 unload timeout

No screens after (WW) Falling back to old probe method for modesetting

[Rafał Miłecki]

2012/6/11 Rafa? Mi?ecki :
> I'm trying to switch from fbdev to modesetting for my AMD Southern
> Islands VERDE card. Of course I've KMS running just fine, radeon
> module loads and sets correct resolution, dmesg looks alright
>
> Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU
> the driver doesn't provide any screens/modes. It looks like this:
> (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
> (WW) Falling back to old probe method for modesetting
> (II) UnloadModule: "modesetting"
> (II) Unloading modesetting
> (EE) Screen(s) found, but none have a usable configuration.
>
> Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm
> using xf86-video-modesetting from today's git. Any patch/trick to
> debug this issue?

Attaching Xorg.0.logs

-- 
Rafa?
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.modesettings.log
Type: application/octet-stream
Size: 6253 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120611/fbf6a401/attachment-0002.obj>
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.fbdev.log
Type: application/octet-stream
Size: 28880 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120611/fbf6a401/attachment-0003.obj>

No screens after (WW) Falling back to old probe method for modesetting

[Rafał Miłecki]

I'm trying to switch from fbdev to modesetting for my AMD Southern
Islands VERDE card. Of course I've KMS running just fine, radeon
module loads and sets correct resolution, dmesg looks alright

Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU
the driver doesn't provide any screens/modes. It looks like this:
(II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
(WW) Falling back to old probe method for modesetting
(II) UnloadModule: "modesetting"
(II) Unloading modesetting
(EE) Screen(s) found, but none have a usable configuration.

Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm
using xf86-video-modesetting from today's git. Any patch/trick to
debug this issue?

-- 
Rafa?

edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Mon, Jun 11, 2012 at 09:20:00AM +0200, Daniel Vetter wrote:
> On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
> > > On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> > > > On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter  
> > > > wrote:
> > > > >
> > > > > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > > > > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
> > > > 
> > > > Hmm. Now *I* can't reproduce it either.
> > > > 
> > > > I have updated my system in the meantime, so maybe this is related to
> > > > that. However, I suspect it's more likely that it's some race
> > > > condition, because when I got it, I got a *lot* of it, but they were
> > > > all very tightly bunched together:
> > > > 
> > > >  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > > 
> > > > ie that's 12 of those warnings (each of them with that huge backtrace
> > > > etc), but they are all within 0.03 seconds of each other. So I suspect
> > > > it needs to hit some particular timing window, and I was just
> > > > (un)lucky.
> > > > 
> > > > Because when I try it now with DRM debugging, I can't hit it. And just
> > > > to make sure, I re-did the test without debugging too (in case the
> > > > debugging would have changed timing), but can't reproduce it that way
> > > > either.
> > > 
> > > Meh, I've been totally blind. Note to self: Next time around actually look
> > > at the backtrace. And I dunno how that escaped our dear QA that long ...
> > 
> > Even more meh, this patch might actually work a bit better.
> > 
> > /me doesn't have an edp panel to test this
> 
> v3 is tested by our QA and hopefully works. I'll send it to Dave for
> -fixes in a few days, attached below just in case. Please yell if this
> doesn't fix your edp dmesg spam.

... and that one died in review. v4 is in the works and going through QA
atm.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Boszormenyi Zoltan]

Yay, it works on HD6570 (TURKS)! Thanks!

2012-06-11 14:11 keltez?ssel, Christian K?nig ?rta:
> On 11.06.2012 12:34, Rafa? Mi?ecki wrote:
>> After recent changes HDMI code is ready to be enabled on DCE5. This
>> patch just changes conditions to execute already present code on DCE5.
>>
>> Signed-off-by: Rafa? Mi?ecki
>> Reviewed-by: Alex Deucher
> Tested-by: Christian K?nig 

Tested-by: Zolt?n B?sz?rm?nyi 

>
>> ---
>> V2: enable audio engine on Cayman (it uses different startup function).
>> ---
>>   drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
>>   drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
>>   drivers/gpu/drm/radeon/ni.c|5 +
>>   drivers/gpu/drm/radeon/r600_audio.c|2 +-
>>   drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
>>   5 files changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index e7b1ec5..486ccdf 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
>> *encoder,
>>
>>   if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
>>   r600_hdmi_enable(encoder);
>> -if (ASIC_IS_DCE4(rdev))
>> +if (ASIC_IS_DCE6(rdev))
>> +; /* TODO (use pointers instead of if-s?) */
>> +else if (ASIC_IS_DCE4(rdev))
>>   evergreen_hdmi_setmode(encoder, adjusted_mode);
>>   else
>>   r600_hdmi_setmode(encoder, adjusted_mode);
>> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
>> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
>> index a51f880..65c5416 100644
>> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
>> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
>> @@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
>> struct 
>> drm_display_mode
>>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>>   uint32_t offset;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> -return;
>> -
>>   /* Silent, r600_hdmi_enable will raise WARN for us */
>>   if (!dig->afmt->enabled)
>>   return;
>> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
>> index 3df4efa..b65fcae 100644
>> --- a/drivers/gpu/drm/radeon/ni.c
>> +++ b/drivers/gpu/drm/radeon/ni.c
>> @@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
>>   if (r)
>>   return r;
>>
>> +r = r600_audio_init(rdev);
>> +if (r)
>> +return r;
>> +
>>   return 0;
>>   }
>>
>> @@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
>>
>>   int cayman_suspend(struct radeon_device *rdev)
>>   {
>> +r600_audio_fini(rdev);
>>   /* FIXME: we should wait for ring to be empty */
>>   radeon_ib_pool_suspend(rdev);
>>   radeon_vm_manager_suspend(rdev);
>> diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
>> b/drivers/gpu/drm/radeon/r600_audio.c
>> index 7479a5c..79b5591 100644
>> --- a/drivers/gpu/drm/radeon/r600_audio.c
>> +++ b/drivers/gpu/drm/radeon/r600_audio.c
>> @@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
>>*/
>>   static int r600_audio_chipset_supported(struct radeon_device *rdev)
>>   {
>> -return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE5(rdev))
>> +return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE6(rdev))
>>   || rdev->family == CHIP_RS600
>>   || rdev->family == CHIP_RS690
>>   || rdev->family == CHIP_RS740;
>> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
>> b/drivers/gpu/drm/radeon/r600_hdmi.c
>> index 969c275..82a0a4c 100644
>> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
>> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
>> @@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
>> struct 
>> drm_display_mode *mod
>>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>>   uint32_t offset;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> -return;
>> -
>>   /* Silent, r600_hdmi_enable will raise WARN for us */
>>   if (!dig->afmt->enabled)
>>   return;
>> @@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
>>   uint32_t offset;
>>   u32 hdmi;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> +if (ASIC_IS_DCE6(rdev))
>>   return;
>>
>>   /* Silent, r600_hdmi_enable will raise WARN for us */
>> @@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
>>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>>   uint32_t offset;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> +if (ASIC_IS_DCE6(rdev))
>>   return;
>>
>>   /* Called for ATOM_ENCODER_MODE_HDMI only */
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50980] New: [r300g, bisected] WebGL cars demo crash (r300_emit.c:865:r300_emit_vertex_arrays: Assertion `(buf)' failed)

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

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

 Bug #: 50980
   Summary: [r300g, bisected] WebGL cars demo crash
(r300_emit.c:865:r300_emit_vertex_arrays: Assertion
`(buf)' failed)
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
   URL: http://www.chromeexperiments.com/detail/webgl-cars/?f=
webgl
OS/Version: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: pavel.ondracka at email.cz
CC: maraeo at gmail.com


Created attachment 62902
  --> https://bugs.freedesktop.org/attachment.cgi?id=62902
backtrace

WebGL cars demo crash with r300_emit.c:865:r300_emit_vertex_arrays: Assertion
`(buf)' failed, full backtrace attached.

784dd51198433e5c299da4a7742c68d21d68d1c1 is the first bad commit
commit 784dd51198433e5c299da4a7742c68d21d68d1c1
Author: Marek Ol??k 
Date:   Mon Apr 16 03:34:22 2012 +0200

mesa,vbo: properly detect when vertex arrays need to be recalculated

This moves the RebindArrays flag into the vbo module, consolidates the
code,
and adds missing vbo_draw_method calls.

Also with this change, the vertex arrays are not needlessly recalculated
twice.
The issue with the old code was:
- If recalculate_input_bindings updates vp_varying_inputs, _NEW_ARRAY is
set.
- _mesa_update_state is called and the vp_varying_inputs change causes
  regeneration of the fixed-function shaders, which also sets _NEW_PROGRAM.
- The occurence of either _NEW_ARRAY or _NEW_PROGRAM sets
  the recalculate_inputs flag to TRUE again.
- The new code sets the flag to FALSE after the second _mesa_update_state,
  because there can't possibly be any change which would require
recalculating
  the arrays.

Reviewed-by: Brian Paul 
Reviewed-by: Mathias Fr?hlich 


GPU:RV530
Kernel: 3.4.0-1.fc17.i686
Firefox 13.0

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm sis: initialize object_idr

[Németh Márton]

From: M?rton N?meth 

The filed object_idr of struct drm_sis_private was introduced with
commit 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6de8a748881f1cd9d795454da2b6db616d5ca3d7
 .

The idr_init(&dev->object_name_idr) is called instead of
idr_init(&dev_priv->object_idr) by mistake, leaving object_idr
uninitialized. Correct this.

This patch was not tested because of lack of hardware.

Signed-off-by: M?rton N?meth 
Cc: Daniel Vetter 
---
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
index 30d98d1..dd14cd1 100644
--- a/drivers/gpu/drm/sis/sis_drv.c
+++ b/drivers/gpu/drm/sis/sis_drv.c
@@ -47,9 +47,9 @@ static int sis_driver_load(struct drm_device *dev, unsigned 
long chipset)
if (dev_priv == NULL)
return -ENOMEM;

+   idr_init(&dev_priv->object_idr);
dev->dev_private = (void *)dev_priv;
dev_priv->chipset = chipset;
-   idr_init(&dev->object_name_idr);

return 0;
 }

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Mon, 2012-06-11 at 09:51 -0500, Gross, Andy wrote:
> Tomi,
> 
> 
> So at this point, are you OK with deferring a split of the DMM until
> it necessary to do so (if ever)?  I'd like to get this patch in so
> that people have a working omapdrm device when they enable the config
> options.

Yes, I'm ok with it.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120611/7053e1e6/attachment.pgp>

[PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Andre Heider]

On Mon, Jun 11, 2012 at 12:34 PM, Rafa? Mi?ecki  wrote:
> After recent changes HDMI code is ready to be enabled on DCE5. This
> patch just changes conditions to execute already present code on DCE5.
>
> Signed-off-by: Rafa? Mi?ecki 
> Reviewed-by: Alex Deucher 
> ---
> V2: enable audio engine on Cayman (it uses different startup function).
> ---
> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?4 +++-
> ?drivers/gpu/drm/radeon/evergreen_hdmi.c ? ?| ? ?3 ---
> ?drivers/gpu/drm/radeon/ni.c ? ? ? ? ? ? ? ?| ? ?5 +
> ?drivers/gpu/drm/radeon/r600_audio.c ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/r600_hdmi.c ? ? ? ? | ? ?7 ++-
> ?5 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index e7b1ec5..486ccdf 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
> *encoder,
>
> ? ? ? ?if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
> ? ? ? ? ? ? ? ?r600_hdmi_enable(encoder);
> - ? ? ? ? ? ? ? if (ASIC_IS_DCE4(rdev))
> + ? ? ? ? ? ? ? if (ASIC_IS_DCE6(rdev))
> + ? ? ? ? ? ? ? ? ? ? ? ; /* TODO (use pointers instead of if-s?) */
> + ? ? ? ? ? ? ? else if (ASIC_IS_DCE4(rdev))
> ? ? ? ? ? ? ? ? ? ? ? ?evergreen_hdmi_setmode(encoder, adjusted_mode);
> ? ? ? ? ? ? ? ?else
> ? ? ? ? ? ? ? ? ? ? ? ?r600_hdmi_setmode(encoder, adjusted_mode);
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index a51f880..65c5416 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
> struct drm_display_mode
> ? ? ? ?struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> ? ? ? ?uint32_t offset;
>
> - ? ? ? if (ASIC_IS_DCE5(rdev))
> - ? ? ? ? ? ? ? return;
> -
> ? ? ? ?/* Silent, r600_hdmi_enable will raise WARN for us */
> ? ? ? ?if (!dig->afmt->enabled)
> ? ? ? ? ? ? ? ?return;
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 3df4efa..b65fcae 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
> ? ? ? ?if (r)
> ? ? ? ? ? ? ? ?return r;
>
> + ? ? ? r = r600_audio_init(rdev);
> + ? ? ? if (r)
> + ? ? ? ? ? ? ? return r;
> +
> ? ? ? ?return 0;
> ?}
>
> @@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
>
> ?int cayman_suspend(struct radeon_device *rdev)
> ?{
> + ? ? ? r600_audio_fini(rdev);
> ? ? ? ?/* FIXME: we should wait for ring to be empty */
> ? ? ? ?radeon_ib_pool_suspend(rdev);
> ? ? ? ?radeon_vm_manager_suspend(rdev);
> diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
> b/drivers/gpu/drm/radeon/r600_audio.c
> index 7479a5c..79b5591 100644
> --- a/drivers/gpu/drm/radeon/r600_audio.c
> +++ b/drivers/gpu/drm/radeon/r600_audio.c
> @@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
> ?*/
> ?static int r600_audio_chipset_supported(struct radeon_device *rdev)
> ?{
> - ? ? ? return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE5(rdev))
> + ? ? ? return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE6(rdev))
> ? ? ? ? ? ? ? ?|| rdev->family == CHIP_RS600
> ? ? ? ? ? ? ? ?|| rdev->family == CHIP_RS690
> ? ? ? ? ? ? ? ?|| rdev->family == CHIP_RS740;
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index 969c275..82a0a4c 100644
> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
> @@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
> struct drm_display_mode *mod
> ? ? ? ?struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> ? ? ? ?uint32_t offset;
>
> - ? ? ? if (ASIC_IS_DCE5(rdev))
> - ? ? ? ? ? ? ? return;
> -
> ? ? ? ?/* Silent, r600_hdmi_enable will raise WARN for us */
> ? ? ? ?if (!dig->afmt->enabled)
> ? ? ? ? ? ? ? ?return;
> @@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
> ? ? ? ?uint32_t offset;
> ? ? ? ?u32 hdmi;
>
> - ? ? ? if (ASIC_IS_DCE5(rdev))
> + ? ? ? if (ASIC_IS_DCE6(rdev))
> ? ? ? ? ? ? ? ?return;
>
> ? ? ? ?/* Silent, r600_hdmi_enable will raise WARN for us */
> @@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
> ? ? ? ?struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> ? ? ? ?uint32_t offset;
>
> - ? ? ? if (ASIC_IS_DCE5(rdev))
> + ? ? ? if (ASIC_IS_DCE6(rdev))
> ? ? ? ? ? ? ? ?return;
>
> ? ? ? ?/* Called for ATOM_ENCODER_MODE_HDMI only */
> --
> 1.7.7

Woot, got sound on BARTS connected to a Onkyo TX-SR674E, thanks alot!

Tested-by: Andre Heider 

[Bug 47475] Stellarium crasch when using pan/zoom

[bugzilla-daemon]

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

Eric Anholt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Eric Anholt  2012-06-11 16:26:25 UTC ---
For this error:
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=1022,
height=563, depth=1)

The app is trying to use NPOT textures on a driver that only exposes support
for rectangle textures (which have a bunch of limitations).  That's an app bug.
 There's very little of this kind of hardware left, so app bugs related to it
are not surprising.

The assertion failure looks like the issue fixed in:

commit 33b07893e92dcee495908c549be872887096c894
Author: Chris Wilson 
Date:   Wed Nov 9 22:21:16 2011 +

i830: Compute initial number of vertices from remaining batch space

commit 024ece7523f1735d2fca0067c0a3bdcf53fde8f9
Author: Kurt Roeckx 
Date:   Fri Mar 2 15:34:45 2012 -0800

i915: Compute maximum number of verts using the actual batchbuffer size.

so I'm closing it for that.  If it's still around on Mesa 8.0 or master, please
reopen this bug or make a new one, hopefully with a backtrace from gdb at the
assert so we can find what's going on.

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

[Bug 47475] Stellarium crasch when using pan/zoom

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

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

Eric Anholt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Eric Anholt  2012-06-11 16:26:25 UTC ---
For this error:
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(level=0, width=1022,
height=563, depth=1)

The app is trying to use NPOT textures on a driver that only exposes support
for rectangle textures (which have a bunch of limitations).  That's an app bug.
 There's very little of this kind of hardware left, so app bugs related to it
are not surprising.

The assertion failure looks like the issue fixed in:

commit 33b07893e92dcee495908c549be872887096c894
Author: Chris Wilson 
Date:   Wed Nov 9 22:21:16 2011 +

i830: Compute initial number of vertices from remaining batch space

commit 024ece7523f1735d2fca0067c0a3bdcf53fde8f9
Author: Kurt Roeckx 
Date:   Fri Mar 2 15:34:45 2012 -0800

i915: Compute maximum number of verts using the actual batchbuffer size.

so I'm closing it for that.  If it's still around on Mesa 8.0 or master, please
reopen this bug or make a new one, hopefully with a backtrace from gdb at the
assert so we can find what's going on.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Subash Patel]

Hi Laurent, Tomasz,

On 06/10/2012 11:28 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Friday 08 June 2012 16:31:31 Tomasz Stanislawski wrote:
>> Hi Laurent and Subash,
>>
>> I confirm the issue found by Subash. The function vb2_dc_kaddr_to_pages does
>> fail for some occasions. The failures are rather strange like 'got 95 of
>> 150 pages'. It took me some time to find the reason of the problem.
>>
>> I found that dma_alloc_coherent for iommu an ARM does use ioremap_page_range
>> to map a buffer to the kernel space. The mapping is done by updating the
>> page-table.
>>
>> The problem is that any process has a different first-level page-table. The
>> ioremap_page_range updates only the table for init process. The PT present
>> in current->mm shares a majority of entries of 1st-level PT at kernel range
>> (above 0xc000) but *not all*. That is why vb2_dc_kaddr_to_pages worked
>> for small buffers and occasionally failed for larger buffers.
>>
>> I found two ways to fix this problem.
>> a) use&init_mm instead of current->mm while creating an artificial vma
>> b) access the dma memory by calling
>> *((volatile int *)kaddr) = 0;
>> before calling follow_pfn
>> This way a fault is generated and the PT is
>> updated by copying entries from init_mm.
>>
>> What do you think about presented solutions?
>
> Just to be sure, this is a hack until dma_get_sgtable is available, and it
> won't make it to mainline, right ?  In that case using init_mm seem easier.
Although I agree adding a hack for timebeing, why not use the 
dma_get_sgtable() RFC itself to solve this in clean way? The hacks 
anyways cannot go into mainline when vb2 patches get merged.

Regards,
Subash
>

[PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Christian König]

On 11.06.2012 12:34, Rafa? Mi?ecki wrote:
> After recent changes HDMI code is ready to be enabled on DCE5. This
> patch just changes conditions to execute already present code on DCE5.
>
> Signed-off-by: Rafa? Mi?ecki
> Reviewed-by: Alex Deucher
Tested-by: Christian K?nig 

> ---
> V2: enable audio engine on Cayman (it uses different startup function).
> ---
>   drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
>   drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
>   drivers/gpu/drm/radeon/ni.c|5 +
>   drivers/gpu/drm/radeon/r600_audio.c|2 +-
>   drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
>   5 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index e7b1ec5..486ccdf 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
> *encoder,
>
>   if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
>   r600_hdmi_enable(encoder);
> - if (ASIC_IS_DCE4(rdev))
> + if (ASIC_IS_DCE6(rdev))
> + ; /* TODO (use pointers instead of if-s?) */
> + else if (ASIC_IS_DCE4(rdev))
>   evergreen_hdmi_setmode(encoder, adjusted_mode);
>   else
>   r600_hdmi_setmode(encoder, adjusted_mode);
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index a51f880..65c5416 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
> struct drm_display_mode
>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>   uint32_t offset;
>
> - if (ASIC_IS_DCE5(rdev))
> - return;
> -
>   /* Silent, r600_hdmi_enable will raise WARN for us */
>   if (!dig->afmt->enabled)
>   return;
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 3df4efa..b65fcae 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
>   if (r)
>   return r;
>
> + r = r600_audio_init(rdev);
> + if (r)
> + return r;
> +
>   return 0;
>   }
>
> @@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
>
>   int cayman_suspend(struct radeon_device *rdev)
>   {
> + r600_audio_fini(rdev);
>   /* FIXME: we should wait for ring to be empty */
>   radeon_ib_pool_suspend(rdev);
>   radeon_vm_manager_suspend(rdev);
> diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
> b/drivers/gpu/drm/radeon/r600_audio.c
> index 7479a5c..79b5591 100644
> --- a/drivers/gpu/drm/radeon/r600_audio.c
> +++ b/drivers/gpu/drm/radeon/r600_audio.c
> @@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
>*/
>   static int r600_audio_chipset_supported(struct radeon_device *rdev)
>   {
> - return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE5(rdev))
> + return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE6(rdev))
>   || rdev->family == CHIP_RS600
>   || rdev->family == CHIP_RS690
>   || rdev->family == CHIP_RS740;
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index 969c275..82a0a4c 100644
> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
> @@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
> struct drm_display_mode *mod
>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>   uint32_t offset;
>
> - if (ASIC_IS_DCE5(rdev))
> - return;
> -
>   /* Silent, r600_hdmi_enable will raise WARN for us */
>   if (!dig->afmt->enabled)
>   return;
> @@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
>   uint32_t offset;
>   u32 hdmi;
>
> - if (ASIC_IS_DCE5(rdev))
> + if (ASIC_IS_DCE6(rdev))
>   return;
>
>   /* Silent, r600_hdmi_enable will raise WARN for us */
> @@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>   uint32_t offset;
>
> - if (ASIC_IS_DCE5(rdev))
> + if (ASIC_IS_DCE6(rdev))
>   return;
>
>   /* Called for ATOM_ENCODER_MODE_HDMI only */

[Bug 50980] New: [r300g, bisected] WebGL cars demo crash (r300_emit.c:865:r300_emit_vertex_arrays: Assertion `(buf)' failed)

[bugzilla-daemon]

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

 Bug #: 50980
   Summary: [r300g, bisected] WebGL cars demo crash
(r300_emit.c:865:r300_emit_vertex_arrays: Assertion
`(buf)' failed)
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
   URL: http://www.chromeexperiments.com/detail/webgl-cars/?f=
webgl
OS/Version: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: pavel.ondra...@email.cz
CC: mar...@gmail.com


Created attachment 62902
  --> https://bugs.freedesktop.org/attachment.cgi?id=62902
backtrace

WebGL cars demo crash with r300_emit.c:865:r300_emit_vertex_arrays: Assertion
`(buf)' failed, full backtrace attached.

784dd51198433e5c299da4a7742c68d21d68d1c1 is the first bad commit
commit 784dd51198433e5c299da4a7742c68d21d68d1c1
Author: Marek Olšák 
Date:   Mon Apr 16 03:34:22 2012 +0200

mesa,vbo: properly detect when vertex arrays need to be recalculated

This moves the RebindArrays flag into the vbo module, consolidates the
code,
and adds missing vbo_draw_method calls.

Also with this change, the vertex arrays are not needlessly recalculated
twice.
The issue with the old code was:
- If recalculate_input_bindings updates vp_varying_inputs, _NEW_ARRAY is
set.
- _mesa_update_state is called and the vp_varying_inputs change causes
  regeneration of the fixed-function shaders, which also sets _NEW_PROGRAM.
- The occurence of either _NEW_ARRAY or _NEW_PROGRAM sets
  the recalculate_inputs flag to TRUE again.
- The new code sets the flag to FALSE after the second _mesa_update_state,
  because there can't possibly be any change which would require
recalculating
  the arrays.

Reviewed-by: Brian Paul 
Reviewed-by: Mathias Fröhlich 


GPU:RV530
Kernel: 3.4.0-1.fc17.i686
Firefox 13.0

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

Re: No screens after (WW) Falling back to old probe method for modesetting

[Rafał Miłecki]

2012/6/11 Rafał Miłecki :
> I'm trying to switch from fbdev to modesetting for my AMD Southern
> Islands VERDE card. Of course I've KMS running just fine, radeon
> module loads and sets correct resolution, dmesg looks alright
>
> Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU
> the driver doesn't provide any screens/modes. It looks like this:
> (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
> (WW) Falling back to old probe method for modesetting
> (II) UnloadModule: "modesetting"
> (II) Unloading modesetting
> (EE) Screen(s) found, but none have a usable configuration.
>
> Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm
> using xf86-video-modesetting from today's git. Any patch/trick to
> debug this issue?

Attaching Xorg.0.logs

-- 
Rafał


Xorg.modesettings.log
Description: Binary data


Xorg.fbdev.log
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

No screens after (WW) Falling back to old probe method for modesetting

[Rafał Miłecki]

I'm trying to switch from fbdev to modesetting for my AMD Southern
Islands VERDE card. Of course I've KMS running just fine, radeon
module loads and sets correct resolution, dmesg looks alright

Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU
the driver doesn't provide any screens/modes. It looks like this:
(II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
(WW) Falling back to old probe method for modesetting
(II) UnloadModule: "modesetting"
(II) Unloading modesetting
(EE) Screen(s) found, but none have a usable configuration.

Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm
using xf86-video-modesetting from today's git. Any patch/trick to
debug this issue?

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

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Mon, Jun 11, 2012 at 09:20:00AM +0200, Daniel Vetter wrote:
> On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
> > > On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> > > > On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter  wrote:
> > > > >
> > > > > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > > > > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
> > > > 
> > > > Hmm. Now *I* can't reproduce it either.
> > > > 
> > > > I have updated my system in the meantime, so maybe this is related to
> > > > that. However, I suspect it's more likely that it's some race
> > > > condition, because when I got it, I got a *lot* of it, but they were
> > > > all very tightly bunched together:
> > > > 
> > > >  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > >  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > > intel_dp_check_edp+0x5d/0xb0()
> > > > 
> > > > ie that's 12 of those warnings (each of them with that huge backtrace
> > > > etc), but they are all within 0.03 seconds of each other. So I suspect
> > > > it needs to hit some particular timing window, and I was just
> > > > (un)lucky.
> > > > 
> > > > Because when I try it now with DRM debugging, I can't hit it. And just
> > > > to make sure, I re-did the test without debugging too (in case the
> > > > debugging would have changed timing), but can't reproduce it that way
> > > > either.
> > > 
> > > Meh, I've been totally blind. Note to self: Next time around actually look
> > > at the backtrace. And I dunno how that escaped our dear QA that long ...
> > 
> > Even more meh, this patch might actually work a bit better.
> > 
> > /me doesn't have an edp panel to test this
> 
> v3 is tested by our QA and hopefully works. I'll send it to Dave for
> -fixes in a few days, attached below just in case. Please yell if this
> doesn't fix your edp dmesg spam.

... and that one died in review. v4 is in the works and going through QA
atm.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Rafał Miłecki]

After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.

Signed-off-by: Rafa? Mi?ecki 
Reviewed-by: Alex Deucher 
---
V2: enable audio engine on Cayman (it uses different startup function).
---
 drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
 drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
 drivers/gpu/drm/radeon/ni.c|5 +
 drivers/gpu/drm/radeon/r600_audio.c|2 +-
 drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e7b1ec5..486ccdf 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,

if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
r600_hdmi_enable(encoder);
-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE6(rdev))
+   ; /* TODO (use pointers instead of if-s?) */
+   else if (ASIC_IS_DCE4(rdev))
evergreen_hdmi_setmode(encoder, adjusted_mode);
else
r600_hdmi_setmode(encoder, adjusted_mode);
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index a51f880..65c5416 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;

-   if (ASIC_IS_DCE5(rdev))
-   return;
-
/* Silent, r600_hdmi_enable will raise WARN for us */
if (!dig->afmt->enabled)
return;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
if (r)
return r;

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

@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)

 int cayman_suspend(struct radeon_device *rdev)
 {
+   r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
radeon_ib_pool_suspend(rdev);
radeon_vm_manager_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index 7479a5c..79b5591 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
  */
 static int r600_audio_chipset_supported(struct radeon_device *rdev)
 {
-   return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE5(rdev))
+   return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE6(rdev))
|| rdev->family == CHIP_RS600
|| rdev->family == CHIP_RS690
|| rdev->family == CHIP_RS740;
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 969c275..82a0a4c 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;

-   if (ASIC_IS_DCE5(rdev))
-   return;
-
/* Silent, r600_hdmi_enable will raise WARN for us */
if (!dig->afmt->enabled)
return;
@@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
uint32_t offset;
u32 hdmi;

-   if (ASIC_IS_DCE5(rdev))
+   if (ASIC_IS_DCE6(rdev))
return;

/* Silent, r600_hdmi_enable will raise WARN for us */
@@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;

-   if (ASIC_IS_DCE5(rdev))
+   if (ASIC_IS_DCE6(rdev))
return;

/* Called for ATOM_ENCODER_MODE_HDMI only */
-- 
1.7.7

Re: [PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Boszormenyi Zoltan]

Yay, it works on HD6570 (TURKS)! Thanks!

2012-06-11 14:11 keltezéssel, Christian König írta:

On 11.06.2012 12:34, Rafał Miłecki wrote:

After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.

Signed-off-by: Rafał Miłecki
Reviewed-by: Alex Deucher

Tested-by: Christian König 


Tested-by: Zoltán Böszörményi 




---
V2: enable audio engine on Cayman (it uses different startup function).
---
  drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
  drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
  drivers/gpu/drm/radeon/ni.c|5 +
  drivers/gpu/drm/radeon/r600_audio.c|2 +-
  drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
  5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c

index e7b1ec5..486ccdf 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,

  if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
  r600_hdmi_enable(encoder);
-if (ASIC_IS_DCE4(rdev))
+if (ASIC_IS_DCE6(rdev))
+; /* TODO (use pointers instead of if-s?) */
+else if (ASIC_IS_DCE4(rdev))
  evergreen_hdmi_setmode(encoder, adjusted_mode);
  else
  r600_hdmi_setmode(encoder, adjusted_mode);
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c

index a51f880..65c5416 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode

  struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
  uint32_t offset;

-if (ASIC_IS_DCE5(rdev))
-return;
-
  /* Silent, r600_hdmi_enable will raise WARN for us */
  if (!dig->afmt->enabled)
  return;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
  if (r)
  return r;

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

@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)

  int cayman_suspend(struct radeon_device *rdev)
  {
+r600_audio_fini(rdev);
  /* FIXME: we should wait for ring to be empty */
  radeon_ib_pool_suspend(rdev);
  radeon_vm_manager_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index 7479a5c..79b5591 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
   */
  static int r600_audio_chipset_supported(struct radeon_device *rdev)
  {
-return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE5(rdev))
+return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE6(rdev))
  || rdev->family == CHIP_RS600
  || rdev->family == CHIP_RS690
  || rdev->family == CHIP_RS740;
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 969c275..82a0a4c 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod

  struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
  uint32_t offset;

-if (ASIC_IS_DCE5(rdev))
-return;
-
  /* Silent, r600_hdmi_enable will raise WARN for us */
  if (!dig->afmt->enabled)
  return;
@@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
  uint32_t offset;
  u32 hdmi;

-if (ASIC_IS_DCE5(rdev))
+if (ASIC_IS_DCE6(rdev))
  return;

  /* Silent, r600_hdmi_enable will raise WARN for us */
@@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
  struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
  uint32_t offset;

-if (ASIC_IS_DCE5(rdev))
+if (ASIC_IS_DCE6(rdev))
  return;

  /* Called for ATOM_ENCODER_MODE_HDMI only */


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


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

RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

[Michel Dänzer]

On Son, 2012-06-10 at 11:56 +, Joakim Plate wrote: 
> Hi, 
> 
> I'm currently trying to make use of OML_sync_control extension to schedule 
> presentation of video frames in xbmc.
> 
> I've run into somewhat of a snag. It seem the spec doesn't specify what
> time the UST clock really is, nor can i find any mention of it elsewhere
> in docs.
> 
> Code wise it seem to be using do_gettimeofday(), which seems like a rather
> poor choice given that it can jump forward and back in time due to
> settimeofday calls. 
> 
> We normally make use of clock_gettime(CLOCK_MONOTONIC) to timestamp display
> of video frames, so to avoid major changes I'd need a way to convert to 
> gettimeofday (seem same as CLOCK_REALTIME).
> 
> Currently i'm trying:
>   struct timespec mon, rel;
>   clock_gettime(CLOCK_MONOTONIC, &mon);
>   clock_gettime(CLOCK_REALTIME , &rel);
> 
>   ticks += (rel.tv_sec  - mon.tv_sec)  * 10;
>   ticks += (rel.tv_nsec - mon.tv_nsec);
> 
> To convert between the two, but that is quite a hack both in the
> possibility of clock changes and scheduling errors.
> 
> Is there a better way, or perhaps the DRI code should use CLOCK_MONOTONIC
> in the first place?

[RFT][PATCH] drm/radeon/hdmi: enable audio on Cayman

[Christian König]

Yeah, just gotten to the same conclusion a second before your last mail 
arrives Heureka! We got HDMI audio on Cayman!

Please merge that with your other patch and resend it to the list.

Cheers,
Christian.

On 11.06.2012 11:38, Rafa? Mi?ecki wrote:
> ---
>   drivers/gpu/drm/radeon/ni.c |5 +
>   1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 3df4efa..b65fcae 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
>   if (r)
>   return r;
>
> + r = r600_audio_init(rdev);
> + if (r)
> + return r;
> +
>   return 0;
>   }
>
> @@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
>
>   int cayman_suspend(struct radeon_device *rdev)
>   {
> + r600_audio_fini(rdev);
>   /* FIXME: we should wait for ring to be empty */
>   radeon_ib_pool_suspend(rdev);
>   radeon_vm_manager_suspend(rdev);

[Intel-gfx] [PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices

[Jani Nikula]

On Fri, 08 Jun 2012, Daniel Vetter  wrote:
> There's the neat little problem that some systems die if vga decoding
> isn't decoded anywhere, because linux disabled that pci device.
>
> Atm we solve that problem by simple not calling pci_disable_device at
> driver unregister time for drm pci devices. Which isn't to great
> because it leaks a pci_enable_device reference on module reload and
> also is rather inconsistent, since the driver load codcode in
> drm/drm_pci.c _does_ call pci_disable_device on the load error path.
>
> To fix this issue, let the vga arbiter hold a pci_enable_device
> reference on its own when the vga device decodes anything. This leaves
> the issue still open when the vga arbiter isn't loaded/compiled in,
> but I guess since drm module unload is riddled with dragons it's ok to
> say "just don't do this".
>
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/vga/vgaarb.c |   27 +--
>  1 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 3df8fc0..82f19a1 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -49,7 +49,11 @@
>  static void vga_arbiter_notify_clients(void);
>  /*
>   * We keep a list of all vga devices in the system to speed
> - * up the various operations of the arbiter
> + * up the various operations of the arbiter. Note that vgaarb keeps a
> + * pci_enable_device reference for all vga devices with owns != 0. This is to
> + * avoid drm devices from killing the system when they call 
> pci_disable_device
> + * on module unload (as they should), because some systems don't like it if 
> no
> + * one decodes vga.
>   */
>  struct vga_device {
>   struct list_head list;
> @@ -171,7 +175,7 @@ static struct vga_device *__vga_tryget(struct vga_device 
> *vgadev,
>  {
>   unsigned int wants, legacy_wants, match;
>   struct vga_device *conflict;
> - unsigned int pci_bits;
> + unsigned int pci_bits, ret;
>   u32 flags = 0;
>  
>   /* Account for "normal" resources to lock. If we decode the legacy,
> @@ -264,6 +268,10 @@ static struct vga_device *__vga_tryget(struct vga_device 
> *vgadev,
>  
>   pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
>   conflict->owns &= ~lwants;
> +
> + if (conflict->owns == 0)
> + pci_disable_device(conflict->pdev);
> +
>   /* If he also owned non-legacy, that is no longer the case */
>   if (lwants & VGA_RSRC_LEGACY_MEM)
>   conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
> @@ -290,6 +298,12 @@ enable_them:
>   if (!!(wants & VGA_RSRC_LEGACY_MASK))
>   flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
>  
> + if (vgadev->owns == 0) {
> + ret = pci_enable_device(vgadev->pdev);
> + if (ret)
> + return ERR_PTR(ret);

Hi Daniel, I think unsigned ret will result in a positive ERR_PTR, which
won't be caught by IS_ERR_VALUE(). (Either that, or I need more coffee
to get the promotion rules right. Better use signed int no matter what.)

BR,
Jani.


> + }
> +
>   pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);
>  
>   if (!vgadev->bridge_has_one_vga) {
> @@ -376,6 +390,8 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int 
> interruptible)
>   if (conflict == NULL)
>   break;
>  
> + if (IS_ERR(conflict))
> + return PTR_ERR(conflict);
>  
>   /* We have a conflict, we wait until somebody kicks the
>* work queue. Currently we have one work queue that we
> @@ -513,6 +529,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>   unsigned long flags;
>   struct pci_bus *bus;
>   struct pci_dev *bridge;
> + int ret;
>   u16 cmd;
>  
>   /* Only deal with VGA class devices */
> @@ -582,6 +599,12 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>  
>   vga_arbiter_check_bridge_sharing(vgadev);
>  
> + if (vgadev->owns != 0) {
> + ret = pci_enable_device(vgadev->pdev);
> + if (ret)
> + goto fail;
> + }
> +
>   /* Add to the list */
>   list_add(&vgadev->list, &vga_list);
>   vga_count++;
> -- 
> 1.7.7.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFT][PATCH] drm/radeon/hdmi: enable audio on Cayman

[Rafał Miłecki]

---
 drivers/gpu/drm/radeon/ni.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
if (r)
return r;

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

@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)

 int cayman_suspend(struct radeon_device *rdev)
 {
+   r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
radeon_ib_pool_suspend(rdev);
radeon_vm_manager_suspend(rdev);
-- 
1.7.7

[PATCH][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Rafał Miłecki]

2012/6/11 Rafa? Mi?ecki :
> 2012/6/10 Christian K?nig :
>> Unfortunately testing it with my Cayman based card shows that it plays with
>> the correct speed, audio registers seems to be ok, but unfortunately I don't
>> hear any sound at all :(
>
> If you can easily switch between fglrx and radeon, comparing
> "avivotool regs hdmi" should give a quick hint. Unless you have better
> debugging tools at AMD :)

Cayman is the latest DCE5, it uses different init code (see ni.c). You
probably just need to put audio init in ni.c :)

-- 
Rafa?

[PATCH] omap2+: add drm device

[Rob Clark]

On Wed, May 23, 2012 at 3:08 PM, Andy Gross  wrote:
> Register OMAP DRM/KMS platform device. ?DMM is split into a
> separate device using hwmod.
>
> Signed-off-by: Andy Gross 

Signed-off-by: Rob Clark 

> ---
> ?arch/arm/mach-omap2/Makefile ? ? ? ? ? | ? ?4 ++
> ?arch/arm/mach-omap2/drm.c ? ? ? ? ? ? ?| ? 61 
> 
> ?drivers/staging/omapdrm/omap_drv.h ? ? | ? ?2 +-
> ?drivers/staging/omapdrm/omap_priv.h ? ?| ? 55 
> ?include/linux/platform_data/omap_drm.h | ? 52 +++
> ?5 files changed, 118 insertions(+), 56 deletions(-)
> ?create mode 100644 arch/arm/mach-omap2/drm.c
> ?delete mode 100644 drivers/staging/omapdrm/omap_priv.h
> ?create mode 100644 include/linux/platform_data/omap_drm.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 49f92bc..c301ab7 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
> ?obj-y ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+= dsp.o
> ?endif
>
> +ifneq ($(CONFIG_DRM_OMAP),)
> +obj-y ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+= drm.o
> +endif
> +
> ?# Specific board support
> ?obj-$(CONFIG_MACH_OMAP_GENERIC) ? ? ? ? ? ? ? ?+= board-generic.o
> ?obj-$(CONFIG_MACH_OMAP_H4) ? ? ? ? ? ? += board-h4.o
> diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
> new file mode 100644
> index 000..72e0f01b
> --- /dev/null
> +++ b/arch/arm/mach-omap2/drm.c
> @@ -0,0 +1,61 @@
> +/*
> + * DRM/KMS device registration for TI OMAP platforms
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program. ?If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
> +
> +static struct platform_device omap_drm_device = {
> + ? ? ? .dev = {
> + ? ? ? ? ? ? ? .coherent_dma_mask = DMA_BIT_MASK(32),
> + ? ? ? },
> + ? ? ? .name = "omapdrm",
> + ? ? ? .id = 0,
> +};
> +
> +static int __init omap_init_drm(void)
> +{
> + ? ? ? struct omap_hwmod *oh = NULL;
> + ? ? ? struct platform_device *pdev;
> +
> + ? ? ? /* lookup and populate the DMM information, if present - OMAP4+ */
> + ? ? ? oh = omap_hwmod_lookup("dmm");
> +
> + ? ? ? if (oh) {
> + ? ? ? ? ? ? ? pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? false);
> + ? ? ? ? ? ? ? WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
> + ? ? ? ? ? ? ? ? ? ? ? oh->name);
> + ? ? ? }
> +
> + ? ? ? return platform_device_register(&omap_drm_device);
> +
> +}
> +
> +arch_initcall(omap_init_drm);
> +
> +#endif
> diff --git a/drivers/staging/omapdrm/omap_drv.h 
> b/drivers/staging/omapdrm/omap_drv.h
> index b7e0f07..96296e0 100644
> --- a/drivers/staging/omapdrm/omap_drv.h
> +++ b/drivers/staging/omapdrm/omap_drv.h
> @@ -25,8 +25,8 @@
> ?#include 
> ?#include 
> ?#include 
> +#include 
> ?#include "omap_drm.h"
> -#include "omap_priv.h"
>
> ?#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
> ?#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug 
> */
> diff --git a/drivers/staging/omapdrm/omap_priv.h 
> b/drivers/staging/omapdrm/omap_priv.h
> deleted file mode 100644
> index ef64414..000
> --- a/drivers/staging/omapdrm/omap_priv.h
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -/*
> - * include/drm/omap_priv.h
> - *
> - * Copyright (C) 2011 Texas Instruments
> - * Author: Rob Clark 
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program. ?If not, see .
> - */
> -
> -#ifndef __OMAP_PRIV_H__
> -#define __OMAP_PRIV_H__
> -
> -/* Non-userspace facing APIs
> - */
> -
> -/* optional platform data to configure the default configuration of which
> - * pipes/overlays/CRTCs are used.. if this is not pro

[Intel-gfx] [PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices

[Daniel Vetter]

On Mon, Jun 11, 2012 at 11:42:35AM +0300, Jani Nikula wrote:
> On Fri, 08 Jun 2012, Daniel Vetter  wrote:
> > There's the neat little problem that some systems die if vga decoding
> > isn't decoded anywhere, because linux disabled that pci device.
> >
> > Atm we solve that problem by simple not calling pci_disable_device at
> > driver unregister time for drm pci devices. Which isn't to great
> > because it leaks a pci_enable_device reference on module reload and
> > also is rather inconsistent, since the driver load codcode in
> > drm/drm_pci.c _does_ call pci_disable_device on the load error path.
> >
> > To fix this issue, let the vga arbiter hold a pci_enable_device
> > reference on its own when the vga device decodes anything. This leaves
> > the issue still open when the vga arbiter isn't loaded/compiled in,
> > but I guess since drm module unload is riddled with dragons it's ok to
> > say "just don't do this".
> >
> > Signed-Off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/vga/vgaarb.c |   27 +--
> >  1 files changed, 25 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> > index 3df8fc0..82f19a1 100644
> > --- a/drivers/gpu/vga/vgaarb.c
> > +++ b/drivers/gpu/vga/vgaarb.c
> > @@ -49,7 +49,11 @@
> >  static void vga_arbiter_notify_clients(void);
> >  /*
> >   * We keep a list of all vga devices in the system to speed
> > - * up the various operations of the arbiter
> > + * up the various operations of the arbiter. Note that vgaarb keeps a
> > + * pci_enable_device reference for all vga devices with owns != 0. This is 
> > to
> > + * avoid drm devices from killing the system when they call 
> > pci_disable_device
> > + * on module unload (as they should), because some systems don't like it 
> > if no
> > + * one decodes vga.
> >   */
> >  struct vga_device {
> > struct list_head list;
> > @@ -171,7 +175,7 @@ static struct vga_device *__vga_tryget(struct 
> > vga_device *vgadev,
> >  {
> > unsigned int wants, legacy_wants, match;
> > struct vga_device *conflict;
> > -   unsigned int pci_bits;
> > +   unsigned int pci_bits, ret;
> > u32 flags = 0;
> >  
> > /* Account for "normal" resources to lock. If we decode the legacy,
> > @@ -264,6 +268,10 @@ static struct vga_device *__vga_tryget(struct 
> > vga_device *vgadev,
> >  
> > pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
> > conflict->owns &= ~lwants;
> > +
> > +   if (conflict->owns == 0)
> > +   pci_disable_device(conflict->pdev);
> > +
> > /* If he also owned non-legacy, that is no longer the case */
> > if (lwants & VGA_RSRC_LEGACY_MEM)
> > conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
> > @@ -290,6 +298,12 @@ enable_them:
> > if (!!(wants & VGA_RSRC_LEGACY_MASK))
> > flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
> >  
> > +   if (vgadev->owns == 0) {
> > +   ret = pci_enable_device(vgadev->pdev);
> > +   if (ret)
> > +   return ERR_PTR(ret);
> 
> Hi Daniel, I think unsigned ret will result in a positive ERR_PTR, which
> won't be caught by IS_ERR_VALUE(). (Either that, or I need more coffee
> to get the promotion rules right. Better use signed int no matter what.)

No coffee needed on your side, ret should clearly be signed. I'll fix this
asap, thanks for catching this.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices

[Daniel Vetter]

There's the neat little problem that some systems die if vga decoding
isn't decoded anywhere, because linux disabled that pci device.

Atm we solve that problem by simple not calling pci_disable_device at
driver unregister time for drm pci devices. Which isn't to great
because it leaks a pci_enable_device reference on module reload and
also is rather inconsistent, since the driver load codcode in
drm/drm_pci.c _does_ call pci_disable_device on the load error path.

To fix this issue, let the vga arbiter hold a pci_enable_device
reference on its own when the vga device decodes anything. This leaves
the issue still open when the vga arbiter isn't loaded/compiled in,
but I guess since drm module unload is riddled with dragons it's ok to
say "just don't do this".

v2: ret needs to be signed, otherwise ERR_PTR will just store a large
positive value on 64bit machines. Noticed by Jani Nikula.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/vga/vgaarb.c |   26 +-
 1 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 3df8fc0..c0b1271 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -49,7 +49,11 @@
 static void vga_arbiter_notify_clients(void);
 /*
  * We keep a list of all vga devices in the system to speed
- * up the various operations of the arbiter
+ * up the various operations of the arbiter. Note that vgaarb keeps a
+ * pci_enable_device reference for all vga devices with owns != 0. This is to
+ * avoid drm devices from killing the system when they call pci_disable_device
+ * on module unload (as they should), because some systems don't like it if no
+ * one decodes vga.
  */
 struct vga_device {
struct list_head list;
@@ -172,6 +176,7 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,
unsigned int wants, legacy_wants, match;
struct vga_device *conflict;
unsigned int pci_bits;
+   int ret;
u32 flags = 0;

/* Account for "normal" resources to lock. If we decode the legacy,
@@ -264,6 +269,10 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,

pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
conflict->owns &= ~lwants;
+
+   if (conflict->owns == 0)
+   pci_disable_device(conflict->pdev);
+
/* If he also owned non-legacy, that is no longer the case */
if (lwants & VGA_RSRC_LEGACY_MEM)
conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
@@ -290,6 +299,12 @@ enable_them:
if (!!(wants & VGA_RSRC_LEGACY_MASK))
flags |= PCI_VGA_STATE_CHANGE_BRIDGE;

+   if (vgadev->owns == 0) {
+   ret = pci_enable_device(vgadev->pdev);
+   if (ret)
+   return ERR_PTR(ret);
+   }
+
pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);

if (!vgadev->bridge_has_one_vga) {
@@ -376,6 +391,8 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int 
interruptible)
if (conflict == NULL)
break;

+   if (IS_ERR(conflict))
+   return PTR_ERR(conflict);

/* We have a conflict, we wait until somebody kicks the
 * work queue. Currently we have one work queue that we
@@ -513,6 +530,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
unsigned long flags;
struct pci_bus *bus;
struct pci_dev *bridge;
+   int ret;
u16 cmd;

/* Only deal with VGA class devices */
@@ -582,6 +600,12 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
*pdev)

vga_arbiter_check_bridge_sharing(vgadev);

+   if (vgadev->owns != 0) {
+   ret = pci_enable_device(vgadev->pdev);
+   if (ret)
+   goto fail;
+   }
+
/* Add to the list */
list_add(&vgadev->list, &vga_list);
vga_count++;
-- 
1.7.7.6

[PATCH] omap2+: add drm device

[Gross, Andy]

Tomi,

So at this point, are you OK with deferring a split of the DMM until it
necessary to do so (if ever)?  I'd like to get this patch in so that people
have a working omapdrm device when they enable the config options.

Regards,

Andy
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120611/8df6c709/attachment.htm>

[PATCH] drm/sis: properly initialize dev_priv->object_idr

[Daniel Vetter]

Spotted while reviewing the same patch for drm/via by N?meth M?rton.

Cc: stable at vger.kernel.org
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/sis/sis_drv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
index 30d98d1..c7263a4 100644
--- a/drivers/gpu/drm/sis/sis_drv.c
+++ b/drivers/gpu/drm/sis/sis_drv.c
@@ -49,7 +49,7 @@ static int sis_driver_load(struct drm_device *dev, unsigned 
long chipset)

dev->dev_private = (void *)dev_priv;
dev_priv->chipset = chipset;
-   idr_init(&dev->object_name_idr);
+   idr_init(&dev_priv->object_idr);

return 0;
 }
-- 
1.7.10

edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
> On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> > > On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter  wrote:
> > > >
> > > > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > > > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
> > > 
> > > Hmm. Now *I* can't reproduce it either.
> > > 
> > > I have updated my system in the meantime, so maybe this is related to
> > > that. However, I suspect it's more likely that it's some race
> > > condition, because when I got it, I got a *lot* of it, but they were
> > > all very tightly bunched together:
> > > 
> > >  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > > 
> > > ie that's 12 of those warnings (each of them with that huge backtrace
> > > etc), but they are all within 0.03 seconds of each other. So I suspect
> > > it needs to hit some particular timing window, and I was just
> > > (un)lucky.
> > > 
> > > Because when I try it now with DRM debugging, I can't hit it. And just
> > > to make sure, I re-did the test without debugging too (in case the
> > > debugging would have changed timing), but can't reproduce it that way
> > > either.
> > 
> > Meh, I've been totally blind. Note to self: Next time around actually look
> > at the backtrace. And I dunno how that escaped our dear QA that long ...
> 
> Even more meh, this patch might actually work a bit better.
> 
> /me doesn't have an edp panel to test this

v3 is tested by our QA and hopefully works. I'll send it to Dave for
-fixes in a few days, attached below just in case. Please yell if this
doesn't fix your edp dmesg spam.

Thanks, Daniel
---

[PATCH] drm via: initialize object_idr

[Daniel Vetter]

On Sun, Jun 10, 2012 at 11:39:55PM +0200, N?meth M?rton wrote:
> From: M?rton N?meth 
> 
> The field obejct_idr of struct drm_via_private was introduced with the
> commit 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc
>  .
> In that patch idr_init(&dev->object_name_idr) was called instead of
> idr_init(&dev_priv->object_idr) by mistake, leaving the dev_priv->object_idr
> uninitialized. To be more exact, the object_idr buffer is filled with zeros
> because of kzalloc(), but the dev_priv->object_idr.lock spinlock can cause
> system freeze at lib/idr.c:move_to_free_list() when spin_lock_irqsave()
> is called on this spinlock.
> 
> The patch was tested on Clevo D4J, model D410J laptop, on the following
> hardware, without AGP kernel module loaded:
> 
>   # lspci -s 01:00.0 -n
>   01:00.0 0300: 1106:3108 (rev 01)
>   # lspci -s 01:00.0 -v
>   01:00.0 VGA compatible controller: VIA Technologies, Inc. 
> K8M800/K8N800/K8N800A [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA 
> controller])
>   Subsystem: CLEVO/KAPOK Computer Device 4702
>   Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>   Memory at f000 (32-bit, prefetchable) [size=64M]
>   Memory at d100 (32-bit, non-prefetchable) [size=16M]
>   Expansion ROM at  [disabled]
>   Capabilities: [60] Power Management version 2
>   Capabilities: [70] AGP version 3.0
> 
> Signed-off-by: M?rton N?meth 

Meh, I fail, thanks for catching this. Although the drm/sis driver has the
same problem, care to write that patch, too? In any case:

Reviewed-by: Daniel Vetter 
Cc: stable at vger.kernel.org

-Daniel

> ---
> diff --git a/drivers/gpu/drm/via/via_map.c b/drivers/gpu/drm/via/via_map.c
> index 1f18225..c126182 100644
> --- a/drivers/gpu/drm/via/via_map.c
> +++ b/drivers/gpu/drm/via/via_map.c
> @@ -100,12 +100,11 @@ int via_driver_load(struct drm_device *dev, unsigned 
> long chipset)
>   if (dev_priv == NULL)
>   return -ENOMEM;
> 
> + idr_init(&dev_priv->object_idr);
>   dev->dev_private = (void *)dev_priv;
> 
>   dev_priv->chipset = chipset;
> 
> - idr_init(&dev->object_name_idr);
> -
>   pci_set_master(dev->pdev);
> 
>   ret = drm_vblank_init(dev, 1);

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[RFC] Documentation: DRM framework documentation

[Hans Verkuil]

On Mon June 11 2012 08:47:59 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Thursday 07 June 2012 11:13:30 Hans Verkuil wrote:
> > Hi Laurent!
> > 
> > I completely missed this when you posted this a week ago, but thank you for
> > doing this. One suggestion: cross-post the next version to linux-media as
> > well: I think this is useful for V4L2 as well.
> 
> I didn't think it would be useful, but sure, I can do that?

It's not directly useful, but it helps the V4L community understand the DRM
subsystem and hopefully lead to better cooperation. Also, having V4L people
with little experience of DRM review the document should help in improving the
documentation.

Regards,

Hans

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Wed, May 23, 2012 at 3:08 PM, Andy Gross  wrote:
> Register OMAP DRM/KMS platform device.  DMM is split into a
> separate device using hwmod.
>
> Signed-off-by: Andy Gross 

Signed-off-by: Rob Clark 

> ---
>  arch/arm/mach-omap2/Makefile           |    4 ++
>  arch/arm/mach-omap2/drm.c              |   61 
> 
>  drivers/staging/omapdrm/omap_drv.h     |    2 +-
>  drivers/staging/omapdrm/omap_priv.h    |   55 
>  include/linux/platform_data/omap_drm.h |   52 +++
>  5 files changed, 118 insertions(+), 56 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/drm.c
>  delete mode 100644 drivers/staging/omapdrm/omap_priv.h
>  create mode 100644 include/linux/platform_data/omap_drm.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 49f92bc..c301ab7 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
>  obj-y                                  += dsp.o
>  endif
>
> +ifneq ($(CONFIG_DRM_OMAP),)
> +obj-y                                  += drm.o
> +endif
> +
>  # Specific board support
>  obj-$(CONFIG_MACH_OMAP_GENERIC)                += board-generic.o
>  obj-$(CONFIG_MACH_OMAP_H4)             += board-h4.o
> diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
> new file mode 100644
> index 000..72e0f01b
> --- /dev/null
> +++ b/arch/arm/mach-omap2/drm.c
> @@ -0,0 +1,61 @@
> +/*
> + * DRM/KMS device registration for TI OMAP platforms
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
> +
> +static struct platform_device omap_drm_device = {
> +       .dev = {
> +               .coherent_dma_mask = DMA_BIT_MASK(32),
> +       },
> +       .name = "omapdrm",
> +       .id = 0,
> +};
> +
> +static int __init omap_init_drm(void)
> +{
> +       struct omap_hwmod *oh = NULL;
> +       struct platform_device *pdev;
> +
> +       /* lookup and populate the DMM information, if present - OMAP4+ */
> +       oh = omap_hwmod_lookup("dmm");
> +
> +       if (oh) {
> +               pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
> +                                       false);
> +               WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
> +                       oh->name);
> +       }
> +
> +       return platform_device_register(&omap_drm_device);
> +
> +}
> +
> +arch_initcall(omap_init_drm);
> +
> +#endif
> diff --git a/drivers/staging/omapdrm/omap_drv.h 
> b/drivers/staging/omapdrm/omap_drv.h
> index b7e0f07..96296e0 100644
> --- a/drivers/staging/omapdrm/omap_drv.h
> +++ b/drivers/staging/omapdrm/omap_drv.h
> @@ -25,8 +25,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "omap_drm.h"
> -#include "omap_priv.h"
>
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>  #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug 
> */
> diff --git a/drivers/staging/omapdrm/omap_priv.h 
> b/drivers/staging/omapdrm/omap_priv.h
> deleted file mode 100644
> index ef64414..000
> --- a/drivers/staging/omapdrm/omap_priv.h
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -/*
> - * include/drm/omap_priv.h
> - *
> - * Copyright (C) 2011 Texas Instruments
> - * Author: Rob Clark 
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
> - */
> -
> -#ifndef __OMAP_PRIV_H__
> -#define __OMAP_PRIV_H__
> -
> -/* Non-userspace facing APIs
> - */
> -
> -/* optional platform data to configure the default configuration of which
> - * pipes/overlays/CRTCs are used.. if this is not pro

[RFC] Documentation: DRM framework documentation

[Laurent Pinchart]

Hi Hans,

On Thursday 07 June 2012 11:13:30 Hans Verkuil wrote:
> Hi Laurent!
> 
> I completely missed this when you posted this a week ago, but thank you for
> doing this. One suggestion: cross-post the next version to linux-media as
> well: I think this is useful for V4L2 as well.

I didn't think it would be useful, but sure, I can do that?

> Some comments below:
> 
> On Wed 30 May 2012 15:13:29 Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  Documentation/drm.txt | 1265 
> >  1 files changed, 1265 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/drm.txt
> > 
> > Hi everybody,
> > 
> > Here's the DRM kernel framework documentation I wrote while developing the
> > Renesas SH Mobile DRM driver. It hopefully covers most of what's needed to
> > write a simple DRM driver (although some areas are not documented, such as
> > properties or the fbdev compatibility layer).
> > 
> > I can convert the documentation to DocBook if needed and integrate it with
> > the existing "documentation stub". In that case I'm thinking of splitting
> > the DocBook documentation in two parts, userspace API documentation (that
> > someone would have to fill, any volunteer ? ;-)) and kernel API
> > documentation. Would that be fine ?
> > 
> > Last but not least, now that documentation exists (albeit in an incomplete
> > state), we need to make sure it won't get outdated too quickly. As nobody
> > will volunteer to maintain it (feel free to prove me wrong though), I'd
> > like to propose the same rule that we already follow in V4L: any patch
> > that touches the API won't get merged if it doesn't update the
> > documentation. Do you think this could work out ?
> 
> I strongly recommend that this policy is adopted. It is working out very
> well in V4L2. Documentation can be a pain, but if you do it when you add new
> functionality (and you still remember what it was you did :-) ), then it
> isn't too bad.

[snip]

> > +"A CRTC is an abstraction representing a part of the chip that contains a
> > +pointer to a scanout buffer.
> 
> A definition of a 'scanout buffer' would be useful here. Also: what does
> CRTC stand for?

I think it stands for cathode ray tube controller.

> In general, I think it would be good to explain abbreviations (DRM, GEM,
> KMS, etc.) That way the terminology is easier to understand.

Good point. I'll add a glossary.

[snip]

> Impressive work, you clearly have way too much time on your hands :-)

Thank you. I'm not sure I agree with you, having to allocate sleep time in my 
schedule isn't really a sign of having too much free time ;-)

-- 
Regards,

Laurent Pinchart

[PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Laurent Pinchart]

Hi Tomasz,

On Friday 08 June 2012 16:31:31 Tomasz Stanislawski wrote:
> Hi Laurent and Subash,
> 
> I confirm the issue found by Subash. The function vb2_dc_kaddr_to_pages does
> fail for some occasions. The failures are rather strange like 'got 95 of
> 150 pages'. It took me some time to find the reason of the problem.
> 
> I found that dma_alloc_coherent for iommu an ARM does use ioremap_page_range
> to map a buffer to the kernel space. The mapping is done by updating the
> page-table.
> 
> The problem is that any process has a different first-level page-table. The
> ioremap_page_range updates only the table for init process. The PT present
> in current->mm shares a majority of entries of 1st-level PT at kernel range
> (above 0xc000) but *not all*. That is why vb2_dc_kaddr_to_pages worked
> for small buffers and occasionally failed for larger buffers.
> 
> I found two ways to fix this problem.
> a) use &init_mm instead of current->mm while creating an artificial vma
> b) access the dma memory by calling
>*((volatile int *)kaddr) = 0;
>before calling follow_pfn
>This way a fault is generated and the PT is
>updated by copying entries from init_mm.
> 
> What do you think about presented solutions?

Just to be sure, this is a hack until dma_get_sgtable is available, and it 
won't make it to mainline, right ?  In that case using init_mm seem easier.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Mon, 2012-06-11 at 09:51 -0500, Gross, Andy wrote:
> Tomi,
> 
> 
> So at this point, are you OK with deferring a split of the DMM until
> it necessary to do so (if ever)?  I'd like to get this patch in so
> that people have a working omapdrm device when they enable the config
> options.

Yes, I'm ok with it.

 Tomi



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Andre Heider]

On Mon, Jun 11, 2012 at 12:34 PM, Rafał Miłecki  wrote:
> After recent changes HDMI code is ready to be enabled on DCE5. This
> patch just changes conditions to execute already present code on DCE5.
>
> Signed-off-by: Rafał Miłecki 
> Reviewed-by: Alex Deucher 
> ---
> V2: enable audio engine on Cayman (it uses different startup function).
> ---
>  drivers/gpu/drm/radeon/atombios_encoders.c |    4 +++-
>  drivers/gpu/drm/radeon/evergreen_hdmi.c    |    3 ---
>  drivers/gpu/drm/radeon/ni.c                |    5 +
>  drivers/gpu/drm/radeon/r600_audio.c        |    2 +-
>  drivers/gpu/drm/radeon/r600_hdmi.c         |    7 ++-
>  5 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index e7b1ec5..486ccdf 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
> *encoder,
>
>        if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
>                r600_hdmi_enable(encoder);
> -               if (ASIC_IS_DCE4(rdev))
> +               if (ASIC_IS_DCE6(rdev))
> +                       ; /* TODO (use pointers instead of if-s?) */
> +               else if (ASIC_IS_DCE4(rdev))
>                        evergreen_hdmi_setmode(encoder, adjusted_mode);
>                else
>                        r600_hdmi_setmode(encoder, adjusted_mode);
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index a51f880..65c5416 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
> struct drm_display_mode
>        struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>        uint32_t offset;
>
> -       if (ASIC_IS_DCE5(rdev))
> -               return;
> -
>        /* Silent, r600_hdmi_enable will raise WARN for us */
>        if (!dig->afmt->enabled)
>                return;
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 3df4efa..b65fcae 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
>        if (r)
>                return r;
>
> +       r = r600_audio_init(rdev);
> +       if (r)
> +               return r;
> +
>        return 0;
>  }
>
> @@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
>
>  int cayman_suspend(struct radeon_device *rdev)
>  {
> +       r600_audio_fini(rdev);
>        /* FIXME: we should wait for ring to be empty */
>        radeon_ib_pool_suspend(rdev);
>        radeon_vm_manager_suspend(rdev);
> diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
> b/drivers/gpu/drm/radeon/r600_audio.c
> index 7479a5c..79b5591 100644
> --- a/drivers/gpu/drm/radeon/r600_audio.c
> +++ b/drivers/gpu/drm/radeon/r600_audio.c
> @@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
>  */
>  static int r600_audio_chipset_supported(struct radeon_device *rdev)
>  {
> -       return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE5(rdev))
> +       return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE6(rdev))
>                || rdev->family == CHIP_RS600
>                || rdev->family == CHIP_RS690
>                || rdev->family == CHIP_RS740;
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index 969c275..82a0a4c 100644
> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
> @@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
> struct drm_display_mode *mod
>        struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>        uint32_t offset;
>
> -       if (ASIC_IS_DCE5(rdev))
> -               return;
> -
>        /* Silent, r600_hdmi_enable will raise WARN for us */
>        if (!dig->afmt->enabled)
>                return;
> @@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
>        uint32_t offset;
>        u32 hdmi;
>
> -       if (ASIC_IS_DCE5(rdev))
> +       if (ASIC_IS_DCE6(rdev))
>                return;
>
>        /* Silent, r600_hdmi_enable will raise WARN for us */
> @@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
>        struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>        uint32_t offset;
>
> -       if (ASIC_IS_DCE5(rdev))
> +       if (ASIC_IS_DCE6(rdev))
>                return;
>
>        /* Called for ATOM_ENCODER_MODE_HDMI only */
> --
> 1.7.7

Woot, got sound on BARTS connected to a Onkyo TX-SR674E, thanks alot!

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

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

Tomi,

So at this point, are you OK with deferring a split of the DMM until it
necessary to do so (if ever)?  I'd like to get this patch in so that people
have a working omapdrm device when they enable the config options.

Regards,

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

[PATCH][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Rafał Miłecki]

2012/6/10 Christian K?nig :
> On 10.06.2012 21:22, Alex Deucher wrote:
>>
>> On Sun, Jun 10, 2012 at 11:59 AM, Rafa? Mi?ecki ?wrote:
>>>
>>> After recent changes HDMI code is ready to be enabled on DCE5. This
>>> patch just changes conditions to execute already present code on DCE5.
>>>
>>> Signed-off-by: Rafa? Mi?ecki
>>> ---
>>> Dave: I know it's common to accept patches adding IDs even while merge
>>> window's closed. Is this OK for you to take this patch as it only
>>> enables existing code for more hardware?
>>> DCE5 has same HDMI engine/code as DCE4.
>>>
>>> This was tested for regressions on R6xx and Evergreen. It makes audio
>>> work on my NI Caicos card.
>>
>> Reviewed-by: Alex Deucher
>>
>> Thanks for all of your hard work on this Rafa?!
>
> Yeah indeed, keep sticking with it! We really need more people working on
> the driver.

Thanks :)


> Unfortunately testing it with my Cayman based card shows that it plays with
> the correct speed, audio registers seems to be ok, but unfortunately I don't
> hear any sound at all :(

If you can easily switch between fglrx and radeon, comparing
"avivotool regs hdmi" should give a quick hint. Unless you have better
debugging tools at AMD :)

-- 
Rafa?

[RFC] Documentation: DRM framework documentation

[Rob Clark]

On Thu, Jun 7, 2012 at 2:52 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Tuesday 05 June 2012 04:31:54 Rob Clark wrote:
>
>> > + ?- int (*firstopen) (struct drm_device *)
>> > + ?- void (*lastclose) (struct drm_device *)
>> > + ?- int (*open) (struct drm_device *, struct drm_file *)
>> > + ?- void (*preclose) (struct drm_device *, struct drm_file *)
>> > + ?- void (*postclose) (struct drm_device *, struct drm_file *)
>> > +
>> > + ?Open and close handlers. None of those methods are mandatory.
>> > +
>> > + ?The .firstopen() method is called by the DRM core when an application
>> > opens
>> > + ?a device that has no other opened file handle. Similarly the
>> > .lastclose()
>> > + ?method is called when the last application holding a file handle opened
>> > on
>> > + ?the device closes it. Both methods are mostly used for UMS (User Mode
>> > + ?Setting) drivers to acquire and release device resources which should
>> > be
>> > + ?done in the .load() and .unload() methods for KMS drivers.
>> > +
>> > + ?Note that the .lastclose() method is also called at module unload time
>> > or,
>> > + ?for hot-pluggable devices, when the device is unplugged. The
>> > .firstopen()
>> > + ?and .lastclose() calls can thus be unbalanced.
>> > +
>>
>> AFAIK lastclose() should also be drm_fb_helper_restore_fbdev_mode() to
>> restore fbcon mode.
>
> Good point. I haven't documented the fbdev helper yet, I'll keep that in mind
> when updating the documentation.
>
>> I'm also restoring crtc and plane properties to default values here, so a
>> subsequent open of the device isn't inheriting some state from the previous
>> user.
>
> That's very unlike V4L2, where we explicitly require state to be kept across
> opens. Is restoring properties a DRM standard behaviour, implemented by other
> drivers as well ?

I think it is in a way required, because on lastclose you are
restoring the state of the fbcon.. and at least some (probably all?)
of the properties are adjusting the mode, so the fbcon mode would be
incorrect if you didn't restore property state.

[snip]
>
>> > +- GEM Initialization
>> > +
>> > + ?Drivers that use GEM must set the DRIVER_GEM bit in the struct
>> > drm_driver
>> > + ?driver_features field. The DRM core will then automatically initialize
>> > the
>> > + ?GEM core before calling the .load() operation.
>> > +
>> > +- GEM Objects Creation
>> > +
>> > + ?GEM splits creation of GEM objects and allocation of the memory that
>> > backs
>> > + ?them in two distinct operations.
>> > +
>> > + ?GEM objects are represented by an instance of struct drm_gem_object.
>> > Drivers
>> > + ?usually need to extend GEM objects with private information and thus
>> > create
>> > + ?a driver-specific GEM object structure type that embeds an instance of
>> > + ?struct drm_gem_object.
>> > +
>> > + ?To create a GEM object, a driver allocates memory for an instance of
>> > its
>> > + ?specific GEM object type and initializes the embedded struct
>> > drm_gem_object
>> > + ?with a call to drm_gem_object_init(). The function takes a pointer to
>> > the
>> > + ?DRM device, a pointer to the GEM object and the buffer object size in
>> > bytes.
>> > +
>> > + ?GEM automatically allocate anonymous pageable memory through shmfs when
>> > an
>>
>> s/allocate/allocates/
>>
>> Also, maybe worth mentioning that actual 'struct page's are allocated
>> when drm_gem_get_pages() is called..
>
> I don't think that's in mainline yet, is it ?

oh, heh, you are right.. maybe I need to revisit that.   Well, for
now, s/drm_gem_get_pages()/shmem_read_mapping_page_gfp()/

[snip]
>
>> > + ?To create a handle for a GEM object drivers call
>> > drm_gem_handle_create().
>> > + ?The function takes a pointer to the DRM file and the GEM object and
>> > returns
>> > + ?a locally unique handle. When the handle is no longer needed drivers
>> > delete
>> > + ?it with a call to drm_gem_handle_delete(). Finally the GEM object
>> > associated
>> > + ?with a handle can be retrieved by a call to drm_gem_object_lookup().
>>
>> I suppose it is easy enough seen from the code, but might be worth
>> mentioning that drm_gem_handle_create() increment's the refcnt of the gem
>> obj, rather than taking ownership of the gem obj.. so in some cases the
>> driver writer would want to drop that reference to the obj
>
> Do you really mean that driver sometimes need to drop the reference taken by
> the handle. My understanding is that they sometimes need to drop the reference
> they already hold. This of course makes no difference in the code, but from a
> documentation point of view that seems less confusing to me.

yes, drop the ref they already hold

>> > + ?GEM names are similar in purpose to handles but are not local to DRM
>> > files.
>> > + ?They can be passed between processes to reference a GEM object
>> > globally.
>> > + ?Names can't be used directly to refer to objects in the DRM API,
>> > + ?applications must convert handles to names and names to handles using
>> > the
>> > + ?DRM_IOCTL

Re: [PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Christian König]

On 11.06.2012 12:34, Rafał Miłecki wrote:

After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.

Signed-off-by: Rafał Miłecki
Reviewed-by: Alex Deucher

Tested-by: Christian König 


---
V2: enable audio engine on Cayman (it uses different startup function).
---
  drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
  drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
  drivers/gpu/drm/radeon/ni.c|5 +
  drivers/gpu/drm/radeon/r600_audio.c|2 +-
  drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
  5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e7b1ec5..486ccdf 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,

if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
r600_hdmi_enable(encoder);
-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE6(rdev))
+   ; /* TODO (use pointers instead of if-s?) */
+   else if (ASIC_IS_DCE4(rdev))
evergreen_hdmi_setmode(encoder, adjusted_mode);
else
r600_hdmi_setmode(encoder, adjusted_mode);
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index a51f880..65c5416 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;

-   if (ASIC_IS_DCE5(rdev))
-   return;
-
/* Silent, r600_hdmi_enable will raise WARN for us */
if (!dig->afmt->enabled)
return;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
if (r)
return r;

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

@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)

  int cayman_suspend(struct radeon_device *rdev)
  {
+   r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
radeon_ib_pool_suspend(rdev);
radeon_vm_manager_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index 7479a5c..79b5591 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
   */
  static int r600_audio_chipset_supported(struct radeon_device *rdev)
  {
-   return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE5(rdev))
+   return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE6(rdev))
|| rdev->family == CHIP_RS600
|| rdev->family == CHIP_RS690
|| rdev->family == CHIP_RS740;
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 969c275..82a0a4c 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;

-   if (ASIC_IS_DCE5(rdev))
-   return;
-
/* Silent, r600_hdmi_enable will raise WARN for us */
if (!dig->afmt->enabled)
return;
@@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
uint32_t offset;
u32 hdmi;

-   if (ASIC_IS_DCE5(rdev))
+   if (ASIC_IS_DCE6(rdev))
return;

/* Silent, r600_hdmi_enable will raise WARN for us */
@@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;

-   if (ASIC_IS_DCE5(rdev))
+   if (ASIC_IS_DCE6(rdev))
return;

/* Called for ATOM_ENCODER_MODE_HDMI only */


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

Re: [RFC] Documentation: DRM framework documentation

[Rob Clark]

On Thu, Jun 7, 2012 at 2:52 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Tuesday 05 June 2012 04:31:54 Rob Clark wrote:
>
>> > +  - int (*firstopen) (struct drm_device *)
>> > +  - void (*lastclose) (struct drm_device *)
>> > +  - int (*open) (struct drm_device *, struct drm_file *)
>> > +  - void (*preclose) (struct drm_device *, struct drm_file *)
>> > +  - void (*postclose) (struct drm_device *, struct drm_file *)
>> > +
>> > +  Open and close handlers. None of those methods are mandatory.
>> > +
>> > +  The .firstopen() method is called by the DRM core when an application
>> > opens
>> > +  a device that has no other opened file handle. Similarly the
>> > .lastclose()
>> > +  method is called when the last application holding a file handle opened
>> > on
>> > +  the device closes it. Both methods are mostly used for UMS (User Mode
>> > +  Setting) drivers to acquire and release device resources which should
>> > be
>> > +  done in the .load() and .unload() methods for KMS drivers.
>> > +
>> > +  Note that the .lastclose() method is also called at module unload time
>> > or,
>> > +  for hot-pluggable devices, when the device is unplugged. The
>> > .firstopen()
>> > +  and .lastclose() calls can thus be unbalanced.
>> > +
>>
>> AFAIK lastclose() should also be drm_fb_helper_restore_fbdev_mode() to
>> restore fbcon mode.
>
> Good point. I haven't documented the fbdev helper yet, I'll keep that in mind
> when updating the documentation.
>
>> I'm also restoring crtc and plane properties to default values here, so a
>> subsequent open of the device isn't inheriting some state from the previous
>> user.
>
> That's very unlike V4L2, where we explicitly require state to be kept across
> opens. Is restoring properties a DRM standard behaviour, implemented by other
> drivers as well ?

I think it is in a way required, because on lastclose you are
restoring the state of the fbcon.. and at least some (probably all?)
of the properties are adjusting the mode, so the fbcon mode would be
incorrect if you didn't restore property state.

[snip]
>
>> > +- GEM Initialization
>> > +
>> > +  Drivers that use GEM must set the DRIVER_GEM bit in the struct
>> > drm_driver
>> > +  driver_features field. The DRM core will then automatically initialize
>> > the
>> > +  GEM core before calling the .load() operation.
>> > +
>> > +- GEM Objects Creation
>> > +
>> > +  GEM splits creation of GEM objects and allocation of the memory that
>> > backs
>> > +  them in two distinct operations.
>> > +
>> > +  GEM objects are represented by an instance of struct drm_gem_object.
>> > Drivers
>> > +  usually need to extend GEM objects with private information and thus
>> > create
>> > +  a driver-specific GEM object structure type that embeds an instance of
>> > +  struct drm_gem_object.
>> > +
>> > +  To create a GEM object, a driver allocates memory for an instance of
>> > its
>> > +  specific GEM object type and initializes the embedded struct
>> > drm_gem_object
>> > +  with a call to drm_gem_object_init(). The function takes a pointer to
>> > the
>> > +  DRM device, a pointer to the GEM object and the buffer object size in
>> > bytes.
>> > +
>> > +  GEM automatically allocate anonymous pageable memory through shmfs when
>> > an
>>
>> s/allocate/allocates/
>>
>> Also, maybe worth mentioning that actual 'struct page's are allocated
>> when drm_gem_get_pages() is called..
>
> I don't think that's in mainline yet, is it ?

oh, heh, you are right.. maybe I need to revisit that.   Well, for
now, s/drm_gem_get_pages()/shmem_read_mapping_page_gfp()/

[snip]
>
>> > +  To create a handle for a GEM object drivers call
>> > drm_gem_handle_create().
>> > +  The function takes a pointer to the DRM file and the GEM object and
>> > returns
>> > +  a locally unique handle. When the handle is no longer needed drivers
>> > delete
>> > +  it with a call to drm_gem_handle_delete(). Finally the GEM object
>> > associated
>> > +  with a handle can be retrieved by a call to drm_gem_object_lookup().
>>
>> I suppose it is easy enough seen from the code, but might be worth
>> mentioning that drm_gem_handle_create() increment's the refcnt of the gem
>> obj, rather than taking ownership of the gem obj.. so in some cases the
>> driver writer would want to drop that reference to the obj
>
> Do you really mean that driver sometimes need to drop the reference taken by
> the handle. My understanding is that they sometimes need to drop the reference
> they already hold. This of course makes no difference in the code, but from a
> documentation point of view that seems less confusing to me.

yes, drop the ref they already hold

>> > +  GEM names are similar in purpose to handles but are not local to DRM
>> > files.
>> > +  They can be passed between processes to reference a GEM object
>> > globally.
>> > +  Names can't be used directly to refer to objects in the DRM API,
>> > +  applications must convert handles to names and names to handles using
>> > the
>> > +  DRM_IOCTL

[PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Rafał Miłecki]

After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.

Signed-off-by: Rafał Miłecki 
Reviewed-by: Alex Deucher 
---
V2: enable audio engine on Cayman (it uses different startup function).
---
 drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
 drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
 drivers/gpu/drm/radeon/ni.c|5 +
 drivers/gpu/drm/radeon/r600_audio.c|2 +-
 drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e7b1ec5..486ccdf 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
 
if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
r600_hdmi_enable(encoder);
-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE6(rdev))
+   ; /* TODO (use pointers instead of if-s?) */
+   else if (ASIC_IS_DCE4(rdev))
evergreen_hdmi_setmode(encoder, adjusted_mode);
else
r600_hdmi_setmode(encoder, adjusted_mode);
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index a51f880..65c5416 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;
 
-   if (ASIC_IS_DCE5(rdev))
-   return;
-
/* Silent, r600_hdmi_enable will raise WARN for us */
if (!dig->afmt->enabled)
return;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
if (r)
return r;
 
+   r = r600_audio_init(rdev);
+   if (r)
+   return r;
+
return 0;
 }
 
@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
 
 int cayman_suspend(struct radeon_device *rdev)
 {
+   r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
radeon_ib_pool_suspend(rdev);
radeon_vm_manager_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index 7479a5c..79b5591 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
  */
 static int r600_audio_chipset_supported(struct radeon_device *rdev)
 {
-   return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE5(rdev))
+   return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE6(rdev))
|| rdev->family == CHIP_RS600
|| rdev->family == CHIP_RS690
|| rdev->family == CHIP_RS740;
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 969c275..82a0a4c 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;
 
-   if (ASIC_IS_DCE5(rdev))
-   return;
-
/* Silent, r600_hdmi_enable will raise WARN for us */
if (!dig->afmt->enabled)
return;
@@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
uint32_t offset;
u32 hdmi;
 
-   if (ASIC_IS_DCE5(rdev))
+   if (ASIC_IS_DCE6(rdev))
return;
 
/* Silent, r600_hdmi_enable will raise WARN for us */
@@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset;
 
-   if (ASIC_IS_DCE5(rdev))
+   if (ASIC_IS_DCE6(rdev))
return;
 
/* Called for ATOM_ENCODER_MODE_HDMI only */
-- 
1.7.7

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

Re: RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

[Michel Dänzer]

On Son, 2012-06-10 at 11:56 +, Joakim Plate wrote: 
> Hi, 
> 
> I'm currently trying to make use of OML_sync_control extension to schedule 
> presentation of video frames in xbmc.
> 
> I've run into somewhat of a snag. It seem the spec doesn't specify what
> time the UST clock really is, nor can i find any mention of it elsewhere
> in docs.
> 
> Code wise it seem to be using do_gettimeofday(), which seems like a rather
> poor choice given that it can jump forward and back in time due to
> settimeofday calls. 
> 
> We normally make use of clock_gettime(CLOCK_MONOTONIC) to timestamp display
> of video frames, so to avoid major changes I'd need a way to convert to 
> gettimeofday (seem same as CLOCK_REALTIME).
> 
> Currently i'm trying:
>   struct timespec mon, rel;
>   clock_gettime(CLOCK_MONOTONIC, &mon);
>   clock_gettime(CLOCK_REALTIME , &rel);
> 
>   ticks += (rel.tv_sec  - mon.tv_sec)  * 10;
>   ticks += (rel.tv_nsec - mon.tv_nsec);
> 
> To convert between the two, but that is quite a hack both in the
> possibility of clock changes and scheduling errors.
> 
> Is there a better way, or perhaps the DRI code should use CLOCK_MONOTONIC
> in the first place?

From the GLX_OML_sync_control spec:

The Unadjusted System Time (or UST) is a 64-bit monotonically
increasing counter [...]

So, without having thought a lot about potential ramifications, I'm
inclined to say that CLOCK_MONOTONIC should indeed be used.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFT][PATCH] drm/radeon/hdmi: enable audio on Cayman

[Christian König]

Yeah, just gotten to the same conclusion a second before your last mail 
arrives Heureka! We got HDMI audio on Cayman!


Please merge that with your other patch and resend it to the list.

Cheers,
Christian.

On 11.06.2012 11:38, Rafał Miłecki wrote:

---
  drivers/gpu/drm/radeon/ni.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
if (r)
return r;

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

@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)

  int cayman_suspend(struct radeon_device *rdev)
  {
+   r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
radeon_ib_pool_suspend(rdev);
radeon_vm_manager_suspend(rdev);


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

[RFT][PATCH] drm/radeon/hdmi: enable audio on Cayman

[Rafał Miłecki]

---
 drivers/gpu/drm/radeon/ni.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
if (r)
return r;
 
+   r = r600_audio_init(rdev);
+   if (r)
+   return r;
+
return 0;
 }
 
@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
 
 int cayman_suspend(struct radeon_device *rdev)
 {
+   r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
radeon_ib_pool_suspend(rdev);
radeon_vm_manager_suspend(rdev);
-- 
1.7.7

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

Re: [PATCH][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

[Rafał Miłecki]

2012/6/11 Rafał Miłecki :
> 2012/6/10 Christian König :
>> Unfortunately testing it with my Cayman based card shows that it plays with
>> the correct speed, audio registers seems to be ok, but unfortunately I don't
>> hear any sound at all :(
>
> If you can easily switch between fglrx and radeon, comparing
> "avivotool regs hdmi" should give a quick hint. Unless you have better
> debugging tools at AMD :)

Cayman is the latest DCE5, it uses different init code (see ni.c). You
probably just need to put audio init in ni.c :)

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

[PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices

[Daniel Vetter]

There's the neat little problem that some systems die if vga decoding
isn't decoded anywhere, because linux disabled that pci device.

Atm we solve that problem by simple not calling pci_disable_device at
driver unregister time for drm pci devices. Which isn't to great
because it leaks a pci_enable_device reference on module reload and
also is rather inconsistent, since the driver load codcode in
drm/drm_pci.c _does_ call pci_disable_device on the load error path.

To fix this issue, let the vga arbiter hold a pci_enable_device
reference on its own when the vga device decodes anything. This leaves
the issue still open when the vga arbiter isn't loaded/compiled in,
but I guess since drm module unload is riddled with dragons it's ok to
say "just don't do this".

v2: ret needs to be signed, otherwise ERR_PTR will just store a large
positive value on 64bit machines. Noticed by Jani Nikula.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/vga/vgaarb.c |   26 +-
 1 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 3df8fc0..c0b1271 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -49,7 +49,11 @@
 static void vga_arbiter_notify_clients(void);
 /*
  * We keep a list of all vga devices in the system to speed
- * up the various operations of the arbiter
+ * up the various operations of the arbiter. Note that vgaarb keeps a
+ * pci_enable_device reference for all vga devices with owns != 0. This is to
+ * avoid drm devices from killing the system when they call pci_disable_device
+ * on module unload (as they should), because some systems don't like it if no
+ * one decodes vga.
  */
 struct vga_device {
struct list_head list;
@@ -172,6 +176,7 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,
unsigned int wants, legacy_wants, match;
struct vga_device *conflict;
unsigned int pci_bits;
+   int ret;
u32 flags = 0;
 
/* Account for "normal" resources to lock. If we decode the legacy,
@@ -264,6 +269,10 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,
 
pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
conflict->owns &= ~lwants;
+
+   if (conflict->owns == 0)
+   pci_disable_device(conflict->pdev);
+
/* If he also owned non-legacy, that is no longer the case */
if (lwants & VGA_RSRC_LEGACY_MEM)
conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
@@ -290,6 +299,12 @@ enable_them:
if (!!(wants & VGA_RSRC_LEGACY_MASK))
flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
 
+   if (vgadev->owns == 0) {
+   ret = pci_enable_device(vgadev->pdev);
+   if (ret)
+   return ERR_PTR(ret);
+   }
+
pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);
 
if (!vgadev->bridge_has_one_vga) {
@@ -376,6 +391,8 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int 
interruptible)
if (conflict == NULL)
break;
 
+   if (IS_ERR(conflict))
+   return PTR_ERR(conflict);
 
/* We have a conflict, we wait until somebody kicks the
 * work queue. Currently we have one work queue that we
@@ -513,6 +530,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
unsigned long flags;
struct pci_bus *bus;
struct pci_dev *bridge;
+   int ret;
u16 cmd;
 
/* Only deal with VGA class devices */
@@ -582,6 +600,12 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
*pdev)
 
vga_arbiter_check_bridge_sharing(vgadev);
 
+   if (vgadev->owns != 0) {
+   ret = pci_enable_device(vgadev->pdev);
+   if (ret)
+   goto fail;
+   }
+
/* Add to the list */
list_add(&vgadev->list, &vga_list);
vga_count++;
-- 
1.7.7.6

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

Re: [Intel-gfx] [PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices

[Daniel Vetter]

On Mon, Jun 11, 2012 at 11:42:35AM +0300, Jani Nikula wrote:
> On Fri, 08 Jun 2012, Daniel Vetter  wrote:
> > There's the neat little problem that some systems die if vga decoding
> > isn't decoded anywhere, because linux disabled that pci device.
> >
> > Atm we solve that problem by simple not calling pci_disable_device at
> > driver unregister time for drm pci devices. Which isn't to great
> > because it leaks a pci_enable_device reference on module reload and
> > also is rather inconsistent, since the driver load codcode in
> > drm/drm_pci.c _does_ call pci_disable_device on the load error path.
> >
> > To fix this issue, let the vga arbiter hold a pci_enable_device
> > reference on its own when the vga device decodes anything. This leaves
> > the issue still open when the vga arbiter isn't loaded/compiled in,
> > but I guess since drm module unload is riddled with dragons it's ok to
> > say "just don't do this".
> >
> > Signed-Off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/vga/vgaarb.c |   27 +--
> >  1 files changed, 25 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> > index 3df8fc0..82f19a1 100644
> > --- a/drivers/gpu/vga/vgaarb.c
> > +++ b/drivers/gpu/vga/vgaarb.c
> > @@ -49,7 +49,11 @@
> >  static void vga_arbiter_notify_clients(void);
> >  /*
> >   * We keep a list of all vga devices in the system to speed
> > - * up the various operations of the arbiter
> > + * up the various operations of the arbiter. Note that vgaarb keeps a
> > + * pci_enable_device reference for all vga devices with owns != 0. This is 
> > to
> > + * avoid drm devices from killing the system when they call 
> > pci_disable_device
> > + * on module unload (as they should), because some systems don't like it 
> > if no
> > + * one decodes vga.
> >   */
> >  struct vga_device {
> > struct list_head list;
> > @@ -171,7 +175,7 @@ static struct vga_device *__vga_tryget(struct 
> > vga_device *vgadev,
> >  {
> > unsigned int wants, legacy_wants, match;
> > struct vga_device *conflict;
> > -   unsigned int pci_bits;
> > +   unsigned int pci_bits, ret;
> > u32 flags = 0;
> >  
> > /* Account for "normal" resources to lock. If we decode the legacy,
> > @@ -264,6 +268,10 @@ static struct vga_device *__vga_tryget(struct 
> > vga_device *vgadev,
> >  
> > pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
> > conflict->owns &= ~lwants;
> > +
> > +   if (conflict->owns == 0)
> > +   pci_disable_device(conflict->pdev);
> > +
> > /* If he also owned non-legacy, that is no longer the case */
> > if (lwants & VGA_RSRC_LEGACY_MEM)
> > conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
> > @@ -290,6 +298,12 @@ enable_them:
> > if (!!(wants & VGA_RSRC_LEGACY_MASK))
> > flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
> >  
> > +   if (vgadev->owns == 0) {
> > +   ret = pci_enable_device(vgadev->pdev);
> > +   if (ret)
> > +   return ERR_PTR(ret);
> 
> Hi Daniel, I think unsigned ret will result in a positive ERR_PTR, which
> won't be caught by IS_ERR_VALUE(). (Either that, or I need more coffee
> to get the promotion rules right. Better use signed int no matter what.)

No coffee needed on your side, ret should clearly be signed. I'll fix this
asap, thanks for catching this.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices

[Jani Nikula]

On Fri, 08 Jun 2012, Daniel Vetter  wrote:
> There's the neat little problem that some systems die if vga decoding
> isn't decoded anywhere, because linux disabled that pci device.
>
> Atm we solve that problem by simple not calling pci_disable_device at
> driver unregister time for drm pci devices. Which isn't to great
> because it leaks a pci_enable_device reference on module reload and
> also is rather inconsistent, since the driver load codcode in
> drm/drm_pci.c _does_ call pci_disable_device on the load error path.
>
> To fix this issue, let the vga arbiter hold a pci_enable_device
> reference on its own when the vga device decodes anything. This leaves
> the issue still open when the vga arbiter isn't loaded/compiled in,
> but I guess since drm module unload is riddled with dragons it's ok to
> say "just don't do this".
>
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/vga/vgaarb.c |   27 +--
>  1 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 3df8fc0..82f19a1 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -49,7 +49,11 @@
>  static void vga_arbiter_notify_clients(void);
>  /*
>   * We keep a list of all vga devices in the system to speed
> - * up the various operations of the arbiter
> + * up the various operations of the arbiter. Note that vgaarb keeps a
> + * pci_enable_device reference for all vga devices with owns != 0. This is to
> + * avoid drm devices from killing the system when they call 
> pci_disable_device
> + * on module unload (as they should), because some systems don't like it if 
> no
> + * one decodes vga.
>   */
>  struct vga_device {
>   struct list_head list;
> @@ -171,7 +175,7 @@ static struct vga_device *__vga_tryget(struct vga_device 
> *vgadev,
>  {
>   unsigned int wants, legacy_wants, match;
>   struct vga_device *conflict;
> - unsigned int pci_bits;
> + unsigned int pci_bits, ret;
>   u32 flags = 0;
>  
>   /* Account for "normal" resources to lock. If we decode the legacy,
> @@ -264,6 +268,10 @@ static struct vga_device *__vga_tryget(struct vga_device 
> *vgadev,
>  
>   pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
>   conflict->owns &= ~lwants;
> +
> + if (conflict->owns == 0)
> + pci_disable_device(conflict->pdev);
> +
>   /* If he also owned non-legacy, that is no longer the case */
>   if (lwants & VGA_RSRC_LEGACY_MEM)
>   conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
> @@ -290,6 +298,12 @@ enable_them:
>   if (!!(wants & VGA_RSRC_LEGACY_MASK))
>   flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
>  
> + if (vgadev->owns == 0) {
> + ret = pci_enable_device(vgadev->pdev);
> + if (ret)
> + return ERR_PTR(ret);

Hi Daniel, I think unsigned ret will result in a positive ERR_PTR, which
won't be caught by IS_ERR_VALUE(). (Either that, or I need more coffee
to get the promotion rules right. Better use signed int no matter what.)

BR,
Jani.


> + }
> +
>   pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);
>  
>   if (!vgadev->bridge_has_one_vga) {
> @@ -376,6 +390,8 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int 
> interruptible)
>   if (conflict == NULL)
>   break;
>  
> + if (IS_ERR(conflict))
> + return PTR_ERR(conflict);
>  
>   /* We have a conflict, we wait until somebody kicks the
>* work queue. Currently we have one work queue that we
> @@ -513,6 +529,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>   unsigned long flags;
>   struct pci_bus *bus;
>   struct pci_dev *bridge;
> + int ret;
>   u16 cmd;
>  
>   /* Only deal with VGA class devices */
> @@ -582,6 +599,12 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>  
>   vga_arbiter_check_bridge_sharing(vgadev);
>  
> + if (vgadev->owns != 0) {
> + ret = pci_enable_device(vgadev->pdev);
> + if (ret)
> + goto fail;
> + }
> +
>   /* Add to the list */
>   list_add(&vgadev->list, &vga_list);
>   vga_count++;
> -- 
> 1.7.7.6
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sis: properly initialize dev_priv->object_idr

[Daniel Vetter]

Spotted while reviewing the same patch for drm/via by Németh Márton.

Cc: sta...@vger.kernel.org
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/sis/sis_drv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
index 30d98d1..c7263a4 100644
--- a/drivers/gpu/drm/sis/sis_drv.c
+++ b/drivers/gpu/drm/sis/sis_drv.c
@@ -49,7 +49,7 @@ static int sis_driver_load(struct drm_device *dev, unsigned 
long chipset)
 
dev->dev_private = (void *)dev_priv;
dev_priv->chipset = chipset;
-   idr_init(&dev->object_name_idr);
+   idr_init(&dev_priv->object_idr);
 
return 0;
 }
-- 
1.7.10

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

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
> On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> > > On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter  wrote:
> > > >
> > > > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > > > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
> > > 
> > > Hmm. Now *I* can't reproduce it either.
> > > 
> > > I have updated my system in the meantime, so maybe this is related to
> > > that. However, I suspect it's more likely that it's some race
> > > condition, because when I got it, I got a *lot* of it, but they were
> > > all very tightly bunched together:
> > > 
> > >  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > >  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> > > intel_dp_check_edp+0x5d/0xb0()
> > > 
> > > ie that's 12 of those warnings (each of them with that huge backtrace
> > > etc), but they are all within 0.03 seconds of each other. So I suspect
> > > it needs to hit some particular timing window, and I was just
> > > (un)lucky.
> > > 
> > > Because when I try it now with DRM debugging, I can't hit it. And just
> > > to make sure, I re-did the test without debugging too (in case the
> > > debugging would have changed timing), but can't reproduce it that way
> > > either.
> > 
> > Meh, I've been totally blind. Note to self: Next time around actually look
> > at the backtrace. And I dunno how that escaped our dear QA that long ...
> 
> Even more meh, this patch might actually work a bit better.
> 
> /me doesn't have an edp panel to test this

v3 is tested by our QA and hopefully works. I'll send it to Dave for
-fixes in a few days, attached below just in case. Please yell if this
doesn't fix your edp dmesg spam.

Thanks, Daniel
---
>From 2b64c5549c000a1c552b8c617129569e3784336f Mon Sep 17 00:00:00 2001
From: Daniel Vetter 
Date: Thu, 7 Jun 2012 08:59:49 +0200
Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect

We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).

v2: Actually enable edp vdd early enough. I've missed one dp aux
channel thingy ...

v3: We also enable/disable vdd in get_edid, which is called from
within ->detect if a monitor is connected. But because we do some
more dp aux transfers afterwards, vdd is actually off and we hit the
WARN again. Hence move vdd enabling/disabling out of get_edid into the
callsite.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds 
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Tested-by: Yang Guang 
Cc: sta...@vger.kernel.org
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..941edbf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2114,13 +2114,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
 static struct edid *
 intel_dp_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
 {
-   struct intel_dp *intel_dp = intel_attached_dp(connector);
-   struct edid *edid;
-
-   ironlake_edp_panel_vdd_on(intel_dp);
-   edid = drm_get_edid(connector, adapter);
-   ironlake_edp_panel_vdd_off(intel_dp, false);
-   return edid;
+   return drm_get_edid(connector, adapter);
 }
 
 static int
@@ -2152,6 +2146,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
 
intel_dp->has_audio = false;
 
+   ironlake_edp_panel_vdd_on(intel_dp);
if (HAS_PCH_SPLIT(dev))
status = ironlake_dp_detec

Re: [PATCH] drm via: initialize object_idr

[Daniel Vetter]

On Sun, Jun 10, 2012 at 11:39:55PM +0200, Németh Márton wrote:
> From: Márton Németh 
> 
> The field obejct_idr of struct drm_via_private was introduced with the
> commit 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc
>  .
> In that patch idr_init(&dev->object_name_idr) was called instead of
> idr_init(&dev_priv->object_idr) by mistake, leaving the dev_priv->object_idr
> uninitialized. To be more exact, the object_idr buffer is filled with zeros
> because of kzalloc(), but the dev_priv->object_idr.lock spinlock can cause
> system freeze at lib/idr.c:move_to_free_list() when spin_lock_irqsave()
> is called on this spinlock.
> 
> The patch was tested on Clevo D4J, model D410J laptop, on the following
> hardware, without AGP kernel module loaded:
> 
>   # lspci -s 01:00.0 -n
>   01:00.0 0300: 1106:3108 (rev 01)
>   # lspci -s 01:00.0 -v
>   01:00.0 VGA compatible controller: VIA Technologies, Inc. 
> K8M800/K8N800/K8N800A [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA 
> controller])
>   Subsystem: CLEVO/KAPOK Computer Device 4702
>   Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>   Memory at f000 (32-bit, prefetchable) [size=64M]
>   Memory at d100 (32-bit, non-prefetchable) [size=16M]
>   Expansion ROM at  [disabled]
>   Capabilities: [60] Power Management version 2
>   Capabilities: [70] AGP version 3.0
> 
> Signed-off-by: Márton Németh 

Meh, I fail, thanks for catching this. Although the drm/sis driver has the
same problem, care to write that patch, too? In any case:

Reviewed-by: Daniel Vetter 
Cc: sta...@vger.kernel.org

-Daniel

> ---
> diff --git a/drivers/gpu/drm/via/via_map.c b/drivers/gpu/drm/via/via_map.c
> index 1f18225..c126182 100644
> --- a/drivers/gpu/drm/via/via_map.c
> +++ b/drivers/gpu/drm/via/via_map.c
> @@ -100,12 +100,11 @@ int via_driver_load(struct drm_device *dev, unsigned 
> long chipset)
>   if (dev_priv == NULL)
>   return -ENOMEM;
> 
> + idr_init(&dev_priv->object_idr);
>   dev->dev_private = (void *)dev_priv;
> 
>   dev_priv->chipset = chipset;
> 
> - idr_init(&dev->object_name_idr);
> -
>   pci_set_master(dev->pdev);
> 
>   ret = drm_vblank_init(dev, 1);

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Documentation: DRM framework documentation

[Hans Verkuil]

On Mon June 11 2012 08:47:59 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Thursday 07 June 2012 11:13:30 Hans Verkuil wrote:
> > Hi Laurent!
> > 
> > I completely missed this when you posted this a week ago, but thank you for
> > doing this. One suggestion: cross-post the next version to linux-media as
> > well: I think this is useful for V4L2 as well.
> 
> I didn't think it would be useful, but sure, I can do that?

It's not directly useful, but it helps the V4L community understand the DRM
subsystem and hopefully lead to better cooperation. Also, having V4L people
with little experience of DRM review the document should help in improving the
documentation.

Regards,

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