i915 pipe A assertion failure (expected on, current off)

2013-09-21 Thread Meelis Roos 
> Tried 3.11-rc7 on Thinkpad X30 (first 3-11-rc tried on this hw). Works 
> but i915 gives strange assertion failure with WARNING stack trace. This 
> is new since 3.10.

It is still there with 3.12-rc1 but now I git around to bisecting it. 
This is the commit that introduces the warning.

commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
Author: Daniel Vetter 
Date:   Thu Jun 13 00:54:58 2013 +0200

drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms

Same reasons as for the previous patch, just no bug report about
anything going wrong yet: We only support exactly the mode we program,
so don't leave any stale BIOS state behind.

Again this will be fun to properly track for fastboot.

Reviewed-by: Chris Wilson 
Reviewed-by: Ville Syrj?l? 
Signed-off-by: Daniel Vetter 

> 
> The only monitor is internal LCD. lspci -vvvnn is also below.
> 
> [0.00] Linux version 3.11.0-rc7 (mroos at x30) (gcc version 4.8.1 
> (Debian 4.8.1-5) ) #4 Mon Aug 26 11:42:19 EEST 2013
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009efff] usable
> [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x1f76] usable
> [0.00] BIOS-e820: [mem 0x1f77-0x1f77dfff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0x1f77e000-0x1f77] ACPI NVS
> [0.00] BIOS-e820: [mem 0x1f78-0x1fff] reserved
> [0.00] BIOS-e820: [mem 0xff80-0x] reserved
> [0.00] Notice: NX (Execute Disable) protection missing in CPU!
> [0.00] SMBIOS 2.3 present.
> [0.00] DMI: IBM 26724XG/26724XG, BIOS 1KET48WW (1.09 ) 06/16/2006
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] e820: last_pfn = 0x1f770 max_arch_pfn = 0x10
> [0.00] MTRR default type: uncachable
> [0.00] MTRR fixed ranges enabled:
> [0.00]   0-9 write-back
> [0.00]   A-B uncachable
> [0.00]   C-C write-protect
> [0.00]   D-DBFFF uncachable
> [0.00]   DC000-D write-back
> [0.00]   E-F write-protect
> [0.00] MTRR variable ranges enabled:
> [0.00]   0 base 0 mask FE000 write-back
> [0.00]   1 base 01FF8 mask 8 uncachable
> [0.00]   2 disabled
> [0.00]   3 disabled
> [0.00]   4 disabled
> [0.00]   5 disabled
> [0.00]   6 disabled
> [0.00]   7 disabled
> [0.00] PAT not supported by CPU.
> [0.00] original variable MTRRs
> [0.00] reg 0, base: 0GB, range: 512MB, type WB
> [0.00] reg 1, base: 523776KB, range: 512KB, type UC
> [0.00] total RAM covered: 511M
> [0.00] Found optimal setting for mtrr clean up
> [0.00]  gran_size: 64Kchunk_size: 1M  num_reg: 2  lose 
> cover RAM: 0G
> [0.00] New variable MTRRs
> [0.00] reg 0, base: 0GB, range: 512MB, type WB
> [0.00] reg 1, base: 523776KB, range: 512KB, type UC
> [0.00] initial memory mapped: [mem 0x-0x017f]
> [0.00] Base memory trampoline at [c009b000] 9b000 size 16384
> [0.00] init_memory_mapping: [mem 0x-0x000f]
> [0.00]  [mem 0x-0x000f] page 4k
> [0.00] init_memory_mapping: [mem 0x1f00-0x1f3f]
> [0.00]  [mem 0x1f00-0x1f3f] page 2M
> [0.00] init_memory_mapping: [mem 0x1800-0x1eff]
> [0.00]  [mem 0x1800-0x1eff] page 2M
> [0.00] init_memory_mapping: [mem 0x0010-0x17ff]
> [0.00]  [mem 0x0010-0x003f] page 4k
> [0.00]  [mem 0x0040-0x17ff] page 2M
> [0.00] init_memory_mapping: [mem 0x1f40-0x1f76]
> [0.00]  [mem 0x1f40-0x1f76] page 4k
> [0.00] BRK [0x014da000, 0x014dafff] PGTABLE
> [0.00] ACPI: RSDP 000f7090 00024 (v02 IBM   )
> [0.00] ACPI: XSDT 1f772a76 0004C (v01 IBMTP-1K1090  LTP 
> )
> [0.00] ACPI: FACP 1f772b00 00081 (v01 IBMTP-1K1090 IBM  
> 0001)
> [0.00] ACPI: DSDT 1f772be7 0B22C (v01 IBMTP-1K1090 MSFT 
> 010D)
> [0.00] ACPI: FACS 1f77f000 00040
> [0.00] ACPI: SSDT 1f772bb4 00033 (v01 IBMTP-1K1090 MSFT 
> 010D)
> [0.00] ACPI: ECDT 1f77de13 00052 (v01 IBMTP-1K1090 IBM  
> 0001)
> [0.00] ACPI: TCPA 1f77de65 00032 (v01 IBMTP-1K1090 PTL  
> 0001)
> [0.00] ACPI: BOOT 1f77dfd8 00028 (v01 IBMTP-1K1090  LTP 
> 0001)
> [0.00] 503MB LOWMEM available.
> [

[Bug 69321] starting openCL crashes/boots system

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69321

--- Comment #7 from udo udo...@xs4all.nl ---
Can you please commit the patch as it appears to work well.

-- 
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 v4 1/6] drm: add SimpleDRM driver

2013-09-21 Thread Tom Gundersen 
Hi David,

On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann dh.herrm...@gmail.com wrote:
 The SimpleDRM driver binds to simple-framebuffer devices and provides a
 DRM/KMS API. It provides only a single CRTC+encoder+connector combination
 plus one initial mode.

 Userspace can create one dumb-buffer and attach it to the CRTC. Only if
 the buffer is destroyed, a new buffer can be created. The buffer is
 directly mapped into user-space, so we have only resources for a single
 buffer. Otherwise, shadow buffers plus damage-request would be needed.

 Signed-off-by: David Herrmann dh.herrm...@gmail.com
 Tested-by: Stephen Warren swar...@nvidia.com
 ---

[...]

 +static int sdrm_conn_fill_modes(struct drm_connector *conn, uint32_t max_x,
 +   uint32_t max_y)
 +{
 +   struct sdrm_device *sdrm = conn-dev-dev_private;
 +   struct drm_display_mode *mode;
 +   int ret;
 +
 +   if (conn-force == DRM_FORCE_ON)
 +   conn-status = connector_status_connected;
 +   else if (conn-force)
 +   conn-status = connector_status_disconnected;
 +   else
 +   conn-status = connector_status_connected;
 +
 +   list_for_each_entry(mode, conn-modes, head)
 +   mode-status = MODE_UNVERIFIED;
 +
 +   mode = drm_gtf_mode(sdrm-ddev, sdrm-fb_width, sdrm-fb_height,
 +   60, 0, 0);
 +   if (mode) {
 +   mode-type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
 +   drm_mode_probed_add(conn, mode);
 +   sdrm-mode = mode;

Should you also be setting sdrm-fb_{width,height} to
mode-{v,h}display here? Otherwise, due to the rounding in
drm_gtf_mode(), these values won't necessarily match (which I suppose
they must?).

Cheers,

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

[Bug 68391] [radeonsi] Crash unigine-sanctuary

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68391

--- Comment #10 from Hohahiu rakothe...@gmail.com ---
The problem is still there. 
With kernel 3.11+patches from drm-next+Alex's patch for dynamic runtime,
Mesa, LLVM and other components from git I see the same error:

LLVM ERROR: ran out of registers during register allocation
AL lib: (EE) alc_cleanup: 1 device not closed

on Unigine Sanctuary and Unigine Heaven 3.0.

I haven't tried Tom's patch yet.

-- 
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: i915 pipe A assertion failure (expected on, current off)

2013-09-21 Thread Daniel Vetter 
On Sat, Sep 21, 2013 at 5:29 PM, Meelis Roos mr...@linux.ee wrote:
 Tried 3.11-rc7 on Thinkpad X30 (first 3-11-rc tried on this hw). Works
 but i915 gives strange assertion failure with WARNING stack trace. This
 is new since 3.10.

 It is still there with 3.12-rc1 but now I git around to bisecting it.
 This is the commit that introduces the warning.

 commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Jun 13 00:54:58 2013 +0200

 drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms

My apologies for not responding to your first report, fell through the
cracks somehow. Can you please boot with drm.debug=0xe, reproduce the
WARN and grab the full dmesg (please make sure everything from boot-up
is in there). That's usually enough to figure out what's going wrong
here.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 pipe A assertion failure (expected on, current off)

2013-09-21 Thread Ville Syrjälä 
On Sat, Sep 21, 2013 at 05:48:42PM +0200, Daniel Vetter wrote:
 On Sat, Sep 21, 2013 at 5:29 PM, Meelis Roos mr...@linux.ee wrote:
  Tried 3.11-rc7 on Thinkpad X30 (first 3-11-rc tried on this hw). Works
  but i915 gives strange assertion failure with WARNING stack trace. This
  is new since 3.10.
 
  It is still there with 3.12-rc1 but now I git around to bisecting it.
  This is the commit that introduces the warning.
 
  commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
  Author: Daniel Vetter daniel.vet...@ffwll.ch
  Date:   Thu Jun 13 00:54:58 2013 +0200
 
  drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
 
 My apologies for not responding to your first report, fell through the
 cracks somehow. Can you please boot with drm.debug=0xe, reproduce the
 WARN and grab the full dmesg (please make sure everything from boot-up
 is in there). That's usually enough to figure out what's going wrong
 here.

I'd say it's a simple matter of forgetting about QUIRK_PIPEA_FORCE in
i9xx_set_pipeconf().

-- 
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: no hdmi sound on hd5450

2013-09-21 Thread stompdagg...@yahoo.com 
2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:

 2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
 does the following patch: [FIX][PATCH] drm/radeon: fix WREG32_OR macro
 setting bits in a register which you've commited fixes my
 issue?

Yes, I believe so! Sorry, I forgot to ping you about that.

 thats ok, I've applied the patch it doesn't seems to work, I'll verify later
 today when I'll get home.

 also, does screen flickering is part of this bug?

Please create a bug report, and stop using HTML in your e-mail all the time.

Provide output of avivotool regs hdmi in your bug report.

bug 68244 opened.

I'm trying to figure out how to disable HTML in mails in yahoo, still no luck, 
sorry.

Rafał, any updates on the mentioned above bug? is there anything I can do to 
help?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65254] opengl flicker in xbmc / glxgears

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=65254

--- Comment #19 from Vladi vl...@aresgate.net ---
no change with latest 3.12-rc2 kernel + mesa-

-- 
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 69660] New: alpha problem on 3D game

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69660

  Priority: medium
Bug ID: 69660
  Assignee: dri-devel@lists.freedesktop.org
   Summary: alpha problem on 3D game
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: m...@mancausoft.org
  Hardware: x86 (IA32)
Status: NEW
   Version: 9.2
 Component: Drivers/DRI/R600
   Product: Mesa

The alpha on all £d game have problem. 
Example screenshot on attachment.

OS: debian

version of driver and mesa:

$ dpkg -l | grep radeon
ii  libdrm-radeon1:i386   2.4.46-3 
 i386 Userspace interface to radeon-specific kernel DRM
services -- runtime
ii  radeontool1.6.2-1.1
 i386 utility to control ATI Radeon backlight functions on
laptops
ii  xserver-xorg-video-radeon 1:7.2.0-1+b1 
 i386 X.Org X server -- AMD/ATI Radeon display driver


$ dpkg -l | grep mesa
ii  glx-alternative-mesa  0.4.0
 i386 allows the selection of MESA as GLX provider
ii  libegl1-mesa:i386 9.2-1
 i386 free implementation of the EGL API -- runtime
ii  libegl1-mesa-drivers:i386 9.2-1
 i386 free implementation of the EGL API -- hardware drivers
ii  libgl1-mesa-dev   9.2-1
 i386 free implementation of the OpenGL API -- GLX development
files
ii  libgl1-mesa-dri:i386  9.2-1
 i386 free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-dri-experimental:i386 9.2-1
 i386 free implementation of the OpenGL API -- Extra DRI
modules
ii  libgl1-mesa-glx:i386  9.2-1
 i386 free implementation of the OpenGL API -- GLX runtime
ii  libglapi-mesa:i3869.2-1
 i386 free implementation of the GL API -- shared library
ii  libgles1-mesa:i3869.2-1
 i386 free implementation of the OpenGL|ES 1.x API -- runtime
ii  libglu1-mesa:i386 9.0.0-2  
 i386 Mesa OpenGL utility library (GLU)
ii  libglu1-mesa-dev  9.0.0-2  
 i386 Mesa OpenGL utility library -- development files
ii  libopenvg1-mesa:i386  9.2-1
 i386 free implementation of the OpenVG API -- runtime
ii  libosmesa6:i386   9.2-1
 i386 Mesa Off-screen rendering extension
ii  mesa-common-dev   9.2-1
 i386 Developer documentation for Mesa
ii  mesa-utils8.1.0-2  
 i386 Miscellaneous Mesa GL utilities

-- 
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 69660] alpha problem on 3D game

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69660

--- Comment #1 from mancausoft m...@mancausoft.org ---
Created attachment 86291
  -- https://bugs.freedesktop.org/attachment.cgi?id=86291action=edit
screenshot of 0ad, nexuiz and trine2

-- 
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 69660] alpha problem on 3D game

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69660

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
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 69660] alpha problem on 3D game

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69660

mancausoft m...@mancausoft.org changed:

   What|Removed |Added

  Component|Drivers/Gallium/r600|Drivers/DRI/R600

--- Comment #2 from mancausoft m...@mancausoft.org ---
HW: 
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Caicos [Radeon HD 6450/7450/8450] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 6450 1 GB
DDR3
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 46
Region 0: Memory at e000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at f7e2 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at e000 [size=256]
Expansion ROM at f7e0 [disabled] [size=128K]
Capabilities: access denied
Kernel driver in use: radeon

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

[Bug 69660] alpha problem on 3D game

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69660

--- Comment #3 from mancausoft m...@mancausoft.org ---
(In reply to comment #2)
 HW: 
 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
 Caicos [Radeon HD 6450/7450/8450] (prog-if 00 [VGA controller])
 Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 6450 1
 GB DDR3
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 46
 Region 0: Memory at e000 (64-bit, prefetchable) [size=256M]
 Region 2: Memory at f7e2 (64-bit, non-prefetchable) [size=128K]
 Region 4: I/O ports at e000 [size=256]
 Expansion ROM at f7e0 [disabled] [size=128K]

 Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 4us, L1
unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency
L0 64ns, L1 1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-,
OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee0f00c  Data: 4122
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
Len=010 ?
Capabilities: [150 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-



 Kernel driver in use: radeon

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

[Bug 69660] alpha problem on 3D game

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69660

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68235

--- Comment #44 from Alex Deucher ag...@yahoo.com ---
Created attachment 86296
  -- https://bugs.freedesktop.org/attachment.cgi?id=86296action=edit
patch 1/2

This patch set works around the issue by limiting the sclk and mclk to the
highest levels listed in the clk/voltage dependency tables.  I'll need to dig a
bit more internally to try and figure out how to handle these clks properly.

-- 
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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

2013-09-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68235

--- Comment #45 from Alex Deucher ag...@yahoo.com ---
Created attachment 86297
  -- https://bugs.freedesktop.org/attachment.cgi?id=86297action=edit
patch 2/2

apply these two patches independent of any others.

-- 
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 1/6] drm/radeon/dpm: fetch the max clk from voltage dep tables helper

2013-09-21 Thread Alex Deucher 
This patch adds a helper function to fetch the max clock
from the voltage clock dependecy tables.  Clocks above that
level tend to be unstable and will require additional driver
tweaks in order to work properly.

This patch implemented the helper function to fetch the max clocks
from the dependency tables.  The following patches implement the
per-asic clock filtering.

See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68235

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/btc_dpm.c | 17 +
 drivers/gpu/drm/radeon/btc_dpm.h |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c
index 05ff315..0d0f065 100644
--- a/drivers/gpu/drm/radeon/btc_dpm.c
+++ b/drivers/gpu/drm/radeon/btc_dpm.c
@@ -1168,6 +1168,23 @@ static const struct radeon_blacklist_clocks 
btc_blacklist_clocks[] =
 { 25000, 3, RADEON_SCLK_UP }
 };
 
+void btc_get_max_clock_from_voltage_dependency_table(struct 
radeon_clock_voltage_dependency_table *table,
+u32 *max_clock)
+{
+   u32 i, clock = 0;
+
+   if ((table == NULL) || (table-count == 0)) {
+   *max_clock = clock;
+   return;
+   }
+
+   for (i = 0; i  table-count; i++) {
+   if (clock  table-entries[i].clk)
+   clock = table-entries[i].clk;
+   }
+   *max_clock = clock;
+}
+
 void btc_apply_voltage_dependency_rules(struct 
radeon_clock_voltage_dependency_table *table,
u32 clock, u16 max_voltage, u16 
*voltage)
 {
diff --git a/drivers/gpu/drm/radeon/btc_dpm.h b/drivers/gpu/drm/radeon/btc_dpm.h
index 1a15e0e..3b6f12b 100644
--- a/drivers/gpu/drm/radeon/btc_dpm.h
+++ b/drivers/gpu/drm/radeon/btc_dpm.h
@@ -46,6 +46,8 @@ void btc_adjust_clock_combinations(struct radeon_device *rdev,
   struct rv7xx_pl *pl);
 void btc_apply_voltage_dependency_rules(struct 
radeon_clock_voltage_dependency_table *table,
u32 clock, u16 max_voltage, u16 
*voltage);
+void btc_get_max_clock_from_voltage_dependency_table(struct 
radeon_clock_voltage_dependency_table *table,
+u32 *max_clock);
 void btc_apply_voltage_delta_rules(struct radeon_device *rdev,
   u16 max_vddc, u16 max_vddci,
   u16 *vddc, u16 *vddci);
-- 
1.8.3.1

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

[PATCH 2/6] drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables

2013-09-21 Thread Alex Deucher 
Filter out mclk and sclk levels higher than listed in the clk
voltage dependency tables.  Supporting these clocks will require
additional driver tweaking that isn't supported yet.

See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68235

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/btc_dpm.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c
index 0d0f065..b162e98 100644
--- a/drivers/gpu/drm/radeon/btc_dpm.c
+++ b/drivers/gpu/drm/radeon/btc_dpm.c
@@ -2097,6 +2097,7 @@ static void btc_apply_state_adjust_rules(struct 
radeon_device *rdev,
bool disable_mclk_switching;
u32 mclk, sclk;
u16 vddc, vddci;
+   u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
 
if ((rdev-pm.dpm.new_active_crtc_count  1) ||
btc_dpm_vblank_too_short(rdev))
@@ -2138,6 +2139,39 @@ static void btc_apply_state_adjust_rules(struct 
radeon_device *rdev,
ps-low.vddci = max_limits-vddci;
}
 
+   /* limit clocks to max supported clocks based on voltage dependency 
tables */
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_sclk,
+   max_sclk_vddc);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddci_dependency_on_mclk,
+   max_mclk_vddci);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_mclk,
+   max_mclk_vddc);
+
+   if (max_sclk_vddc) {
+   if (ps-low.sclk  max_sclk_vddc)
+   ps-low.sclk = max_sclk_vddc;
+   if (ps-medium.sclk  max_sclk_vddc)
+   ps-medium.sclk = max_sclk_vddc;
+   if (ps-high.sclk  max_sclk_vddc)
+   ps-high.sclk = max_sclk_vddc;
+   }
+   if (max_mclk_vddci) {
+   if (ps-low.mclk  max_mclk_vddci)
+   ps-low.mclk = max_mclk_vddci;
+   if (ps-medium.mclk  max_mclk_vddci)
+   ps-medium.mclk = max_mclk_vddci;
+   if (ps-high.mclk  max_mclk_vddci)
+   ps-high.mclk = max_mclk_vddci;
+   }
+   if (max_mclk_vddc) {
+   if (ps-low.mclk  max_mclk_vddc)
+   ps-low.mclk = max_mclk_vddc;
+   if (ps-medium.mclk  max_mclk_vddc)
+   ps-medium.mclk = max_mclk_vddc;
+   if (ps-high.mclk  max_mclk_vddc)
+   ps-high.mclk = max_mclk_vddc;
+   }
+
/* XXX validate the min clocks required for display */
 
if (disable_mclk_switching) {
-- 
1.8.3.1

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

[PATCH 4/6] drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables

2013-09-21 Thread Alex Deucher 
Filter out mclk and sclk levels higher than listed in the clk
voltage dependency tables.  Supporting these clocks will require
additional driver tweaking that isn't supported yet.

See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68235

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/si_dpm.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index cfe5d4d..9ace287 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2910,6 +2910,7 @@ static void si_apply_state_adjust_rules(struct 
radeon_device *rdev,
bool disable_sclk_switching = false;
u32 mclk, sclk;
u16 vddc, vddci;
+   u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
int i;
 
if ((rdev-pm.dpm.new_active_crtc_count  1) ||
@@ -2943,6 +2944,29 @@ static void si_apply_state_adjust_rules(struct 
radeon_device *rdev,
}
}
 
+   /* limit clocks to max supported clocks based on voltage dependency 
tables */
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_sclk,
+   max_sclk_vddc);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddci_dependency_on_mclk,
+   max_mclk_vddci);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_mclk,
+   max_mclk_vddc);
+
+   for (i = 0; i  ps-performance_level_count; i++) {
+   if (max_sclk_vddc) {
+   if (ps-performance_levels[i].sclk  max_sclk_vddc)
+   ps-performance_levels[i].sclk = max_sclk_vddc;
+   }
+   if (max_mclk_vddci) {
+   if (ps-performance_levels[i].mclk  max_mclk_vddci)
+   ps-performance_levels[i].mclk = max_mclk_vddci;
+   }
+   if (max_mclk_vddc) {
+   if (ps-performance_levels[i].mclk  max_mclk_vddc)
+   ps-performance_levels[i].mclk = max_mclk_vddc;
+   }
+   }
+
/* XXX validate the min clocks required for display */
 
if (disable_mclk_switching) {
-- 
1.8.3.1

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

[PATCH 3/6] drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables

2013-09-21 Thread Alex Deucher 
filter out mclk and sclk levels higher than listed in the clk
voltage dependency tables.  Supporting these clocks will require
additional driver tweaking that isn't supported yet.

See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68235

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/ni_dpm.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index 6c398a4..f263390 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -787,6 +787,7 @@ static void ni_apply_state_adjust_rules(struct 
radeon_device *rdev,
bool disable_mclk_switching;
u32 mclk, sclk;
u16 vddc, vddci;
+   u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
int i;
 
if ((rdev-pm.dpm.new_active_crtc_count  1) ||
@@ -813,6 +814,29 @@ static void ni_apply_state_adjust_rules(struct 
radeon_device *rdev,
}
}
 
+   /* limit clocks to max supported clocks based on voltage dependency 
tables */
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_sclk,
+   max_sclk_vddc);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddci_dependency_on_mclk,
+   max_mclk_vddci);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_mclk,
+   max_mclk_vddc);
+
+   for (i = 0; i  ps-performance_level_count; i++) {
+   if (max_sclk_vddc) {
+   if (ps-performance_levels[i].sclk  max_sclk_vddc)
+   ps-performance_levels[i].sclk = max_sclk_vddc;
+   }
+   if (max_mclk_vddci) {
+   if (ps-performance_levels[i].mclk  max_mclk_vddci)
+   ps-performance_levels[i].mclk = max_mclk_vddci;
+   }
+   if (max_mclk_vddc) {
+   if (ps-performance_levels[i].mclk  max_mclk_vddc)
+   ps-performance_levels[i].mclk = max_mclk_vddc;
+   }
+   }
+
/* XXX validate the min clocks required for display */
 
if (disable_mclk_switching) {
-- 
1.8.3.1

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

[PATCH 5/6] drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables

2013-09-21 Thread Alex Deucher 
Filter out mclk and sclk levels higher than listed in the clk
voltage dependency tables.  Supporting these clocks will require
additional driver tweaking that isn't supported yet.

See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68235

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/ci_dpm.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 8996274..51e947a 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -146,6 +146,8 @@ static const struct ci_pt_config_reg didt_config_ci[] =
 };
 
 extern u8 rv770_get_memory_module_index(struct radeon_device *rdev);
+extern void btc_get_max_clock_from_voltage_dependency_table(struct 
radeon_clock_voltage_dependency_table *table,
+   u32 *max_clock);
 extern int ni_copy_and_switch_arb_sets(struct radeon_device *rdev,
   u32 arb_freq_src, u32 arb_freq_dest);
 extern u8 si_get_ddr3_mclk_frequency_ratio(u32 memory_clock);
@@ -712,6 +714,7 @@ static void ci_apply_state_adjust_rules(struct 
radeon_device *rdev,
struct radeon_clock_and_voltage_limits *max_limits;
bool disable_mclk_switching;
u32 sclk, mclk;
+   u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
int i;
 
if ((rdev-pm.dpm.new_active_crtc_count  1) ||
@@ -739,6 +742,29 @@ static void ci_apply_state_adjust_rules(struct 
radeon_device *rdev,
}
}
 
+   /* limit clocks to max supported clocks based on voltage dependency 
tables */
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_sclk,
+   max_sclk_vddc);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddci_dependency_on_mclk,
+   max_mclk_vddci);
+   
btc_get_max_clock_from_voltage_dependency_table(rdev-pm.dpm.dyn_state.vddc_dependency_on_mclk,
+   max_mclk_vddc);
+
+   for (i = 0; i  ps-performance_level_count; i++) {
+   if (max_sclk_vddc) {
+   if (ps-performance_levels[i].sclk  max_sclk_vddc)
+   ps-performance_levels[i].sclk = max_sclk_vddc;
+   }
+   if (max_mclk_vddci) {
+   if (ps-performance_levels[i].mclk  max_mclk_vddci)
+   ps-performance_levels[i].mclk = max_mclk_vddci;
+   }
+   if (max_mclk_vddc) {
+   if (ps-performance_levels[i].mclk  max_mclk_vddc)
+   ps-performance_levels[i].mclk = max_mclk_vddc;
+   }
+   }
+
/* XXX validate the min clocks required for display */
 
if (disable_mclk_switching) {
-- 
1.8.3.1

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

[PATCH 6/6] drm/radeon: don't set default clocks for SI when DPM is disabled

2013-09-21 Thread Alex Deucher 
This is a partial revert of c6cfa32da874fabec4fd1c2a579f0ba4e4dd.

We need to take into account the clk voltage dependencies of the
board.  Not doing so can lead to stability issues on certain
boards if the clks exceed the levels in the dep tables.

DPM already takes that into account, so for optimal performance,
use DPM.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_pm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 87e1d69..ac07ad1 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1002,7 +1002,7 @@ static void radeon_pm_resume_old(struct radeon_device 
*rdev)
 {
/* set up the default clocks if the MC ucode is loaded */
if ((rdev-family = CHIP_BARTS) 
-   (rdev-family = CHIP_HAINAN) 
+   (rdev-family = CHIP_CAYMAN) 
rdev-mc_fw) {
if (rdev-pm.default_vddc)
radeon_atom_set_voltage(rdev, rdev-pm.default_vddc,
@@ -1046,7 +1046,7 @@ static void radeon_pm_resume_dpm(struct radeon_device 
*rdev)
if (ret) {
DRM_ERROR(radeon: dpm resume failed\n);
if ((rdev-family = CHIP_BARTS) 
-   (rdev-family = CHIP_HAINAN) 
+   (rdev-family = CHIP_CAYMAN) 
rdev-mc_fw) {
if (rdev-pm.default_vddc)
radeon_atom_set_voltage(rdev, 
rdev-pm.default_vddc,
@@ -1097,7 +1097,7 @@ static int radeon_pm_init_old(struct radeon_device *rdev)
radeon_pm_init_profile(rdev);
/* set up the default clocks if the MC ucode is loaded */
if ((rdev-family = CHIP_BARTS) 
-   (rdev-family = CHIP_HAINAN) 
+   (rdev-family = CHIP_CAYMAN) 
rdev-mc_fw) {
if (rdev-pm.default_vddc)
radeon_atom_set_voltage(rdev, 
rdev-pm.default_vddc,
@@ -1183,7 +1183,7 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev)
if (ret) {
rdev-pm.dpm_enabled = false;
if ((rdev-family = CHIP_BARTS) 
-   (rdev-family = CHIP_HAINAN) 
+   (rdev-family = CHIP_CAYMAN) 
rdev-mc_fw) {
if (rdev-pm.default_vddc)
radeon_atom_set_voltage(rdev, 
rdev-pm.default_vddc,
-- 
1.8.3.1

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

[PATCH 1/1] drm/radeon: Don't run tests when underlying memory was uninitialized

2013-09-21 Thread Alex Ivanov 
20.09.2013, в 22:33, Alex Deucher alexdeuc...@gmail.com написал(а):

 On Fri, Sep 20, 2013 at 9:36 AM, Alex Ivanov gnido...@p0n4ik.tk wrote:
 Prevent NULL pointer dereference in case when radeon_ring_fini() did it's 
 job.
 
 Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead 
 to a KP if ring buffer was deallocated, e.g. on failed ring test.
 Seen on PA-RISC machine having radeon: ring test failed 
 (scratch(0x8504)=0xCAFEDEAD) issue.
 
 Signed-off-by: Alex Ivanov gnido...@p0n4ik.tk
 
 Applied.  thanks!
 
 Alex

One more. Thank you!

Signed-off-by: Alex Ivanov gnido...@p0n4ik.tk
---
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e29faa7..e6d1897 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1319,6 +1319,11 @@ int radeon_device_init(struct radeon_device *rdev,
if (r)
return r;
}
+   /* If ring buffer or PCI GART got uninitialized, we should't run tests 
*/
+   if (!rdev-accel_working) {
+   DRM_INFO(radeon: acceleration disabled, skipping tests and 
benchmark.\n);
+   return 0;
+   }
if ((radeon_testing  1)) {
radeon_test_moves(rdev);
}



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