[git pull] drm radeon fixes

2013-02-03 Thread Dave Airlie 

Hi Linus,

I got these late last week, the main chunks of these fix a rendering 
regression since 3.7, and the settle ones all fix the issue where we don't 
wait long enough for the memory controller to settle after turning it off 
which causes bad memory reads, they all fix real users bugs, and most of 
them are destined for stable.

can't remember if you had net connection on that island :-)

Dave.

The following changes since commit ff0d05bf73620eb7dc8aee7423e992ef87870bdf:

  Revert "console: implement lockdep support for console_lock" (2013-01-31 
15:46:56 +1100)

are available in the git repository at:

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

for you to fetch changes up to 089c71a7c306dff067097f37ef329ccdf3269811:

  Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux 
(2013-02-01 10:51:02 +1100)



Alex Deucher (7):
  drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN
  drm/radeon: add quirk for RV100 board
  drm/radeon: fix backend map setup on 1 RB sumo boards
  drm/radeon/evergreen+: wait for the MC to settle after MC blackout
  drm/radeon/r5xx-r7xx: wait for the MC to settle after MC blackout
  drm/radeon: prevent crash in the ring space allocation
  drm/radeon: switch back to the CP ring for VM PT updates

Christopher Staite (1):
  drm/radeon: fix MC blackout on evergreen+

Dave Airlie (1):
  Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux

Mikko Tiihonen (1):
  drm/radeon: protect against div by 0 in backend setup

liu chuansheng (1):
  drm/radeon: Calling object_unrefer() when creating fb failure

 drivers/gpu/drm/radeon/evergreen.c  | 27 ---
 drivers/gpu/drm/radeon/r600.c   |  7 +--
 drivers/gpu/drm/radeon/radeon_asic.c|  6 +++---
 drivers/gpu/drm/radeon/radeon_combios.c |  8 
 drivers/gpu/drm/radeon/radeon_display.c |  4 +++-
 drivers/gpu/drm/radeon/radeon_ring.c|  3 +++
 drivers/gpu/drm/radeon/reg_srcs/cayman  |  1 +
 drivers/gpu/drm/radeon/rv515.c  |  2 ++
 8 files changed, 49 insertions(+), 9 deletions(-)

3.8-rc6: nouveau lockdep recursive lock acquisition

2013-02-03 Thread Daniel J Blueman 
>From recent additional locking in nouveau, it looks like we see
recursive lock acquisition in 3.8-rc6:

nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0e7150a2
nouveau [ DEVICE][:01:00.0] Chipset: GK107 (NVE7)
nouveau [ DEVICE][:01:00.0] Family : NVE0
nouveau [  VBIOS][:01:00.0] checking PRAMIN for image...
nouveau [  VBIOS][:01:00.0] ... appears to be valid
nouveau [  VBIOS][:01:00.0] using image from PRAMIN
nouveau [  VBIOS][:01:00.0] BIT signature found
nouveau [  VBIOS][:01:00.0] version 80.07.26.04.01
nouveau [   PFB][:01:00.0] RAM type: GDDR5
nouveau [   PFB][:01:00.0] RAM size: 1024 MiB
nouveau [   PFB][:01:00.0]  ZCOMP: 0 tags
init: gdm main process (960) killed by TERM signal
vga_switcheroo: enabled
[TTM] Zone kernel: Available graphics memory: 4038258 kiB
[TTM] Zone  dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
nouveau [   DRM] VRAM: 1024 MiB
nouveau [   DRM] GART: 512 MiB
nouveau [   DRM] BIT BIOS found
nouveau [   DRM] Bios version 80.07.26.04
nouveau [   DRM] TMDS table version 2.0
nouveau [   DRM] DCB version 4.0
nouveau [   DRM] DCB outp 00: 048101b6 0f230010
nouveau [   DRM] DCB outp 01: 018212d6 0f220020
nouveau [   DRM] DCB outp 02: 01021212 00020020
nouveau [   DRM] DCB outp 03: 088324c6 0f220010
nouveau [   DRM] DCB outp 04: 08032402 00020010
nouveau [   DRM] DCB outp 05: 02843862 00020010
nouveau [   DRM] DCB conn 00: 00020047
nouveau [   DRM] DCB conn 01: 02208146
nouveau [   DRM] DCB conn 02: 01104246
nouveau [   DRM] DCB conn 03: 00410361

=
[ INFO: possible recursive locking detected ]
3.8.0-rc6-ninja+ #1 Not tainted
-
modprobe/585 is trying to acquire lock:
 (>mutex){+.+.+.}, at: []
nouveau_instobj_create_+0x43/0x90 [nouveau]

but task is already holding lock:
 (>mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]

other info that might help us debug this:
 Possible unsafe locking scenario:

CPU0

 lock(>mutex);
 lock(>mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

4 locks held by modprobe/585:
 #0: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x53/0xb0
 #1: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x61/0xb0
 #2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xbc/0x2b0
 #3: (>mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]

stack backtrace:
Pid: 585, comm: modprobe Not tainted 3.8.0-rc6-expert+ #1
Call Trace:
 [] validate_chain.isra.33+0xd72/0x10d0
 [] ? __kernel_text_address+0x58/0x80
 [] ? print_context_stack+0x5d/0xd0
 [] __lock_acquire+0x3a1/0xb60
 [] ? __lock_is_held+0x54/0x80
 [] lock_acquire+0x5a/0x70
 [] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
 [] mutex_lock_nested+0x69/0x340
 [] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
 [] ? nouveau_object_create_+0x60/0xa0 [nouveau]
 [] nouveau_instobj_create_+0x43/0x90 [nouveau]
 [] nv50_instobj_ctor+0x4c/0xf0 [nouveau]
 [] nouveau_object_ctor+0x33/0xc0 [nouveau]
 [] nv50_instmem_alloc+0x21/0x30 [nouveau]
 [] nouveau_gpuobj_create_+0x247/0x2f0 [nouveau]
 [] ? _raw_spin_unlock_irqrestore+0x3a/0x70
 [] ? trace_hardirqs_on_caller+0x10d/0x1a0
 [] nouveau_engctx_create_+0x25c/0x2a0 [nouveau]
 [] nv50_disp_data_ctor+0xc1/0xd0 [nouveau]
 [] ? nouveau_subdev_reset+0x52/0x60 [nouveau]
 [] nouveau_object_ctor+0x33/0xc0 [nouveau]
 [] nouveau_object_new+0x112/0x240 [nouveau]
 [] nv50_display_create+0x18d/0x860 [nouveau]
 [] ? __cancel_work_timer+0x6d/0xc0
 [] nouveau_display_create+0x3cb/0x670 [nouveau]
 [] nouveau_drm_load+0x26f/0x590 [nouveau]
 [] ? device_register+0x19/0x20
 [] ? drm_sysfs_device_add+0x81/0xb0
 [] drm_get_pci_dev+0x17e/0x2b0
 [] ? __pci_set_master+0x26/0x80
 [] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
 [] local_pci_probe+0x46/0x80
 [] pci_device_probe+0x101/0x110
 [] driver_probe_device+0x76/0x240
 [] __driver_attach+0xa3/0xb0
 [] ? driver_probe_device+0x240/0x240
 [] bus_for_each_dev+0x4d/0x90
 [] driver_attach+0x19/0x20
 [] bus_add_driver+0x1a0/0x270
 [] ? 0xa023cfff
 [] driver_register+0x72/0x170
 [] ? 0xa023cfff
 [] __pci_register_driver+0x5f/0x70
 [] drm_pci_init+0x115/0x130
 [] ? 0xa023cfff
 [] ? 0xa023cfff
 [] nouveau_drm_init+0x4d/0x1000 [nouveau]
 [] do_one_initcall+0x11a/0x170
 [] load_module+0xe84/0x1470
 [] ? in_lock_functions+0x20/0x20
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] sys_init_module+0xb7/0xe0
 [] system_call_fastpath+0x1a/0x1f
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
nouveau W[   DRM] voltage table 0x50 unknown
nouveau [   DRM] 4 available performance level(s)
nouveau [   DRM] 1: core 209MHz shader 419MHz memory 405MHz voltage 520mV
nouveau [   DRM] 2: core 390MHz shader 780MHz memory 1080MHz voltage 610mV
nouveau [   DRM] 3: core 1000MHz shader 2000MHz memory 1080MHz voltage 630mV
nouveau [   DRM]

[PATCH] drm: fix compile failure by including

2013-02-03 Thread Maarten Lankhorst 
Op 01-02-13 19:44, Chris Metcalf schreef:
> On tile architecture (with "make allyesconfig") including
>  is required to call swiotlb_nr_tbl().
I'll take your word for the need, since I lack the hardware to verify the 
failure. :-)
Applying your patch doesn't seem to break compilation on x86 though, which is 
good enough for me.

Acked-by: Maarten Lankhorst 
> Signed-off-by: Chris Metcalf 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
>  drivers/gpu/drm/radeon/radeon_ttm.c  |1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 69d7b1d..1699a90 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -28,6 +28,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 1d8ff2f..93f760e 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "radeon_reg.h"
>  #include "radeon.h"
>

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

2013-02-03 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=44341


Christopher Fr?mmel  changed:

   What|Removed |Added

 Kernel Version|3.5.2   |3.7.5




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

[Bug 60254] kernel Oops when provoking GPU lock.

2013-02-03 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=60254

Andy Furniss  changed:

   What|Removed |Added

Summary|agd5f wip kernel Oops when  |kernel Oops when provoking
   |provoking GPU lock. |GPU lock.

--- Comment #1 from Andy Furniss  ---
(In reply to comment #0)
> The GPU lock with Rv670 and openarena is nothing new - it seems to have been
> a feature for almost a year (I haven't used rv670 for most of that time).
> 
> On noticing the new gpu reset code in drm-next-3.9-wip I decided to provoke
> it on my AGP box and got -

Hmm I just managed to get the same running drm-fixes so it's not wip maybe it's
because I am now using llvm. In the (no llvm) past with other kernels this GPU
lock normally went quite well - the game often just continued for a while,
until it hit another one.

-- 
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/20130203/75737f5e/attachment.html>

[Bug 60254] New: agd5f wip kernel Oops when provoking GPU lock.

2013-02-03 Thread bugzilla-dae...@freedesktop.org 
he bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130203/47aa1d29/attachment.html>

[RFC PATCH 0/4] Common Display Framework-TF

2013-02-03 Thread Tomasz Figa 
Hi Laurent,

On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
> Hi Tomasz,
> 
> Thank you for your RFC.
> 
> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
> > Hi,
> > 
> > After pretty long time of trying to adapt Exynos-specific DSI display
> > support to Common Display Framework I'm ready to show some preliminary
> > RFC patches. This series shows some ideas for CDF that came to my
> > mind during my work, some changes based on comments received by
> > Tomi's edition of CDF and also preliminarys version of Exynos DSI
> > (video source part only, still with some FIXMEs) and Samsung S6E8AX0
> > DSI panel drivers.
> > 
> > It is heavily based on Tomi's work which can be found here:
> > http://thread.gmane.org/gmane.comp.video.dri.devel/78227
> > 
> > The code might be a bit hacky in places, as I wanted to get it to a
> > kind of complete and working state first. However I hope that some of
> > the ideas might useful for further works.
> > 
> > So, here comes the TF edition of Common Clock Framework.
> > 
> > 
> > Changes done to Tomi's edition of CDF:
> >  - Replaced set_operation_mode, set_pixel_format and set_size video
> >  source>  
> >operations with get_params display entity operation, as it was
> >originally in Laurent's version.
> >
> >We have discussed this matter on the mailing list and decided that
> >it
> >would be better to have the source ask the sink for its parameter
> >structure and do whatever appropriate with it.
> 
> Could you briefly outline the rationale behind this ?

Display interfaces may be described by an arbitrary number of parameters. 
Some will require just video timings, others like DSI will require a 
significant number of additional bus-specific ones.

Separating all the parameters (all of which are usually set at the same 
time) into a lot of ops setting single parameter will just add unnecessary 
complexity.

> I'm wondering whether get_params could limit us if a device needs to
> modify parameters at runtime. For instance a panel might need to change
> clock frequencies or number of used data lane depending on various
> runtime conditions. I don't have a real use case here, so it might just
> be a bit of over-engineering.

Hmm, isn't it in the opposite direction (the user requests the display 
interface to change, for example, video mode, which in turn reconfigures 
the link and requests the panel to update its settings)?

However it might be reasonable to split the parameters into constant and 
variable ones. In case of DSI bus, there is a lot of parameters that are 
considered just at link initialization time (the whole dsi params struct I 
defined). Video mode, however, is a variable parameter that can be changed 
on some displays.

> 
> >  - Defined a preliminary set of DSI bus parameters.
> >  
> >Following parameters are defined:
> >
> >1. Pixel format used for video data transmission.
> >
> >2. Mode flags (several bit flags ORed together):
> >  a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command
> >  
> > mode), following DSI_MODE_VIDEO_* flags are relevant only if
> > this
> > flag is set.
> > b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video
> > data
> > c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as
> > opposed
> > 
> >to sync events)
> > 
> > d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
> > 
> >detection
> > 
> > e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end
> > packets
> > f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch
> > area
> > g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch
> > area
> > h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active
> > area
> >  
> >  i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
> >  j) DSI_MODE_EOT_PACKET - entity needs EoT packets
> >
> >3. Bit (serial) clock frequency in HS mode.
> >4. Escape mode clock frequency.
> >5. Mask of used data lanes (each bit represents single lane).
> 
> From my experience with MIPI CSI (Camera Serial Interface, similar to
> DSI) some transceivers can reroute data lanes internally. Is that true
> for DSI as well ? In that case we would need a list of data lanes, not
> just a mask.

Hmm, I don't remember at the moment, will have to look to the 
specification. Exynos DSI master doesn't support such feature.

> >6. Command allow area in video mode - amount of lines after
> >transmitting>
> >   video data when generic commands are accepted.
> >
> >Feel free to suggest anything missing or wrong, as the list of
> >parameters is based merely on what was used in original Exynos MIPI
> >DSIM driver.
> >  
> >  -

[Bug 43751] [TTM] Out of kernel memory

2013-02-03 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=43751


cyberbat  changed:

   What|Removed |Added

 CC||cyberbat at lavabit.com




--- Comment #8 from cyberbat   2013-02-03 19:43:52 ---
I have just the same thing on 3.6.11 kernel:
Feb  3 06:54:27 cybernest kernel: [329369.962274] [TTM] Out of kernel memory
Feb  3 06:54:27 cybernest kernel: [329369.962279] radeon :01:00.0:
object_init failed for (4096, 0x0002)
Feb  3 06:54:27 cybernest kernel: [329369.962281]
[drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (4096, 2,
4096, -12)

I use xorg-server-1.13.1 (xf86-video-ati-7.0.0) and mesa-9.0.1. I can provide
more info if needed.

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

[Bug 53391] nouveau: wrong display output order

2013-02-03 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=53391





--- Comment #1 from Stijn Tintel   2013-02-03 
18:22:04 ---
Created an attachment (id=92501)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=92501)
dmesg

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

[Bug 53391] New: nouveau: wrong display output order

2013-02-03 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=53391

   Summary: nouveau: wrong display output order
   Product: Drivers
   Version: 2.5
Kernel Version: 3.8-rc6
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: stijn+bugs at linux-ipv6.be
Regression: No


My graphics card is a Gainward GTX480
(http://www.gainward.com/main/vgapro.php?id=238). It has 2 DVI outputs, and 1
mini HDMI output. The DVI outputs are numbered on the card, with DVI 1 being
the closest to the PCIe slot, then DVI 2, and finally the mini HDMI.

My primary (left) monitor, is connected to DVI 1, my secondary (right) monitor
to DVI 2. When I boot the computer, the BIOS initializes and uses the monitor
on DVI 1. Grub is displayed on the primary monitor, and the kernel initially
outputs to the primary monitor as well.

However, as soon as the nouveau module is loaded, the primary monitor goes to
standby and the kernel now uses the secondary monitor (on DVI 2) as primary.
When X starts (no Xorg.conf file), it is also displayed on the secondary
monitor.

When using either efifb, vesafb or uvesafb, the monitor on DVI 1 is always the
primary monitor. X with nvidia.ko also uses DVI 1 as the primary display.
Finally, when booting Windows, the startup screen is also displayed on the
monitor connected to DVI 1.

Here comes the weird part: when I am in X, and run xrandr, it does show 3
connected devices: DVI-I-1, DVI-I-2, and HDMI-1, with DVI-I-2 being the only
active one. So it seems that in X, the output order is correct, but with
nouveaufb the DVI connectors are swapped.

I will attach the output of dmesg here. If anything else is needed, please let
me know and I'll be happy to add it.

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

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

2013-02-03 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=60236

--- Comment #2 from Paul Heldens  ---
also corruption in 2D apps (seamonkey)

-- 
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/20130203/28098665/attachment.html>

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

2013-02-03 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=60236

--- Comment #1 from Paul Heldens  ---
linux 3.8-rc63.7.4 had it also

-- 
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/20130203/d2ddfe79/attachment.html>

[Bug 60236] New: corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

2013-02-03 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=60236

  Priority: medium
Bug ID: 60236
  Assignee: dri-devel at lists.freedesktop.org
   Summary: corruption of text and bottom of screen in xonotic
menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: pheldens at ziggo.nl
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

bisected to this commit

325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit
commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
Author: Jerome Glisse 
Date:   Mon Jan 7 17:45:59 2013 -0500

r600g: add async for staging buffer upload v2

v2: Add virtual address to dma src/dst offset for cayman

Signed-off-by: Jerome Glisse 

:04 04 4ef6e784f3acb7f21da0c5e1923810c78917d16d
55f0ce7d9793ce04d392fc7943059545053a9d79 Msrc

-- 
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/20130203/ec61627a/attachment.html>

[Bug 60224] New: Radeon hd6770 graphics artifacts in team fortress 2 with 3.8 kernel

2013-02-03 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=60224

  Priority: medium
Bug ID: 60224
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Radeon hd6770 graphics artifacts in team fortress 2
with 3.8 kernel
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pontostroy at gmail.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 74130
  --> https://bugs.freedesktop.org/attachment.cgi?id=74130=edit
tf2

mesa, libdrm, ddx from git
1:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Juniper
XT [AMD Radeon HD 6000 Series]

With kernel <3.8 all looks fine.

-- 
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/20130203/d454c74f/attachment.html>

CDF discussions at FOSDEM

2013-02-03 Thread Martin Peres 
On 31/01/2013 11:53, Laurent Pinchart wrote:
> On Friday 11 January 2013 21:27:03 Laurent Pinchart wrote:
>> Hi everybody,
>>
>> Would anyone be interested in meeting at the FOSDEM to discuss the Common
>> Display Framework ? There will be a CDF meeting at the ELC at the end of
>> February, the FOSDEM would be a good venue for European developers.
> A quick follow-up on this.
>
> Given the late notice getting a room from the FOSDEM staff wasn't possible.
> There will be two meeting rooms available that can be reserved on-site only.
> They can accomodate aroudn 30 people but there will deliberately be no
> projector. They will be given on a first-come, first-serve basis for one hour
> time slots at most (see https://fosdem.org/2013/news/2013-01-31-bof-
> announce/).
>
> As room availability isn't guaranteed, and as one hour might be a bit short,
> I've secured an off-site but very close
> (http://www.openstreetmap.org/?lat=50.812924=4.384506=18=M -
> UrLab) room that can accomodate 12 people around a meeting table (more is
> possible, but it might get a bit tight then). I propose having the CDF
> discussion there on Sunday morning from 9am to 11am (please let me know ASAP
> if you can't make it at that time).
>
> Daniel Vetter
> Jani Nikula
> Marcus Lorentzon
> Laurent Pinchart
> Michael (from Pengutronix, not sure about the last name, sorry)
> Philipp Zabel
> Rob Clark
> Robert Schwebel
> Sascha Hauer
> Ville Syrj?l?
>
> That's already 10 people. If someone else would like to attend the meeting
> please let me know.
Hi,

I am interested in the CDF. Where and when are you meeting?

Martin

[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy

2013-02-03 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=59903

klondike  changed:

   What|Removed |Added

 CC||klondike at klondike.es

--- Comment #12 from klondike  ---
I have found this issue today at FOSDEM after disconnecting the VGA cable from
the projector (not sure if before or after putting the computer to sleep).

When I came back, this wasw happening and xrandr showed what follows:
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS connected 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x
0mm
   1366x768   59.9*+
   1280x720   59.9  
   1152x768   59.8  
   1024x768   59.9  
   800x60059.9  
   848x48059.7  
   720x48059.7  
   640x48059.4  
HDMI-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm
x 0mm
  1024x768 (0x6c77)   65.0MHz
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz

After running xrandr --output VGA-0 --off to turn VGA off it worked again.

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

Re: CDF discussions at FOSDEM

2013-02-03 Thread Martin Peres 

On 31/01/2013 11:53, Laurent Pinchart wrote:

On Friday 11 January 2013 21:27:03 Laurent Pinchart wrote:

Hi everybody,

Would anyone be interested in meeting at the FOSDEM to discuss the Common
Display Framework ? There will be a CDF meeting at the ELC at the end of
February, the FOSDEM would be a good venue for European developers.

A quick follow-up on this.

Given the late notice getting a room from the FOSDEM staff wasn't possible.
There will be two meeting rooms available that can be reserved on-site only.
They can accomodate aroudn 30 people but there will deliberately be no
projector. They will be given on a first-come, first-serve basis for one hour
time slots at most (see https://fosdem.org/2013/news/2013-01-31-bof-
announce/).

As room availability isn't guaranteed, and as one hour might be a bit short,
I've secured an off-site but very close
(http://www.openstreetmap.org/?lat=50.812924lon=4.384506zoom=18layers=M -
UrLab) room that can accomodate 12 people around a meeting table (more is
possible, but it might get a bit tight then). I propose having the CDF
discussion there on Sunday morning from 9am to 11am (please let me know ASAP
if you can't make it at that time).

Daniel Vetter
Jani Nikula
Marcus Lorentzon
Laurent Pinchart
Michael (from Pengutronix, not sure about the last name, sorry)
Philipp Zabel
Rob Clark
Robert Schwebel
Sascha Hauer
Ville Syrjälä

That's already 10 people. If someone else would like to attend the meeting
please let me know.

Hi,

I am interested in the CDF. Where and when are you meeting?

Martin

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

[Bug 60224] New: Radeon hd6770 graphics artifacts in team fortress 2 with 3.8 kernel

2013-02-03 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=60224

  Priority: medium
Bug ID: 60224
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Radeon hd6770 graphics artifacts in team fortress 2
with 3.8 kernel
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pontost...@gmail.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 74130
  -- https://bugs.freedesktop.org/attachment.cgi?id=74130action=edit
tf2

mesa, libdrm, ddx from git
1:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Juniper
XT [AMD Radeon HD 6000 Series]

With kernel 3.8 all looks fine.

-- 
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 60236] New: corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

2013-02-03 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=60236

  Priority: medium
Bug ID: 60236
  Assignee: dri-devel@lists.freedesktop.org
   Summary: corruption of text and bottom of screen in xonotic
menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: pheld...@ziggo.nl
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

bisected to this commit

325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit
commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
Author: Jerome Glisse jgli...@redhat.com
Date:   Mon Jan 7 17:45:59 2013 -0500

r600g: add async for staging buffer upload v2

v2: Add virtual address to dma src/dst offset for cayman

Signed-off-by: Jerome Glisse jgli...@redhat.com

:04 04 4ef6e784f3acb7f21da0c5e1923810c78917d16d
55f0ce7d9793ce04d392fc7943059545053a9d79 Msrc

-- 
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 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

2013-02-03 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=60236

--- Comment #1 from Paul Heldens pheld...@ziggo.nl ---
linux 3.8-rc63.7.4 had it also

-- 
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 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

2013-02-03 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=60236

--- Comment #2 from Paul Heldens pheld...@ziggo.nl ---
also corruption in 2D apps (seamonkey)

-- 
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 53391] New: nouveau: wrong display output order

2013-02-03 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=53391

   Summary: nouveau: wrong display output order
   Product: Drivers
   Version: 2.5
Kernel Version: 3.8-rc6
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: stijn+b...@linux-ipv6.be
Regression: No


My graphics card is a Gainward GTX480
(http://www.gainward.com/main/vgapro.php?id=238). It has 2 DVI outputs, and 1
mini HDMI output. The DVI outputs are numbered on the card, with DVI 1 being
the closest to the PCIe slot, then DVI 2, and finally the mini HDMI.

My primary (left) monitor, is connected to DVI 1, my secondary (right) monitor
to DVI 2. When I boot the computer, the BIOS initializes and uses the monitor
on DVI 1. Grub is displayed on the primary monitor, and the kernel initially
outputs to the primary monitor as well.

However, as soon as the nouveau module is loaded, the primary monitor goes to
standby and the kernel now uses the secondary monitor (on DVI 2) as primary.
When X starts (no Xorg.conf file), it is also displayed on the secondary
monitor.

When using either efifb, vesafb or uvesafb, the monitor on DVI 1 is always the
primary monitor. X with nvidia.ko also uses DVI 1 as the primary display.
Finally, when booting Windows, the startup screen is also displayed on the
monitor connected to DVI 1.

Here comes the weird part: when I am in X, and run xrandr, it does show 3
connected devices: DVI-I-1, DVI-I-2, and HDMI-1, with DVI-I-2 being the only
active one. So it seems that in X, the output order is correct, but with
nouveaufb the DVI connectors are swapped.

I will attach the output of dmesg here. If anything else is needed, please let
me know and I'll be happy to add it.

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

[Bug 53391] nouveau: wrong display output order

2013-02-03 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=53391





--- Comment #1 from Stijn Tintel stijn+b...@linux-ipv6.be  2013-02-03 
18:22:04 ---
Created an attachment (id=92501)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=92501)
dmesg

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

[Bug 43751] [TTM] Out of kernel memory

2013-02-03 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=43751


cyberbat cyber...@lavabit.com changed:

   What|Removed |Added

 CC||cyber...@lavabit.com




--- Comment #8 from cyberbat cyber...@lavabit.com  2013-02-03 19:43:52 ---
I have just the same thing on 3.6.11 kernel:
Feb  3 06:54:27 cybernest kernel: [329369.962274] [TTM] Out of kernel memory
Feb  3 06:54:27 cybernest kernel: [329369.962279] radeon :01:00.0:
object_init failed for (4096, 0x0002)
Feb  3 06:54:27 cybernest kernel: [329369.962281]
[drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (4096, 2,
4096, -12)

I use xorg-server-1.13.1 (xf86-video-ati-7.0.0) and mesa-9.0.1. I can provide
more info if needed.

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

[Bug 60254] New: agd5f wip kernel Oops when provoking GPU lock.

2013-02-03 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=60254

  Priority: medium
Bug ID: 60254
  Assignee: dri-devel@lists.freedesktop.org
   Summary: agd5f wip kernel Oops when provoking GPU lock.
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: li...@andyfurniss.entadsl.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

The GPU lock with Rv670 and openarena is nothing new - it seems to have been a
feature for almost a year (I haven't used rv670 for most of that time).

On noticing the new gpu reset code in drm-next-3.9-wip I decided to provoke it
on my AGP box and got -

Feb  3 20:46:56 nf7 kernel: radeon :02:00.0: GPU lockup CP stall for more
than 1msec
Feb  3 20:46:56 nf7 kernel: radeon :02:00.0: GPU lockup (waiting for
0x000111c8 last fence id 0x000111c6)
Feb  3 20:46:56 nf7 kernel: radeon :02:00.0: f51df600 unpin not necessary
Feb  3 20:46:56 nf7 kernel: radeon :02:00.0: Saved 217 dwords of commands
on ring 0.
Feb  3 20:46:56 nf7 kernel: BUG: unable to handle kernel paging request at
f87aec0c
Feb  3 20:46:56 nf7 kernel: IP: [fa033a3e] radeon_fence_process+0x7e/0x160
[radeon]
Feb  3 20:46:56 nf7 kernel: *pde = 3702f067 *pte =  
Feb  3 20:46:56 nf7 kernel: Oops:  [#1] PREEMPT 
Feb  3 20:46:56 nf7 kernel: Modules linked in: radeon fbcon font bitblit ttm
softcursor drm_kms_helper drm fb fbdev i2c_algo_bit i2c_core cfbcopyarea
cfbimgblt cfbfillrect ehci_pci ehci_hcd nvidia_agp agpgart ohci_hcd usbhid
usbcore usb_common snd_intel8x0 snd_ac97_codec ac97_bus forcedeth
Feb  3 20:46:56 nf7 kernel: Pid: 2511, comm: openarena.i386 Not tainted
3.8.0-rc3-gc7fb5ff #1/NF7-S/NF7 (nVidia-nForce2)
Feb  3 20:46:56 nf7 kernel: EIP: 0060:[fa033a3e] EFLAGS: 00210246 CPU: 0
Feb  3 20:46:56 nf7 kernel: EIP is at radeon_fence_process+0x7e/0x160 [radeon]
Feb  3 20:46:56 nf7 kernel: EAX: f87aec0c EBX: f73b2848 ECX: f73b2848 EDX:

Feb  3 20:46:56 nf7 kernel: ESI:  EDI: f73b2000 EBP: e4765d8c ESP:
e4765d58
Feb  3 20:46:56 nf7 kernel:  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
Feb  3 20:46:56 nf7 kernel: CR0: 8005003b CR2: f87aec0c CR3: 1e75f000 CR4:
07d0
Feb  3 20:46:56 nf7 kernel: DR0:  DR1:  DR2:  DR3:

Feb  3 20:46:56 nf7 kernel: DR6: 0ff0 DR7: 0400
Feb  3 20:46:56 nf7 kernel: Process openarena.i386 (pid: 2511, ti=e4764000
task=f70ad2b0 task.ti=e4764000)
Feb  3 20:46:56 nf7 kernel: Stack:
Feb  3 20:46:56 nf7 kernel:  c13d4e58 00765d7c 0018 f73b2848 f73b2888
0872 0003 0872
Feb  3 20:46:56 nf7 kernel:   000c 0003 f73b2a5c e4765e0c
e4765da4 fa034850 f73b2000
Feb  3 20:46:56 nf7 kernel:  f73b2000 f73b2a5c e4765e0c e4765dc4 fa049bb8
f73b28e8  c12b06cd
Feb  3 20:46:56 nf7 kernel: Call Trace:
Feb  3 20:46:56 nf7 kernel:  [c13d4e58] ? sub_preempt_count+0x8/0x80
Feb  3 20:46:56 nf7 kernel:  [fa034850] radeon_fence_count_emitted+0x20/0x90
[radeon]
Feb  3 20:46:56 nf7 kernel:  [fa049bb8] radeon_ring_backup+0x38/0x100
[radeon]
Feb  3 20:46:56 nf7 kernel:  [c12b06cd] ? _dev_info+0x2d/0x30
Feb  3 20:46:56 nf7 kernel:  [fa020b22] radeon_gpu_reset+0x62/0x1d0 [radeon]
Feb  3 20:46:56 nf7 kernel:  [f8be99c6] ? ttm_bo_unreserve+0x26/0x50 [ttm]
Feb  3 20:46:56 nf7 kernel:  [fa04821d]
radeon_gem_handle_lockup.part.2+0xd/0x20 [radeon]
Feb  3 20:46:56 nf7 kernel:  [fa048b13] radeon_gem_wait_idle_ioctl+0xb3/0xd0
[radeon]
Feb  3 20:46:56 nf7 kernel:  [fa048a60] ? radeon_gem_busy_ioctl+0xf0/0xf0
[radeon]
Feb  3 20:46:56 nf7 kernel:  [f8af9e82] drm_ioctl+0x402/0x460 [drm]
Feb  3 20:46:56 nf7 kernel:  [fa048a60] ? radeon_gem_busy_ioctl+0xf0/0xf0
[radeon]
Feb  3 20:46:56 nf7 kernel:  [c104f469] ? ktime_add_safe+0x9/0x60
Feb  3 20:46:56 nf7 kernel:  [c104fe80] ? hrtimer_forward+0xa0/0x190
Feb  3 20:46:56 nf7 kernel:  [f8af9a80] ? drm_copy_field+0x80/0x80 [drm]
Feb  3 20:46:56 nf7 kernel:  [c10eb65a] do_vfs_ioctl+0x7a/0x590
Feb  3 20:46:56 nf7 kernel:  [c101ef0b] ? lapic_next_event+0x1b/0x20
Feb  3 20:46:56 nf7 kernel:  [c106978d] ?
clockevents_program_event+0x9d/0x150
Feb  3 20:46:56 nf7 kernel:  [c106ab18] ? tick_program_event+0x28/0x30
Feb  3 20:46:56 nf7 kernel:  [c1050612] ? hrtimer_interrupt+0x182/0x2f0
Feb  3 20:46:56 nf7 kernel:  [c13d4e58] ? sub_preempt_count+0x8/0x80
Feb  3 20:46:56 nf7 kernel:  [c1048cf9] ? __rcu_read_unlock+0x9/0x60
Feb  3 20:46:56 nf7 kernel:  [c10f4bc7] ? fget_light+0x77/0xd0
Feb  3 20:46:56 nf7 kernel:  [c10ebbac] sys_ioctl+0x3c/0x70
Feb  3 20:46:56 nf7 kernel:  [c13d7ffa] sysenter_do_call+0x12/0x22
Feb  3 20:46:56 nf7 kernel: Code: 8b 4d d4 8d 84 51 f0 00 00 00 8b 74 c7 08 89
75 e0 8b 74 c7 0c 8b 45 d8 83 c0 08 80 bf ec 0d 00 00 00 0f 84 bf 00 00 00 8b
40 0c 8b 00 39 45 e8 8b 4d ec 89 c3 ba 01 00 00 00 0f 47 ce 39 f1 77
Feb  3 20:46:56 nf7 kernel: EIP: [fa033a3e] radeon_fence_process+0x7e/0x160
[radeon]

[Bug 60254] kernel Oops when provoking GPU lock.

2013-02-03 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=60254

Andy Furniss li...@andyfurniss.entadsl.com changed:

   What|Removed |Added

Summary|agd5f wip kernel Oops when  |kernel Oops when provoking
   |provoking GPU lock. |GPU lock.

--- Comment #1 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #0)
 The GPU lock with Rv670 and openarena is nothing new - it seems to have been
 a feature for almost a year (I haven't used rv670 for most of that time).
 
 On noticing the new gpu reset code in drm-next-3.9-wip I decided to provoke
 it on my AGP box and got -

Hmm I just managed to get the same running drm-fixes so it's not wip maybe it's
because I am now using llvm. In the (no llvm) past with other kernels this GPU
lock normally went quite well - the game often just continued for a while,
until it hit another one.

-- 
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] drm: fix compile failure by including linux/swiotlb.h

2013-02-03 Thread Maarten Lankhorst 
Op 01-02-13 19:44, Chris Metcalf schreef:
 On tile architecture (with make allyesconfig) including
 linux/swiotlb.h is required to call swiotlb_nr_tbl().
I'll take your word for the need, since I lack the hardware to verify the 
failure. :-)
Applying your patch doesn't seem to break compilation on x86 though, which is 
good enough for me.

Acked-by: Maarten Lankhorst maarten.lankho...@canonical.com
 Signed-off-by: Chris Metcalf cmetc...@tilera.com
 ---
  drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
  drivers/gpu/drm/radeon/radeon_ttm.c  |1 +
  2 files changed, 2 insertions(+)

 diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
 b/drivers/gpu/drm/nouveau/nouveau_bo.c
 index 69d7b1d..1699a90 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
 @@ -28,6 +28,7 @@
   */
  
  #include core/engine.h
 +#include linux/swiotlb.h
  
  #include subdev/fb.h
  #include subdev/vm.h
 diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
 b/drivers/gpu/drm/radeon/radeon_ttm.c
 index 1d8ff2f..93f760e 100644
 --- a/drivers/gpu/drm/radeon/radeon_ttm.c
 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
 @@ -38,6 +38,7 @@
  #include drm/radeon_drm.h
  #include linux/seq_file.h
  #include linux/slab.h
 +#include linux/swiotlb.h
  #include radeon_reg.h
  #include radeon.h
  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

2013-02-03 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=44341


Christopher Frömmel cfroem...@web.de changed:

   What|Removed |Added

 Kernel Version|3.5.2   |3.7.5




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

[git pull] drm radeon fixes

2013-02-03 Thread Dave Airlie 

Hi Linus,

I got these late last week, the main chunks of these fix a rendering 
regression since 3.7, and the settle ones all fix the issue where we don't 
wait long enough for the memory controller to settle after turning it off 
which causes bad memory reads, they all fix real users bugs, and most of 
them are destined for stable.

can't remember if you had net connection on that island :-)

Dave.

The following changes since commit ff0d05bf73620eb7dc8aee7423e992ef87870bdf:

  Revert console: implement lockdep support for console_lock (2013-01-31 
15:46:56 +1100)

are available in the git repository at:

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

for you to fetch changes up to 089c71a7c306dff067097f37ef329ccdf3269811:

  Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux 
(2013-02-01 10:51:02 +1100)



Alex Deucher (7):
  drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN
  drm/radeon: add quirk for RV100 board
  drm/radeon: fix backend map setup on 1 RB sumo boards
  drm/radeon/evergreen+: wait for the MC to settle after MC blackout
  drm/radeon/r5xx-r7xx: wait for the MC to settle after MC blackout
  drm/radeon: prevent crash in the ring space allocation
  drm/radeon: switch back to the CP ring for VM PT updates

Christopher Staite (1):
  drm/radeon: fix MC blackout on evergreen+

Dave Airlie (1):
  Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux

Mikko Tiihonen (1):
  drm/radeon: protect against div by 0 in backend setup

liu chuansheng (1):
  drm/radeon: Calling object_unrefer() when creating fb failure

 drivers/gpu/drm/radeon/evergreen.c  | 27 ---
 drivers/gpu/drm/radeon/r600.c   |  7 +--
 drivers/gpu/drm/radeon/radeon_asic.c|  6 +++---
 drivers/gpu/drm/radeon/radeon_combios.c |  8 
 drivers/gpu/drm/radeon/radeon_display.c |  4 +++-
 drivers/gpu/drm/radeon/radeon_ring.c|  3 +++
 drivers/gpu/drm/radeon/reg_srcs/cayman  |  1 +
 drivers/gpu/drm/radeon/rv515.c  |  2 ++
 8 files changed, 49 insertions(+), 9 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D

2013-02-03 Thread Kukjin Kim 
Kukjin Kim wrote:
 
Oops, I'm re-sending due to my e-mail client problem :-(

 Sylwester Nawrocki wrote:
 
  On 02/01/2013 09:33 AM, Sachin Kamat wrote:
   On 1 February 2013 06:57, Inki Dae inki@samsung.com wrote:
  
   For example,
   If compatible = samsung,g2d-3.0 is added to exynos4210.dtsi, it'd be
   reasonable. But what if that compatible string is added to exynos4.dtsi?.
   This case isn't considered for exynos4412 SoC with v4.1.
  
   In case of Exynos4 series the base address of G2D ip is different
   across series. Hence we cannot define it in exynos4.dtsi and need to
   define the nodes in exynos4xxx.dtsi or specific board files. Thus we
   can use the version appended compatible string.
  
   However even the second option suggested by Sylwester is OK with me
 or
   to be even more specific we could go for both SoC as well as version
   option something like this.
  
   compatible = samsung,exynos3110-g2d-3.0 /* for Exynos3110,
  Exynos4210 */
   compatible = samsung,exynos4212-g2d-4.1 /* for Exynos4212,
  Exynos4412 */
  
   In any case please let me know the final preferred one so that I can
   update the code send the revised patches.
 
  The version with SoC name embedded in it seems most reliable and correct
  to me.
 
  compatible = samsung,exynos3110-fimg-2d /* for Exynos3110 (S5PC110,
  S5PV210),
   Exynos4210 */
 
 If this convention will be used, I hope, the known name, S5PV210 can be
 used. Why don't you use same SoC name with using in arch/arm/?
 
  compatible = samsung,exynos4212-fimg-2d /* for Exynos4212,
 Exynos4412
  */
 
  FIMG stands for Fully Interactive Mobile Graphics, and other multimedia
  IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller),
  FIMC (Camera), etc.
 
 How about MFC?
 
  This is just my opinion though, and it seems this is a most common scheme
  from greping the device tree bindings documentation.
 
 IMO, you can grep '$ git grep  compatible.*samsung'...or IP name.
 
  As Stephen pointed out, and I also did in some other mail thread in the
  past, not only an IP revision might be required, but also its integration
  details, specific to an SoC type are important. This actually happens
  to be the case with FIMC, where same version of one instance of the IP
  has more data interfaces routed to other SoC subsystems on one SoC type
  than on other one.
 
 Well, I don't think so. As you know Samsung makes many EXYNOS SoCs and
 nowadays the EXYNOS SoCs include many Samsung own IPs such as
 multimedia. And the IPs are reused on across Samsung SoCs, and I hope on
 other SoC vendor's SoC. It means Samsung is no longer just SoC vendor and
 can be called IP vendor. So let's see other IP vendors, ARM, Synopsys and so
 on. How are their IPs implemented in kernel? Why should Samsung use the
 SoC name for their IP? And why should we use old SoC name in futre? For
 example, see the s3c2410-xxx for i2c, wdt, rtc, i2s and so on. Unfortunately,
 no one didn't know Samsung should prepare some brand name or  future at
 that time...Just I don't want to undergo trial and error again. I'm still 
 saying
 why Samsung own IPs cannot be used as IP vendors' ones...
 
  I think it won't be possible to use a scheme like samsung-exynos-g2d-3.0
 
 Hmm...I think, the name, 'EXYNOS' is not a brand name for IP...
 
  for all IPs. And I would much more like to see a uniform naming convention
  used, rather than living with a chaotic set of compatible properties, that
  has a potential to become even more chaotic in the future.
 
Thanks.

- Kukjin

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

[PATCH] drm: fix compile failure by including linux/swiotlb.h

2013-02-03 Thread Chris Metcalf 
On tile architecture (with make allyesconfig) including
linux/swiotlb.h is required to call swiotlb_nr_tbl().

Signed-off-by: Chris Metcalf cmetc...@tilera.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
 drivers/gpu/drm/radeon/radeon_ttm.c  |1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 69d7b1d..1699a90 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -28,6 +28,7 @@
  */
 
 #include core/engine.h
+#include linux/swiotlb.h
 
 #include subdev/fb.h
 #include subdev/vm.h
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1d8ff2f..93f760e 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -38,6 +38,7 @@
 #include drm/radeon_drm.h
 #include linux/seq_file.h
 #include linux/slab.h
+#include linux/swiotlb.h
 #include radeon_reg.h
 #include radeon.h
 
-- 
1.7.10.3

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

[PATCH] drm: fix compile failure by including linux/swiotlb.h

2013-02-03 Thread Chris Metcalf 
On tile architecture (with make allyesconfig) including
linux/swiotlb.h is required to call swiotlb_nr_tbl().

Signed-off-by: Chris Metcalf cmetc...@tilera.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
 drivers/gpu/drm/radeon/radeon_ttm.c  |1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 69d7b1d..1699a90 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -28,6 +28,7 @@
  */
 
 #include core/engine.h
+#include linux/swiotlb.h
 
 #include subdev/fb.h
 #include subdev/vm.h
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1d8ff2f..93f760e 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -38,6 +38,7 @@
 #include drm/radeon_drm.h
 #include linux/seq_file.h
 #include linux/slab.h
+#include linux/swiotlb.h
 #include radeon_reg.h
 #include radeon.h
 
-- 
1.7.10.3

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

Re: [PATCH v3 00/22] PCI: Iterate pci host bridge instead of pci root bus

2013-02-03 Thread Bjorn Helgaas 
On Sun, Jan 27, 2013 at 12:23 PM, Yinghai Lu ying...@kernel.org wrote:
 Now we have pci_root_buses list, and there is lots of iteration with
 list_of_each of it, that is not safe after we add pci root bus hotplug
 support after booting stage.

 Add pci_get_next_host_bridge and use bus_find_device in driver core to
 iterate host bridge and the same time get root bus.

 We replace searching root bus with searching host_bridge,
 as host_bridge-bus is the root bus.
 After those replacing, we even could kill pci_root_buses list.

These are the problems I think you're fixing:

1) pci_find_next_bus() is not safe because even though it holds
pci_bus_sem while walking the pci_root_buses list, it doesn't hold a
reference on the bus it returns.  The bus could be removed while the
caller is using it.

2) list_for_each_entry(bus, pci_root_buses, node) is not safe
because hotplug might modify the pci_root_buses list.  Replacing that
with for_each_pci_host_bridge() solves that problem by using
bus_find_device(), which is built on klists, which are designed for
that problem.

3) pci_find_next_bus() claims to iterate through all known PCI buses,
but in fact only iterates through root buses.

So far, so good.  Those are problems we need to fix.

Your solution is to introduce for_each_pci_host_bridge() as an
iterator through the known host bridges.  There are two scenarios
where we use something like this:

1) We want to perform an operation on every known host bridge.

2) We want to initialize something for every host bridge.

In my opinion, the only instance of scenario 1) is bus_rescan_store(),
where we want to rescan all PCI host bridges.

In every other case, we're doing some kind of initialization of all
the host bridges.  For these cases, for_each_pci_host_bridge() is the
wrong solution because it doesn't work for hot-added bridges.  I think
these cases should be changed to use pcibios_root_bridge_prepare() or
something something else called in the host bridge add path.

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

3.8-rc6: nouveau lockdep recursive lock acquisition

2013-02-03 Thread Daniel J Blueman 
From recent additional locking in nouveau, it looks like we see
recursive lock acquisition in 3.8-rc6:

nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0e7150a2
nouveau [ DEVICE][:01:00.0] Chipset: GK107 (NVE7)
nouveau [ DEVICE][:01:00.0] Family : NVE0
nouveau [  VBIOS][:01:00.0] checking PRAMIN for image...
nouveau [  VBIOS][:01:00.0] ... appears to be valid
nouveau [  VBIOS][:01:00.0] using image from PRAMIN
nouveau [  VBIOS][:01:00.0] BIT signature found
nouveau [  VBIOS][:01:00.0] version 80.07.26.04.01
nouveau [   PFB][:01:00.0] RAM type: GDDR5
nouveau [   PFB][:01:00.0] RAM size: 1024 MiB
nouveau [   PFB][:01:00.0]  ZCOMP: 0 tags
init: gdm main process (960) killed by TERM signal
vga_switcheroo: enabled
[TTM] Zone kernel: Available graphics memory: 4038258 kiB
[TTM] Zone  dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
nouveau [   DRM] VRAM: 1024 MiB
nouveau [   DRM] GART: 512 MiB
nouveau [   DRM] BIT BIOS found
nouveau [   DRM] Bios version 80.07.26.04
nouveau [   DRM] TMDS table version 2.0
nouveau [   DRM] DCB version 4.0
nouveau [   DRM] DCB outp 00: 048101b6 0f230010
nouveau [   DRM] DCB outp 01: 018212d6 0f220020
nouveau [   DRM] DCB outp 02: 01021212 00020020
nouveau [   DRM] DCB outp 03: 088324c6 0f220010
nouveau [   DRM] DCB outp 04: 08032402 00020010
nouveau [   DRM] DCB outp 05: 02843862 00020010
nouveau [   DRM] DCB conn 00: 00020047
nouveau [   DRM] DCB conn 01: 02208146
nouveau [   DRM] DCB conn 02: 01104246
nouveau [   DRM] DCB conn 03: 00410361

=
[ INFO: possible recursive locking detected ]
3.8.0-rc6-ninja+ #1 Not tainted
-
modprobe/585 is trying to acquire lock:
 (subdev-mutex){+.+.+.}, at: [a016c323]
nouveau_instobj_create_+0x43/0x90 [nouveau]

but task is already holding lock:
 (subdev-mutex){+.+.+.}, at: [a017672d]
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]

other info that might help us debug this:
 Possible unsafe locking scenario:

CPU0

 lock(subdev-mutex);
 lock(subdev-mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

4 locks held by modprobe/585:
 #0: (__lockdep_no_validate__){..}, at: [813075f3]
__driver_attach+0x53/0xb0
 #1: (__lockdep_no_validate__){..}, at: [81307601]
__driver_attach+0x61/0xb0
 #2: (drm_global_mutex){+.+.+.}, at: [812ee59c]
drm_get_pci_dev+0xbc/0x2b0
 #3: (subdev-mutex){+.+.+.}, at: [a017672d]
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]

stack backtrace:
Pid: 585, comm: modprobe Not tainted 3.8.0-rc6-expert+ #1
Call Trace:
 [8108fde2] validate_chain.isra.33+0xd72/0x10d0
 [8105fa08] ? __kernel_text_address+0x58/0x80
 [8100575d] ? print_context_stack+0x5d/0xd0
 [81090bc1] __lock_acquire+0x3a1/0xb60
 [8108d504] ? __lock_is_held+0x54/0x80
 [8109184a] lock_acquire+0x5a/0x70
 [a016c323] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
 [81558739] mutex_lock_nested+0x69/0x340
 [a016c323] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
 [a0152370] ? nouveau_object_create_+0x60/0xa0 [nouveau]
 [a016c323] nouveau_instobj_create_+0x43/0x90 [nouveau]
 [a016cf8c] nv50_instobj_ctor+0x4c/0xf0 [nouveau]
 [a0152163] nouveau_object_ctor+0x33/0xc0 [nouveau]
 [a016cd51] nv50_instmem_alloc+0x21/0x30 [nouveau]
 [a0150917] nouveau_gpuobj_create_+0x247/0x2f0 [nouveau]
 [8155b35a] ? _raw_spin_unlock_irqrestore+0x3a/0x70
 [810921fd] ? trace_hardirqs_on_caller+0x10d/0x1a0
 [a014f4bc] nouveau_engctx_create_+0x25c/0x2a0 [nouveau]
 [a0176791] nv50_disp_data_ctor+0xc1/0xd0 [nouveau]
 [a0153722] ? nouveau_subdev_reset+0x52/0x60 [nouveau]
 [a0152163] nouveau_object_ctor+0x33/0xc0 [nouveau]
 [a0152a42] nouveau_object_new+0x112/0x240 [nouveau]
 [a01f4b1d] nv50_display_create+0x18d/0x860 [nouveau]
 [8105cb5d] ? __cancel_work_timer+0x6d/0xc0
 [a01db8eb] nouveau_display_create+0x3cb/0x670 [nouveau]
 [a01cb1bf] nouveau_drm_load+0x26f/0x590 [nouveau]
 [81304c99] ? device_register+0x19/0x20
 [812efe91] ? drm_sysfs_device_add+0x81/0xb0
 [812ee65e] drm_get_pci_dev+0x17e/0x2b0
 [81245e56] ? __pci_set_master+0x26/0x80
 [a01cab2a] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
 [8124a386] local_pci_probe+0x46/0x80
 [8124ac11] pci_device_probe+0x101/0x110
 [813073d6] driver_probe_device+0x76/0x240
 [81307643] __driver_attach+0xa3/0xb0
 [813075a0] ? driver_probe_device+0x240/0x240
 [8130564d] bus_for_each_dev+0x4d/0x90
 [81306f39] driver_attach+0x19/0x20
 [81306af0] bus_add_driver+0x1a0/0x270
 [a023d000] ? 0xa023cfff
 [81307cd2] driver_register+0x72/0x170
 [a023d000] ? 0xa023cfff

Re: [RFC PATCH 0/4] Common Display Framework-TF

2013-02-03 Thread Tomasz Figa 
Hi Laurent,

On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
 Hi Tomasz,
 
 Thank you for your RFC.
 
 On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
  Hi,
  
  After pretty long time of trying to adapt Exynos-specific DSI display
  support to Common Display Framework I'm ready to show some preliminary
  RFC patches. This series shows some ideas for CDF that came to my
  mind during my work, some changes based on comments received by
  Tomi's edition of CDF and also preliminarys version of Exynos DSI
  (video source part only, still with some FIXMEs) and Samsung S6E8AX0
  DSI panel drivers.
  
  It is heavily based on Tomi's work which can be found here:
  http://thread.gmane.org/gmane.comp.video.dri.devel/78227
  
  The code might be a bit hacky in places, as I wanted to get it to a
  kind of complete and working state first. However I hope that some of
  the ideas might useful for further works.
  
  So, here comes the TF edition of Common Clock Framework.
  
  
  Changes done to Tomi's edition of CDF:
   - Replaced set_operation_mode, set_pixel_format and set_size video
   source  
 operations with get_params display entity operation, as it was
 originally in Laurent's version.
 
 We have discussed this matter on the mailing list and decided that
 it
 would be better to have the source ask the sink for its parameter
 structure and do whatever appropriate with it.
 
 Could you briefly outline the rationale behind this ?

Display interfaces may be described by an arbitrary number of parameters. 
Some will require just video timings, others like DSI will require a 
significant number of additional bus-specific ones.

Separating all the parameters (all of which are usually set at the same 
time) into a lot of ops setting single parameter will just add unnecessary 
complexity.

 I'm wondering whether get_params could limit us if a device needs to
 modify parameters at runtime. For instance a panel might need to change
 clock frequencies or number of used data lane depending on various
 runtime conditions. I don't have a real use case here, so it might just
 be a bit of over-engineering.

Hmm, isn't it in the opposite direction (the user requests the display 
interface to change, for example, video mode, which in turn reconfigures 
the link and requests the panel to update its settings)?

However it might be reasonable to split the parameters into constant and 
variable ones. In case of DSI bus, there is a lot of parameters that are 
considered just at link initialization time (the whole dsi params struct I 
defined). Video mode, however, is a variable parameter that can be changed 
on some displays.

 
   - Defined a preliminary set of DSI bus parameters.
   
 Following parameters are defined:
 
 1. Pixel format used for video data transmission.
 
 2. Mode flags (several bit flags ORed together):
   a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command
   
  mode), following DSI_MODE_VIDEO_* flags are relevant only if
  this
  flag is set.
  b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video
  data
  c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as
  opposed
  
 to sync events)
  
  d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
  
 detection
  
  e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end
  packets
  f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch
  area
  g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch
  area
  h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active
  area
   
   i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
   j) DSI_MODE_EOT_PACKET - entity needs EoT packets
 
 3. Bit (serial) clock frequency in HS mode.
 4. Escape mode clock frequency.
 5. Mask of used data lanes (each bit represents single lane).
 
 From my experience with MIPI CSI (Camera Serial Interface, similar to
 DSI) some transceivers can reroute data lanes internally. Is that true
 for DSI as well ? In that case we would need a list of data lanes, not
 just a mask.

Hmm, I don't remember at the moment, will have to look to the 
specification. Exynos DSI master doesn't support such feature.

 6. Command allow area in video mode - amount of lines after
 transmitting
video data when generic commands are accepted.
 
 Feel free to suggest anything missing or wrong, as the list of
 parameters is based merely on what was used in original Exynos MIPI
 DSIM driver.
   
   - Redesigned source-entity matching.
   
 Now each source has name string and integer id and each entity has
 source name and source id. In addition, they can have of_node

Re: [Linaro-mm-sig] [PATCH 6/7] reservation: cross-device reservation support

2013-02-03 Thread Inki Dae 
 +/**
 + * ticket_commit - commit a reservation with a new fence
 + * @ticket:[in]the reservation_ticket returned by
 + * ticket_reserve
 + * @entries:   [in]a linked list of struct reservation_entry
 + * @fence: [in]the fence that indicates completion
 + *
 + * This function will call reservation_ticket_fini, no need
 + * to do it manually.
 + *
 + * This function should be called after a hardware command submission is
 + * completed succesfully. The fence is used to indicate completion of
 + * those commands.
 + */
 +void
 +ticket_commit(struct reservation_ticket *ticket,
 + struct list_head *entries, struct fence *fence)
 +{
 +   struct list_head *cur;
 +
 +   if (list_empty(entries))
 +   return;
 +
 +   if (WARN_ON(!fence)) {
 +   ticket_backoff(ticket, entries);
 +   return;
 +   }
 +
 +   list_for_each(cur, entries) {
 +   struct reservation_object *bo;
 +   bool shared;
 +
 +   reservation_entry_get(cur, bo, shared);
 +
 +   if (!shared) {
 +   int i;
 +   for (i = 0; i  bo-fence_shared_count; ++i) {
 +   fence_put(bo-fence_shared[i]);
 +   bo-fence_shared[i] = NULL;
 +   }
 +   bo-fence_shared_count = 0;
 +   if (bo-fence_excl)
 +   fence_put(bo-fence_excl);
 +
 +   bo-fence_excl = fence;
 +   } else {
 +   if (WARN_ON(bo-fence_shared_count =
 +   ARRAY_SIZE(bo-fence_shared))) {
 +   mutex_unreserve_unlock(bo-lock);
 +   continue;
 +   }
 +
 +   bo-fence_shared[bo-fence_shared_count++] = fence;
 +   }

Hi,

I got some questions to fence_excl and fence_shared. At the above
code, if bo-fence_excl is not NULL then it puts bo-fence_excl and
sets a new fence to it. This seems like that someone that committed a
new fence, wants to access the given dmabuf exclusively even if
someone is accessing the given dmabuf.

On the other hand, in case of fence_shared, someone wants to access
that dmabuf non-exclusively. So this case seems like that the given
dmabuf could be accessed by two more devices. So I guess that the
fence_excl could be used for write access(may need buffer sync like
blocking) and read access for the fence_shared(may not need buffer
sync). I'm not sure that I understand these two things correctly so
could you please give me more comments for them?

Thanks,
Inki Dae

 +   fence_get(fence);
 +
 +   mutex_unreserve_unlock(bo-lock);
 +   }
 +   reservation_ticket_fini(ticket);
 +}
 +EXPORT_SYMBOL(ticket_commit);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel