[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #10 from Kris Scott  ---
Yes, those fixed it. Thank you very much.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/ab5f7ef4/attachment.html>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
>  wrote:
> > Alex Deucher  writes:
> >
> >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
> >>  wrote:
> >>>
> >>>
> >>> Alex Deucher  wrote:
> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>  wrote:
> > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
> >>  wrote:
> >> > On my test machine Xorg doesn't start anymore when I kexec into a
> >> > 3.11.0-rc3 kernel.
> >>
> >> With kexec, dpm doesn't get torn down properly which can result in a
> >> bad hardware state when the driver loads again.  Does the attached
> >> patch help?  It attempts to disable dpm at startup in case it wasn't
> >> torn down properly previously.
> >
> > dpm initialization now works, but unfortunately GPU acceleration
> still gets
> > disabled:
> 
> Stupid kexec complicates things.  We need to make sure dpm is torn
> down before we init the rest of the GPU, but dpm needs get initialized
> later in the init process since it depends on certain other state from
> the driver.  I need to think about this for a bit.  I'm not sure of a
> good way to handle this.
> >>>
> >>> You might just want to implement a shutdown method that cleans things up 
> >>> properly.   At least as a first pass until you worry about things like 
> >>> kexec on panic.
> >>>
> >>> Or can you not shutdown the graphics stack on reboot because of the need 
> >>> to display the kernels shutdown progress?
> >>
> >> Does kexec actually call this shutdown method?  The driver implements
> >> appropriate clean-up measures if it's shutdown properly.
> >
> > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> > kexec.
> >
> > You don't get a device remove/hotunplug but unless this is a kexec on
> > panic ->shutdown is most definitely called.  Now I am talking about the
> > device layer/pci layer shutdown method I don't know how gpu drivers are
> > wired up.  GPU land was a little strange last I looked.  Hopefully it
> > isn't so strange that there is a method named shutdown that is not wired
> > up.
> 
> It doesn't look like the drm infrastructure has a shutdown callback.
> The drm drivers register a drm_driver callback struct that includes an
> unload callback which takes care of all the device teardown (if you
> unload the module for example).  I don't know that it actually gets
> called at kexec time however.  I don't know enough about how kexec
> works.
> 
> Markus, does everything work ok after a reboot?  Is it just kexec that
> is a problem?

Yes.

-- 
Markus

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Hohahiu]

Hello, Dave!

I have a hybrid muxless laptop with intel+radeon:
#lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core 
processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 
Cape Verde [Radeon HD 7700M Series]

I have some questions related to this series of patches.
When I power down discrete card by vgaswitcheroo, restart X server and 
turn on radeon card again, xrandr doesn't recognize my discrete card and 
only shows the intel one. Is this a bug or a feature of X server?
And how would this behavior change with this patch?

Also sometimes I have the following configuration:
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:DIS: :Pwr::01:00.0
1:IGD:+:Pwr::00:02.0

In this case if I do
# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
the system hangs and doesn't respond (ssh, magic keys etc.).

In the meantime for a
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::00:02.0
1:DIS: :Pwr::01:00.0

# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
powers down discrete card successfully.

Would it be resolved with these patches?

Hohahiu

PS. Should I open bug report for these issues?

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
 > 
 > > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
 > > loaded.
 > > (Note, no X running on that box)
 > > 
 > > Trace below shows trinity, but I can reproduce it with just cat
 > > /proc/dri/0/vma
 > 
 > How about this, lets just rip it all out.

No-one objected, and this is still around in 3.11-rc3 in the same
easily oopsable state.. I vote we kill it with fire.

Dave

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #9 from Rafa? Mi?ecki  ---
@Kris: thank you for you debugging! I hope this is last debugging request.

Can you boot not working (bad) kernel, connect HDMI display and then type:

avivotool regset 0x0524 0x00249f00
avivotool regset 0x0528 0x00714be8
avivotool regset 0x0534 0x0001

I hope this will resume audio on your card, but I just want to be sure, before
asking Alex for getting more details on that.

If you could confirm that above 3 commands fix audio for you, it'd be great.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/4dc88e8e/attachment.html>

[Bug 67107] Xorg starts and crashes with DPM enable

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

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

--- Comment #3 from Christopher Chmielewski  ---
I just tried with rc3 and it still happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/03a42ad8/attachment.html>

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

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

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

Nicholas Miell  changed:

   What|Removed |Added

Summary|Trine 2 color problems on   |Trine 2's fragment normal
   |Radeon HD 6770 (Juniper)|buffer is mixtextured on
   ||Radeon HD 6770 (Juniper)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/7c7c7000/attachment-0001.html>

[pull] radeon drm-fixes-3.11

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

A few more radeon bug fixes, mostly for SI dpm.  At this point dpm is
pretty solid across the majority of asics.  I think we mostly just have
corner cases and fixing up some of the trickier features at this point.

The following changes since commit bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:

  Merge tag 'drm-intel-fixes-2013-07-25' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
20:38:14 +1000)

are available in the git repository at:

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

Alex Deucher (10):
  drm/radeon: fix audio dto programming on DCE4+
  drm/radeon/dpm: fix display gap programming on SI
  drm/radeon/dpm: fix si_calculate_memory_refresh_rate()
  drm/radeon/dpm: fix powertune handling for pci id 0x6835
  drm/radeon: properly handle cg on asics without UVD
  drm/radeon/atom: fix fb when fetching engine params
  drm/radeon/dpm: fix forcing performance state to low on cayman
  drm/radeon/si: disable cgcg and pg for now
  drm/radeon/dpm: disable cac setup on SI
  drm/radeon/dpm: fix and enable reclocking on SI

 drivers/gpu/drm/radeon/evergreen_hdmi.c  |2 +-
 drivers/gpu/drm/radeon/ni_dpm.c  |7 +-
 drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
 drivers/gpu/drm/radeon/si.c  |   14 
 drivers/gpu/drm/radeon/si_dpm.c  |   34 ++---
 5 files changed, 24 insertions(+), 35 deletions(-)

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 18:14 +0200, Joshua C. wrote:
> 
> This error message seems similar to mine "[drm:r600_uvd_ring_test]
> *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)" Bugzilla:
> https://bugs.freedesktop.org/show_bug.cgi?id=67276 In my case I blame
> another commit for this. Are these bugs related?

I guess not, because reverting commit 9cc2e0e9f13 doesn't fix the issue
for me. 
Can you check if reverting commit f5d9b7f0f9 does fixes the problem for
you?

-- 
Markus

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Joshua C.]

2013/7/29 Alex Deucher :
> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>  wrote:
>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>>  wrote:
>>> > On my test machine Xorg doesn't start anymore when I kexec into a
>>> > 3.11.0-rc3 kernel.
>>>
>>> With kexec, dpm doesn't get torn down properly which can result in a
>>> bad hardware state when the driver loads again.  Does the attached
>>> patch help?  It attempts to disable dpm at startup in case it wasn't
>>> torn down properly previously.
>>
>> dpm initialization now works, but unfortunately GPU acceleration still gets
>> disabled:
>
> Stupid kexec complicates things.  We need to make sure dpm is torn
> down before we init the rest of the GPU, but dpm needs get initialized
> later in the init process since it depends on certain other state from
> the driver.  I need to think about this for a bit.  I'm not sure of a
> good way to handle this.
>
> Alex
>
>>
>> [drm] Initialized drm 1.1.0 20060810 
>>  
>>   [135/1104]
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
>> [drm] register mmio base: 0xFBEE
>> [drm] register mmio size: 65536
>> ATOM BIOS: 113
>> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
>> (128M used)
>> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
>> [drm] Detected VRAM RAM=128M, BAR=128M
>> [drm] RAM width 32bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [TTM] Initializing pool allocator
>> [TTM] Initializing DMA pool allocator
>> [drm] radeon: 128M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] Loading RS780 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>> radeon :01:05.0: WB enabled
>> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
>> and cpu addr 0x880215c30c00
>> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
>> and cpu addr 0x880215c30c0c
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> [drm] radeon: irq initialized.
>> radeon :01:05.0: setting latency timer to 64
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
>> radeon :01:05.0: disabling GPU acceleration
>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   VGA-1
>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] Connector 1:
>> [drm]   DVI-D-1
>> [drm]   HPD3
>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>> [drm]   Encoders:
>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>> == power state 0 ==
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c r b
>> == power state 1 ==
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status:
>> == power state 2 ==
>> ui class: none
>> internal class: uvd
>> caps: video
>> uvdvclk: 53300 dclk: 4
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 5 vddc_index: 1
>> status:
>> switching from power state:
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c b
>> switching to power state:
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status: r
>> [drm] radeon: dpm initialized
>> [drm] fb mappable at 0xF0142000
>> [drm] vram apper at 0xF000
>> [drm] size 7299072
>> [drm] fb depth is 24
>> [drm]pitch is 6912
>> fbcon: radeondrmfb (fb0)
>>
>> --
>> Markus
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> 

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

0094

Audio conn list:
R600_AUDIO_CONN_LIST_LEN0001
R600_AUDIO_CONN_LIST08060402

Audio verbs:
R600_AUDIO_RATE_BPS_CHANNEL0011
R600_AUDIO_PLAYING0010
R600_AUDIO_IMPLEMENTATION_ID104d2e00
R600_AUDIO_CONFIG_DEFAULT18560010
R600_AUDIO_PIN_SENSE7fff
R600_AUDIO_PIN_WIDGET_CNTL40404040
R600_AUDIO_STATUS_BITS0001

HDMI block at 0x7400:
74000011 (17)
7404 (0)
74080010 (16)
740c0001 (65536)
7410 (0)
7414 (0)
7418 (0)
741c (0)
7420 (0)
7424 (0)
7428 (0)
742c (0)
7430 (0)
7434 (0)
7438 (0)
743c (0)
7440 (0)
7444 (0)
7448 (0)
744c (0)
7450 (0)
7454 (0)
7458 (0)
745c (0)
74600200 (33554432)
7464 (0)
7468 (0)
746c (0)
7470 (0)
7474 (0)
7478 (0)
747c (0)
7480 (0)
7484 (0)
7488 (0)
748c (0)
7490 (0)
7494 (0)
7498 (0)
749c (0)
74a0 (0)
74a4 (0)
74a8 (0)
74ac (0)
74b0 (0)
74b4 (0)
74b8 (0)
74bc (0)
74c0 (0)
74c4 (0)
74c8 (0)
74cc0170 (368)
74d0 (0)
74d41000 (268435456)
74d8 (0)
74dc (0)
74e0 (0)
74e4 (0)
74e8 (0)
74ec (0)

HDMI block at 0x7800:
78000011 (17)
78040001 (65536)
780800030010 (196624)
780c1000 (4096)
78100031 (49)
78140033 (51)
78180202 (514)
781c (0)
7820 (0)
7824 (0)
7828 (0)
782c (0)
7830 (0)
7834 (0)
7838 (0)
783c (0)
7840 (0)
7844 (0)
7848 (0)
784c (0)
7850 (0)
785400080063 (524387)
78580004 (4)
785c (0)
78600200 (33554432)
7864 (0)
7868 (0)
786c (0)
7870 (0)
7874 (0)
7878 (0)
787c (0)
7880 (0)
7884 (0)
7888 (0)
788c (0)
7890 (0)
7894 (0)
7898 (0)
789c (0)
78a0 (0)
78a4 (0)
78a8 (0)
78ac1220a000 (304128000)
78b01000 (4096)
78b414244000 (33792)
78b81880 (6272)
78bc1220a000 (304128000)
78c01800 (6144)
78c40cb19000 (212963328)
78c81800 (6144)
78cc0170 (368)
78d0 (0)
78d40200 (33554432)
78d80002 (2)
78dc1100 (4352)
78e000ff (16777215)
78e4007f (8388607)
78e80001 (1)
78ec0001 (1)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/f3fa47dc/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #7 from Rafa? Mi?ecki  ---
Err, did you call "avivotool regs hdmi" as I asked?

It should return something like:

Audio clocks:
EVERGREEN_AUDIO_PLL1_MUL
EVERGREEN_AUDIO_PLL1_DIV0001
EVERGREEN_AUDIO_PLL1_UNK0070

which is the most interesting part for us.

Of course on R6xx hardware it won't start with EVERGREEN_*

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/37393ece/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #6 from Kris Scott  ---
Good:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTL804df8a8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b8bebc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-
Bad:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTLc045fab8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b836bc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/cac4ae74/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #5 from Rafa? Mi?ecki  ---
As I suggested earlier, can you provide output of "avivotool regs hdmi" before
and after this patch?

This way we will sure if registers are programmed and with what values.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/fff46053/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #4 from Kris Scott  ---
Bisect complete:

b1f6f47e3e33c4a74534f1301aca241ffabbb3a0 is the first bad commit
commit b1f6f47e3e33c4a74534f1301aca241ffabbb3a0
Author: Alex Deucher 
Date:   Thu Apr 18 10:50:55 2013 -0400

drm/radeon: clean up audio dto programming

Split into DCE2/3 and DCE4/5 variants. Still todo is to
calculate the DTO dividers properly.  Add proper formula
to the comments.

Reviewed-by: Christian K?nig 
Signed-off-by: Alex Deucher 

:04 04 b60cf880f2227596705391e71a56aaa12e1eb61c
a723f4928d1a20bcd0b5759077360f9342c9eecc Mdrivers

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/e1e0c32b/attachment-0001.html>

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

On Mon, 29 Jul 2013 16:29:04 +1000 Dave Airlie  wrote:
>
> Okay should all be back in place now.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/3702faca/attachment-0001.pgp>

linux-next: problem fetching the drm-intel-fixes tree

[Dave Airlie]

On Mon, Jul 29, 2013 at 10:26 AM, Stephen Rothwell  
wrote:
> Hi Dave,
>
> On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie  wrote:
>>
>> > Trying to fetch the drm-intel-fixes tree
>> > (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
>> > morning produced this error:
>>
>> There is some issue with personal fdo repos at the moment and anon git,
>>
>> I'll ask admin to look into it.
>
> Thanks.  In the mean time, I will use what I fetched on Friday.

Okay should all be back in place now.

Dave.

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>  wrote:
> > On my test machine Xorg doesn't start anymore when I kexec into a
> > 3.11.0-rc3 kernel.
> 
> With kexec, dpm doesn't get torn down properly which can result in a
> bad hardware state when the driver loads again.  Does the attached
> patch help?  It attempts to disable dpm at startup in case it wasn't
> torn down properly previously.

dpm initialization now works, but unfortunately GPU acceleration still gets
disabled:

[drm] Initialized drm 1.1.0 20060810

[135/1104]
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c30c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c30c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 1 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU acceleration
radeon :01:05.0: 8802161cfc00 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912
fbcon: radeondrmfb (fb0)

-- 
Markus

[PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Dave Airlie]

Add support for HDMI audio device on VGA cards that powerdown
to D3cold using non-standard ACPI/PCI infrastructure (optimus).

This does a couple of things to make it work:

a) add a set of power ops for the hdmi domain, and enables them
via vga_switcheroo when we are a switcheroo controlled card. This
just replaces the runtime resume operation so that when the card
is in D3cold the userspace pci config space access via sysfs,
the vga switcheroon runtime resume gets called first and it calls
the GPU resume callback before calling the sound card runtime
resume.

b) standard ACPI/PCI stacks won't put a device into D3cold without
an ACPI handle, but since the hdmi audio devices on gpus don't have
an ACPI handle, we need to manually force the device into D3cold
after suspend from the switcheroo path only.

c) don't try and do runtime s/r when the GPU is off.

d) call runtime suspend/resume during switcheroo suspend/resume
this is to make sure the runtime stack knows to try and resume
the hdmi audio device for pci config space access.

Signed-off-by: Dave Airlie 
---
 sound/pci/hda/hda_intel.c | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 8860dd5..4b4d05b 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -555,6 +555,9 @@ struct azx {
 #ifdef CONFIG_SND_HDA_DSP_LOADER
struct azx_dev saved_azx_dev;
 #endif
+
+   /* secondary power domain for hdmi audio under vga device */
+   struct dev_pm_domain hdmi_pm_domain;
 };

 #define CREATE_TRACE_POINTS
@@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const struct 
kernel_param *kp)
 /*
  * power management
  */
-static int azx_suspend(struct device *dev)
+static int azx_do_suspend(struct device *dev, pci_power_t state)
 {
struct pci_dev *pci = to_pci_dev(dev);
struct snd_card *card = dev_get_drvdata(dev);
@@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
free_irq(chip->irq, chip);
chip->irq = -1;
}
+
+   /*
+* for vga switcheroo suspend we need to
+* force runtime suspend so lspci works.
+*/
+   if (state == PCI_D3cold)
+   pm_runtime_suspend(>dev);
+
if (chip->msi)
pci_disable_msi(chip->pci);
pci_disable_device(pci);
pci_save_state(pci);
-   pci_set_power_state(pci, PCI_D3hot);
+
+   pci_set_power_state(pci, state);
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
hda_display_power(false);
return 0;
 }

+static int azx_suspend(struct device *dev)
+{
+   return azx_do_suspend(dev, PCI_D3hot);
+}
+
 static int azx_resume(struct device *dev)
 {
struct pci_dev *pci = to_pci_dev(dev);
@@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
azx_stop_chip(chip);
azx_enter_link_reset(chip);
azx_clear_irq_pending(chip);
@@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
hda_display_power(true);
azx_init_pci(chip);
@@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
if (!power_save_controller ||
!(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
return -EBUSY;
@@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
   "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
   disabled ? "Disabling" : "Enabling");
if (disabled) {
-   azx_suspend(>dev);
+   azx_do_suspend(>dev, PCI_D3cold);
+   /* when we get suspended by vga switcheroo we end up in 
D3cold,
+* however we have no ACPI handle, so pci/acpi can't 
put us there,
+* put ourselves there */
+   pci->current_state = PCI_D3cold;
chip->disabled = true;
if (snd_hda_lock_devices(chip->bus))
snd_printk(KERN_WARNING SFX "%s: Cannot lock 
devices!\n",
@@ -3087,6 +3117,7 @@ static void azx_vs_set_state(struct pci_dev *pci,
snd_hda_unlock_devices(chip->bus);
chip->disabled = false;
azx_resume(>dev);
+   

[PATCH 3/4] nouveau: add runtime PM support (v0.7)

[Dave Airlie]

From: Dave Airlie 

This hooks nouveau up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and optimus laptops.

a) rewrite suspend/resume printks to hide them during dynamic s/r
to avoid cluttering logs
b) add runtime pm suspend to irq handler, crtc display, ioctl handler,
connector status,
c) handle hdmi audio dynamic power on/off using magic register.

v0.5:
make sure we hit D3 properly
fix fbdev_set_suspend locking interaction, we only will poweroff if we have no
active crtcs/fbcon anyways.
add reference for active crtcs.
sprinkle mark last busy for autosuspend timeout

v0.6:
allow more flexible debugging - to avoid log spam
add option to enable/disable dynpm
got to D3Cold

v0.7:
add hdmi audio support.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/core/core/printk.c |  19 ++
 drivers/gpu/drm/nouveau/core/include/core/printk.h |  13 ++
 drivers/gpu/drm/nouveau/core/subdev/bios/init.c|   2 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c  |   5 +
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|  49 +++-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  42 +++-
 drivers/gpu/drm/nouveau/nouveau_connector.c|  27 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  12 +-
 drivers/gpu/drm/nouveau/nouveau_display.h  |   2 +
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 247 +++--
 drivers/gpu/drm/nouveau/nouveau_drm.h  |   9 +
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  14 +-
 12 files changed, 399 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/printk.c 
b/drivers/gpu/drm/nouveau/core/core/printk.c
index 6161eaf..52fb2aa 100644
--- a/drivers/gpu/drm/nouveau/core/core/printk.c
+++ b/drivers/gpu/drm/nouveau/core/core/printk.c
@@ -27,6 +27,8 @@
 #include 
 #include 

+int nv_printk_suspend_level = NV_DBG_DEBUG;
+
 void
 nv_printk_(struct nouveau_object *object, const char *pfx, int level,
   const char *fmt, ...)
@@ -72,3 +74,20 @@ nv_printk_(struct nouveau_object *object, const char *pfx, 
int level,
vprintk(mfmt, args);
va_end(args);
 }
+
+#define CONV_LEVEL(x) case NV_DBG_##x: return NV_PRINTK_##x
+
+const char *nv_printk_level_to_pfx(int level)
+{
+   switch (level) {
+   CONV_LEVEL(FATAL);
+   CONV_LEVEL(ERROR);
+   CONV_LEVEL(WARN);
+   CONV_LEVEL(INFO);
+   CONV_LEVEL(DEBUG);
+   CONV_LEVEL(PARANOIA);
+   CONV_LEVEL(TRACE);
+   CONV_LEVEL(SPAM);
+   }
+   return NV_PRINTK_DEBUG;
+}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/printk.h 
b/drivers/gpu/drm/nouveau/core/include/core/printk.h
index febed2e..d87836e 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/printk.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/printk.h
@@ -15,6 +15,12 @@ struct nouveau_object;
 #define NV_PRINTK_TRACEKERN_DEBUG
 #define NV_PRINTK_SPAM KERN_DEBUG

+extern int nv_printk_suspend_level;
+
+#define NV_DBG_SUSPEND (nv_printk_suspend_level)
+#define NV_PRINTK_SUSPEND  (nv_printk_level_to_pfx(nv_printk_suspend_level))
+
+const char *nv_printk_level_to_pfx(int level);
 void __printf(4, 5)
 nv_printk_(struct nouveau_object *, const char *, int, const char *, ...);

@@ -31,6 +37,13 @@ nv_printk_(struct nouveau_object *, const char *, int, const 
char *, ...);
 #define nv_trace(o,f,a...) nv_printk((o), TRACE, f, ##a)
 #define nv_spam(o,f,a...) nv_printk((o), SPAM, f, ##a)

+#define nv_suspend(o,f,a...) nv_printk((o), SUSPEND, f, ##a)
+
+static inline void nv_suspend_set_printk_level(int level)
+{
+   nv_printk_suspend_level = level;
+}
+
 #define nv_assert(f,a...) do { 
\
if (NV_DBG_FATAL <= CONFIG_NOUVEAU_DEBUG)  \
nv_printk_(NULL, NV_PRINTK_FATAL, NV_DBG_FATAL, f "\n", ##a);  \
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
index 0687e64..2e11ea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
@@ -2165,7 +2165,7 @@ nvbios_init(struct nouveau_subdev *subdev, bool execute)
u16 data;

if (execute)
-   nv_info(bios, "running init tables\n");
+   nv_suspend(bios, "running init tables\n");
while (!ret && (data = (init_script(bios, ++i {
struct nvbios_init init = {
.subdev = subdev,
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index 1c0330b..b6afd98 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,16 +23,20 @@
  */

 #include 
+#include 

 static irqreturn_t
 nouveau_mc_intr(int irq, void *arg)
 {
struct nouveau_mc *pmc = arg;
const struct nouveau_mc_intr *map = pmc->intr_map;

[PATCH 2/4] drm: allow open of dynamic off devices.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fops.c | 2 +-
 include/drm/drmP.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..d5429ee 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -257,7 +257,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
return -EBUSY;  /* No exclusive opens */
if (!drm_cpu_valid())
return -EINVAL;
-   if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
+   if (dev->switch_power_state != DRM_SWITCH_POWER_ON && 
dev->switch_power_state != DRM_SWITCH_POWER_DYNAMIC_OFF)
return -EINVAL;

DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor_id);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 12083dc..7f8acaf 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1223,6 +1223,7 @@ struct drm_device {
 #define DRM_SWITCH_POWER_ON 0
 #define DRM_SWITCH_POWER_OFF 1
 #define DRM_SWITCH_POWER_CHANGING 2
+#define DRM_SWITCH_POWER_DYNAMIC_OFF 3

 static __inline__ int drm_core_check_feature(struct drm_device *dev,
 int feature)
-- 
1.8.2.1

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Dave Airlie]

From: Dave Airlie 

For optimus and powerxpress muxless we really want the GPU
driver deciding when to power up/down the GPU, not userspace.

This adds the ability for a driver to dynamically power up/down
the GPU and remove the switcheroo from controlling it, the
switcheroo reports the dynamic state to userspace also.

It also adds 2 power domains, one for machine where the power
switch is controlled outside the GPU D3 state, so the powerdown
ordering is done correctly, and the second for the hdmi audio
device to make sure it can resume for PCI config space accesses.

v1.1: fix build with switcheroo off

v2: add power domain support for radeon and v1 nvidia dsms
v2.1: fix typo in off case

v3: add audio power domain for hdmi audio + misc audio fixes

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_dma.c|   2 +-
 drivers/gpu/drm/nouveau/nouveau_vga.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   2 +-
 drivers/gpu/vga/vga_switcheroo.c   | 147 +++--
 include/linux/vga_switcheroo.h |  13 ++-
 5 files changed, 156 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b152068..5f930a1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1293,7 +1293,7 @@ static int i915_load_modeset_init(struct drm_device *dev)

intel_register_dsm_handler();

-   ret = vga_switcheroo_register_client(dev->pdev, _switcheroo_ops);
+   ret = vga_switcheroo_register_client(dev->pdev, _switcheroo_ops, 
false);
if (ret)
goto cleanup_vga_client;

diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 25d3495..40a09f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -79,7 +79,7 @@ nouveau_vga_init(struct nouveau_drm *drm)
 {
struct drm_device *dev = drm->dev;
vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
-   vga_switcheroo_register_client(dev->pdev, _switcheroo_ops);
+   vga_switcheroo_register_client(dev->pdev, _switcheroo_ops, 
false);
 }

 void
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 82335e3..0610ca4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1269,7 +1269,7 @@ int radeon_device_init(struct radeon_device *rdev,
/* this will fail for cards that aren't VGA class devices, just
 * ignore it */
vga_client_register(rdev->pdev, rdev, NULL, radeon_vga_set_decode);
-   vga_switcheroo_register_client(rdev->pdev, _switcheroo_ops);
+   vga_switcheroo_register_client(rdev->pdev, _switcheroo_ops, 
false);

r = radeon_init(rdev);
if (r)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index cf787e1..afb3956 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -37,6 +38,7 @@ struct vga_switcheroo_client {
const struct vga_switcheroo_client_ops *ops;
int id;
bool active;
+   bool driver_power_control;
struct list_head list;
 };

@@ -132,7 +134,7 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);

 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
-  int id, bool active)
+  int id, bool active, bool driver_power_control)
 {
struct vga_switcheroo_client *client;

@@ -145,6 +147,7 @@ static int register_client(struct pci_dev *pdev,
client->ops = ops;
client->id = id;
client->active = active;
+   client->driver_power_control = driver_power_control;

mutex_lock(_mutex);
list_add_tail(>list, _priv.clients);
@@ -160,10 +163,11 @@ static int register_client(struct pci_dev *pdev,
 }

 int vga_switcheroo_register_client(struct pci_dev *pdev,
-  const struct vga_switcheroo_client_ops *ops)
+  const struct vga_switcheroo_client_ops *ops,
+  bool driver_power_control)
 {
return register_client(pdev, ops, -1,
-  pdev == vga_default_device());
+  pdev == vga_default_device(), 
driver_power_control);
 }
 EXPORT_SYMBOL(vga_switcheroo_register_client);

@@ -171,7 +175,7 @@ int vga_switcheroo_register_audio_client(struct pci_dev 
*pdev,
 const struct vga_switcheroo_client_ops 
*ops,
 int id, bool active)
 {
-   return register_client(pdev, ops, id | ID_BIT_AUDIO, active);
+   return register_client(pdev, ops, id | ID_BIT_AUDIO, active, false);
 }
 

nouveau optimus dynamic power off

[Dave Airlie]

I finally got back to debugging the HDMI audio interactions that
stopped me last time,

This adds switcheroo + nouveau + hda_intel support for turning
off the secondary GPU in optimus laptops, saving a lot of power.

The GPU should come back on for things like lspci on the devices
or for DRI_PRIME= or X starting up.

Signed-off-by: Dave Airlie 

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

[Maarten Lankhorst]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
 wrote:
> Alex Deucher  writes:
>
>> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
>>  wrote:
>>>
>>>
>>> Alex Deucher  wrote:
On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 wrote:
> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>  wrote:
>> > On my test machine Xorg doesn't start anymore when I kexec into a
>> > 3.11.0-rc3 kernel.
>>
>> With kexec, dpm doesn't get torn down properly which can result in a
>> bad hardware state when the driver loads again.  Does the attached
>> patch help?  It attempts to disable dpm at startup in case it wasn't
>> torn down properly previously.
>
> dpm initialization now works, but unfortunately GPU acceleration
still gets
> disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.
>>>
>>> You might just want to implement a shutdown method that cleans things up 
>>> properly.   At least as a first pass until you worry about things like 
>>> kexec on panic.
>>>
>>> Or can you not shutdown the graphics stack on reboot because of the need to 
>>> display the kernels shutdown progress?
>>
>> Does kexec actually call this shutdown method?  The driver implements
>> appropriate clean-up measures if it's shutdown properly.
>
> Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> kexec.
>
> You don't get a device remove/hotunplug but unless this is a kexec on
> panic ->shutdown is most definitely called.  Now I am talking about the
> device layer/pci layer shutdown method I don't know how gpu drivers are
> wired up.  GPU land was a little strange last I looked.  Hopefully it
> isn't so strange that there is a method named shutdown that is not wired
> up.

It doesn't look like the drm infrastructure has a shutdown callback.
The drm drivers register a drm_driver callback struct that includes an
unload callback which takes care of all the device teardown (if you
unload the module for example).  I don't know that it actually gets
called at kexec time however.  I don't know enough about how kexec
works.

Markus, does everything work ok after a reboot?  Is it just kexec that
is a problem?

Alex

[PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Takashi Iwai]

At Mon, 29 Jul 2013 16:06:59 +1000,
Dave Airlie wrote:
> 
> Add support for HDMI audio device on VGA cards that powerdown
> to D3cold using non-standard ACPI/PCI infrastructure (optimus).
> 
> This does a couple of things to make it work:
> 
> a) add a set of power ops for the hdmi domain, and enables them
> via vga_switcheroo when we are a switcheroo controlled card. This
> just replaces the runtime resume operation so that when the card
> is in D3cold the userspace pci config space access via sysfs,
> the vga switcheroon runtime resume gets called first and it calls
> the GPU resume callback before calling the sound card runtime
> resume.
> 
> b) standard ACPI/PCI stacks won't put a device into D3cold without
> an ACPI handle, but since the hdmi audio devices on gpus don't have
> an ACPI handle, we need to manually force the device into D3cold
> after suspend from the switcheroo path only.
> 
> c) don't try and do runtime s/r when the GPU is off.
> 
> d) call runtime suspend/resume during switcheroo suspend/resume
> this is to make sure the runtime stack knows to try and resume
> the hdmi audio device for pci config space access.
> 
> Signed-off-by: Dave Airlie 
> ---
>  sound/pci/hda/hda_intel.c | 40 +---
>  1 file changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 8860dd5..4b4d05b 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -555,6 +555,9 @@ struct azx {
>  #ifdef CONFIG_SND_HDA_DSP_LOADER
>   struct azx_dev saved_azx_dev;
>  #endif
> +
> + /* secondary power domain for hdmi audio under vga device */
> + struct dev_pm_domain hdmi_pm_domain;
>  };
>  
>  #define CREATE_TRACE_POINTS
> @@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const struct 
> kernel_param *kp)
>  /*
>   * power management
>   */
> -static int azx_suspend(struct device *dev)
> +static int azx_do_suspend(struct device *dev, pci_power_t state)
>  {
>   struct pci_dev *pci = to_pci_dev(dev);
>   struct snd_card *card = dev_get_drvdata(dev);
> @@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
>   free_irq(chip->irq, chip);
>   chip->irq = -1;
>   }
> +
> + /*
> +  * for vga switcheroo suspend we need to
> +  * force runtime suspend so lspci works.
> +  */
> + if (state == PCI_D3cold)
> + pm_runtime_suspend(>dev);
> +
>   if (chip->msi)
>   pci_disable_msi(chip->pci);
>   pci_disable_device(pci);
>   pci_save_state(pci);
> - pci_set_power_state(pci, PCI_D3hot);
> +
> + pci_set_power_state(pci, state);
>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>   hda_display_power(false);
>   return 0;
>  }
>  
> +static int azx_suspend(struct device *dev)
> +{
> + return azx_do_suspend(dev, PCI_D3hot);
> +}
> +
>  static int azx_resume(struct device *dev)
>  {
>   struct pci_dev *pci = to_pci_dev(dev);
> @@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   azx_stop_chip(chip);
>   azx_enter_link_reset(chip);
>   azx_clear_irq_pending(chip);
> @@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>   hda_display_power(true);
>   azx_init_pci(chip);
> @@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   if (!power_save_controller ||
>   !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
>   return -EBUSY;
> @@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
>  "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
>  disabled ? "Disabling" : "Enabling");
>   if (disabled) {
> - azx_suspend(>dev);
> + azx_do_suspend(>dev, PCI_D3cold);
> + /* when we get suspended by vga switcheroo we end up in 
> D3cold,
> +  * however we have no ACPI handle, so pci/acpi can't 
> put us there,
> +  * put ourselves there */
> + pci->current_state = PCI_D3cold;
>   chip->disabled = true;
>   if (snd_hda_lock_devices(chip->bus))
>   snd_printk(KERN_WARNING SFX "%s: Cannot lock 
> devices!\n",
> @@ -3087,6 +3117,7 @@ static void 

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
 wrote:
>
>
> Alex Deucher  wrote:
>>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>> wrote:
>>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  wrote:
 > On my test machine Xorg doesn't start anymore when I kexec into a
 > 3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.
>>>
>>> dpm initialization now works, but unfortunately GPU acceleration
>>still gets
>>> disabled:
>>
>>Stupid kexec complicates things.  We need to make sure dpm is torn
>>down before we init the rest of the GPU, but dpm needs get initialized
>>later in the init process since it depends on certain other state from
>>the driver.  I need to think about this for a bit.  I'm not sure of a
>>good way to handle this.
>
> You might just want to implement a shutdown method that cleans things up 
> properly.   At least as a first pass until you worry about things like kexec 
> on panic.
>
> Or can you not shutdown the graphics stack on reboot because of the need to 
> display the kernels shutdown progress?

Does kexec actually call this shutdown method?  The driver implements
appropriate clean-up measures if it's shutdown properly.

Alex


>
> Eric
>
>>Alex
>>
>>>
>>> [drm] Initialized drm 1.1.0 20060810
>> [135/1104]
>>> [drm] radeon kernel modesetting enabled.
>>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614
>>0x1043:0x834D).
>>> [drm] register mmio base: 0xFBEE
>>> [drm] register mmio size: 65536
>>> ATOM BIOS: 113
>>> radeon :01:05.0: VRAM: 128M 0xC000 -
>>0xC7FF (128M used)
>>> radeon :01:05.0: GTT: 512M 0xA000 -
>>0xBFFF
>>> [drm] Detected VRAM RAM=128M, BAR=128M
>>> [drm] RAM width 32bits DDR
>>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>>> [TTM] Initializing pool allocator
>>> [TTM] Initializing DMA pool allocator
>>> [drm] radeon: 128M of VRAM memory ready
>>> [drm] radeon: 512M of GTT memory ready.
>>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>>> [drm] Loading RS780 Microcode
>>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>>> radeon :01:05.0: WB enabled
>>> radeon :01:05.0: fence driver on ring 0 use gpu addr
>>0xac00 and cpu addr 0x880215c30c00
>>> radeon :01:05.0: fence driver on ring 3 use gpu addr
>>0xac0c and cpu addr 0x880215c30c0c
>>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>>> [drm] Driver supports precise vblank timestamp query.
>>> [drm] radeon: irq initialized.
>>> radeon :01:05.0: setting latency timer to 64
>>> [drm] ring test on 0 succeeded in 1 usecs
>>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
>>(0xCAFEDEAD)
>>> radeon :01:05.0: disabling GPU acceleration
>>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>>> [drm] Radeon Display Connectors
>>> [drm] Connector 0:
>>> [drm]   VGA-1
>>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>>> [drm]   Encoders:
>>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>> [drm] Connector 1:
>>> [drm]   DVI-D-1
>>> [drm]   HPD3
>>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>>> [drm]   Encoders:
>>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>>> == power state 0 ==
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c r b
>>> == power state 1 ==
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status:
>>> == power state 2 ==
>>> ui class: none
>>> internal class: uvd
>>> caps: video
>>> uvdvclk: 53300 dclk: 4
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 5 vddc_index: 1
>>> status:
>>> switching from power state:
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c b
>>> switching to power state:
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 12:14 PM, Joshua C.  wrote:
> 2013/7/29 Alex Deucher :
>> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>>  wrote:
>>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  wrote:
 > On my test machine Xorg doesn't start anymore when I kexec into a
 > 3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.
>>>
>>> dpm initialization now works, but unfortunately GPU acceleration still gets
>>> disabled:
>>
>> Stupid kexec complicates things.  We need to make sure dpm is torn
>> down before we init the rest of the GPU, but dpm needs get initialized
>> later in the init process since it depends on certain other state from
>> the driver.  I need to think about this for a bit.  I'm not sure of a
>> good way to handle this.
>>
>> Alex
>>
>>>
>>> [drm] Initialized drm 1.1.0 20060810
>>> 
>>> [135/1104]
>>> [drm] radeon kernel modesetting enabled.
>>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
>>> [drm] register mmio base: 0xFBEE
>>> [drm] register mmio size: 65536
>>> ATOM BIOS: 113
>>> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
>>> (128M used)
>>> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
>>> [drm] Detected VRAM RAM=128M, BAR=128M
>>> [drm] RAM width 32bits DDR
>>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>>> [TTM] Initializing pool allocator
>>> [TTM] Initializing DMA pool allocator
>>> [drm] radeon: 128M of VRAM memory ready
>>> [drm] radeon: 512M of GTT memory ready.
>>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>>> [drm] Loading RS780 Microcode
>>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>>> radeon :01:05.0: WB enabled
>>> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
>>> and cpu addr 0x880215c30c00
>>> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
>>> and cpu addr 0x880215c30c0c
>>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>>> [drm] Driver supports precise vblank timestamp query.
>>> [drm] radeon: irq initialized.
>>> radeon :01:05.0: setting latency timer to 64
>>> [drm] ring test on 0 succeeded in 1 usecs
>>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
>>> radeon :01:05.0: disabling GPU acceleration
>>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>>> [drm] Radeon Display Connectors
>>> [drm] Connector 0:
>>> [drm]   VGA-1
>>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>>> [drm]   Encoders:
>>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>> [drm] Connector 1:
>>> [drm]   DVI-D-1
>>> [drm]   HPD3
>>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>>> [drm]   Encoders:
>>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>>> == power state 0 ==
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c r b
>>> == power state 1 ==
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status:
>>> == power state 2 ==
>>> ui class: none
>>> internal class: uvd
>>> caps: video
>>> uvdvclk: 53300 dclk: 4
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 5 vddc_index: 1
>>> status:
>>> switching from power state:
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c b
>>> switching to power state:
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status: r
>>> [drm] radeon: dpm initialized
>>> [drm] fb mappable at 0xF0142000
>>> [drm] vram apper at 0xF000
>>> [drm] size 7299072
>>> [drm] fb depth is 24
>>> [drm]pitch is 6912
>>> fbcon: radeondrmfb 

[PATCH] drm/nouveau: protect vm refcount with mutex

[Maarten Lankhorst]

The refcount was not protected by the vm lock, fix this..

[ cut here ]
WARNING: CPU: 2 PID: 2008 at drivers/gpu/drm/nouveau/core/core/mm.c:242 
nouveau_mm_fini+0x4f/0x56 [nouveau]()
Modules linked in: adt7475 ebtable_nat ebtables nouveau ipt_MASQUERADE 
iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc 
snd_hda_codec_hdmi kvm_intel ttm kvm drm_kms_helper drm mxm_wmi 
snd_hda_codec_realtek snd_hda_intel e1000e snd_hda_codec snd_hwdep snd_pcm ptp 
pps_core snd_page_alloc video parport_pc ppdev nfsd parport lockd nfs_acl 
auth_rpcgss sunrpc oid_registry
CPU: 2 PID: 2008 Comm: Xorg Tainted: GW3.11.0-rc1-patser+ #119
Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
 00f2 8803f59b1b68 81637988 b0b0
  8803f59b1ba8 81059e1d 
  8803f9dd6c48 8803f9dd6c00 8803f688d898
Call Trace:
 [] dump_stack+0x55/0x86
 [] warn_slowpath_common+0x87/0xaf
 [] warn_slowpath_null+0x15/0x17
 [] nouveau_mm_fini+0x4f/0x56 [nouveau]
 [] nouveau_vm_ref+0x154/0x180 [nouveau]
 [] ? nouveau_mm_free+0x85/0x116 [nouveau]
 [] nouveau_vm_put+0x9a/0xb0 [nouveau]
 [] ? nouveau_gem_info+0x9d/0x9d [nouveau]
 [] nouveau_gem_object_delete+0x19/0x28 [nouveau]
 [] nouveau_fence_work+0xc9/0x102 [nouveau]
 [] nouveau_gem_object_close+0x103/0x182 [nouveau]
 [] drm_gem_handle_delete+0xcc/0x153 [drm]
 [] drm_gem_close_ioctl+0x23/0x25 [drm]
 [] drm_ioctl+0x4cc/0x612 [drm]
 [] ? __slab_free.isra.66+0x24d/0x2aa
 [] ? drm_gem_destroy+0x4c/0x4c [drm]
 [] ? avc_has_perm_flags+0xb1/0x179
 [] do_vfs_ioctl+0x8b/0x4f8
 [] ? inode_has_perm.isra.43.constprop.75+0x25/0x2b
 [] ? file_has_perm+0x8c/0x9a
 [] ? rcu_user_exit+0xe/0x10
 [] SyS_ioctl+0x8a/0x9b
 [] tracesys+0xdd/0xe2
---[ end trace f99ff0179509b495 ]---

Signed-off-by: Maarten Lankhorst 
---

diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 3b90b42..afc5106 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -28,6 +28,8 @@
 #include 
 #include 

+static void nouveau_vm_del(struct nouveau_vm *vm);
+
 void
 nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
 {
@@ -335,10 +337,10 @@ nouveau_vm_get(struct nouveau_vm *vm, u64 size, u32 
page_shift,
return ret;
}
}
+   ++vm->refcount;
+   vma->vm = vm;
mutex_unlock(_subdev(vmm)->mutex);

-   vma->vm = NULL;
-   nouveau_vm_ref(vm, >vm, NULL);
vma->offset = (u64)vma->node->offset << 12;
 #ifdef NOUVEAU_VM_POISON
if (vm->poison)
@@ -353,7 +355,7 @@ nouveau_vm_put(struct nouveau_vma *vma)
 {
struct nouveau_vm *vm = vma->vm;
struct nouveau_vmmgr *vmm = vm->vmm;
-   u32 fpde, lpde;
+   u32 fpde, lpde, ref;

if (unlikely(vma->node == NULL))
return;
@@ -363,9 +365,12 @@ nouveau_vm_put(struct nouveau_vma *vma)
mutex_lock(_subdev(vmm)->mutex);
nouveau_vm_unmap_pgt(vm, vma->node->type != vmm->spg_shift, fpde, lpde);
nouveau_mm_free(>mm, >node);
-   mutex_unlock(_subdev(vmm)->mutex);

-   nouveau_vm_ref(NULL, >vm, NULL);
+   vma->vm = NULL;
+   ref = --vm->refcount;
+   mutex_unlock(_subdev(vmm)->mutex);
+   if (!ref)
+   nouveau_vm_del(vm);
 }

 int
@@ -429,25 +434,21 @@ nouveau_vm_link(struct nouveau_vm *vm, struct 
nouveau_gpuobj *pgd)

nouveau_gpuobj_ref(pgd, >obj);

-   mutex_lock(_subdev(vmm)->mutex);
for (i = vm->fpde; i <= vm->lpde; i++)
vmm->map_pgt(pgd, i, vm->pgt[i - vm->fpde].obj);
list_add(>head, >pgd_list);
-   mutex_unlock(_subdev(vmm)->mutex);
return 0;
 }

 static void
 nouveau_vm_unlink(struct nouveau_vm *vm, struct nouveau_gpuobj *mpgd)
 {
-   struct nouveau_vmmgr *vmm = vm->vmm;
struct nouveau_vm_pgd *vpgd, *tmp;
struct nouveau_gpuobj *pgd = NULL;

if (!mpgd)
return;

-   mutex_lock(_subdev(vmm)->mutex);
list_for_each_entry_safe(vpgd, tmp, >pgd_list, head) {
if (vpgd->obj == mpgd) {
pgd = vpgd->obj;
@@ -456,7 +457,6 @@ nouveau_vm_unlink(struct nouveau_vm *vm, struct 
nouveau_gpuobj *mpgd)
break;
}
}
-   mutex_unlock(_subdev(vmm)->mutex);

nouveau_gpuobj_ref(NULL, );
 }
@@ -489,20 +489,31 @@ nouveau_vm_ref(struct nouveau_vm *ref, struct nouveau_vm 
**ptr,

vm = ref;
if (vm) {
+   struct nouveau_vmmgr *vmm = vm->vmm;
+
+   mutex_lock(_subdev(vmm)->mutex);
ret = nouveau_vm_link(vm, pgd);
-   if (ret)
+   if (ret) {
+   mutex_unlock(_subdev(vmm)->mutex);
return ret;
+   }

[PATCH] Fix #include in drm_mm.h to unbreak ia64 build

[Luck, Tony]

Linux-next build on ia64 is falling over with errors like this:

In file included from include/drm/drm_vma_manager.h:26,
 from include/drm/ttm/ttm_bo_api.h:35,
 from include/drm/ttm/ttm_bo_driver.h:33,
 from drivers/gpu/drm/ttm/ttm_agp_backend.c:35:
include/drm/drm_mm.h:67: error: expected specifier-qualifier-list before 
'spinlock_t'

I guess other architectures are pulling in spinlock.h
through some twisty #include path so are not seeing this
error.  But drm_mm.h makes use of spinlock_t - so it
should do the right thing and #include 

Signed-off-by: Tony Luck 

---

First saw this break in tag "next-20130726"

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index b87d05e..7d5fbae 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -37,6 +37,7 @@
  * Generic range manager structs
  */
 #include 
+#include 
 #ifdef CONFIG_DEBUG_FS
 #include 
 #endif

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

Alex Deucher  writes:

> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
>  wrote:
>>
>>
>> Alex Deucher  wrote:
>>>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>>> wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>  wrote:
> > On my test machine Xorg doesn't start anymore when I kexec into a
> > 3.11.0-rc3 kernel.
>
> With kexec, dpm doesn't get torn down properly which can result in a
> bad hardware state when the driver loads again.  Does the attached
> patch help?  It attempts to disable dpm at startup in case it wasn't
> torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration
>>>still gets
 disabled:
>>>
>>>Stupid kexec complicates things.  We need to make sure dpm is torn
>>>down before we init the rest of the GPU, but dpm needs get initialized
>>>later in the init process since it depends on certain other state from
>>>the driver.  I need to think about this for a bit.  I'm not sure of a
>>>good way to handle this.
>>
>> You might just want to implement a shutdown method that cleans things up 
>> properly.   At least as a first pass until you worry about things like kexec 
>> on panic.
>>
>> Or can you not shutdown the graphics stack on reboot because of the need to 
>> display the kernels shutdown progress?
>
> Does kexec actually call this shutdown method?  The driver implements
> appropriate clean-up measures if it's shutdown properly.

Absoltuely.  All parts of the reboot path call ->shutdown.  Including
kexec.

You don't get a device remove/hotunplug but unless this is a kexec on
panic ->shutdown is most definitely called.  Now I am talking about the
device layer/pci layer shutdown method I don't know how gpu drivers are
wired up.  GPU land was a little strange last I looked.  Hopefully it
isn't so strange that there is a method named shutdown that is not wired
up.

Eric

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Rob Clark]

On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey  wrote:
> Hi Rob,
>
>> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >allocate buffers for the GPU. Still not sure how to resolve this
>> >as we don't use DRM for our GPU driver.
>>
>> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
>> once the dma-fence stuff is in place), we'd have gpu-specific drm
>> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
>> using prime/dmabuf to share between the two.
>
> The "extra" buffers we were allocating from armsoc DDX were really
> being allocated through DRM/GEM so we could get an flink name
> for them and pass a reference to them back to our GPU driver on
> the client side. If it weren't for our need to access those
> extra off-screen buffers with the GPU we wouldn't need to
> allocate them with DRM at all. So, given they are really "GPU"
> buffers, it does absolutely make sense to allocate them in a
> different driver to the display driver.
>
> However, to avoid unnecessary memcpys & related cache
> maintenance ops, we'd also like the GPU to render into buffers
> which are scanned out by the display controller. So let's say
> we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
> out buffers with the display's DRM driver but a custom ioctl
> on the GPU's DRM driver to allocate non scanout, off-screen
> buffers. Sounds great, but I don't think that really works
> with DRI2. If we used two drivers to allocate buffers, which
> of those drivers do we return in DRI2ConnectReply? Even if we
> solve that somehow, GEM flink names are name-spaced to a
> single device node (AFAIK). So when we do a DRI2GetBuffers,
> how does the EGL in the client know which DRM device owns GEM
> flink name "1234"? We'd need some pretty dirty hacks.

You would return the name of the display driver allocating the
buffers.  On the client side you can use generic ioctls to go from
flink -> handle -> dmabuf.  So the client side would end up opening
both the display drm device and the gpu, but without needing to know
too much about the display.

(Probably in (for example) mesa there needs to be a bit of work to
handle this better, but I think that would be needed as well for
sharing between, say, nouveau and udl displaylink driver.. which is
really the same scenario.)

> So then we looked at allocating _all_ buffers with the GPU's
> DRM driver. That solves the DRI2 single-device-name and single
> name-space issue. It also means the GPU would _never_ render
> into buffers allocated through DRM_IOCTL_MODE_CREATE_DUMB.

Well, I think we can differentiate between shared buffers and internal
buffers (textures, vertex upload, etc, etc).

For example, in mesa/gallium driver there are two paths to getting a
buffer...  ->resource_create() and ->resource_from_handle(), the
latter is the path you go for dri2 buffers shared w/ x11.  The former
is buffers that are just internal to gpu (if !(bind &
PIPE_BIND_SHARED)).  I guess you must have something similar in mali
driver.

> One thing I wasn't sure about is if there was an objection
> to using PRIME to export scanout buffers allocated with
> DRM_IOCTL_MODE_CREATE_DUMB and then importing them into a GPU
> driver to be rendered into? Is that a concern?

well.. it wasn't quite the original intention of the 'dumb' ioctls.
But I guess in the end if you hand the gpu a buffer with a
layout/format that it can't grok, then gpu does a staging texture plus
copy.  If you had, for example, some setup w/ gpu that could only
render to tiled format, plus a display that could scanout that format,
then your DDX driver would need to allocate the dri2 buffers with
something other than dumb ioctl.  (But at that point, you probably
need to implement your own EXA so you could hook in your own custom
upload-to/download-from screen fxns for sw fallbacks, so you're not
talking about using generic DDX anyways.)

> Anyway, that latter case also gets quite difficult. The "GPU"
> DRM driver would need to know the constraints of the display
> controller when allocating buffers intended to be scanned out.
> For example, pl111 typically isn't behind an IOMMU and so
> requires physically contiguous memory. We'd have to teach the
> GPU's DRM driver about the constraints of the display HW. Not
> exactly a clean driver model. :-(
>
> I'm still a little stuck on how to proceed, so any ideas
> would greatly appreciated! My current train of thought is
> having a kind of SoC-specific DRM driver which allocates
> buffers for both display and GPU within a single GEM
> namespace. That SoC-specific DRM driver could then know the
> constraints of both the GPU and the display HW. We could then
> use PRIME to export buffers allocated with the SoC DRM driver
> and import them into the GPU and/or display DRM driver.

Usually if the display drm driver is allocating the buffers that might
be scanned out, it just needs to have minimal knowledge of the GPU
(pitch alignment constraints). 

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie  wrote:
>
> > Trying to fetch the drm-intel-fixes tree
> > (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
> > morning produced this error:
> 
> There is some issue with personal fdo repos at the moment and anon git,
> 
> I'll ask admin to look into it.

Thanks.  In the mean time, I will use what I fetched on Friday.

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/b210386c/attachment.pgp>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 wrote:
> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>  wrote:
>> > On my test machine Xorg doesn't start anymore when I kexec into a
>> > 3.11.0-rc3 kernel.
>>
>> With kexec, dpm doesn't get torn down properly which can result in a
>> bad hardware state when the driver loads again.  Does the attached
>> patch help?  It attempts to disable dpm at startup in case it wasn't
>> torn down properly previously.
>
> dpm initialization now works, but unfortunately GPU acceleration still gets
> disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

Alex

>
> [drm] Initialized drm 1.1.0 20060810  
>   
> [135/1104]
> [drm] radeon kernel modesetting enabled.
> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
> [drm] register mmio base: 0xFBEE
> [drm] register mmio size: 65536
> ATOM BIOS: 113
> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
> used)
> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
> [drm] Detected VRAM RAM=128M, BAR=128M
> [drm] RAM width 32bits DDR
> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [TTM] Initializing pool allocator
> [TTM] Initializing DMA pool allocator
> [drm] radeon: 128M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] Loading RS780 Microcode
> [drm] PCIE GART of 512M enabled (table at 0xC004).
> radeon :01:05.0: WB enabled
> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
> and cpu addr 0x880215c30c00
> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
> and cpu addr 0x880215c30c0c
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> radeon :01:05.0: setting latency timer to 64
> [drm] ring test on 0 succeeded in 1 usecs
> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
> radeon :01:05.0: disabling GPU acceleration
> radeon :01:05.0: 8802161cfc00 unpin not necessary
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   VGA-1
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] Connector 1:
> [drm]   DVI-D-1
> [drm]   HPD3
> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [drm]   Encoders:
> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
> == power state 0 ==
> ui class: none
> internal class: boot
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 2
> power level 1sclk: 5 vddc_index: 2
> status: c r b
> == power state 1 ==
> ui class: performance
> internal class: none
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 7 vddc_index: 2
> status:
> == power state 2 ==
> ui class: none
> internal class: uvd
> caps: video
> uvdvclk: 53300 dclk: 4
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 5 vddc_index: 1
> status:
> switching from power state:
> ui class: none
> internal class: boot
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 2
> power level 1sclk: 5 vddc_index: 2
> status: c b
> switching to power state:
> ui class: performance
> internal class: none
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 7 vddc_index: 2
> status: r
> [drm] radeon: dpm initialized
> [drm] fb mappable at 0xF0142000
> [drm] vram apper at 0xF000
> [drm] size 7299072
> [drm] fb depth is 24
> [drm]pitch is 6912
> fbcon: radeondrmfb (fb0)
>
> --
> Markus

linux-next: problem fetching the drm-intel-fixes tree

[Dave Airlie]

>
> Trying to fetch the drm-intel-fixes tree
> (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
> morning produced this error:

There is some issue with personal fdo repos at the moment and anon git,

I'll ask admin to look into it.

Dave.

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

On Mon, 29 Jul 2013 10:08:43 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Trying to fetch the drm-intel-fixes tree
> (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
> morning produced this error:
> 
> fatal: remote error: access denied or repository not exported: 
> ~danvet/drm-intel

The same is true for the drm and drm-intel trees
(git://people.freedesktop.org/~airlied/linux.git#drm-next and
git://people.freedesktop.org/~danvet/drm-intel#for-linux-next)

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/026d726d/attachment.pgp>

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Trying to fetch the drm-intel-fixes tree
(git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
morning produced this error:

fatal: remote error: access denied or repository not exported: ~danvet/drm-intel
-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/7159b427/attachment.pgp>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 wrote:
> On my test machine Xorg doesn't start anymore when I kexec into a
> 3.11.0-rc3 kernel.

With kexec, dpm doesn't get torn down properly which can result in a
bad hardware state when the driver loads again.  Does the attached
patch help?  It attempts to disable dpm at startup in case it wasn't
torn down properly previously.

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-dpm-disable-dpm-before-enabling-it-to-dea.patch
Type: text/x-diff
Size: 1188 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/06e052cb/attachment.patch>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On my test machine Xorg doesn't start anymore when I kexec into a
3.11.0-rc3 kernel.
On cold boot everything is fine:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912

But after I run kexec things go wrong:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU 

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

Alex Deucher  wrote:
>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
> wrote:
>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>>  wrote:
>>> > On my test machine Xorg doesn't start anymore when I kexec into a
>>> > 3.11.0-rc3 kernel.
>>>
>>> With kexec, dpm doesn't get torn down properly which can result in a
>>> bad hardware state when the driver loads again.  Does the attached
>>> patch help?  It attempts to disable dpm at startup in case it wasn't
>>> torn down properly previously.
>>
>> dpm initialization now works, but unfortunately GPU acceleration
>still gets
>> disabled:
>
>Stupid kexec complicates things.  We need to make sure dpm is torn
>down before we init the rest of the GPU, but dpm needs get initialized
>later in the init process since it depends on certain other state from
>the driver.  I need to think about this for a bit.  I'm not sure of a
>good way to handle this.

You might just want to implement a shutdown method that cleans things up 
properly.   At least as a first pass until you worry about things like kexec on 
panic.

Or can you not shutdown the graphics stack on reboot because of the need to 
display the kernels shutdown progress?

Eric

>Alex
>
>>
>> [drm] Initialized drm 1.1.0 20060810 
> [135/1104]
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614
>0x1043:0x834D).
>> [drm] register mmio base: 0xFBEE
>> [drm] register mmio size: 65536
>> ATOM BIOS: 113
>> radeon :01:05.0: VRAM: 128M 0xC000 -
>0xC7FF (128M used)
>> radeon :01:05.0: GTT: 512M 0xA000 -
>0xBFFF
>> [drm] Detected VRAM RAM=128M, BAR=128M
>> [drm] RAM width 32bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [TTM] Initializing pool allocator
>> [TTM] Initializing DMA pool allocator
>> [drm] radeon: 128M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] Loading RS780 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>> radeon :01:05.0: WB enabled
>> radeon :01:05.0: fence driver on ring 0 use gpu addr
>0xac00 and cpu addr 0x880215c30c00
>> radeon :01:05.0: fence driver on ring 3 use gpu addr
>0xac0c and cpu addr 0x880215c30c0c
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> [drm] radeon: irq initialized.
>> radeon :01:05.0: setting latency timer to 64
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
>(0xCAFEDEAD)
>> radeon :01:05.0: disabling GPU acceleration
>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   VGA-1
>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] Connector 1:
>> [drm]   DVI-D-1
>> [drm]   HPD3
>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>> [drm]   Encoders:
>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>> == power state 0 ==
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c r b
>> == power state 1 ==
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status:
>> == power state 2 ==
>> ui class: none
>> internal class: uvd
>> caps: video
>> uvdvclk: 53300 dclk: 4
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 5 vddc_index: 1
>> status:
>> switching from power state:
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c b
>> switching to power state:
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status: r
>> [drm] radeon: dpm initialized
>> [drm] fb mappable at 0xF0142000
>> [drm] vram apper at 0xF000
>> [drm] size 7299072
>> [drm] fb 

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #3 from Rafa? Mi?ecki  ---
You can also compare output of
avivotool regs hdmi
when using 3.9 and 3.10. That should give some hint.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/926c5637/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

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

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

--- Comment #2 from Kris Scott  ---
Will do, gonna take some time though. Kernel compiling is not the fastest.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/i915: Sync the hotplug work when device suspending

[Chuansheng Liu]

It is possible that during i915 device suspending with one pending
hotplug work, one of cases is the device resume/suspend quickly.

At this case, the hotplug work will be executed even after device
is OFF, in Intel Android platform, it will cause system hang.

Here we need sync the hotplug work in function i915_drm_freeze().

Signed-off-by: Liu, Chuansheng chuansheng@intel.com
Signed-off-by: Li Fei fei...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 45b3c03..95c6956 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -562,6 +562,8 @@ static int i915_drm_freeze(struct drm_device *dev)
 
drm_irq_uninstall(dev);
dev_priv-enable_hotplug_processing = false;
+   cancel_work_sync(dev_priv-hotplug_work);
+
/*
 * Disable CRTCs directly since we want to preserve sw state
 * for _thaw.
-- 
1.7.9.5



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

Re: [git pull] drm fixes - regular pull req

[Jim Bos]

On 07/26/2013 12:52 PM, Dave Airlie wrote:
 
 This is just a regular fixes pull apart from the qxl one, it has radeon 
 and intel bits in it,
 
 the intel fixes are for a regression with the RC6 fix and a 3.10 hdmi 
 regression, whereas radeon is more DPM fixes, a few lockup fixes and 
 some rn50/r100 DAC fixes.
 
 Dave.
 
 The following changes since commit 07bc9dc1b01bad7084fed3d2659e5d83317869bc:
 
   Merge branch 'merge' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2013-07-24 
 11:07:18 -0700)
 
 are available in the git repository at:
 
 
   git://people.freedesktop.org/~airlied/linux drm-fixes
 
 for you to fetch changes up to bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:
 
   Merge tag 'drm-intel-fixes-2013-07-25' of 
 git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
 20:38:14 +1000)
 
 
 
 Alex Deucher (8):
   drm/radeon: wait for 3D idle before using CP DMA
   drm/radeon/vm: only align the pt base to 32k
   drm/radeon: fix endian issues with DP handling (v3)
   drm/radeon: improve dac adjust heuristics for legacy pdac
   drm/radeon/dpm: fix a typo in the rv6xx mclk setup
   drm/radeon/dpm: fix displaygap programming on rv6xx
   drm/radeon/dpm: implement force performance levels for rv6xx
   drm/radeon/dpm: fix r600_enable_sclk_control()
 
 Daniel Vetter (1):
   drm/i915: fix hdmi portclock limits
 
 Dave Airlie (2):
   Merge branch 'drm-fixes-3.11' of 
 git://people.freedesktop.org/~agd5f/linux into drm-fixes
   Merge tag 'drm-intel-fixes-2013-07-25' of 
 git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
 
 Jani Nikula (1):
   drm/i915: initialize gt_lock early with other spin locks
 
 Mark Kettenis (1):
   drm/radeon: fix combios tables on older cards
 
 Ondrej Zary (1):
   drm/radeon: Another card with wrong primary dac adj
 
  drivers/gpu/drm/i915/i915_dma.c |   1 +
  drivers/gpu/drm/i915/intel_hdmi.c   |  19 +++-
  drivers/gpu/drm/i915/intel_pm.c |   2 -
  drivers/gpu/drm/radeon/atombios_dp.c|  43 -
  drivers/gpu/drm/radeon/r600.c   |   5 +-
  drivers/gpu/drm/radeon/r600_dpm.c   |   4 +-
  drivers/gpu/drm/radeon/radeon_asic.c|   1 +
  drivers/gpu/drm/radeon/radeon_asic.h|   2 +
  drivers/gpu/drm/radeon/radeon_combios.c | 159 
 ++--
  drivers/gpu/drm/radeon/radeon_gart.c|   8 +-
  drivers/gpu/drm/radeon/rv6xx_dpm.c  |  41 +++-
  11 files changed, 158 insertions(+), 127 deletions(-)
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

FYI, with these commits, I'm still seeing attached stack trace and
  [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
VCPU!!! 
messages  *after* resuming from Suspend-2-Ram.

This is with new power management enabled (radeon.dpm=1) which seems to
work just fine.

_
Jim


[  198.100849] ACPI: Low-level resume complete
[  198.100883] PM: Restoring platform NVS memory
[  198.101277] Enabling non-boot CPUs ...
[  198.101305] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  198.114618] CPU1 is up
[  198.114629] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  198.127911] CPU2 is up
[  198.127922] smpboot: Booting Node 0 Processor 3 APIC 0x6
[  198.141200] CPU3 is up
[  198.143177] ACPI: Waking up from system sleep state S3
[  198.154441] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[  198.167770] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[  198.207819] pcieport :00:1c.3: System wakeup disabled by ACPI
[  198.234485] pcieport :00:1c.5: System wakeup disabled by ACPI
[  198.247912] PM: noirq resume of devices complete after 104.343 msecs
[  198.248040] PM: early resume of devices complete after 0.088 msecs
[  198.248086] ahci :00:1f.2: setting latency timer to 64
[  198.248109] ehci-pci :00:1a.0: setting latency timer to 64
[  198.248222] ehci-pci :00:1d.0: setting latency timer to 64
[  198.248319] pcieport :00:1c.6: System wakeup disabled by ACPI
[  198.251310] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[  198.251727] serial 00:02: activated
[  198.253294] [drm] PCIE GART of 512M enabled (table at 0x0025D000).
[  198.253396] radeon :01:00.0: WB enabled
[  198.253398] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0x88032d113c00
[  198.253399] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0x88032d113c0c
[  198.253873] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x0005c418 and cpu addr 0xc9001189c418
[  198.270138] [drm] ring test on 0 succeeded in 0 usecs
[  198.270200] [drm] ring test on 3 

RE: [Intel-gfx] [PATCH] drm/i915: Sync the hotplug work when device suspending

[Liu, Chuansheng]

 -Original Message-
 From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
 Sent: Saturday, July 27, 2013 5:40 PM
 To: Liu, Chuansheng
 Cc: daniel.vet...@ffwll.ch; airl...@linux.ie; 
 intel-...@lists.freedesktop.org; Li,
 Fei; dri-devel@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Sync the hotplug work when device
 suspending
 
 On Sun, Jul 28, 2013 at 01:43:02AM +0800, Chuansheng Liu wrote:
 
  It is possible that during i915 device suspending with one pending
  hotplug work, one of cases is the device resume/suspend quickly.
 
  At this case, the hotplug work will be executed even after device
  is OFF, in Intel Android platform, it will cause system hang.
 
 See
 
   1343070574-23917-1-git-send-email-ch...@chris-wilson.co.uk
   http://lists.freedesktop.org/archives/intel-gfx/2012-July/019144.html
Sorry to not know this thread before, and it seems it did not be included into 
upstream.
Moreover, in current upstream code the rps_work has been synced in 
intel_disable_gt_powersave().

So, is it possible to consider my patch based on current upstream code? Thanks.

 
 which is in response to the bug raised here
 
   s5hlilr4s9h.wl%ti...@suse.de
   http://lists.freedesktop.org/archives/intel-gfx/2012-April/016738.html
 -Chris
 
 --
 Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] i2c.c: Fixed coding style issue for if statement

[santosh.anbu]

From: santosh.anbu asantosh.k...@gmail.com

Fixed coding style issue

Signed-off-by: santosh.anbu asantosh.k...@gmail.com
---
 drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
index cfb9288..e88529c 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c
@@ -114,15 +114,19 @@ dcb_i2c_parse(struct nouveau_bios *bios, u8 idx, struct 
dcb_i2c_entry *info)
 
if (idx == 0) {
info-drive = nv_ro08(bios, ent + 4);
-   if (!info-drive) info-drive = 0x3f;
+   if (!info-drive)
+   info-drive = 0x3f;
info-sense = nv_ro08(bios, ent + 5);
-   if (!info-sense) info-sense = 0x3e;
+   if (!info-sense)
+   info-sense = 0x3e;
} else
if (idx == 1) {
info-drive = nv_ro08(bios, ent + 6);
-   if (!info-drive) info-drive = 0x37;
+   if (!info-drive)
+   info-drive = 0x37;
info-sense = nv_ro08(bios, ent + 7);
-   if (!info-sense) info-sense = 0x36;
+   if (!info-sense)
+   info-sense = 0x36;
}
 
info-type  = DCB_I2C_NV04_BIT;
-- 
1.8.1.2

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

[PATCH] drm/cirrus: fix error handling in cirrus_device_init()

[Wei Yongjun]

From: Wei Yongjun yongjun_...@trendmicro.com.cn

Fix the error handling in function cirrus_device_init() to avoid resources
leak in the error handling case.

Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 3a7a0ef..5f59bb0 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -138,17 +138,22 @@ int cirrus_device_init(struct cirrus_device *cdev,
}
 
cdev-rmmio = ioremap(cdev-rmmio_base, cdev-rmmio_size);
-
-   if (cdev-rmmio == NULL)
-   return -ENOMEM;
+   if (cdev-rmmio == NULL) {
+   ret = -ENOMEM;
+   goto err_ioremap;
+   }
 
ret = cirrus_vram_init(cdev);
-   if (ret) {
-   release_mem_region(cdev-rmmio_base, cdev-rmmio_size);
-   return ret;
-   }
+   if (ret)
+   goto err_init;
 
return 0;
+
+err_init:
+   iounmap(cdev-rmmio);
+err_ioremap:
+   release_mem_region(cdev-rmmio_base, cdev-rmmio_size);
+   return ret;
 }
 
 void cirrus_device_fini(struct cirrus_device *cdev)

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

[RFC 7/9] backports: backport ww_mutex support

[Luis R. Rodriguez]

From: Luis R. Rodriguez mcg...@do-not-panic.com

This backports the kernel's wound/wait style locks 040a0a371,
using the linux-stable v3.11-rc2 as a base for development.
Given the complexity to support debugging mutexes this backport
implementation is simplified by only making this feature availabe
if you to have DEBUG_MUTEXES and DEBUG_LOCK_ALLOC disabled. Given
that ww mutex is required for DRM this also means we must update
the kconfig for DRM and require you to also not be able to build
DRM if you have either of these options enabled. Support for
DEBUG_MUTEXES and DEBUG_LOCK_ALLOC can be added later by anyone
daring.

Part of the ww mutex addition to the kernel required modifying
the fast path mutex locking scheme by requiring you to deal
with the slow path alternatives on your own (refer to a41b56ef).
The reason for this change was that the mutex fastpath implementation
assumed your slowpath alternative can only be passed one argument
and the addition of ww mutexes requires dealing with the slow
path with a context passed.

It'd be painful to backport all asm for an optimized fastpath
implementation so we penalize the backport ww mutex fast path
by using the generic atomic_dec_return().

To backport a clean our own mutex_lock_common() with the least
amount of changes against upstream commits 2bd2c92c and 41fcb9f2
also needed to be backported. Commit 2bd2c92c dealt with adding
support for queue mutex spinners with an MCS lock, since this
cannot be backported for older kernels we provide empty inlines.
Commit 41fcb9f2 just removed SCHED_FEAT_OWNER_SPIN as it was an
early hack, the only thing required to backport this commit was
to provide an alternative declaration for mutex_spin_on_owner()
as it was declared non-inline for older kernels.

Finally c5491ea7 required backporting schedule_preempt_disabled()
as well but that just consisted of carrying over the original
implementation. Since its not exported we need to reimplement
it to make it available to our internal core ww mutex port.

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 040a0a371
v3.11-rc1~147^2~5

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains a41b56ef
v3.11-rc1~147^2~6

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 2bd2c92c
v3.10-rc1~200^2~3

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 41fcb9f2
v3.10-rc1~200^2~5

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains c5491ea7
v3.4-rc1~3^2~27

commit 040a0a37100563754bb1fee6ff6427420bcfa609
Author: Maarten Lankhorst maarten.lankho...@canonical.com
Date:   Mon Jun 24 10:30:04 2013 +0200

mutex: Add support for wound/wait style locks

Wound/wait mutexes are used when other multiple lock
acquisitions of a similar type can be done in an arbitrary
order. The deadlock handling used here is called wait/wound in
the RDBMS literature: The older tasks waits until it can acquire
the contended lock. The younger tasks needs to back off and drop
all the locks it is currently holding, i.e. the younger task is
wounded.

For full documentation please read Documentation/ww-mutex-design.txt.

References: https://lwn.net/Articles/548909/
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Rob Clark robdcl...@gmail.com
Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: rost...@goodmis.org
Cc: dan...@ffwll.ch
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Link: http://lkml.kernel.org/r/51c8038c.9000...@canonical.com
Signed-off-by: Ingo Molnar mi...@kernel.org

commit a41b56efa70e060f650aeb54740aaf52044a1ead
Author: Maarten Lankhorst maarten.lankho...@canonical.com
Date:   Thu Jun 20 13:31:05 2013 +0200

arch: Make __mutex_fastpath_lock_retval return whether fastpath succeeded 
or not

This will allow me to call functions that have multiple
arguments if fastpath fails. This is required to support ticket
mutexes, because they need to be able to pass an extra argument
to the fail function.

Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg. This ended up being just a
duplication of the existing function, so a way to test if
fastpath was called ended up being better.

This also cleaned up the reservation mutex patch some by being
able to call an atomic_set instead of atomic_xchg, and making it
easier to detect if the wrong unlock function was previously
used.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: robcl...@gmail.com
Cc: rost...@goodmis.org
Cc: 

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #3 from Rafał Miłecki zaj...@gmail.com ---
You can also compare output of
avivotool regs hdmi
when using 3.9 and 3.10. That should give some hint.

-- 
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

[PATCH 3/4] nouveau: add runtime PM support (v0.7)

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This hooks nouveau up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and optimus laptops.

a) rewrite suspend/resume printks to hide them during dynamic s/r
to avoid cluttering logs
b) add runtime pm suspend to irq handler, crtc display, ioctl handler,
connector status,
c) handle hdmi audio dynamic power on/off using magic register.

v0.5:
make sure we hit D3 properly
fix fbdev_set_suspend locking interaction, we only will poweroff if we have no
active crtcs/fbcon anyways.
add reference for active crtcs.
sprinkle mark last busy for autosuspend timeout

v0.6:
allow more flexible debugging - to avoid log spam
add option to enable/disable dynpm
got to D3Cold

v0.7:
add hdmi audio support.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/nouveau/core/core/printk.c |  19 ++
 drivers/gpu/drm/nouveau/core/include/core/printk.h |  13 ++
 drivers/gpu/drm/nouveau/core/subdev/bios/init.c|   2 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c  |   5 +
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|  49 +++-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  42 +++-
 drivers/gpu/drm/nouveau/nouveau_connector.c|  27 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  12 +-
 drivers/gpu/drm/nouveau/nouveau_display.h  |   2 +
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 247 +++--
 drivers/gpu/drm/nouveau/nouveau_drm.h  |   9 +
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  14 +-
 12 files changed, 399 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/printk.c 
b/drivers/gpu/drm/nouveau/core/core/printk.c
index 6161eaf..52fb2aa 100644
--- a/drivers/gpu/drm/nouveau/core/core/printk.c
+++ b/drivers/gpu/drm/nouveau/core/core/printk.c
@@ -27,6 +27,8 @@
 #include core/subdev.h
 #include core/printk.h
 
+int nv_printk_suspend_level = NV_DBG_DEBUG;
+
 void
 nv_printk_(struct nouveau_object *object, const char *pfx, int level,
   const char *fmt, ...)
@@ -72,3 +74,20 @@ nv_printk_(struct nouveau_object *object, const char *pfx, 
int level,
vprintk(mfmt, args);
va_end(args);
 }
+
+#define CONV_LEVEL(x) case NV_DBG_##x: return NV_PRINTK_##x
+
+const char *nv_printk_level_to_pfx(int level)
+{
+   switch (level) {
+   CONV_LEVEL(FATAL);
+   CONV_LEVEL(ERROR);
+   CONV_LEVEL(WARN);
+   CONV_LEVEL(INFO);
+   CONV_LEVEL(DEBUG);
+   CONV_LEVEL(PARANOIA);
+   CONV_LEVEL(TRACE);
+   CONV_LEVEL(SPAM);
+   }
+   return NV_PRINTK_DEBUG;
+}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/printk.h 
b/drivers/gpu/drm/nouveau/core/include/core/printk.h
index febed2e..d87836e 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/printk.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/printk.h
@@ -15,6 +15,12 @@ struct nouveau_object;
 #define NV_PRINTK_TRACEKERN_DEBUG
 #define NV_PRINTK_SPAM KERN_DEBUG
 
+extern int nv_printk_suspend_level;
+
+#define NV_DBG_SUSPEND (nv_printk_suspend_level)
+#define NV_PRINTK_SUSPEND  (nv_printk_level_to_pfx(nv_printk_suspend_level))
+
+const char *nv_printk_level_to_pfx(int level);
 void __printf(4, 5)
 nv_printk_(struct nouveau_object *, const char *, int, const char *, ...);
 
@@ -31,6 +37,13 @@ nv_printk_(struct nouveau_object *, const char *, int, const 
char *, ...);
 #define nv_trace(o,f,a...) nv_printk((o), TRACE, f, ##a)
 #define nv_spam(o,f,a...) nv_printk((o), SPAM, f, ##a)
 
+#define nv_suspend(o,f,a...) nv_printk((o), SUSPEND, f, ##a)
+
+static inline void nv_suspend_set_printk_level(int level)
+{
+   nv_printk_suspend_level = level;
+}
+
 #define nv_assert(f,a...) do { 
\
if (NV_DBG_FATAL = CONFIG_NOUVEAU_DEBUG)  \
nv_printk_(NULL, NV_PRINTK_FATAL, NV_DBG_FATAL, f \n, ##a);  \
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
index 0687e64..2e11ea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
@@ -2165,7 +2165,7 @@ nvbios_init(struct nouveau_subdev *subdev, bool execute)
u16 data;
 
if (execute)
-   nv_info(bios, running init tables\n);
+   nv_suspend(bios, running init tables\n);
while (!ret  (data = (init_script(bios, ++i {
struct nvbios_init init = {
.subdev = subdev,
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index 1c0330b..b6afd98 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,16 +23,20 @@
  */
 
 #include subdev/mc.h
+#include linux/pm_runtime.h
 
 static irqreturn_t
 nouveau_mc_intr(int irq, void *arg)
 {
struct nouveau_mc 

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Dave Airlie]

From: Dave Airlie airl...@dhcp-40-90.bne.redhat.com

For optimus and powerxpress muxless we really want the GPU
driver deciding when to power up/down the GPU, not userspace.

This adds the ability for a driver to dynamically power up/down
the GPU and remove the switcheroo from controlling it, the
switcheroo reports the dynamic state to userspace also.

It also adds 2 power domains, one for machine where the power
switch is controlled outside the GPU D3 state, so the powerdown
ordering is done correctly, and the second for the hdmi audio
device to make sure it can resume for PCI config space accesses.

v1.1: fix build with switcheroo off

v2: add power domain support for radeon and v1 nvidia dsms
v2.1: fix typo in off case

v3: add audio power domain for hdmi audio + misc audio fixes

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/i915/i915_dma.c|   2 +-
 drivers/gpu/drm/nouveau/nouveau_vga.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   2 +-
 drivers/gpu/vga/vga_switcheroo.c   | 147 +++--
 include/linux/vga_switcheroo.h |  13 ++-
 5 files changed, 156 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b152068..5f930a1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1293,7 +1293,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
intel_register_dsm_handler();
 
-   ret = vga_switcheroo_register_client(dev-pdev, i915_switcheroo_ops);
+   ret = vga_switcheroo_register_client(dev-pdev, i915_switcheroo_ops, 
false);
if (ret)
goto cleanup_vga_client;
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 25d3495..40a09f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -79,7 +79,7 @@ nouveau_vga_init(struct nouveau_drm *drm)
 {
struct drm_device *dev = drm-dev;
vga_client_register(dev-pdev, dev, NULL, nouveau_vga_set_decode);
-   vga_switcheroo_register_client(dev-pdev, nouveau_switcheroo_ops);
+   vga_switcheroo_register_client(dev-pdev, nouveau_switcheroo_ops, 
false);
 }
 
 void
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 82335e3..0610ca4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1269,7 +1269,7 @@ int radeon_device_init(struct radeon_device *rdev,
/* this will fail for cards that aren't VGA class devices, just
 * ignore it */
vga_client_register(rdev-pdev, rdev, NULL, radeon_vga_set_decode);
-   vga_switcheroo_register_client(rdev-pdev, radeon_switcheroo_ops);
+   vga_switcheroo_register_client(rdev-pdev, radeon_switcheroo_ops, 
false);
 
r = radeon_init(rdev);
if (r)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index cf787e1..afb3956 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -27,6 +27,7 @@
 #include linux/pci.h
 #include linux/console.h
 #include linux/vga_switcheroo.h
+#include linux/pm_runtime.h
 
 #include linux/vgaarb.h
 
@@ -37,6 +38,7 @@ struct vga_switcheroo_client {
const struct vga_switcheroo_client_ops *ops;
int id;
bool active;
+   bool driver_power_control;
struct list_head list;
 };
 
@@ -132,7 +134,7 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
 
 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
-  int id, bool active)
+  int id, bool active, bool driver_power_control)
 {
struct vga_switcheroo_client *client;
 
@@ -145,6 +147,7 @@ static int register_client(struct pci_dev *pdev,
client-ops = ops;
client-id = id;
client-active = active;
+   client-driver_power_control = driver_power_control;
 
mutex_lock(vgasr_mutex);
list_add_tail(client-list, vgasr_priv.clients);
@@ -160,10 +163,11 @@ static int register_client(struct pci_dev *pdev,
 }
 
 int vga_switcheroo_register_client(struct pci_dev *pdev,
-  const struct vga_switcheroo_client_ops *ops)
+  const struct vga_switcheroo_client_ops *ops,
+  bool driver_power_control)
 {
return register_client(pdev, ops, -1,
-  pdev == vga_default_device());
+  pdev == vga_default_device(), 
driver_power_control);
 }
 EXPORT_SYMBOL(vga_switcheroo_register_client);
 
@@ -171,7 +175,7 @@ int vga_switcheroo_register_audio_client(struct pci_dev 
*pdev,
 const struct vga_switcheroo_client_ops 
*ops,
 int id, bool active)
 {
-   

[PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Dave Airlie]

Add support for HDMI audio device on VGA cards that powerdown
to D3cold using non-standard ACPI/PCI infrastructure (optimus).

This does a couple of things to make it work:

a) add a set of power ops for the hdmi domain, and enables them
via vga_switcheroo when we are a switcheroo controlled card. This
just replaces the runtime resume operation so that when the card
is in D3cold the userspace pci config space access via sysfs,
the vga switcheroon runtime resume gets called first and it calls
the GPU resume callback before calling the sound card runtime
resume.

b) standard ACPI/PCI stacks won't put a device into D3cold without
an ACPI handle, but since the hdmi audio devices on gpus don't have
an ACPI handle, we need to manually force the device into D3cold
after suspend from the switcheroo path only.

c) don't try and do runtime s/r when the GPU is off.

d) call runtime suspend/resume during switcheroo suspend/resume
this is to make sure the runtime stack knows to try and resume
the hdmi audio device for pci config space access.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 sound/pci/hda/hda_intel.c | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 8860dd5..4b4d05b 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -555,6 +555,9 @@ struct azx {
 #ifdef CONFIG_SND_HDA_DSP_LOADER
struct azx_dev saved_azx_dev;
 #endif
+
+   /* secondary power domain for hdmi audio under vga device */
+   struct dev_pm_domain hdmi_pm_domain;
 };
 
 #define CREATE_TRACE_POINTS
@@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const struct 
kernel_param *kp)
 /*
  * power management
  */
-static int azx_suspend(struct device *dev)
+static int azx_do_suspend(struct device *dev, pci_power_t state)
 {
struct pci_dev *pci = to_pci_dev(dev);
struct snd_card *card = dev_get_drvdata(dev);
@@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
free_irq(chip-irq, chip);
chip-irq = -1;
}
+
+   /*
+* for vga switcheroo suspend we need to
+* force runtime suspend so lspci works.
+*/
+   if (state == PCI_D3cold)
+   pm_runtime_suspend(pci-dev);
+
if (chip-msi)
pci_disable_msi(chip-pci);
pci_disable_device(pci);
pci_save_state(pci);
-   pci_set_power_state(pci, PCI_D3hot);
+
+   pci_set_power_state(pci, state);
if (chip-driver_caps  AZX_DCAPS_I915_POWERWELL)
hda_display_power(false);
return 0;
 }
 
+static int azx_suspend(struct device *dev)
+{
+   return azx_do_suspend(dev, PCI_D3hot);
+}
+
 static int azx_resume(struct device *dev)
 {
struct pci_dev *pci = to_pci_dev(dev);
@@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card-private_data;
 
+   if (chip-disabled)
+   return 0;
+
azx_stop_chip(chip);
azx_enter_link_reset(chip);
azx_clear_irq_pending(chip);
@@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card-private_data;
 
+   if (chip-disabled)
+   return 0;
+
if (chip-driver_caps  AZX_DCAPS_I915_POWERWELL)
hda_display_power(true);
azx_init_pci(chip);
@@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card-private_data;
 
+   if (chip-disabled)
+   return 0;
+
if (!power_save_controller ||
!(chip-driver_caps  AZX_DCAPS_PM_RUNTIME))
return -EBUSY;
@@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
   %s: %s via VGA-switcheroo\n, pci_name(chip-pci),
   disabled ? Disabling : Enabling);
if (disabled) {
-   azx_suspend(pci-dev);
+   azx_do_suspend(pci-dev, PCI_D3cold);
+   /* when we get suspended by vga switcheroo we end up in 
D3cold,
+* however we have no ACPI handle, so pci/acpi can't 
put us there,
+* put ourselves there */
+   pci-current_state = PCI_D3cold;
chip-disabled = true;
if (snd_hda_lock_devices(chip-bus))
snd_printk(KERN_WARNING SFX %s: Cannot lock 
devices!\n,
@@ -3087,6 +3117,7 @@ static void azx_vs_set_state(struct pci_dev *pci,
snd_hda_unlock_devices(chip-bus);
chip-disabled = false;
azx_resume(pci-dev);
+   

nouveau optimus dynamic power off

[Dave Airlie]

I finally got back to debugging the HDMI audio interactions that
stopped me last time,

This adds switcheroo + nouveau + hda_intel support for turning
off the secondary GPU in optimus laptops, saving a lot of power.

The GPU should come back on for things like lspci on the devices
or for DRI_PRIME= or X starting up.

Signed-off-by: Dave Airlie airl...@redhat.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm: allow open of dynamic off devices.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_fops.c | 2 +-
 include/drm/drmP.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..d5429ee 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -257,7 +257,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
return -EBUSY;  /* No exclusive opens */
if (!drm_cpu_valid())
return -EINVAL;
-   if (dev-switch_power_state != DRM_SWITCH_POWER_ON)
+   if (dev-switch_power_state != DRM_SWITCH_POWER_ON  
dev-switch_power_state != DRM_SWITCH_POWER_DYNAMIC_OFF)
return -EINVAL;
 
DRM_DEBUG(pid = %d, minor = %d\n, task_pid_nr(current), minor_id);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 12083dc..7f8acaf 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1223,6 +1223,7 @@ struct drm_device {
 #define DRM_SWITCH_POWER_ON 0
 #define DRM_SWITCH_POWER_OFF 1
 #define DRM_SWITCH_POWER_CHANGING 2
+#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
 
 static __inline__ int drm_core_check_feature(struct drm_device *dev,
 int feature)
-- 
1.8.2.1

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

Re: linux-next: problem fetching the drm-intel-fixes tree

[Dave Airlie]

On Mon, Jul 29, 2013 at 10:26 AM, Stephen Rothwell s...@canb.auug.org.au 
wrote:
 Hi Dave,

 On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie airl...@gmail.com wrote:

  Trying to fetch the drm-intel-fixes tree
  (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
  morning produced this error:

 There is some issue with personal fdo repos at the moment and anon git,

 I'll ask admin to look into it.

 Thanks.  In the mean time, I will use what I fetched on Friday.

Okay should all be back in place now.

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

Re: linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

On Mon, 29 Jul 2013 16:29:04 +1000 Dave Airlie airl...@gmail.com wrote:

 Okay should all be back in place now.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp3VeuvCymK5.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On my test machine Xorg doesn't start anymore when I kexec into a
3.11.0-rc3 kernel.
On cold boot everything is fine:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912

But after I run kexec things go wrong:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU 

[PATCH] drm/nouveau: protect vm refcount with mutex

[Maarten Lankhorst]

The refcount was not protected by the vm lock, fix this..

[ cut here ]
WARNING: CPU: 2 PID: 2008 at drivers/gpu/drm/nouveau/core/core/mm.c:242 
nouveau_mm_fini+0x4f/0x56 [nouveau]()
Modules linked in: adt7475 ebtable_nat ebtables nouveau ipt_MASQUERADE 
iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc 
snd_hda_codec_hdmi kvm_intel ttm kvm drm_kms_helper drm mxm_wmi 
snd_hda_codec_realtek snd_hda_intel e1000e snd_hda_codec snd_hwdep snd_pcm ptp 
pps_core snd_page_alloc video parport_pc ppdev nfsd parport lockd nfs_acl 
auth_rpcgss sunrpc oid_registry
CPU: 2 PID: 2008 Comm: Xorg Tainted: GW3.11.0-rc1-patser+ #119
Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
 00f2 8803f59b1b68 81637988 b0b0
  8803f59b1ba8 81059e1d 
  8803f9dd6c48 8803f9dd6c00 8803f688d898
Call Trace:
 [81637988] dump_stack+0x55/0x86
 [81059e1d] warn_slowpath_common+0x87/0xaf
 [81059e5a] warn_slowpath_null+0x15/0x17
 [a02d6109] nouveau_mm_fini+0x4f/0x56 [nouveau]
 [a02f5703] nouveau_vm_ref+0x154/0x180 [nouveau]
 [a02d5cdb] ? nouveau_mm_free+0x85/0x116 [nouveau]
 [a02f57c9] nouveau_vm_put+0x9a/0xb0 [nouveau]
 [a033462d] ? nouveau_gem_info+0x9d/0x9d [nouveau]
 [a0334646] nouveau_gem_object_delete+0x19/0x28 [nouveau]
 [a032fc90] nouveau_fence_work+0xc9/0x102 [nouveau]
 [a0334d59] nouveau_gem_object_close+0x103/0x182 [nouveau]
 [a01d8bcd] drm_gem_handle_delete+0xcc/0x153 [drm]
 [a01d8fc5] drm_gem_close_ioctl+0x23/0x25 [drm]
 [a01d6f75] drm_ioctl+0x4cc/0x612 [drm]
 [816341c0] ? __slab_free.isra.66+0x24d/0x2aa
 [a01d8fa2] ? drm_gem_destroy+0x4c/0x4c [drm]
 [812dbef8] ? avc_has_perm_flags+0xb1/0x179
 [8115e988] do_vfs_ioctl+0x8b/0x4f8
 [812dccb4] ? inode_has_perm.isra.43.constprop.75+0x25/0x2b
 [812debef] ? file_has_perm+0x8c/0x9a
 [810d3267] ? rcu_user_exit+0xe/0x10
 [8115ee7f] SyS_ioctl+0x8a/0x9b
 [8164240b] tracesys+0xdd/0xe2
---[ end trace f99ff0179509b495 ]---

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---

diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 3b90b42..afc5106 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -28,6 +28,8 @@
 #include subdev/fb.h
 #include subdev/vm.h
 
+static void nouveau_vm_del(struct nouveau_vm *vm);
+
 void
 nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
 {
@@ -335,10 +337,10 @@ nouveau_vm_get(struct nouveau_vm *vm, u64 size, u32 
page_shift,
return ret;
}
}
+   ++vm-refcount;
+   vma-vm = vm;
mutex_unlock(nv_subdev(vmm)-mutex);
 
-   vma-vm = NULL;
-   nouveau_vm_ref(vm, vma-vm, NULL);
vma-offset = (u64)vma-node-offset  12;
 #ifdef NOUVEAU_VM_POISON
if (vm-poison)
@@ -353,7 +355,7 @@ nouveau_vm_put(struct nouveau_vma *vma)
 {
struct nouveau_vm *vm = vma-vm;
struct nouveau_vmmgr *vmm = vm-vmm;
-   u32 fpde, lpde;
+   u32 fpde, lpde, ref;
 
if (unlikely(vma-node == NULL))
return;
@@ -363,9 +365,12 @@ nouveau_vm_put(struct nouveau_vma *vma)
mutex_lock(nv_subdev(vmm)-mutex);
nouveau_vm_unmap_pgt(vm, vma-node-type != vmm-spg_shift, fpde, lpde);
nouveau_mm_free(vm-mm, vma-node);
-   mutex_unlock(nv_subdev(vmm)-mutex);
 
-   nouveau_vm_ref(NULL, vma-vm, NULL);
+   vma-vm = NULL;
+   ref = --vm-refcount;
+   mutex_unlock(nv_subdev(vmm)-mutex);
+   if (!ref)
+   nouveau_vm_del(vm);
 }
 
 int
@@ -429,25 +434,21 @@ nouveau_vm_link(struct nouveau_vm *vm, struct 
nouveau_gpuobj *pgd)
 
nouveau_gpuobj_ref(pgd, vpgd-obj);
 
-   mutex_lock(nv_subdev(vmm)-mutex);
for (i = vm-fpde; i = vm-lpde; i++)
vmm-map_pgt(pgd, i, vm-pgt[i - vm-fpde].obj);
list_add(vpgd-head, vm-pgd_list);
-   mutex_unlock(nv_subdev(vmm)-mutex);
return 0;
 }
 
 static void
 nouveau_vm_unlink(struct nouveau_vm *vm, struct nouveau_gpuobj *mpgd)
 {
-   struct nouveau_vmmgr *vmm = vm-vmm;
struct nouveau_vm_pgd *vpgd, *tmp;
struct nouveau_gpuobj *pgd = NULL;
 
if (!mpgd)
return;
 
-   mutex_lock(nv_subdev(vmm)-mutex);
list_for_each_entry_safe(vpgd, tmp, vm-pgd_list, head) {
if (vpgd-obj == mpgd) {
pgd = vpgd-obj;
@@ -456,7 +457,6 @@ nouveau_vm_unlink(struct nouveau_vm *vm, struct 
nouveau_gpuobj *mpgd)
break;
}
}
-   mutex_unlock(nv_subdev(vmm)-mutex);
 
nouveau_gpuobj_ref(NULL, pgd);
 }
@@ -489,20 +489,31 @@ 

Re: [PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Takashi Iwai]

At Mon, 29 Jul 2013 16:06:59 +1000,
Dave Airlie wrote:
 
 Add support for HDMI audio device on VGA cards that powerdown
 to D3cold using non-standard ACPI/PCI infrastructure (optimus).
 
 This does a couple of things to make it work:
 
 a) add a set of power ops for the hdmi domain, and enables them
 via vga_switcheroo when we are a switcheroo controlled card. This
 just replaces the runtime resume operation so that when the card
 is in D3cold the userspace pci config space access via sysfs,
 the vga switcheroon runtime resume gets called first and it calls
 the GPU resume callback before calling the sound card runtime
 resume.
 
 b) standard ACPI/PCI stacks won't put a device into D3cold without
 an ACPI handle, but since the hdmi audio devices on gpus don't have
 an ACPI handle, we need to manually force the device into D3cold
 after suspend from the switcheroo path only.
 
 c) don't try and do runtime s/r when the GPU is off.
 
 d) call runtime suspend/resume during switcheroo suspend/resume
 this is to make sure the runtime stack knows to try and resume
 the hdmi audio device for pci config space access.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  sound/pci/hda/hda_intel.c | 40 +---
  1 file changed, 37 insertions(+), 3 deletions(-)
 
 diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
 index 8860dd5..4b4d05b 100644
 --- a/sound/pci/hda/hda_intel.c
 +++ b/sound/pci/hda/hda_intel.c
 @@ -555,6 +555,9 @@ struct azx {
  #ifdef CONFIG_SND_HDA_DSP_LOADER
   struct azx_dev saved_azx_dev;
  #endif
 +
 + /* secondary power domain for hdmi audio under vga device */
 + struct dev_pm_domain hdmi_pm_domain;
  };
  
  #define CREATE_TRACE_POINTS
 @@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const struct 
 kernel_param *kp)
  /*
   * power management
   */
 -static int azx_suspend(struct device *dev)
 +static int azx_do_suspend(struct device *dev, pci_power_t state)
  {
   struct pci_dev *pci = to_pci_dev(dev);
   struct snd_card *card = dev_get_drvdata(dev);
 @@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
   free_irq(chip-irq, chip);
   chip-irq = -1;
   }
 +
 + /*
 +  * for vga switcheroo suspend we need to
 +  * force runtime suspend so lspci works.
 +  */
 + if (state == PCI_D3cold)
 + pm_runtime_suspend(pci-dev);
 +
   if (chip-msi)
   pci_disable_msi(chip-pci);
   pci_disable_device(pci);
   pci_save_state(pci);
 - pci_set_power_state(pci, PCI_D3hot);
 +
 + pci_set_power_state(pci, state);
   if (chip-driver_caps  AZX_DCAPS_I915_POWERWELL)
   hda_display_power(false);
   return 0;
  }
  
 +static int azx_suspend(struct device *dev)
 +{
 + return azx_do_suspend(dev, PCI_D3hot);
 +}
 +
  static int azx_resume(struct device *dev)
  {
   struct pci_dev *pci = to_pci_dev(dev);
 @@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
   struct snd_card *card = dev_get_drvdata(dev);
   struct azx *chip = card-private_data;
  
 + if (chip-disabled)
 + return 0;
 +
   azx_stop_chip(chip);
   azx_enter_link_reset(chip);
   azx_clear_irq_pending(chip);
 @@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
   struct snd_card *card = dev_get_drvdata(dev);
   struct azx *chip = card-private_data;
  
 + if (chip-disabled)
 + return 0;
 +
   if (chip-driver_caps  AZX_DCAPS_I915_POWERWELL)
   hda_display_power(true);
   azx_init_pci(chip);
 @@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
   struct snd_card *card = dev_get_drvdata(dev);
   struct azx *chip = card-private_data;
  
 + if (chip-disabled)
 + return 0;
 +
   if (!power_save_controller ||
   !(chip-driver_caps  AZX_DCAPS_PM_RUNTIME))
   return -EBUSY;
 @@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
  %s: %s via VGA-switcheroo\n, pci_name(chip-pci),
  disabled ? Disabling : Enabling);
   if (disabled) {
 - azx_suspend(pci-dev);
 + azx_do_suspend(pci-dev, PCI_D3cold);
 + /* when we get suspended by vga switcheroo we end up in 
 D3cold,
 +  * however we have no ACPI handle, so pci/acpi can't 
 put us there,
 +  * put ourselves there */
 + pci-current_state = PCI_D3cold;
   chip-disabled = true;
   if (snd_hda_lock_devices(chip-bus))
   snd_printk(KERN_WARNING SFX %s: Cannot lock 
 devices!\n,
 @@ -3087,6 +3117,7 @@ static void azx_vs_set_state(struct pci_dev *pci,
   snd_hda_unlock_devices(chip-bus);
   chip-disabled = false;
   

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 On my test machine Xorg doesn't start anymore when I kexec into a
 3.11.0-rc3 kernel.

With kexec, dpm doesn't get torn down properly which can result in a
bad hardware state when the driver loads again.  Does the attached
patch help?  It attempts to disable dpm at startup in case it wasn't
torn down properly previously.

Alex
From 8a39fdbfd4002c79ba9ab4eeb778c751fb20e173 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Mon, 29 Jul 2013 09:50:37 -0400
Subject: [PATCH] drm/radeon/dpm: disable dpm before enabling it to deal with
 kexec

Hopefully deal with kexec properly by disabling dpm prior to
enabling it in case dpm has not been torn down properly
previously.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: Markus Trippelsdorf mar...@trippelsdorf.de
---
 drivers/gpu/drm/radeon/radeon_pm.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c
index 76ffb91..c8e697e 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1193,6 +1193,8 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev)
 	radeon_dpm_init(rdev);
 	rdev-pm.dpm.current_ps = rdev-pm.dpm.requested_ps = rdev-pm.dpm.boot_ps;
 	radeon_dpm_print_power_states(rdev);
+	/* for cases like kexec, disable dpm just in case */
+	radeon_dpm_disable(rdev);
 	radeon_dpm_setup_asic(rdev);
 	ret = radeon_dpm_enable(rdev);
 	mutex_unlock(rdev-pm.mutex);
-- 
1.7.7.5

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

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

[Maarten Lankhorst]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.
 
 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

dpm initialization now works, but unfortunately GPU acceleration still gets
disabled:

[drm] Initialized drm 1.1.0 20060810

[135/1104]
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c30c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c30c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 1 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU acceleration
radeon :01:05.0: 8802161cfc00 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912
fbcon: radeondrmfb (fb0)

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

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration still gets
 disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

Alex


 [drm] Initialized drm 1.1.0 20060810  
   
 [135/1104]
 [drm] radeon kernel modesetting enabled.
 [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
 [drm] register mmio base: 0xFBEE
 [drm] register mmio size: 65536
 ATOM BIOS: 113
 radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
 used)
 radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
 [drm] Detected VRAM RAM=128M, BAR=128M
 [drm] RAM width 32bits DDR
 [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
 [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
 [TTM] Initializing pool allocator
 [TTM] Initializing DMA pool allocator
 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] Loading RS780 Microcode
 [drm] PCIE GART of 512M enabled (table at 0xC004).
 radeon :01:05.0: WB enabled
 radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
 and cpu addr 0x880215c30c00
 radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
 and cpu addr 0x880215c30c0c
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] radeon: irq initialized.
 radeon :01:05.0: setting latency timer to 64
 [drm] ring test on 0 succeeded in 1 usecs
 [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
 radeon :01:05.0: disabling GPU acceleration
 radeon :01:05.0: 8802161cfc00 unpin not necessary
 [drm] Radeon Display Connectors
 [drm] Connector 0:
 [drm]   VGA-1
 [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
 [drm]   Encoders:
 [drm] CRT1: INTERNAL_KLDSCP_DAC1
 [drm] Connector 1:
 [drm]   DVI-D-1
 [drm]   HPD3
 [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
 [drm]   Encoders:
 [drm] DFP3: INTERNAL_KLDSCP_LVTMA
 == power state 0 ==
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c r b
 == power state 1 ==
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status:
 == power state 2 ==
 ui class: none
 internal class: uvd
 caps: video
 uvdvclk: 53300 dclk: 4
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 5 vddc_index: 1
 status:
 switching from power state:
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c b
 switching to power state:
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status: r
 [drm] radeon: dpm initialized
 [drm] fb mappable at 0xF0142000
 [drm] vram apper at 0xF000
 [drm] size 7299072
 [drm] fb depth is 24
 [drm]pitch is 6912
 fbcon: radeondrmfb (fb0)

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

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Rob Clark]

On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com wrote:
 Hi Rob,

   * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
 allocate buffers for the GPU. Still not sure how to resolve this
 as we don't use DRM for our GPU driver.

 any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
 once the dma-fence stuff is in place), we'd have gpu-specific drm
 (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
 using prime/dmabuf to share between the two.

 The extra buffers we were allocating from armsoc DDX were really
 being allocated through DRM/GEM so we could get an flink name
 for them and pass a reference to them back to our GPU driver on
 the client side. If it weren't for our need to access those
 extra off-screen buffers with the GPU we wouldn't need to
 allocate them with DRM at all. So, given they are really GPU
 buffers, it does absolutely make sense to allocate them in a
 different driver to the display driver.

 However, to avoid unnecessary memcpys  related cache
 maintenance ops, we'd also like the GPU to render into buffers
 which are scanned out by the display controller. So let's say
 we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
 out buffers with the display's DRM driver but a custom ioctl
 on the GPU's DRM driver to allocate non scanout, off-screen
 buffers. Sounds great, but I don't think that really works
 with DRI2. If we used two drivers to allocate buffers, which
 of those drivers do we return in DRI2ConnectReply? Even if we
 solve that somehow, GEM flink names are name-spaced to a
 single device node (AFAIK). So when we do a DRI2GetBuffers,
 how does the EGL in the client know which DRM device owns GEM
 flink name 1234? We'd need some pretty dirty hacks.

You would return the name of the display driver allocating the
buffers.  On the client side you can use generic ioctls to go from
flink - handle - dmabuf.  So the client side would end up opening
both the display drm device and the gpu, but without needing to know
too much about the display.

(Probably in (for example) mesa there needs to be a bit of work to
handle this better, but I think that would be needed as well for
sharing between, say, nouveau and udl displaylink driver.. which is
really the same scenario.)

 So then we looked at allocating _all_ buffers with the GPU's
 DRM driver. That solves the DRI2 single-device-name and single
 name-space issue. It also means the GPU would _never_ render
 into buffers allocated through DRM_IOCTL_MODE_CREATE_DUMB.

Well, I think we can differentiate between shared buffers and internal
buffers (textures, vertex upload, etc, etc).

For example, in mesa/gallium driver there are two paths to getting a
buffer...  -resource_create() and -resource_from_handle(), the
latter is the path you go for dri2 buffers shared w/ x11.  The former
is buffers that are just internal to gpu (if !(bind 
PIPE_BIND_SHARED)).  I guess you must have something similar in mali
driver.

 One thing I wasn't sure about is if there was an objection
 to using PRIME to export scanout buffers allocated with
 DRM_IOCTL_MODE_CREATE_DUMB and then importing them into a GPU
 driver to be rendered into? Is that a concern?

well.. it wasn't quite the original intention of the 'dumb' ioctls.
But I guess in the end if you hand the gpu a buffer with a
layout/format that it can't grok, then gpu does a staging texture plus
copy.  If you had, for example, some setup w/ gpu that could only
render to tiled format, plus a display that could scanout that format,
then your DDX driver would need to allocate the dri2 buffers with
something other than dumb ioctl.  (But at that point, you probably
need to implement your own EXA so you could hook in your own custom
upload-to/download-from screen fxns for sw fallbacks, so you're not
talking about using generic DDX anyways.)

 Anyway, that latter case also gets quite difficult. The GPU
 DRM driver would need to know the constraints of the display
 controller when allocating buffers intended to be scanned out.
 For example, pl111 typically isn't behind an IOMMU and so
 requires physically contiguous memory. We'd have to teach the
 GPU's DRM driver about the constraints of the display HW. Not
 exactly a clean driver model. :-(

 I'm still a little stuck on how to proceed, so any ideas
 would greatly appreciated! My current train of thought is
 having a kind of SoC-specific DRM driver which allocates
 buffers for both display and GPU within a single GEM
 namespace. That SoC-specific DRM driver could then know the
 constraints of both the GPU and the display HW. We could then
 use PRIME to export buffers allocated with the SoC DRM driver
 and import them into the GPU and/or display DRM driver.

Usually if the display drm driver is allocating the buffers that might
be scanned out, it just needs to have minimal knowledge of the GPU
(pitch alignment constraints).  I don't think we need a 3rd device
just to allocate buffers.

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #4 from Kris Scott k...@syntosis.net ---
Bisect complete:

b1f6f47e3e33c4a74534f1301aca241ffabbb3a0 is the first bad commit
commit b1f6f47e3e33c4a74534f1301aca241ffabbb3a0
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Thu Apr 18 10:50:55 2013 -0400

drm/radeon: clean up audio dto programming

Split into DCE2/3 and DCE4/5 variants. Still todo is to
calculate the DTO dividers properly.  Add proper formula
to the comments.

Reviewed-by: Christian König christian.koe...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com

:04 04 b60cf880f2227596705391e71a56aaa12e1eb61c
a723f4928d1a20bcd0b5759077360f9342c9eecc Mdrivers

-- 
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 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #5 from Rafał Miłecki zaj...@gmail.com ---
As I suggested earlier, can you provide output of avivotool regs hdmi before
and after this patch?

This way we will sure if registers are programmed and with what values.

-- 
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 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #6 from Kris Scott k...@syntosis.net ---
Good:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTL804df8a8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b8bebc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-
Bad:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTLc045fab8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b836bc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-- 
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

[GIT PULL] exynos-drm-fixes

[inki . dae]

Hi Dave,
   This pull request fixes module build and g2d clock
   control issues, and includes related cleanup.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:

  Merge tag 'drm-intel-fixes-2013-07-25' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
20:38:14 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to db70d16ef63dbd412a974c893c52ee5ad0777d21:

  drm/exynos: Remove module.h header inclusion (2013-07-30 02:01:54 +0900)


Inki Dae (2):
  drm/exynos: fix module build error
  drm/exynos: consider common clock framework to g2d driver.

Sachin Kamat (1):
  drm/exynos: Remove module.h header inclusion

Wei Yongjun (1):
  drm/exynos: exynos_drm_ipp: fix return value check

 drivers/gpu/drm/exynos/exynos_ddc.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  3 ---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 13 ++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  1 -
 drivers/gpu/drm/exynos/exynos_hdmi.c|  1 -
 drivers/gpu/drm/exynos/exynos_hdmiphy.c |  1 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |  1 -
 12 files changed, 20 insertions(+), 24 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #7 from Rafał Miłecki zaj...@gmail.com ---
Err, did you call avivotool regs hdmi as I asked?

It should return something like:

Audio clocks:
EVERGREEN_AUDIO_PLL1_MUL
EVERGREEN_AUDIO_PLL1_DIV0001
EVERGREEN_AUDIO_PLL1_UNK0070

which is the most interesting part for us.

Of course on R6xx hardware it won't start with EVERGREEN_*

-- 
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: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 12:14 PM, Joshua C. joshua...@gmail.com wrote:
 2013/7/29 Alex Deucher alexdeuc...@gmail.com:
 On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration still gets
 disabled:

 Stupid kexec complicates things.  We need to make sure dpm is torn
 down before we init the rest of the GPU, but dpm needs get initialized
 later in the init process since it depends on certain other state from
 the driver.  I need to think about this for a bit.  I'm not sure of a
 good way to handle this.

 Alex


 [drm] Initialized drm 1.1.0 20060810
 
 [135/1104]
 [drm] radeon kernel modesetting enabled.
 [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
 [drm] register mmio base: 0xFBEE
 [drm] register mmio size: 65536
 ATOM BIOS: 113
 radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
 (128M used)
 radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
 [drm] Detected VRAM RAM=128M, BAR=128M
 [drm] RAM width 32bits DDR
 [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
 [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
 [TTM] Initializing pool allocator
 [TTM] Initializing DMA pool allocator
 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] Loading RS780 Microcode
 [drm] PCIE GART of 512M enabled (table at 0xC004).
 radeon :01:05.0: WB enabled
 radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
 and cpu addr 0x880215c30c00
 radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
 and cpu addr 0x880215c30c0c
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] radeon: irq initialized.
 radeon :01:05.0: setting latency timer to 64
 [drm] ring test on 0 succeeded in 1 usecs
 [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
 radeon :01:05.0: disabling GPU acceleration
 radeon :01:05.0: 8802161cfc00 unpin not necessary
 [drm] Radeon Display Connectors
 [drm] Connector 0:
 [drm]   VGA-1
 [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
 [drm]   Encoders:
 [drm] CRT1: INTERNAL_KLDSCP_DAC1
 [drm] Connector 1:
 [drm]   DVI-D-1
 [drm]   HPD3
 [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
 [drm]   Encoders:
 [drm] DFP3: INTERNAL_KLDSCP_LVTMA
 == power state 0 ==
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c r b
 == power state 1 ==
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status:
 == power state 2 ==
 ui class: none
 internal class: uvd
 caps: video
 uvdvclk: 53300 dclk: 4
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 5 vddc_index: 1
 status:
 switching from power state:
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c b
 switching to power state:
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status: r
 [drm] radeon: dpm initialized
 [drm] fb mappable at 0xF0142000
 [drm] vram apper at 0xF000
 [drm] size 7299072
 [drm] fb depth is 24
 [drm]pitch is 6912
 fbcon: radeondrmfb (fb0)

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

 This error message seems similar to mine [drm:r600_uvd_ring_test]
 *ERROR* radeon: ring 5 

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
ebied...@xmission.com wrote:


 Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration
still gets
 disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

 You might just want to implement a shutdown method that cleans things up 
 properly.   At least as a first pass until you worry about things like kexec 
 on panic.

 Or can you not shutdown the graphics stack on reboot because of the need to 
 display the kernels shutdown progress?

Does kexec actually call this shutdown method?  The driver implements
appropriate clean-up measures if it's shutdown properly.

Alex



 Eric

Alex


 [drm] Initialized drm 1.1.0 20060810
 [135/1104]
 [drm] radeon kernel modesetting enabled.
 [drm] initializing kernel modesetting (RS780 0x1002:0x9614
0x1043:0x834D).
 [drm] register mmio base: 0xFBEE
 [drm] register mmio size: 65536
 ATOM BIOS: 113
 radeon :01:05.0: VRAM: 128M 0xC000 -
0xC7FF (128M used)
 radeon :01:05.0: GTT: 512M 0xA000 -
0xBFFF
 [drm] Detected VRAM RAM=128M, BAR=128M
 [drm] RAM width 32bits DDR
 [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
 [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
 [TTM] Initializing pool allocator
 [TTM] Initializing DMA pool allocator
 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] Loading RS780 Microcode
 [drm] PCIE GART of 512M enabled (table at 0xC004).
 radeon :01:05.0: WB enabled
 radeon :01:05.0: fence driver on ring 0 use gpu addr
0xac00 and cpu addr 0x880215c30c00
 radeon :01:05.0: fence driver on ring 3 use gpu addr
0xac0c and cpu addr 0x880215c30c0c
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] radeon: irq initialized.
 radeon :01:05.0: setting latency timer to 64
 [drm] ring test on 0 succeeded in 1 usecs
 [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
(0xCAFEDEAD)
 radeon :01:05.0: disabling GPU acceleration
 radeon :01:05.0: 8802161cfc00 unpin not necessary
 [drm] Radeon Display Connectors
 [drm] Connector 0:
 [drm]   VGA-1
 [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
 [drm]   Encoders:
 [drm] CRT1: INTERNAL_KLDSCP_DAC1
 [drm] Connector 1:
 [drm]   DVI-D-1
 [drm]   HPD3
 [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
 [drm]   Encoders:
 [drm] DFP3: INTERNAL_KLDSCP_LVTMA
 == power state 0 ==
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c r b
 == power state 1 ==
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status:
 == power state 2 ==
 ui class: none
 internal class: uvd
 caps: video
 uvdvclk: 53300 dclk: 4
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 5 vddc_index: 1
 status:
 switching from power state:
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c b
 switching to power state:
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status: r
 [drm] radeon: dpm initialized
 [drm] fb mappable at 0xF0142000
 [drm] vram apper at 0xF000
 [drm] 

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #8 from Kris Scott k...@syntosis.net ---
Oops, sorry, here you go.

Good:

Audio clocks:
R600_AUDIO_PLL1_MUL
R600_AUDIO_PLL1_DIV
R600_AUDIO_PLL2_MUL00249f00
R600_AUDIO_PLL2_DIV00714be8
R600_AUDIO_CLK_SRCSEL0001

Audio general:
R600_AUDIO_ENABLE81f0
R600_AUDIO_TIMING0170

Audio params:
R600_AUDIO_VENDOR_ID1002aa01
R600_AUDIO_REVISION_ID00100100
R600_AUDIO_ROOT_NODE_COUNT00010001
R600_AUDIO_NID1_NODE_COUNT00020002
R600_AUDIO_NID1_TYPE0001
R600_AUDIO_SUPPORTED_SIZE_RATE00020070
R600_AUDIO_SUPPORTED_CODEC0001
R600_AUDIO_SUPPORTED_POWER_STATES0009
R600_AUDIO_NID2_CAPS0201
R600_AUDIO_NID3_CAPS00400381
R600_AUDIO_NID3_PIN_CAPS0094

Audio conn list:
R600_AUDIO_CONN_LIST_LEN0001
R600_AUDIO_CONN_LIST08060402

Audio verbs:
R600_AUDIO_RATE_BPS_CHANNEL4011
R600_AUDIO_PLAYING0010
R600_AUDIO_IMPLEMENTATION_ID104d2e00
R600_AUDIO_CONFIG_DEFAULT18560010
R600_AUDIO_PIN_SENSE7fff
R600_AUDIO_PIN_WIDGET_CNTL40404040
R600_AUDIO_STATUS_BITS0001

HDMI block at 0x7400:
74000011 (17)
7404 (0)
74080010 (16)
740c0001 (65536)
7410 (0)
7414 (0)
7418 (0)
741c (0)
7420 (0)
7424 (0)
7428 (0)
742c (0)
7430 (0)
7434 (0)
7438 (0)
743c (0)
7440 (0)
7444 (0)
7448 (0)
744c (0)
7450 (0)
7454 (0)
7458 (0)
745c (0)
74600200 (33554432)
7464 (0)
7468 (0)
746c (0)
7470 (0)
7474 (0)
7478 (0)
747c (0)
7480 (0)
7484 (0)
7488 (0)
748c (0)
7490 (0)
7494 (0)
7498 (0)
749c (0)
74a0 (0)
74a4 (0)
74a8 (0)
74ac (0)
74b0 (0)
74b4 (0)
74b8 (0)
74bc (0)
74c0 (0)
74c4 (0)
74c8 (0)
74cc0170 (368)
74d0 (0)
74d41000 (268435456)
74d8 (0)
74dc (0)
74e0 (0)
74e4 (0)
74e8 (0)
74ec (0)

HDMI block at 0x7800:
78000011 (17)
78040001 (65536)
780800030010 (196624)
780c1000 (4096)
78100031 (49)
78140033 (51)
78180202 (514)
781c (0)
7820 (0)
7824 (0)
7828 (0)
782c (0)
7830 (0)
7834 (0)
7838 (0)
783c (0)
7840 (0)
7844 (0)
7848 (0)
784c (0)
7850 (0)
785400080065 (524389)
78580004 (4)
785c (0)
7860 (0)
7864 (0)
7868 (0)
786c (0)
7870 (0)
7874 (0)
7878 (0)
787c (0)
7880 (0)
7884 (0)
7888 (0)
788c (0)
7890 (0)
7894 (0)
7898 (0)
789c (0)
78a0 (0)
78a4 (0)
78a8 (0)
78ac1220a000 (304128000)
78b01000 (4096)
78b414244000 (33792)
78b81880 (6272)
78bc1220a000 (304128000)
78c01800 (6144)
78c414242000 (337911808)
78c81880 (6272)
78cc0170 (368)
78d0 (0)
78d4 (0)
78d80002 (2)
78dc1100 (4352)
78e000ff (16777215)
78e4007f (8388607)
78e80001 (1)
78ec0001 (1)


Bad:

Audio clocks:
R600_AUDIO_PLL1_MUL00249f00
R600_AUDIO_PLL1_DIV00714be8
R600_AUDIO_PLL2_MUL
R600_AUDIO_PLL2_DIV
R600_AUDIO_CLK_SRCSEL

Audio general:
R600_AUDIO_ENABLE811000f0
R600_AUDIO_TIMING0070

Audio params:
R600_AUDIO_VENDOR_ID1002aa01
R600_AUDIO_REVISION_ID00100100
R600_AUDIO_ROOT_NODE_COUNT00010001
R600_AUDIO_NID1_NODE_COUNT00020002
R600_AUDIO_NID1_TYPE0001
R600_AUDIO_SUPPORTED_SIZE_RATE00020070
R600_AUDIO_SUPPORTED_CODEC0001
R600_AUDIO_SUPPORTED_POWER_STATES0009
R600_AUDIO_NID2_CAPS0201
R600_AUDIO_NID3_CAPS00400381

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

Nicholas Miell nmi...@gmail.com changed:

   What|Removed |Added

Summary|Trine 2 color problems on   |Trine 2's fragment normal
   |Radeon HD 6770 (Juniper)|buffer is mixtextured on
   ||Radeon HD 6770 (Juniper)

-- 
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 67107] Xorg starts and crashes with DPM enable

[bugzilla-daemon]

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

--- Comment #3 from Christopher Chmielewski c.chmielew...@outlook.com ---
I just tried with rc3 and it still happens.

-- 
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 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #9 from Rafał Miłecki zaj...@gmail.com ---
@Kris: thank you for you debugging! I hope this is last debugging request.

Can you boot not working (bad) kernel, connect HDMI display and then type:

avivotool regset 0x0524 0x00249f00
avivotool regset 0x0528 0x00714be8
avivotool regset 0x0534 0x0001

I hope this will resume audio on your card, but I just want to be sure, before
asking Alex for getting more details on that.

If you could confirm that above 3 commands fix audio for you, it'd be great.

-- 
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: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
ebied...@xmission.com wrote:
 Alex Deucher alexdeuc...@gmail.com writes:

 On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
 ebied...@xmission.com wrote:


 Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration
still gets
 disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

 You might just want to implement a shutdown method that cleans things up 
 properly.   At least as a first pass until you worry about things like 
 kexec on panic.

 Or can you not shutdown the graphics stack on reboot because of the need to 
 display the kernels shutdown progress?

 Does kexec actually call this shutdown method?  The driver implements
 appropriate clean-up measures if it's shutdown properly.

 Absoltuely.  All parts of the reboot path call -shutdown.  Including
 kexec.

 You don't get a device remove/hotunplug but unless this is a kexec on
 panic -shutdown is most definitely called.  Now I am talking about the
 device layer/pci layer shutdown method I don't know how gpu drivers are
 wired up.  GPU land was a little strange last I looked.  Hopefully it
 isn't so strange that there is a method named shutdown that is not wired
 up.

It doesn't look like the drm infrastructure has a shutdown callback.
The drm drivers register a drm_driver callback struct that includes an
unload callback which takes care of all the device teardown (if you
unload the module for example).  I don't know that it actually gets
called at kexec time however.  I don't know enough about how kexec
works.

Markus, does everything work ok after a reboot?  Is it just kexec that
is a problem?

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

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
 ebied...@xmission.com wrote:
  Alex Deucher alexdeuc...@gmail.com writes:
 
  On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
  ebied...@xmission.com wrote:
 
 
  Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
  On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  mar...@trippelsdorf.de wrote:
   On my test machine Xorg doesn't start anymore when I kexec into a
   3.11.0-rc3 kernel.
 
  With kexec, dpm doesn't get torn down properly which can result in a
  bad hardware state when the driver loads again.  Does the attached
  patch help?  It attempts to disable dpm at startup in case it wasn't
  torn down properly previously.
 
  dpm initialization now works, but unfortunately GPU acceleration
 still gets
  disabled:
 
 Stupid kexec complicates things.  We need to make sure dpm is torn
 down before we init the rest of the GPU, but dpm needs get initialized
 later in the init process since it depends on certain other state from
 the driver.  I need to think about this for a bit.  I'm not sure of a
 good way to handle this.
 
  You might just want to implement a shutdown method that cleans things up 
  properly.   At least as a first pass until you worry about things like 
  kexec on panic.
 
  Or can you not shutdown the graphics stack on reboot because of the need 
  to display the kernels shutdown progress?
 
  Does kexec actually call this shutdown method?  The driver implements
  appropriate clean-up measures if it's shutdown properly.
 
  Absoltuely.  All parts of the reboot path call -shutdown.  Including
  kexec.
 
  You don't get a device remove/hotunplug but unless this is a kexec on
  panic -shutdown is most definitely called.  Now I am talking about the
  device layer/pci layer shutdown method I don't know how gpu drivers are
  wired up.  GPU land was a little strange last I looked.  Hopefully it
  isn't so strange that there is a method named shutdown that is not wired
  up.
 
 It doesn't look like the drm infrastructure has a shutdown callback.
 The drm drivers register a drm_driver callback struct that includes an
 unload callback which takes care of all the device teardown (if you
 unload the module for example).  I don't know that it actually gets
 called at kexec time however.  I don't know enough about how kexec
 works.
 
 Markus, does everything work ok after a reboot?  Is it just kexec that
 is a problem?

Yes.

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

[pull] radeon drm-fixes-3.11

[alexdeucher]

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

Hi Dave,

A few more radeon bug fixes, mostly for SI dpm.  At this point dpm is
pretty solid across the majority of asics.  I think we mostly just have
corner cases and fixing up some of the trickier features at this point.

The following changes since commit bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:

  Merge tag 'drm-intel-fixes-2013-07-25' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
20:38:14 +1000)

are available in the git repository at:

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

Alex Deucher (10):
  drm/radeon: fix audio dto programming on DCE4+
  drm/radeon/dpm: fix display gap programming on SI
  drm/radeon/dpm: fix si_calculate_memory_refresh_rate()
  drm/radeon/dpm: fix powertune handling for pci id 0x6835
  drm/radeon: properly handle cg on asics without UVD
  drm/radeon/atom: fix fb when fetching engine params
  drm/radeon/dpm: fix forcing performance state to low on cayman
  drm/radeon/si: disable cgcg and pg for now
  drm/radeon/dpm: disable cac setup on SI
  drm/radeon/dpm: fix and enable reclocking on SI

 drivers/gpu/drm/radeon/evergreen_hdmi.c  |2 +-
 drivers/gpu/drm/radeon/ni_dpm.c  |7 +-
 drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
 drivers/gpu/drm/radeon/si.c  |   14 
 drivers/gpu/drm/radeon/si_dpm.c  |   34 ++---
 5 files changed, 24 insertions(+), 35 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #10 from Kris Scott k...@syntosis.net ---
Yes, those fixed it. Thank you very much.

-- 
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 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher ag...@yahoo.com ---
Can you tell be the values of 0x7340, 0x7344, 0x520, and 0x530?
avivotool regmatch 0x7340
avivotool regmatch 0x7344
avivotool regmatch 0x520
avivotool regmatch 0x530

-- 
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 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #12 from Kris Scott k...@syntosis.net ---
0x73400x001b0018 (1769496)
0x73440x0070 (112)
0x5200x0070 (112)
0x5300x0070 (112)

-- 
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 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #13 from Kris Scott k...@syntosis.net ---
That is also after I had changed the registers that Rafal asked me to change,
if it makes any difference.

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

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

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

--- Comment #14 from Alex Deucher ag...@yahoo.com ---
Can you boot back into the broken state and try this alternative fix:
avivotool regset 0x7344 0x0170

-- 
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 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

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

--- Comment #23 from Alex Deucher ag...@yahoo.com ---
Created attachment 83246
  -- https://bugs.freedesktop.org/attachment.cgi?id=83246action=edit
hacks to test

That attached patch disables some options in the dpm driver.  See if it helps
at all.  Make sure you are using a kernel that contains the fixes mentioned in
comment 9 or my drm-fixes-3.11 branch.

If the patch doesn't work as is, try changing the:
#if 1
in the patch to:
#if 0
and see if that helps.

Please attach your dmesg output with the patch applied.

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

Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
  
   Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
   loaded.
   (Note, no X running on that box)
   
   Trace below shows trinity, but I can reproduce it with just cat
   /proc/dri/0/vma
  
  How about this, lets just rip it all out.

No-one objected, and this is still around in 3.11-rc3 in the same
easily oopsable state.. I vote we kill it with fire.

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

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

[bugzilla-daemon]

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

--- Comment #34 from rafael castillo jrch2...@gmail.com ---
tested with today drm-fixes patches and its reclocking like a boss and xonotic
passed from 30 FPS to an massive 190FPS in ultimate at 1366x768. i read you
need some fixes for other part of asic for later so is up to you if you wish to
close the bug report.

again a hundred bazillions thanks this is just awesome now

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

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Hohahiu]

Hello, Dave!

I have a hybrid muxless laptop with intel+radeon:
#lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core 
processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 
Cape Verde [Radeon HD 7700M Series]


I have some questions related to this series of patches.
When I power down discrete card by vgaswitcheroo, restart X server and 
turn on radeon card again, xrandr doesn't recognize my discrete card and 
only shows the intel one. Is this a bug or a feature of X server?

And how would this behavior change with this patch?

Also sometimes I have the following configuration:
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:DIS: :Pwr::01:00.0
1:IGD:+:Pwr::00:02.0

In this case if I do
# echo OFF  /sys/kernel/debug/vgaswitcheroo/switch
the system hangs and doesn't respond (ssh, magic keys etc.).

In the meantime for a
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::00:02.0
1:DIS: :Pwr::01:00.0

# echo OFF  /sys/kernel/debug/vgaswitcheroo/switch
powers down discrete card successfully.

Would it be resolved with these patches?

Hohahiu

PS. Should I open bug report for these issues?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

[bugzilla-daemon]

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

--- Comment #17 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Alex, is there a chance for me to reverse some commits prior to 69e0b57 to find
which one or which feature is hanging my computer? Any approach I should try?

-- 
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: [PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

[Ben Skeggs]

On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
 before
 the rework to event interface, so I guess it got reintroduced.
I don't know how/why you think this fixes anything.  The interrupt
handler can't possibly be called until after priv-base.vblank has
been initialised...

Seriously, go look, the subdev interrupt handler pointer isn't filled
in (and can't be) until after nouveau_disp_create() has been called,
and nouveau_disp_create() initialises priv-base.vblank before it
returns...

Ben.



 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 ---
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
 b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
 index 7e3875d..35e526b 100644
 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
 +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
 @@ -1266,13 +1266,15 @@ nv50_disp_intr(struct nouveau_subdev *subdev)
 }

 if (intr1  0x0004) {
 -   nouveau_event_trigger(priv-base.vblank, 0);
 +   if (priv-base.vblank)
 +   nouveau_event_trigger(priv-base.vblank, 0);
 nv_wr32(priv, 0x610024, 0x0004);
 intr1 = ~0x0004;
 }

 if (intr1  0x0008) {
 -   nouveau_event_trigger(priv-base.vblank, 1);
 +   if (priv-base.vblank)
 +   nouveau_event_trigger(priv-base.vblank, 1);
 nv_wr32(priv, 0x610024, 0x0008);
 intr1 = ~0x0008;
 }
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c 
 b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
 index 52dd7a1..4095f65 100644
 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
 +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
 @@ -941,7 +941,7 @@ nvd0_disp_intr(struct nouveau_subdev *subdev)
 u32 mask = 0x0100  i;
 if (mask  intr) {
 u32 stat = nv_rd32(priv, 0x6100bc + (i * 0x800));
 -   if (stat  0x0001)
 +   if ((stat  0x0001)  priv-base.vblank)
 nouveau_event_trigger(priv-base.vblank, i);
 nv_mask(priv, 0x6100bc + (i * 0x800), 0, 0);
 nv_rd32(priv, 0x6100c0 + (i * 0x800));

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

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

[bugzilla-daemon]

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

--- Comment #18 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #17)
 Alex, is there a chance for me to reverse some commits prior to 69e0b57 to
 find which one or which feature is hanging my computer? Any approach I
 should try?

I'm not really sure what would have broken your system.  I also don't really
see how 69e0b57 could have broken anything since nothing changes with that as
long as dpm is disabled.  Do you still have the issue if you reset your tree to
the commit prior to 69e0b57?  Do you still get hangs if you disable radeon
(e.g., add radeon.modeset=0 to your kernel command line in grub)?

-- 
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 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

[bugzilla-daemon]

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

--- Comment #19 from Alex Deucher ag...@yahoo.com ---
Does booting a recent 3.11rc kernel with radeon.aspm=0 help?

-- 
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 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

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

--- Comment #24 from Alex Deucher ag...@yahoo.com ---
Created attachment 83257
  -- https://bugs.freedesktop.org/attachment.cgi?id=83257action=edit
disable lvtma resync

Another patch to test.

-- 
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 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

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

--- Comment #25 from Alex Deucher ag...@yahoo.com ---
Created attachment 83258
  -- https://bugs.freedesktop.org/attachment.cgi?id=83258action=edit
use alternate fb_div scale

Another patch to test.

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

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Rahul Sharma]

On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.comwrote:

 Hi,

 On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
  Thanks all,
 
  On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com wrote:
  Hello Kishon,
 
  On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
  Hi,
 
  On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
 
 
  -Original Message-
  From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
  Sent: Thursday, June 13, 2013 5:56 PM
  To: Rahul Sharma
  Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org;
  devicetree-
  disc...@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo
 Kim;
  Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
  grant.lik...@linaro.org
  Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock
 with
  pmu reg control
 
  Hi,
 
  On 06/13/2013 06:26 AM, Rahul Sharma wrote:
  Mr. Dae,
 
  Thanks for your valuable inputs.
 
  I posted it as RFC because, I also have received comments to
 register
  hdmiphy as a clock controller. As we always configure it for
 specific
  frequency, hdmi-phy looks similar to a PLL. But it really doesn't
  belong to that class. Secondly prior to exynos5420, it was a i2c
  device. I am not sure we can register a I2C device as a clock
  controller. I wanted to discuss and explore this option here.
 
  Have you considered using the generic PHY framework for those HDMI
  PHY devices [1] ? I guess we could add a dedicated group of ops for
  video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
  configuring things like the carrier/pixel clock frequency or anything
  what's common across the video PHYs.
 
  Perhaps you could have a look and see if this framework would be
  useful for HDMI and possibly point out anything what might be
 missing ?
 
  I'm not sure it it really solves the issues specific to the Exynos
  HDMI but at least with a generic PHY driver the PHY module would be
  separate from the PHY controller, as often same HDMI DPHY can be used
  with various types of a HDMI controller. So this would allow to not
  duplicate the HDMI PHY drivers in the long-term perspective.
 
  Yeah, at least, it seems that we could use PHY module to control PMU
  register, HDMI_PHY_CONTROL. However, PHY module provides only
 init/on/off
  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
  HDMIPHY
  clock. So with PHY module, HDMIPHY driver could enable PMU more
  generically,
  but also has to use existing i2c stuff to control HDMIPHY clock. I
 had a
  quick review to Generic PHY Framework[v6] but I didn't see that the
 PHY
  module could generically support more features such as i2c stuff.
 
  I don't think PHY framework needs to provide i2c interfaces to program
  certain configurations. Instead in one of the callbacks (init/on/off)
  PHY driver can program whatever it wants using any of the interfaces it
  needs. IMO PHY framework should work independent of the interfaces.
 
  In exnoys hdmi case, i2c interface is not the exact issue. In exynos
  hdmi, hdmiphy should send i2c configuration about video clock
  information as the video mode information including resolution, bit per
  pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
  of phy framework are not enough for exynos hdmiphy and it should have a
  callback to set video mode.
 
  Do you have plan to add driver specific extend callback pointers to phy
  framework?
 
  Currently, hdmi directly calls phy operations, but Rahul's another patch
  set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is
  connected with exynos hdmi own sub driver callback operations.
 
  IMHO, if phy framework can support extend callback feature, then this
  own sub driver callbacks can be replaced with phy framework at long term
  view.
 
  Extended callbacks are always welcome. I can also use phy device
  private data to pass on private ops like get_pixelclk and set_pixelclk.

 I would recommend creating a wrapper to the existing PHY framework
 for HDMI PHY. That way, we can have other HDMI phys added
 easily. We need to figure out all the ops that might be needed by the
 HDMI PHY to be added to the wrapper.
 IMO extended callbacks can lead to abuse of the system and should be
 used only when absolutely necessary.

 Thanks
 Kishon


Thanks Kishon,

I have started working on this wrapper layer which is customized for video
phys.
As if now, adding set_dv_timing, get_dv_timing as the only additional
callbacks.
I will post the RFC patches.

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

[Bug 60639] RV635: Kernel displays black screen when monitor is connect via DisplayPort

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher alexdeuc...@gmail.com ---
Created attachment 107040
  -- https://bugzilla.kernel.org/attachment.cgi?id=107040action=edit
possible fix

The attached patch should fix the issue.

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

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Joshua C.]

2013/7/29 Alex Deucher alexdeuc...@gmail.com:
 On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration still gets
 disabled:

 Stupid kexec complicates things.  We need to make sure dpm is torn
 down before we init the rest of the GPU, but dpm needs get initialized
 later in the init process since it depends on certain other state from
 the driver.  I need to think about this for a bit.  I'm not sure of a
 good way to handle this.

 Alex


 [drm] Initialized drm 1.1.0 20060810 
  
   [135/1104]
 [drm] radeon kernel modesetting enabled.
 [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
 [drm] register mmio base: 0xFBEE
 [drm] register mmio size: 65536
 ATOM BIOS: 113
 radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
 (128M used)
 radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
 [drm] Detected VRAM RAM=128M, BAR=128M
 [drm] RAM width 32bits DDR
 [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
 [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
 [TTM] Initializing pool allocator
 [TTM] Initializing DMA pool allocator
 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] Loading RS780 Microcode
 [drm] PCIE GART of 512M enabled (table at 0xC004).
 radeon :01:05.0: WB enabled
 radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
 and cpu addr 0x880215c30c00
 radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
 and cpu addr 0x880215c30c0c
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] radeon: irq initialized.
 radeon :01:05.0: setting latency timer to 64
 [drm] ring test on 0 succeeded in 1 usecs
 [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
 radeon :01:05.0: disabling GPU acceleration
 radeon :01:05.0: 8802161cfc00 unpin not necessary
 [drm] Radeon Display Connectors
 [drm] Connector 0:
 [drm]   VGA-1
 [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
 [drm]   Encoders:
 [drm] CRT1: INTERNAL_KLDSCP_DAC1
 [drm] Connector 1:
 [drm]   DVI-D-1
 [drm]   HPD3
 [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
 [drm]   Encoders:
 [drm] DFP3: INTERNAL_KLDSCP_LVTMA
 == power state 0 ==
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c r b
 == power state 1 ==
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status:
 == power state 2 ==
 ui class: none
 internal class: uvd
 caps: video
 uvdvclk: 53300 dclk: 4
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 5 vddc_index: 1
 status:
 switching from power state:
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c b
 switching to power state:
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status: r
 [drm] radeon: dpm initialized
 [drm] fb mappable at 0xF0142000
 [drm] vram apper at 0xF000
 [drm] size 7299072
 [drm] fb depth is 24
 [drm]pitch is 6912
 fbcon: radeondrmfb (fb0)

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

This error message seems similar to mine [drm:r600_uvd_ring_test]
*ERROR* radeon: ring 5 test failed (0xCAFEDEAD) Bugzilla:

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration
still gets
 disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

You might just want to implement a shutdown method that cleans things up 
properly.   At least as a first pass until you worry about things like kexec on 
panic.

Or can you not shutdown the graphics stack on reboot because of the need to 
display the kernels shutdown progress?

Eric

Alex


 [drm] Initialized drm 1.1.0 20060810 
 [135/1104]
 [drm] radeon kernel modesetting enabled.
 [drm] initializing kernel modesetting (RS780 0x1002:0x9614
0x1043:0x834D).
 [drm] register mmio base: 0xFBEE
 [drm] register mmio size: 65536
 ATOM BIOS: 113
 radeon :01:05.0: VRAM: 128M 0xC000 -
0xC7FF (128M used)
 radeon :01:05.0: GTT: 512M 0xA000 -
0xBFFF
 [drm] Detected VRAM RAM=128M, BAR=128M
 [drm] RAM width 32bits DDR
 [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
 [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
 [TTM] Initializing pool allocator
 [TTM] Initializing DMA pool allocator
 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] Loading RS780 Microcode
 [drm] PCIE GART of 512M enabled (table at 0xC004).
 radeon :01:05.0: WB enabled
 radeon :01:05.0: fence driver on ring 0 use gpu addr
0xac00 and cpu addr 0x880215c30c00
 radeon :01:05.0: fence driver on ring 3 use gpu addr
0xac0c and cpu addr 0x880215c30c0c
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] radeon: irq initialized.
 radeon :01:05.0: setting latency timer to 64
 [drm] ring test on 0 succeeded in 1 usecs
 [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
(0xCAFEDEAD)
 radeon :01:05.0: disabling GPU acceleration
 radeon :01:05.0: 8802161cfc00 unpin not necessary
 [drm] Radeon Display Connectors
 [drm] Connector 0:
 [drm]   VGA-1
 [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
 [drm]   Encoders:
 [drm] CRT1: INTERNAL_KLDSCP_DAC1
 [drm] Connector 1:
 [drm]   DVI-D-1
 [drm]   HPD3
 [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
 [drm]   Encoders:
 [drm] DFP3: INTERNAL_KLDSCP_LVTMA
 == power state 0 ==
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c r b
 == power state 1 ==
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status:
 == power state 2 ==
 ui class: none
 internal class: uvd
 caps: video
 uvdvclk: 53300 dclk: 4
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 5 vddc_index: 1
 status:
 switching from power state:
 ui class: none
 internal class: boot
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 2
 power level 1sclk: 5 vddc_index: 2
 status: c b
 switching to power state:
 ui class: performance
 internal class: none
 caps: video
 uvdvclk: 0 dclk: 0
 power level 0sclk: 5 vddc_index: 1
 power level 1sclk: 7 vddc_index: 2
 status: r
 [drm] radeon: dpm initialized
 [drm] fb mappable at 0xF0142000
 [drm] vram apper at 0xF000
 [drm] size 7299072
 [drm] fb depth is 24
 [drm]pitch is 6912
 fbcon: radeondrmfb (fb0)

 --
 Markus

___
dri-devel mailing list

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

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

 On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
 ebied...@xmission.com wrote:


 Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On my test machine Xorg doesn't start anymore when I kexec into a
  3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration
still gets
 disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

 You might just want to implement a shutdown method that cleans things up 
 properly.   At least as a first pass until you worry about things like kexec 
 on panic.

 Or can you not shutdown the graphics stack on reboot because of the need to 
 display the kernels shutdown progress?

 Does kexec actually call this shutdown method?  The driver implements
 appropriate clean-up measures if it's shutdown properly.

Absoltuely.  All parts of the reboot path call -shutdown.  Including
kexec.

You don't get a device remove/hotunplug but unless this is a kexec on
panic -shutdown is most definitely called.  Now I am talking about the
device layer/pci layer shutdown method I don't know how gpu drivers are
wired up.  GPU land was a little strange last I looked.  Hopefully it
isn't so strange that there is a method named shutdown that is not wired
up.

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

[PATCH] Fix #include in drm_mm.h to unbreak ia64 build

[Luck, Tony]

Linux-next build on ia64 is falling over with errors like this:

In file included from include/drm/drm_vma_manager.h:26,
 from include/drm/ttm/ttm_bo_api.h:35,
 from include/drm/ttm/ttm_bo_driver.h:33,
 from drivers/gpu/drm/ttm/ttm_agp_backend.c:35:
include/drm/drm_mm.h:67: error: expected specifier-qualifier-list before 
'spinlock_t'

I guess other architectures are pulling in spinlock.h
through some twisty #include path so are not seeing this
error.  But drm_mm.h makes use of spinlock_t - so it
should do the right thing and #include linux/spinlock.h

Signed-off-by: Tony Luck tony.l...@intel.com

---

First saw this break in tag next-20130726

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index b87d05e..7d5fbae 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -37,6 +37,7 @@
  * Generic range manager structs
  */
 #include linux/list.h
+#include linux/spinlock.h
 #ifdef CONFIG_DEBUG_FS
 #include linux/seq_file.h
 #endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Kishon Vijay Abraham I]

Hi,

On Tuesday 30 July 2013 09:12 AM, Rahul Sharma wrote:
 
 
 On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com wrote:
 
 Hi,
 
 On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
  Thanks all,
 
  On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com
 mailto:sw0312@samsung.com wrote:
  Hello Kishon,
 
  On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
  Hi,
 
  On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
 
 
  -Original Message-
  From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
 mailto:s.nawro...@samsung.com]
  Sent: Thursday, June 13, 2013 5:56 PM
  To: Rahul Sharma
  Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org
 mailto:linux-samsung-...@vger.kernel.org;
  devicetree-
  disc...@lists.ozlabs.org mailto:disc...@lists.ozlabs.org; DRI
 mailing list; Kukjin Kim; Seung-Woo Kim;
  Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
  grant.lik...@linaro.org mailto:grant.lik...@linaro.org
  Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock 
 with
  pmu reg control
 
  Hi,
 
  On 06/13/2013 06:26 AM, Rahul Sharma wrote:
  Mr. Dae,
 
  Thanks for your valuable inputs.
 
  I posted it as RFC because, I also have received comments to 
 register
  hdmiphy as a clock controller. As we always configure it for 
 specific
  frequency, hdmi-phy looks similar to a PLL. But it really doesn't
  belong to that class. Secondly prior to exynos5420, it was a i2c
  device. I am not sure we can register a I2C device as a clock
  controller. I wanted to discuss and explore this option here.
 
  Have you considered using the generic PHY framework for those HDMI
  PHY devices [1] ? I guess we could add a dedicated group of ops for
  video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
  configuring things like the carrier/pixel clock frequency or 
 anything
  what's common across the video PHYs.
 
  Perhaps you could have a look and see if this framework would be
  useful for HDMI and possibly point out anything what might be 
 missing ?
 
  I'm not sure it it really solves the issues specific to the Exynos
  HDMI but at least with a generic PHY driver the PHY module would be
  separate from the PHY controller, as often same HDMI DPHY can be 
 used
  with various types of a HDMI controller. So this would allow to not
  duplicate the HDMI PHY drivers in the long-term perspective.
 
  Yeah, at least, it seems that we could use PHY module to control PMU
  register, HDMI_PHY_CONTROL. However, PHY module provides only 
 init/on/off
  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
  HDMIPHY
  clock. So with PHY module, HDMIPHY driver could enable PMU more
  generically,
  but also has to use existing i2c stuff to control HDMIPHY clock. I 
 had a
  quick review to Generic PHY Framework[v6] but I didn't see that the 
 PHY
  module could generically support more features such as i2c stuff.
 
  I don't think PHY framework needs to provide i2c interfaces to program
  certain configurations. Instead in one of the callbacks (init/on/off)
  PHY driver can program whatever it wants using any of the interfaces 
 it
  needs. IMO PHY framework should work independent of the interfaces.
 
  In exnoys hdmi case, i2c interface is not the exact issue. In exynos
  hdmi, hdmiphy should send i2c configuration about video clock
  information as the video mode information including resolution, bit per
  pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
  of phy framework are not enough for exynos hdmiphy and it should have a
  callback to set video mode.
 
  Do you have plan to add driver specific extend callback pointers to phy
  framework?
 
  Currently, hdmi directly calls phy operations, but Rahul's another 
 patch
  set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy 
 is
  connected with exynos hdmi own sub driver callback operations.
 
  IMHO, if phy framework can support extend callback feature, then this
  own sub driver callbacks can be replaced with phy framework at long 
 term
  view.
 
  Extended callbacks are always welcome. I can also use phy device
  private data to pass on private ops like get_pixelclk and set_pixelclk.
 
 I would recommend creating a wrapper to the existing PHY framework
 for HDMI PHY. That way, we can have other HDMI phys added
 easily. We need to figure out all the ops that might be needed by the
 HDMI PHY to be added to the wrapper.
 IMO extended callbacks can lead to abuse of the system and should be
 used only when absolutely