Introduce a new helper framework for buffer synchronization

[Inki Dae]

> -Original Message-
> From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On Behalf 
> Of
> Daniel Vetter
> Sent: Thursday, May 23, 2013 8:56 PM
> To: Inki Dae
> Cc: Rob Clark; linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham;
> YoungJun Cho; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org
> Subject: Re: Introduce a new helper framework for buffer synchronization
> 
> On Tue, May 21, 2013 at 11:22 AM, Inki Dae  wrote:
> >> -Original Message-
> >> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> >> Vetter
> >> Sent: Tuesday, May 21, 2013 4:45 PM
> >> To: Inki Dae
> >> Cc: 'Daniel Vetter'; 'Rob Clark'; 'linux-fbdev'; 'DRI mailing list';
> >> 'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> >> kernel at lists.infradead.org; linux-media at vger.kernel.org
> >> Subject: Re: Introduce a new helper framework for buffer
> synchronization
> >>
> >> On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
> >> > > - Integration of fence syncing into dma_buf. Imo we should have a
> >> > >   per-attachment mode which decides whether map/unmap (and the new
> >> sync)
> >> > >   should wait for fences or whether the driver takes care of
> syncing
> >> > >   through the new fence framework itself (for direct hw sync).
> >> >
> >> > I think it's a good idea to have per-attachment mode for buffer sync.
> >> But
> >> > I'd like to say we make sure what is the purpose of map
> >> > (dma_buf_map_attachment)first. This interface is used to get a sgt;
> >> > containing pages to physical memory region, and map that region with
> >> > device's iommu table. The important thing is that this interface is
> >> called
> >> > just one time when user wants to share an allocated buffer with dma.
> But
> >> cpu
> >> > will try to access the buffer every time as long as it wants.
> Therefore,
> >> we
> >> > need cache control every time cpu and dma access the shared buffer:
> >> cache
> >> > clean when cpu goes to dma and cache invalidate when dma goes to cpu.
> >> That
> >> > is why I added new interfaces, DMA_BUF_GET_FENCE and
> DMA_BUF_PUT_FENCE,
> >> to
> >> > dma buf framework. Of course, Those are ugly so we need a better way:
> I
> >> just
> >> > wanted to show you that in such way, we can synchronize the shared
> >> buffer
> >> > between cpu and dma. By any chance, is there any way that kernel can
> be
> >> > aware of when cpu accesses the shared buffer or is there any point I
> >> didn't
> >> > catch up?
> >>
> >> Well dma_buf_map/unmap_attachment should also flush/invalidate any
> caches,
> >> and with the current dma_buf spec those two functions are the _only_
> means
> >
> > I know that dma buf exporter should make sure that cache
> clean/invalidate
> > are done when dma_buf_map/unmap_attachement is called. For this, already
> we
> > do so. However, this function is called when dma buf import is requested
> by
> > user to map a dmabuf fd with dma. This means that
> dma_buf_map_attachement()
> > is called ONCE when user wants to share the dmabuf fd with dma.
Actually,
> in
> > case of exynos drm, dma_map_sg_attrs(), performing cache operation
> > internally, is called when dmabuf import is requested by user.
> >
> >> you have to do so. Which strictly means that if you interleave device
> dma
> >> and cpu acccess you need to unmap/map every time.
> >>
> >> Which is obviously horribly inefficient, but a known gap in the dma_buf
> >
> > Right, and also this has big overhead.
> >
> >> interface. Hence why I proposed to add dma_buf_sync_attachment similar
> to
> >> dma_sync_single_for_device:
> >>
> >> /**
> >>  * dma_buf_sync_sg_attachment - sync caches for dma access
> >>  * @attach: dma-buf attachment to sync
> >>  * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
> >>  * @direction: dma direction to sync for
> >>  *
> >>  * This function synchronizes caches for device dma through the given
> >>  * dma-buf attachment when interleaving dma from different devices and
> the
> >>  * cpu. Other device dma needs to be synced also by calls to this
> >>  * function (or a pair of dma_buf_map/unmap_attachment calls), cpu
> access
> >>  * needs to be synced with dma_buf_begin/end_cpu_access.
> >>  */
> >> void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
> >>   struct sg_table *sgt,
> >>   enum dma_data_direction direction)
> >>
> >> Note that "sync" here only means to synchronize caches, not wait for
> any
> >> outstanding fences. This is simply to be consistent with the
> established
> >> lingo of the dma api. How the dma-buf fences fit into this is imo a
> >> different topic, but my idea is that all the cache coherency barriers
> >> (i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
> >> dma_buf_begin/end_cpu_access) would automatically block for any
> attached
> >> fences (i.e. block for write fences when doing read-only 

[PATCH 00/33] devm improvement series, part 1, take 2

[Thierry Reding]

On Thu, May 16, 2013 at 01:15:28PM +0200, Wolfram Sang wrote:
> Lately, I have been experimenting how to improve the devm interface to make
> writing device drivers easier and less error prone while also getting rid of
> its subtle issues. I think it has more potential but still needs work and
> definately conistency, especiall in its usage.
> 
> The first thing I come up with is a low hanging fruit regarding
> devm_ioremap_resouce(). This function already checks if the passed resource is
> valid and gives an error message if not. So, we can remove similar checks from
> the drivers and get rid of a bit of code and a number of inconsistent error
> strings.

Sorry for jumping in so late. I generally like the idea. One small
inconvenience is that devm_ioremap_resource() returns -EINVAL if
res == NULL, which means that drivers will now also return -EINVAL
in cases where no resource was returned. Typically drivers handle
this by returning something like -ENODEV, -ENXIO, -ENOENT. Some do
return -EINVAL but perhaps having a separate error code (and maybe
error message as well) for a missing resource would be helpful.

Doing this would be rather easy now that you've paved the way by
making devm_ioremap_resource() usage consistent across drivers.

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

[Bug 58731] New: radeon_uvd: Can't load firmware "radeon/RV710_uvd.bin"

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

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

   Summary: radeon_uvd: Can't load firmware "radeon/RV710_uvd.bin"
   Product: Drivers
   Version: 2.5
Kernel Version: 3.10.0-rc2
  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: smf.linux at ntlworld.com
Regression: No


Created an attachment (id=102361)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=102361)
dmesg output and other supporting information

[AMD/ATI] RV710 [Radeon HD 4350/4550] on M5A97 PRO and AMD Phenom(tm) II X6
1100T Processor (16Gbyte RAM) fails to load RV710_uvd.bin at boot. I have found
that "request_firmware" call is returning -2 (ENOENT) though the correct file
is available in /lib/firmware/radeon. On further investigation this appears to
stem from "assign_firmware_buf" not having a buffer available (buf->size=0). I
have attached an instrumented dmesg (lines tagged with SMF), lspci and
/lib/firmware/radion listings for information. I am assuming that this video
card should support the UVD functionality.
Please advise.

regards

Stuart Foster

-- 
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 64879] i915 doesn't do derivatives, neither gallium nor intel driver

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

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

--- Comment #4 from Marek Ol??k  ---
FYI, the old failover module was actually capable of switching between a
hardware driver and softpipe in the middle of rendering. It should be possible
to implement something similar for i915g, though it might be a lot of work.

-- 
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/20130523/714d90cb/attachment.html>

[Bug 64933] New: Hyperz related gpu lockup on git mesa in Brütal Legend

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

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

  Priority: medium
Bug ID: 64933
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Hyperz related gpu lockup on git mesa in Br?tal Legend
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: thomas.lindroth at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 79724
  --> https://bugs.freedesktop.org/attachment.cgi?id=79724=edit
dmesg, xorg.log

It locks up in the opening scene unless R600_HYPERZ=0 is set. Here it a trace
for it.
https://dl.dropboxusercontent.com/s/w1dr3abdesxcp66/Buddha2.bin.x86.trace.xz
[337M]

I tried to trim it but I only got an unplayable result. glretrace would segfult
in r600g.so so it could also be a problem with the driver. Replaying with
mesa-9.1.2 didn't segfault, instead I got this error message: glretrace:
../../src/mesa/main/fbobject.c:2014: reuse_framebuffer_texture_attachment:
Assertion `src_att->Renderbuffer != ((void *)0)' failed

I uploaded the full trace just to make sure there is nothing wrong with the
trace.

I'm using 32bit: br?tal legend (steam), mesa-git, libdri-git and 64bit:
xf86-video-ati-7.1.0 xorg-server-1.13.4 kernel-3.9.3


./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules
--disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float
--disable-debug --enable-egl --disable-gbm --disable-gles1 --disable-gles2
--enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi
--disable-xa --disable-xorg --with-dri-drivers=
--with-gallium-drivers=,swrast,r600 PYTHON2=/usr/bin/python2.7
--with-egl-platforms=x11 --enable-gallium-egl --enable-gallium-llvm
--disable-openvg --disable-r600-llvm-compiler --disable-vdpau --disable-xvmc

-- 
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/20130523/1e1f740b/attachment.html>

[Bug 64879] i915 doesn't do derivatives, neither gallium nor intel driver

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

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

--- Comment #3 from Roland Scheidegger  ---
(In reply to comment #2)
> The software rendering fallback in the intel driver is pretty slick.  The
> gallium driver has nothing like that, correct?
Nope. Not sure though what you mean by pretty slick, in my experience it is
usually useless due to glacial performance (though I guess maybe it's better
thanks to UMA compared to old radeons).

-- 
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/20130523/51b9ce46/attachment.html>

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave,

   This pull request includes drm_send_vblank_event() helper
   relevant patch I missed and code cleanups. And also it fixes
   a pended page flip issue.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 0eca56f9467038ee0b798637f03581aaa1186fac:

  drm/imx: use drm_send_vblank_event() helper (2013-05-22 09:13:42 +1000)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-fixes

Inki Dae (1):
  drm/exynos: wait for the completion of pending page flip

Lars-Peter Clausen (1):
  drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()

Rob Clark (2):
  drm/exynos: page flip fixes
  drm/exynos: use drm_send_vblank_event() helper

Sachin Kamat (2):
  drm/exynos: exynos_drm_fbdev: Fix incorrect usage of IS_ERR_OR_NULL
  drm/exynos: exynos_drm_ipp: Fix incorrect usage of IS_ERR_OR_NULL

Seung-Woo Kim (4):
  drm/exynos: cleanup device pointer usages
  drm/exynos: fix build warnings from ipp fimc
  drm/exynos: remove unnecessary devm_kfree
  drm/exynos: replace request_threaded_irq with devm function

 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   27 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   12 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   10 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 +++-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   18 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c|   21 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |   14 +++---
 12 files changed, 64 insertions(+), 77 deletions(-)

[Bug 64879] i915 doesn't do derivatives, neither gallium nor intel driver

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

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

--- Comment #2 from fjhenigman  ---
The software rendering fallback in the intel driver is pretty slick.  The
gallium driver has nothing like that, correct?

-- 
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/20130523/6ff154ec/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

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

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

--- Comment #16 from Tom Stellard  ---
Created attachment 79717
  --> https://bugs.freedesktop.org/attachment.cgi?id=79717=edit
Possible fix

Does this patch fix any of the outstanding RS880 issues?

-- 
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/20130523/f1174745/attachment.html>

[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

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

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

--- Comment #2 from Patrik Plihal  ---
crosslinking
http://forum.kerbalspaceprogram.com/showthread.php/24529-The-Linux-compatibility-thread%21?p=381728=1#post381728

-- 
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/20130523/90312d37/attachment.html>

[Intel-gfx] [PATCH 7/7] drm: Remove some unused stuff from drm_plane

[Imre Deak]

On Wed, 2013-05-08 at 12:55 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> There's a bunch of unused members inside drm_plane, bloating the size of
> the structure needlessly. Eliminate them.
> 
> Signed-off-by: Ville Syrj?l? 

On the series:
Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/drm_crtc.c |  2 +-
>  include/drm/drm_crtc.h | 10 --
>  2 files changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d7c449f..e591914 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1739,7 +1739,7 @@ int drm_mode_getplane(struct drm_device *dev, void 
> *data,
>  
>   plane_resp->plane_id = plane->base.id;
>   plane_resp->possible_crtcs = plane->possible_crtcs;
> - plane_resp->gamma_size = plane->gamma_size;
> + plane_resp->gamma_size = 0;
>  
>   /*
>* This ioctl is called twice, once to determine how much space is
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index adb3f9b..99420c4 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -654,9 +654,6 @@ struct drm_plane_funcs {
>   * @format_count: number of formats supported
>   * @crtc: currently bound CRTC
>   * @fb: currently bound fb
> - * @gamma_size: size of gamma table
> - * @gamma_store: gamma correction table
> - * @enabled: enabled flag
>   * @funcs: helper functions
>   * @helper_private: storage for drver layer
>   * @properties: property tracking for this plane
> @@ -674,14 +671,7 @@ struct drm_plane {
>   struct drm_crtc *crtc;
>   struct drm_framebuffer *fb;
>  
> - /* CRTC gamma size for reporting to userspace */
> - uint32_t gamma_size;
> - uint16_t *gamma_store;
> -
> - bool enabled;
> -
>   const struct drm_plane_funcs *funcs;
> - void *helper_private;
>  
>   struct drm_object_properties properties;
>  };

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #43 from russianneuromancer at ya.ru ---
As I understand this patch will be included into next 3.10 RC?

-- 
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/20130523/ad7c81d9/attachment.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

--- Comment #6 from Michel D?nzer  ---
(In reply to comment #5)
> should i close the report? 

No. It's just a workaround, not a fix.

-- 
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/20130523/7ca5ba8f/attachment-0001.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

--- Comment #5 from Rafael Castillo  ---
well im using gentoo so /etc/env.d/00egl did the trick to make it global, so
its working that way it seems[kwin_gles works fine now].

should i close the report? 

many thanks for your help

btw i hit this other bug https://bugzilla.kernel.org/show_bug.cgi?id=58621
maybe you know someone who could check it out or give me some advice's in how
to debug it further?

-- 
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/20130523/5f56ed8e/attachment.html>

[Bug 64850] Second screen black on Pitcairn PRO

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

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

--- Comment #16 from Jakob Nixdorf  ---
I checkt again when the second monitor is switched off.

I booted with radeon.modeset=0, which caused the radeon module to not be loaded
since I don't have UMS support in my kernel. With this both monitors work and I
can get a TTY on both.
But as soon as I run 'modprobe -v radeon modeset=1' the second monitor is
switched off to black.

-- 
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/20130523/b7307bd7/attachment.html>

[Bug 64738] missing notification icons with glamor

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

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

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |zhigang.gong at gmail.com
   |.org|
Summary|[radeonsi] missing  |missing notification icons
   |notification icons with |with glamor
   |glamor  |
Product|Mesa|xorg
  Component|Drivers/Gallium/radeonsi|Driver/glamor

--- Comment #10 from Michel D?nzer  ---
Then it sounds like it's most likely a glamor issue. Might be interesting if
someone could test this on an Intel GPU.

-- 
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/20130523/c8ae227a/attachment.html>

[Bug 64738] [radeonsi] missing notification icons with glamor

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #79495|0   |1
is obsolete||

-- 
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/20130523/e2283d5b/attachment.html>

[Bug 64738] [radeonsi] missing notification icons with glamor

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #79494|0   |1
is obsolete||

-- 
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/20130523/3f02760c/attachment.html>

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

A few fixes, nothing shocking:
- More Haswell pci ids. Includes a pile of marketing spare ids (which
  despite the spare moniker show up all over the place).
- Fix a regression in handling modeset failures, resulting in black
  screens on 3 pipe setups when we've run out of pch plls (Chris).
- Fix up the setcrtc semantics to unconditionally enable the outputs.
  Juding from git digging that has (kinda) always been the case and neatly
  fixes a few long-standing (i.e. forever) bug reports (Imre).
- jiffies_timeout + 1 patches from Imre. They partially fix spurious
  wait_event failures in the interrupt-driven dp aux/i2c code. The other
  part is a core patch for the wait_event macros going in through -mm. A
  few patches more than strictly required since Imre is pushing for a
  general solution in 3.11.

Cheers, Daniel


The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:

  Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 3598706b52cb45ba0a9e8aa99ce5ac59140f2b8b:

  drm/i915: avoid premature DP AUX timeouts (2013-05-22 13:51:26 +0200)


Chris Wilson (1):
  drm/i915: Propagate errors back from fb set-base

Imre Deak (5):
  drm/i915: force full modeset if the connector is in DPMS OFF mode
  drm/i915: add msecs_to_jiffies_timeout to guarantee minimum duration
  drm/i915: use msecs_to_jiffies_timeout instead of open coding the same
  drm/i915: avoid premature timeouts in __wait_seqno()
  drm/i915: avoid premature DP AUX timeouts

Rodrigo Vivi (1):
  drm/i915: Adding more reserved PCI IDs for Haswell.

 drivers/gpu/drm/i915/i915_drv.c  |   46 +++
 drivers/gpu/drm/i915/i915_drv.h  |   15 +++
 drivers/gpu/drm/i915/i915_gem.c  |2 +-
 drivers/gpu/drm/i915/intel_display.c |   49 ++
 drivers/gpu/drm/i915/intel_dp.c  |2 +-
 drivers/gpu/drm/i915/intel_i2c.c |5 ++--
 6 files changed, 87 insertions(+), 32 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Introduce a new helper framework for buffer synchronization

[Daniel Vetter]

On Tue, May 21, 2013 at 11:22 AM, Inki Dae  wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Tuesday, May 21, 2013 4:45 PM
>> To: Inki Dae
>> Cc: 'Daniel Vetter'; 'Rob Clark'; 'linux-fbdev'; 'DRI mailing list';
>> 'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
>> kernel at lists.infradead.org; linux-media at vger.kernel.org
>> Subject: Re: Introduce a new helper framework for buffer synchronization
>>
>> On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
>> > > - Integration of fence syncing into dma_buf. Imo we should have a
>> > >   per-attachment mode which decides whether map/unmap (and the new
>> sync)
>> > >   should wait for fences or whether the driver takes care of syncing
>> > >   through the new fence framework itself (for direct hw sync).
>> >
>> > I think it's a good idea to have per-attachment mode for buffer sync.
>> But
>> > I'd like to say we make sure what is the purpose of map
>> > (dma_buf_map_attachment)first. This interface is used to get a sgt;
>> > containing pages to physical memory region, and map that region with
>> > device's iommu table. The important thing is that this interface is
>> called
>> > just one time when user wants to share an allocated buffer with dma. But
>> cpu
>> > will try to access the buffer every time as long as it wants. Therefore,
>> we
>> > need cache control every time cpu and dma access the shared buffer:
>> cache
>> > clean when cpu goes to dma and cache invalidate when dma goes to cpu.
>> That
>> > is why I added new interfaces, DMA_BUF_GET_FENCE and DMA_BUF_PUT_FENCE,
>> to
>> > dma buf framework. Of course, Those are ugly so we need a better way: I
>> just
>> > wanted to show you that in such way, we can synchronize the shared
>> buffer
>> > between cpu and dma. By any chance, is there any way that kernel can be
>> > aware of when cpu accesses the shared buffer or is there any point I
>> didn't
>> > catch up?
>>
>> Well dma_buf_map/unmap_attachment should also flush/invalidate any caches,
>> and with the current dma_buf spec those two functions are the _only_ means
>
> I know that dma buf exporter should make sure that cache clean/invalidate
> are done when dma_buf_map/unmap_attachement is called. For this, already we
> do so. However, this function is called when dma buf import is requested by
> user to map a dmabuf fd with dma. This means that dma_buf_map_attachement()
> is called ONCE when user wants to share the dmabuf fd with dma. Actually, in
> case of exynos drm, dma_map_sg_attrs(), performing cache operation
> internally, is called when dmabuf import is requested by user.
>
>> you have to do so. Which strictly means that if you interleave device dma
>> and cpu acccess you need to unmap/map every time.
>>
>> Which is obviously horribly inefficient, but a known gap in the dma_buf
>
> Right, and also this has big overhead.
>
>> interface. Hence why I proposed to add dma_buf_sync_attachment similar to
>> dma_sync_single_for_device:
>>
>> /**
>>  * dma_buf_sync_sg_attachment - sync caches for dma access
>>  * @attach: dma-buf attachment to sync
>>  * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
>>  * @direction: dma direction to sync for
>>  *
>>  * This function synchronizes caches for device dma through the given
>>  * dma-buf attachment when interleaving dma from different devices and the
>>  * cpu. Other device dma needs to be synced also by calls to this
>>  * function (or a pair of dma_buf_map/unmap_attachment calls), cpu access
>>  * needs to be synced with dma_buf_begin/end_cpu_access.
>>  */
>> void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
>>   struct sg_table *sgt,
>>   enum dma_data_direction direction)
>>
>> Note that "sync" here only means to synchronize caches, not wait for any
>> outstanding fences. This is simply to be consistent with the established
>> lingo of the dma api. How the dma-buf fences fit into this is imo a
>> different topic, but my idea is that all the cache coherency barriers
>> (i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
>> dma_buf_begin/end_cpu_access) would automatically block for any attached
>> fences (i.e. block for write fences when doing read-only access, block for
>> all fences otherwise).
>
> As I mentioned already, kernel can't aware of when cpu accesses a shared
> buffer: user can access a shared buffer after mmap anytime and the shared
> buffer should be synchronized between cpu and dma. Therefore, the above
> cache coherency barriers should be called every time cpu and dma tries to
> access a shared buffer, checking before and after of cpu and dma access. And
> exactly, the proposed way do such thing. For this, you can refer to the
> below link,
>
> http://www.mail-archive.com/linux-media at vger.kernel.org/msg62124.html
>
> My point is that how kernel can aware of when those 

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

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

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

--- Comment #34 from Evgeny  ---
Excuse me for disturbing all of you here, but, please, can anyone help me
finding kernel with these patches already packaged? Some PPAs?

-- 
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/20130523/5ec64ecd/attachment.html>

[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

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

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

--- Comment #1 from Knut Andre Tidemann  ---
I can also add that I have a Radeon HD 5670.

-- 
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/20130523/352b60e2/attachment.html>

[Linaro-mm-sig] [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Daniel Vetter]

On Thu, May 23, 2013 at 11:13 AM, Maarten Lankhorst
 wrote:
>> 2. Do you really want to drop the *_slow variants?
>> Doing so might reduce debugging slightly. I like method #2 in 
>> ww-mutex-design.txt, it makes it very clear why you
>> would handle the *_slow case differently anyway.
> As you pointed out, we wouldn't lose much debugging information.
> The same checks could be done in the normal variant with
> WARN_ON(ctx->lock && ctx->lock != lock);
> WARN_ON(ctx->lock && ctx->acquired > 0);

s/lock/contending_lock/ I guess. But yeah, I should have more
carefully read Peter's suggestion to fold in some of the ww_slow debug
checks, we can indeed keep the important debug checks even when
dropping slow. Silly me should be less sloppy.

> But it boils down to ww_mutex_lock_slow returning void instead of int 
> __must_check from ww_mutex_lock.
>
> Maybe add inlines for *_slow, that use the ww_mutex_lock functions, and check 
> ctx->lock == lock in debugging mode?

So either we keep the _slow versions or drop the __must_check for
ww_mutex_lock. In both cases the ww mutex user needs to think a bit
what to do, and I don't there's much we can do in the implementation
(beside all the existing debug support we have) to help. So now I'm
leaning more towards dropping the _slow variants to avoid interface
proliferation.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

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

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

Knut Andre Tidemann  changed:

   What|Removed |Added

Summary|[r600] KSP 0.20 crashes |[r600g] KSP 0.20 crashes
   |when entering settings /|when entering settings /
   |starting new game.  |starting new game.

-- 
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/20130523/87fbf989/attachment.html>

[Bug 64913] New: [r600] KSP 0.20 crashes when entering settings / starting new game.

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

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

  Priority: medium
Bug ID: 64913
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [r600] KSP 0.20 crashes when entering settings /
starting new game.
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: knut.tidemann at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 79702
  --> https://bugs.freedesktop.org/attachment.cgi?id=79702=edit
Backtrace of crash from gdb

I tested Kerbal Space Program today (after the new 0.20 updated) and it crashes
when entering 'Settings' or starting the actual game from the menu.

I've attached a backtrace, and the crash seems to be the same in both cases.
Atleast the same function is involved.

I was running mesa from git. Last commit was:
7bfb4bea6562b2e69d0376f15224c3811da42167

Running kernel 3.8.8.

The last version of the game (0.19.1) works without problems.

-- 
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/20130523/c85531ff/attachment.html>

[Bug 64738] [radeonsi] missing notification icons with glamor

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

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

--- Comment #9 from Alexander Tsoy  ---
(In reply to comment #8)

It's also the case with the 6450 card. Furthermore with 6450 and vanilla
glamor-0.5 I see the same graphics artifacts, so sorry for disinformation in
comment 0.

-- 
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/20130523/7723bef6/attachment.html>

[PATCH v2] drm: Fix drm_rect documentation

[Daniel Vetter]

On Wed, May 08, 2013 at 05:16:45PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrj?l? 
> 
> The 'struct' keyword was missing so struct drm_rect documentation never
> ended up in the generated docs.
> 
> Also move the drm_rect documentations to a new section alognside the
> various helper functions and add a short description about the intended
> purpose of drm_rect.
> 
> v2: Move to new section and add general description
> 
> Signed-off-by: Ville Syrj?l? 

Now merged into dinq since the original stuff is in there, too.

Thanks, Daniel
> ---
>  Documentation/DocBook/drm.tmpl | 8 ++--
>  include/drm/drm_rect.h | 9 -
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7c7af25..91ee107 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -1653,8 +1653,6 @@ void intel_crt_init(struct drm_device *dev)
>  
>KMS API Functions
>  !Edrivers/gpu/drm/drm_crtc.c
> -!Edrivers/gpu/drm/drm_rect.c
> -!Finclude/drm/drm_rect.h
>  
>
>  
> @@ -2163,6 +2161,12 @@ void intel_crt_init(struct drm_device *dev)
>EDID Helper Functions Reference
>  !Edrivers/gpu/drm/drm_edid.c
>  
> +
> +  Rectangle Utilities Reference
> +!Pinclude/drm/drm_rect.h rect utils
> +!Iinclude/drm/drm_rect.h
> +!Edrivers/gpu/drm/drm_rect.c
> +
>
>  
>
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index 64fa265..d128629 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -25,7 +25,14 @@
>  #define DRM_RECT_H
>  
>  /**
> - * drm_rect - two dimensional rectangle
> + * DOC: rect utils
> + *
> + * Utility functions to help manage rectangular areas for
> + * clipping, scaling, etc. calculations.
> + */
> +
> +/**
> + * struct drm_rect - two dimensional rectangle
>   * @x1: horizontal starting coordinate (inclusive)
>   * @x2: horizontal ending coordinate (exclusive)
>   * @y1: vertical starting coordinate (inclusive)
> -- 
> 1.8.1.5
> 

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

[PATCH v3 0/9] Clean up write-combining MTRR addition

[Andy Lutomirski]

On Mon, May 13, 2013 at 4:58 PM, Andy Lutomirski  wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
>
> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
> otherwise.  (Other architectures, if any, with a similar mechanism could
> implement them.)

That's the path to upstream for this?  Should it go through drm-next?
(Sorry for possible noob question -- I've never sent in anything other
than trivial fixes to drm stuff before.)

--Andy

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Maarten Lankhorst]

Op 22-05-13 19:24, Maarten Lankhorst schreef:
> Hey,
>
> Op 22-05-13 18:18, Peter Zijlstra schreef:
>> On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
>>
>> Lacking the actual msg atm, I'm going to paste in here...
> Thanks for taking the time to review.
>>> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
>>> From: Maarten Lankhorst 
>>>
>>> Changes since RFC patch v1:
>>>  - Updated to use atomic_long instead of atomic, since the reservation_id 
>>> was a long.
>>>  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>>>  - removed mutex_locked_set_reservation_id (or w/e it was called)
>>> Changes since RFC patch v2:
>>>  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
>>> combination of
>>>mutex_(,reserve_)lock/unlock.
>>> Changes since v1:
>>>  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
>>> can be
>>>triggered from normal locks, because __builtin_constant_p might evaluate 
>>> to false
>>>for the constant 0 in that case. Tests for this have been added in the 
>>> next patch.
>>>  - Updated documentation slightly.
>>> Changes since v2:
>>>  - Renamed everything to ww_mutex. (mlankhorst)
>>>  - Added ww_acquire_ctx and ww_class. (mlankhorst)
>>>  - Added a lot of checks for wrong api usage. (mlankhorst)
>>>  - Documentation updates. (danvet)
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>>  Documentation/ww-mutex-design.txt |  322 +++
>>>  include/linux/mutex-debug.h   |1 
>>>  include/linux/mutex.h |  257 +
>>>  kernel/mutex.c|  445 
>>> -
>>>  lib/debug_locks.c |2 
>>>  5 files changed, 1010 insertions(+), 17 deletions(-)
>>>  create mode 100644 Documentation/ww-mutex-design.txt
>>>
>>> diff --git a/Documentation/ww-mutex-design.txt 
>>> b/Documentation/ww-mutex-design.txt
>>> new file mode 100644
>>> index 000..154bae3
>>> --- /dev/null
>>> +++ b/Documentation/ww-mutex-design.txt
>>> @@ -0,0 +1,322 @@
>>> +Wait/Wound Deadlock-Proof Mutex Design
>>> +==
>>> +
>>> +Please read mutex-design.txt first, as it applies to wait/wound mutexes 
>>> too.
>>> +
>>> +Motivation for WW-Mutexes
>>> +-
>>> +
>>> +GPU's do operations that commonly involve many buffers.  Those buffers
>>> +can be shared across contexts/processes, exist in different memory
>>> +domains (for example VRAM vs system memory), and so on.  And with
>>> +PRIME / dmabuf, they can even be shared across devices.  So there are
>>> +a handful of situations where the driver needs to wait for buffers to
>>> +become ready.  If you think about this in terms of waiting on a buffer
>>> +mutex for it to become available, this presents a problem because
>>> +there is no way to guarantee that buffers appear in a execbuf/batch in
>>> +the same order in all contexts.  That is directly under control of
>>> +userspace, and a result of the sequence of GL calls that an application
>>> +makes. Which results in the potential for deadlock.  The problem gets
>>> +more complex when you consider that the kernel may need to migrate the
>>> +buffer(s) into VRAM before the GPU operates on the buffer(s), which
>>> +may in turn require evicting some other buffers (and you don't want to
>>> +evict other buffers which are already queued up to the GPU), but for a
>>> +simplified understanding of the problem you can ignore this.
>>> +
>>> +The algorithm that TTM came up with for dealing with this problem is quite
>>> +simple.  For each group of buffers (execbuf) that need to be locked, the 
>>> caller
>>> +would be assigned a unique reservation id/ticket, from a global counter.  
>>> In
>>> +case of deadlock while locking all the buffers associated with a execbuf, 
>>> the
>>> +one with the lowest reservation ticket (i.e. the oldest task) wins, and 
>>> the one
>>> +with the higher reservation id (i.e. the younger task) unlocks all of the
>>> +buffers that it has already locked, and then tries again.
>>> +
>>> +In the RDBMS literature this deadlock handling approach is called 
>>> wait/wound:
>>> +The older tasks waits until it can acquire the contended lock. The younger 
>>> tasks
>>> +needs to back off and drop all the locks it is currently holding, i.e. the
>>> +younger task is wounded.
>>> +
>>> +Concepts
>>> +
>>> +
>>> +Compared to normal mutexes two additional concepts/objects show up in the 
>>> lock
>>> +interface for w/w mutexes:
>>> +
>>> +Acquire context: To ensure eventual forward progress it is important the a 
>>> task
>>> +trying to acquire locks doesn't grab a new reservation id, but keeps the 
>>> one it
>>> +acquired when starting the lock acquisition. This ticket is stored in the
>>> +acquire context. Furthermore the acquire context keeps track of debugging 
>>> state
>>> +to catch 

[PATCH 0/4] drm/exynos: code cleanups

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/5/22 Seung-Woo Kim 

> Build warnings of ipp fimc is fixed and device pointer usage is
> simplified as directly using dev variable.
>
> devm related fixes are also appiled: meaningless devm_kfree is
> removed and request_threaded_irq is replaced to devm function.
>
> Seung-Woo Kim (4):
>   drm/exynos: cleanup device pointer usages
>   drm/exynos: fix build warnings from ipp fimc
>   drm/exynos: remove unnecessary devm_kfree
>   drm/exynos: replace request_threaded_irq with devm function
>
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|   12 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   10 +-
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c |6 +++---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 +++-
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c|2 +-
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c |4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++--
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c|4 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c|   21 -
>  drivers/gpu/drm/exynos/exynos_mixer.c   |   14 +++---
>  10 files changed, 38 insertions(+), 60 deletions(-)
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130523/3e4afbdf/attachment.html>

[PATCH] drm/radeon: revert Apple re-POST hack

[Christian König]

Am 22.05.2013 19:38, schrieb alexdeucher at gmail.com:
> From: Alex Deucher 
>
> This reverts:
> drm/radeon: re-POST the asic on Apple hardware when booted via EFI
>
> That patch prevents UVD from working on macs when booted in EFI
> mode.  The original patch may not be required any more due to other
> fixes for UEFI on non-Mac platforms, but I don't have any Macs.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=63935
>
> Cc: Matthew Garrett 
> Signed-off-by: Alex Deucher 

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/radeon_device.c |4 
>   1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index af82c9b..261fe11 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -467,10 +467,6 @@ bool radeon_card_posted(struct radeon_device *rdev)
>   {
>   uint32_t reg;
>   
> - if (efi_enabled(EFI_BOOT) &&
> - rdev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE)
> - return false;
> -
>   if (ASIC_IS_NODCE(rdev))
>   goto check_memsize;
>   

[PATCH] drm/i915: Cocci spatch "memdup.spatch"

[Daniel Vetter]

On Wed, May 22, 2013 at 11:07:09PM +0200, Thomas Meyer wrote:
> 
> Signed-off-by: Thomas Meyer 

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

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #42 from Christian K?nig  ---
(In reply to comment #41)
> So do the conditions which required commit bcc65fd8 (which introduced this
> test) not exist anymore?

Good question, hopefully Matthew can retest that.

Anyway I think we can close this bugreport now.

Christian.

-- 
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/20130523/f5f639ac/attachment.html>

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #41 from Austin Lund  ---
(In reply to comment #40)
> (In reply to comment #37)
> > Created attachment 79663 [details] [review] [review]
> > don't re-post mac cards
> > 
> > For the non-Macs, this patch should fix the issue:
> > http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html
> > 
> > For the macs, does the attached patch help?
> 
> Yes, with the attached patch UVD initializes successfully on my
> MacBookPro8,2.  Thank you!

I can also confirm this.

So do the conditions which required commit bcc65fd8 (which introduced this
test) not exist anymore?

-- 
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/20130523/8059e0e9/attachment.html>

[Bug 64738] [radeonsi] missing notification icons with glamor

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

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

Michel D?nzer  changed:

   What|Removed |Added

Summary|graphics corruption with|[radeonsi] missing
   |glamor  |notification icons with
   ||glamor

--- Comment #8 from Michel D?nzer  ---
(In reply to comment #7)
> Yes, glamor Git works good. But icons in notification area still missing.

I take it that's not the case with the 6450 card either?

-- 
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/20130523/deff333a/attachment-0001.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

--- Comment #4 from Michel D?nzer  ---
BTW, if you don't need OpenVG support, building Mesa without
--enable-gallium-egl (or with --disable-gallium-egl) might avoid this problem.

-- 
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/20130523/b2de171c/attachment.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

Michel D?nzer  changed:

   What|Removed |Added

Summary|EGL/Gles/Weston give|EGL/Gles/Weston give
   |segfault on RADEONSI|segfault on RADEONSI with
   ||egl_gallium.so

--- Comment #3 from Michel D?nzer  ---
I think the problem is that egl_gallium.so links both radeonsi and r600g, which
have some conflicting symbols.

-- 
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/20130523/222de517/attachment.html>

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

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

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

--- Comment #7 from mombelli.mauro at gmail.com ---
uff tryed now but i have to recompile LLVM from git as my distribution has
only 3.2.. i'll try again next time with some spare time.
Thanks anyway


2013/5/22 

>   *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c6> on bug
> 64776 <https://bugs.freedesktop.org/show_bug.cgi?id=64776> from Michel
> D?nzer  *
>
> Created attachment 79647 
> <https://bugs.freedesktop.org/attachment.cgi?id=79647> [details] 
> <https://bugs.freedesktop.org/attachment.cgi?id=79647=edit> [review] 
> <https://bugs.freedesktop.org/page.cgi?id=splinter.html=64776=79647>
> radeonsi: Make sure disabled colour buffers are disabled in the CB state
>
> Does this Mesa patch help?
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
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/20130523/b7f22400/attachment.html>

[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

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

 name
May 22 11:02:29 localhost colord: Device added: xrandr-Dell-DELL
U2412M-YMYH132P0L7L
May 22 11:02:30 localhost kernel: [215032.645946] [drm:drm_edid_block_valid]
*ERROR* EDID checksum is invalid, remainder is 151
May 22 11:02:30 localhost kernel: [215032.645954] Raw EDID:
May 22 11:02:30 localhost kernel: [215032.645958]  00 ff ff ff ff ff ff 00
10 ac 7a a0 4c 37 4c 30
May 22 11:02:30 localhost kernel: [215032.645961]  09 17 01 03 80 34 20 78
ea ee 95 a3 54 4c 99 26
May 22 11:02:30 localhost kernel: [215032.645964]  0f 50 54 a1 08 00 81 40
81 80 a9 40 b3 00 d1 c0
May 22 11:02:30 localhost kernel: [215032.645966]  01 01 01 01 01 01 28 3c
80 a0 70 b0 23 40 30 20
May 22 11:02:30 localhost kernel: [215032.645969]  36 00 06 44 21 00 00 1a
00 00 00 ff 00 59 5f ff
May 22 11:02:30 localhost kernel: [215032.645971]  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
May 22 11:02:30 localhost kernel: [215032.645973]  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
May 22 11:02:30 localhost kernel: [215032.645976]  ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
May 22 11:02:30 localhost kernel: [215032.647233] [drm:radeon_dvi_detect]
*ERROR* DVI-I-1: probed a monitor but no|invalid EDID


in /var/log/messages.

Odd that the DDC code doesn't see the loss of clock on SCL (DDC Clock, pin 6)
or the change in state on HPD (Hot Plug Detect, pin 16) and simply abort the
I2C transfer until the interface is restored to a valid state.

-- 
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/20130523/a63a7f68/attachment-0001.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI

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

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

--- Comment #2 from Rafael Castillo  ---
yes, effectively setting this environment variable works fine it seems.

only thing is weston give this warning, not sure if important

EGL_EXT_buffer_age not supported. Performance could be affected

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

[PATCH] drm/i915: Cocci spatch "memdup.spatch"

[Thomas Meyer]

Signed-off-by: Thomas Meyer 
---

diff -u -p a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2282,11 +2282,10 @@ intel_dp_get_edid(struct drm_connector *
return NULL;

size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
-   edid = kmalloc(size, GFP_KERNEL);
+   edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
if (!edid)
return NULL;

-   memcpy(edid, intel_connector->edid, size);
return edid;
}

[PATCH] drm: Cocci spatch "memdup.spatch"

[Thomas Meyer]

Signed-off-by: Thomas Meyer 
---

diff -u -p a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -186,12 +186,11 @@ static u8 *edid_load(struct drm_connecto
goto relfw_out;
}

-   edid = kmalloc(fwsize, GFP_KERNEL);
+   edid = kmemdup(fwdata, fwsize, GFP_KERNEL);
if (edid == NULL) {
err = -ENOMEM;
goto relfw_out;
}
-   memcpy(edid, fwdata, fwsize);

if (!drm_edid_block_valid(edid, 0, print_bad_edid)) {
connector->bad_edid_counter++;

Re: [PATCH] drm/i915: Cocci spatch memdup.spatch

[Daniel Vetter]

On Wed, May 22, 2013 at 11:07:09PM +0200, Thomas Meyer wrote:
 
 Signed-off-by: Thomas Meyer tho...@m3y3r.de

Queued for -next, thanks for the patch.
-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

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

Summary|EGL/Gles/Weston give|EGL/Gles/Weston give
   |segfault on RADEONSI|segfault on RADEONSI with
   ||egl_gallium.so

--- Comment #3 from Michel Dänzer mic...@daenzer.net ---
I think the problem is that egl_gallium.so links both radeonsi and r600g, which
have some conflicting symbols.

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #4 from Michel Dänzer mic...@daenzer.net ---
BTW, if you don't need OpenVG support, building Mesa without
--enable-gallium-egl (or with --disable-gallium-egl) might avoid this problem.

-- 
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 64738] [radeonsi] missing notification icons with glamor

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

Summary|graphics corruption with|[radeonsi] missing
   |glamor  |notification icons with
   ||glamor

--- Comment #8 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #7)
 Yes, glamor Git works good. But icons in notification area still missing.

I take it that's not the case with the 6450 card either?

-- 
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/radeon: revert Apple re-POST hack

[Christian König]

Am 22.05.2013 19:38, schrieb alexdeuc...@gmail.com:

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

This reverts:
drm/radeon: re-POST the asic on Apple hardware when booted via EFI

That patch prevents UVD from working on macs when booted in EFI
mode.  The original patch may not be required any more due to other
fixes for UEFI on non-Mac platforms, but I don't have any Macs.

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

Cc: Matthew Garrett mj...@srcf.ucam.org
Signed-off-by: Alex Deucher alexander.deuc...@amd.com


Reviewed-by: Christian König christian.koe...@amd.com


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

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index af82c9b..261fe11 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -467,10 +467,6 @@ bool radeon_card_posted(struct radeon_device *rdev)
  {
uint32_t reg;
  
-	if (efi_enabled(EFI_BOOT) 

-   rdev-pdev-subsystem_vendor == PCI_VENDOR_ID_APPLE)
-   return false;
-
if (ASIC_IS_NODCE(rdev))
goto check_memsize;
  


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

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

--- Comment #41 from Austin Lund austin.l...@gmail.com ---
(In reply to comment #40)
 (In reply to comment #37)
  Created attachment 79663 [details] [review] [review]
  don't re-post mac cards
  
  For the non-Macs, this patch should fix the issue:
  http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html
  
  For the macs, does the attached patch help?
 
 Yes, with the attached patch UVD initializes successfully on my
 MacBookPro8,2.  Thank you!

I can also confirm this.

So do the conditions which required commit bcc65fd8 (which introduced this
test) not exist anymore?

-- 
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 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #42 from Christian König deathsim...@vodafone.de ---
(In reply to comment #41)
 So do the conditions which required commit bcc65fd8 (which introduced this
 test) not exist anymore?

Good question, hopefully Matthew can retest that.

Anyway I think we can close this bugreport now.

Christian.

-- 
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 v3 2/3] mutex: add support for wound/wait style locks, v3

[Maarten Lankhorst]

Op 22-05-13 19:24, Maarten Lankhorst schreef:
 Hey,

 Op 22-05-13 18:18, Peter Zijlstra schreef:
 On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:

 Lacking the actual msg atm, I'm going to paste in here...
 Thanks for taking the time to review.
 Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
 From: Maarten Lankhorst maarten.lankhorst@x

 Changes since RFC patch v1:
  - Updated to use atomic_long instead of atomic, since the reservation_id 
 was a long.
  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
  - removed mutex_locked_set_reservation_id (or w/e it was called)
 Changes since RFC patch v2:
  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
 combination of
mutex_(,reserve_)lock/unlock.
 Changes since v1:
  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
 can be
triggered from normal locks, because __builtin_constant_p might evaluate 
 to false
for the constant 0 in that case. Tests for this have been added in the 
 next patch.
  - Updated documentation slightly.
 Changes since v2:
  - Renamed everything to ww_mutex. (mlankhorst)
  - Added ww_acquire_ctx and ww_class. (mlankhorst)
  - Added a lot of checks for wrong api usage. (mlankhorst)
  - Documentation updates. (danvet)

 Signed-off-by: Maarten Lankhorst maarten.lankhorst@x
 Signed-off-by: Daniel Vetter daniel.vetter@
 ---
  Documentation/ww-mutex-design.txt |  322 +++
  include/linux/mutex-debug.h   |1 
  include/linux/mutex.h |  257 +
  kernel/mutex.c|  445 
 -
  lib/debug_locks.c |2 
  5 files changed, 1010 insertions(+), 17 deletions(-)
  create mode 100644 Documentation/ww-mutex-design.txt

 diff --git a/Documentation/ww-mutex-design.txt 
 b/Documentation/ww-mutex-design.txt
 new file mode 100644
 index 000..154bae3
 --- /dev/null
 +++ b/Documentation/ww-mutex-design.txt
 @@ -0,0 +1,322 @@
 +Wait/Wound Deadlock-Proof Mutex Design
 +==
 +
 +Please read mutex-design.txt first, as it applies to wait/wound mutexes 
 too.
 +
 +Motivation for WW-Mutexes
 +-
 +
 +GPU's do operations that commonly involve many buffers.  Those buffers
 +can be shared across contexts/processes, exist in different memory
 +domains (for example VRAM vs system memory), and so on.  And with
 +PRIME / dmabuf, they can even be shared across devices.  So there are
 +a handful of situations where the driver needs to wait for buffers to
 +become ready.  If you think about this in terms of waiting on a buffer
 +mutex for it to become available, this presents a problem because
 +there is no way to guarantee that buffers appear in a execbuf/batch in
 +the same order in all contexts.  That is directly under control of
 +userspace, and a result of the sequence of GL calls that an application
 +makes. Which results in the potential for deadlock.  The problem gets
 +more complex when you consider that the kernel may need to migrate the
 +buffer(s) into VRAM before the GPU operates on the buffer(s), which
 +may in turn require evicting some other buffers (and you don't want to
 +evict other buffers which are already queued up to the GPU), but for a
 +simplified understanding of the problem you can ignore this.
 +
 +The algorithm that TTM came up with for dealing with this problem is quite
 +simple.  For each group of buffers (execbuf) that need to be locked, the 
 caller
 +would be assigned a unique reservation id/ticket, from a global counter.  
 In
 +case of deadlock while locking all the buffers associated with a execbuf, 
 the
 +one with the lowest reservation ticket (i.e. the oldest task) wins, and 
 the one
 +with the higher reservation id (i.e. the younger task) unlocks all of the
 +buffers that it has already locked, and then tries again.
 +
 +In the RDBMS literature this deadlock handling approach is called 
 wait/wound:
 +The older tasks waits until it can acquire the contended lock. The younger 
 tasks
 +needs to back off and drop all the locks it is currently holding, i.e. the
 +younger task is wounded.
 +
 +Concepts
 +
 +
 +Compared to normal mutexes two additional concepts/objects show up in the 
 lock
 +interface for w/w mutexes:
 +
 +Acquire context: To ensure eventual forward progress it is important the a 
 task
 +trying to acquire locks doesn't grab a new reservation id, but keeps the 
 one it
 +acquired when starting the lock acquisition. This ticket is stored in the
 +acquire context. Furthermore the acquire context keeps track of debugging 
 state
 +to catch w/w mutex interface abuse.
 +
 +W/w class: In contrast to normal mutexes the lock class needs to be 
 explicit for
 +w/w mutexes, since it is required to initialize the acquire context.
 +
 +Furthermore there are three different classe of w/w 

Re: [Linaro-mm-sig] [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Daniel Vetter]

On Thu, May 23, 2013 at 11:13 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 2. Do you really want to drop the *_slow variants?
 Doing so might reduce debugging slightly. I like method #2 in 
 ww-mutex-design.txt, it makes it very clear why you
 would handle the *_slow case differently anyway.
 As you pointed out, we wouldn't lose much debugging information.
 The same checks could be done in the normal variant with
 WARN_ON(ctx-lock  ctx-lock != lock);
 WARN_ON(ctx-lock  ctx-acquired  0);

s/lock/contending_lock/ I guess. But yeah, I should have more
carefully read Peter's suggestion to fold in some of the ww_slow debug
checks, we can indeed keep the important debug checks even when
dropping slow. Silly me should be less sloppy.

 But it boils down to ww_mutex_lock_slow returning void instead of int 
 __must_check from ww_mutex_lock.

 Maybe add inlines for *_slow, that use the ww_mutex_lock functions, and check 
 ctx-lock == lock in debugging mode?

So either we keep the _slow versions or drop the __must_check for
ww_mutex_lock. In both cases the ww mutex user needs to think a bit
what to do, and I don't there's much we can do in the implementation
(beside all the existing debug support we have) to help. So now I'm
leaning more towards dropping the _slow variants to avoid interface
proliferation.
-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

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave,

   This pull request includes drm_send_vblank_event() helper
   relevant patch I missed and code cleanups. And also it fixes
   a pended page flip issue.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 0eca56f9467038ee0b798637f03581aaa1186fac:

  drm/imx: use drm_send_vblank_event() helper (2013-05-22 09:13:42 +1000)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-fixes

Inki Dae (1):
  drm/exynos: wait for the completion of pending page flip

Lars-Peter Clausen (1):
  drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()

Rob Clark (2):
  drm/exynos: page flip fixes
  drm/exynos: use drm_send_vblank_event() helper

Sachin Kamat (2):
  drm/exynos: exynos_drm_fbdev: Fix incorrect usage of IS_ERR_OR_NULL
  drm/exynos: exynos_drm_ipp: Fix incorrect usage of IS_ERR_OR_NULL

Seung-Woo Kim (4):
  drm/exynos: cleanup device pointer usages
  drm/exynos: fix build warnings from ipp fimc
  drm/exynos: remove unnecessary devm_kfree
  drm/exynos: replace request_threaded_irq with devm function

 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   27 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   12 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   10 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 +++-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   18 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c|   21 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |   14 +++---
 12 files changed, 64 insertions(+), 77 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Introduce a new helper framework for buffer synchronization

[Daniel Vetter]

On Tue, May 21, 2013 at 11:22 AM, Inki Dae inki@samsung.com wrote:
 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
 Vetter
 Sent: Tuesday, May 21, 2013 4:45 PM
 To: Inki Dae
 Cc: 'Daniel Vetter'; 'Rob Clark'; 'linux-fbdev'; 'DRI mailing list';
 'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
 ker...@lists.infradead.org; linux-me...@vger.kernel.org
 Subject: Re: Introduce a new helper framework for buffer synchronization

 On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
   - Integration of fence syncing into dma_buf. Imo we should have a
 per-attachment mode which decides whether map/unmap (and the new
 sync)
 should wait for fences or whether the driver takes care of syncing
 through the new fence framework itself (for direct hw sync).
 
  I think it's a good idea to have per-attachment mode for buffer sync.
 But
  I'd like to say we make sure what is the purpose of map
  (dma_buf_map_attachment)first. This interface is used to get a sgt;
  containing pages to physical memory region, and map that region with
  device's iommu table. The important thing is that this interface is
 called
  just one time when user wants to share an allocated buffer with dma. But
 cpu
  will try to access the buffer every time as long as it wants. Therefore,
 we
  need cache control every time cpu and dma access the shared buffer:
 cache
  clean when cpu goes to dma and cache invalidate when dma goes to cpu.
 That
  is why I added new interfaces, DMA_BUF_GET_FENCE and DMA_BUF_PUT_FENCE,
 to
  dma buf framework. Of course, Those are ugly so we need a better way: I
 just
  wanted to show you that in such way, we can synchronize the shared
 buffer
  between cpu and dma. By any chance, is there any way that kernel can be
  aware of when cpu accesses the shared buffer or is there any point I
 didn't
  catch up?

 Well dma_buf_map/unmap_attachment should also flush/invalidate any caches,
 and with the current dma_buf spec those two functions are the _only_ means

 I know that dma buf exporter should make sure that cache clean/invalidate
 are done when dma_buf_map/unmap_attachement is called. For this, already we
 do so. However, this function is called when dma buf import is requested by
 user to map a dmabuf fd with dma. This means that dma_buf_map_attachement()
 is called ONCE when user wants to share the dmabuf fd with dma. Actually, in
 case of exynos drm, dma_map_sg_attrs(), performing cache operation
 internally, is called when dmabuf import is requested by user.

 you have to do so. Which strictly means that if you interleave device dma
 and cpu acccess you need to unmap/map every time.

 Which is obviously horribly inefficient, but a known gap in the dma_buf

 Right, and also this has big overhead.

 interface. Hence why I proposed to add dma_buf_sync_attachment similar to
 dma_sync_single_for_device:

 /**
  * dma_buf_sync_sg_attachment - sync caches for dma access
  * @attach: dma-buf attachment to sync
  * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
  * @direction: dma direction to sync for
  *
  * This function synchronizes caches for device dma through the given
  * dma-buf attachment when interleaving dma from different devices and the
  * cpu. Other device dma needs to be synced also by calls to this
  * function (or a pair of dma_buf_map/unmap_attachment calls), cpu access
  * needs to be synced with dma_buf_begin/end_cpu_access.
  */
 void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
   struct sg_table *sgt,
   enum dma_data_direction direction)

 Note that sync here only means to synchronize caches, not wait for any
 outstanding fences. This is simply to be consistent with the established
 lingo of the dma api. How the dma-buf fences fit into this is imo a
 different topic, but my idea is that all the cache coherency barriers
 (i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
 dma_buf_begin/end_cpu_access) would automatically block for any attached
 fences (i.e. block for write fences when doing read-only access, block for
 all fences otherwise).

 As I mentioned already, kernel can't aware of when cpu accesses a shared
 buffer: user can access a shared buffer after mmap anytime and the shared
 buffer should be synchronized between cpu and dma. Therefore, the above
 cache coherency barriers should be called every time cpu and dma tries to
 access a shared buffer, checking before and after of cpu and dma access. And
 exactly, the proposed way do such thing. For this, you can refer to the
 below link,

 http://www.mail-archive.com/linux-media@vger.kernel.org/msg62124.html

 My point is that how kernel can aware of when those cache coherency barriers
 should be called to synchronize caches and buffer access between cpu and
 dma.


 Then we could do a new dma_buf_attach_flags interface for special cases
 (might also be 

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

A few fixes, nothing shocking:
- More Haswell pci ids. Includes a pile of marketing spare ids (which
  despite the spare moniker show up all over the place).
- Fix a regression in handling modeset failures, resulting in black
  screens on 3 pipe setups when we've run out of pch plls (Chris).
- Fix up the setcrtc semantics to unconditionally enable the outputs.
  Juding from git digging that has (kinda) always been the case and neatly
  fixes a few long-standing (i.e. forever) bug reports (Imre).
- jiffies_timeout + 1 patches from Imre. They partially fix spurious
  wait_event failures in the interrupt-driven dp aux/i2c code. The other
  part is a core patch for the wait_event macros going in through -mm. A
  few patches more than strictly required since Imre is pushing for a
  general solution in 3.11.

Cheers, Daniel


The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:

  Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 3598706b52cb45ba0a9e8aa99ce5ac59140f2b8b:

  drm/i915: avoid premature DP AUX timeouts (2013-05-22 13:51:26 +0200)


Chris Wilson (1):
  drm/i915: Propagate errors back from fb set-base

Imre Deak (5):
  drm/i915: force full modeset if the connector is in DPMS OFF mode
  drm/i915: add msecs_to_jiffies_timeout to guarantee minimum duration
  drm/i915: use msecs_to_jiffies_timeout instead of open coding the same
  drm/i915: avoid premature timeouts in __wait_seqno()
  drm/i915: avoid premature DP AUX timeouts

Rodrigo Vivi (1):
  drm/i915: Adding more reserved PCI IDs for Haswell.

 drivers/gpu/drm/i915/i915_drv.c  |   46 +++
 drivers/gpu/drm/i915/i915_drv.h  |   15 +++
 drivers/gpu/drm/i915/i915_gem.c  |2 +-
 drivers/gpu/drm/i915/intel_display.c |   49 ++
 drivers/gpu/drm/i915/intel_dp.c  |2 +-
 drivers/gpu/drm/i915/intel_i2c.c |5 ++--
 6 files changed, 87 insertions(+), 32 deletions(-)
-- 
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

[Bug 64738] [radeonsi] missing notification icons with glamor

[bugzilla-daemon]

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

--- Comment #9 from Alexander Tsoy alexan...@tsoy.me ---
(In reply to comment #8)

It's also the case with the 6450 card. Furthermore with 6450 and vanilla
glamor-0.5 I see the same graphics artifacts, so sorry for disinformation in
comment 0.

-- 
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 64913] New: [r600] KSP 0.20 crashes when entering settings / starting new game.

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64913
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [r600] KSP 0.20 crashes when entering settings /
starting new game.
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: knut.tidem...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 79702
  -- https://bugs.freedesktop.org/attachment.cgi?id=79702action=edit
Backtrace of crash from gdb

I tested Kerbal Space Program today (after the new 0.20 updated) and it crashes
when entering 'Settings' or starting the actual game from the menu.

I've attached a backtrace, and the crash seems to be the same in both cases.
Atleast the same function is involved.

I was running mesa from git. Last commit was:
7bfb4bea6562b2e69d0376f15224c3811da42167

Running kernel 3.8.8.

The last version of the game (0.19.1) works without problems.

-- 
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 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

[bugzilla-daemon]

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

--- Comment #1 from Knut Andre Tidemann knut.tidem...@gmail.com ---
I can also add that I have a Radeon HD 5670.

-- 
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: [Intel-gfx] [PATCH 7/7] drm: Remove some unused stuff from drm_plane

[Imre Deak]

On Wed, 2013-05-08 at 12:55 +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 There's a bunch of unused members inside drm_plane, bloating the size of
 the structure needlessly. Eliminate them.
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

On the series:
Reviewed-by: Imre Deak imre.d...@intel.com

 ---
  drivers/gpu/drm/drm_crtc.c |  2 +-
  include/drm/drm_crtc.h | 10 --
  2 files changed, 1 insertion(+), 11 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index d7c449f..e591914 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1739,7 +1739,7 @@ int drm_mode_getplane(struct drm_device *dev, void 
 *data,
  
   plane_resp-plane_id = plane-base.id;
   plane_resp-possible_crtcs = plane-possible_crtcs;
 - plane_resp-gamma_size = plane-gamma_size;
 + plane_resp-gamma_size = 0;
  
   /*
* This ioctl is called twice, once to determine how much space is
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index adb3f9b..99420c4 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -654,9 +654,6 @@ struct drm_plane_funcs {
   * @format_count: number of formats supported
   * @crtc: currently bound CRTC
   * @fb: currently bound fb
 - * @gamma_size: size of gamma table
 - * @gamma_store: gamma correction table
 - * @enabled: enabled flag
   * @funcs: helper functions
   * @helper_private: storage for drver layer
   * @properties: property tracking for this plane
 @@ -674,14 +671,7 @@ struct drm_plane {
   struct drm_crtc *crtc;
   struct drm_framebuffer *fb;
  
 - /* CRTC gamma size for reporting to userspace */
 - uint32_t gamma_size;
 - uint16_t *gamma_store;
 -
 - bool enabled;
 -
   const struct drm_plane_funcs *funcs;
 - void *helper_private;
  
   struct drm_object_properties properties;
  };


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

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

[bugzilla-daemon]

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

--- Comment #34 from Evgeny evge...@gmail.com ---
Excuse me for disturbing all of you here, but, please, can anyone help me
finding kernel with these patches already packaged? Some PPAs?

-- 
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 64738] [radeonsi] missing notification icons with glamor

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #79494|0   |1
is obsolete||

-- 
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 64738] [radeonsi] missing notification icons with glamor

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #79495|0   |1
is obsolete||

-- 
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 64738] missing notification icons with glamor

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |zhigang.g...@gmail.com
   |.org|
Summary|[radeonsi] missing  |missing notification icons
   |notification icons with |with glamor
   |glamor  |
Product|Mesa|xorg
  Component|Drivers/Gallium/radeonsi|Driver/glamor

--- Comment #10 from Michel Dänzer mic...@daenzer.net ---
Then it sounds like it's most likely a glamor issue. Might be interesting if
someone could test this on an Intel GPU.

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #16 from Jakob Nixdorf flo...@shadowice.org ---
I checkt again when the second monitor is switched off.

I booted with radeon.modeset=0, which caused the radeon module to not be loaded
since I don't have UMS support in my kernel. With this both monitors work and I
can get a TTY on both.
But as soon as I run 'modprobe -v radeon modeset=1' the second monitor is
switched off to black.

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #5 from Rafael Castillo jrch2...@gmail.com ---
well im using gentoo so /etc/env.d/00egl did the trick to make it global, so
its working that way it seems[kwin_gles works fine now].

should i close the report? 

many thanks for your help

btw i hit this other bug https://bugzilla.kernel.org/show_bug.cgi?id=58621
maybe you know someone who could check it out or give me some advice's in how
to debug it further?

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #5)
 should i close the report? 

No. It's just a workaround, not a fix.

-- 
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 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

--- Comment #43 from russianneuroman...@ya.ru ---
As I understand this patch will be included into next 3.10 RC?

-- 
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 64879] i915 doesn't do derivatives, neither gallium nor intel driver

[bugzilla-daemon]

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

--- Comment #3 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #2)
 The software rendering fallback in the intel driver is pretty slick.  The
 gallium driver has nothing like that, correct?
Nope. Not sure though what you mean by pretty slick, in my experience it is
usually useless due to glacial performance (though I guess maybe it's better
thanks to UMA compared to old radeons).

-- 
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 64933] New: Hyperz related gpu lockup on git mesa in Brütal Legend

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64933
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Hyperz related gpu lockup on git mesa in Brütal Legend
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: thomas.lindr...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 79724
  -- https://bugs.freedesktop.org/attachment.cgi?id=79724action=edit
dmesg, xorg.log

It locks up in the opening scene unless R600_HYPERZ=0 is set. Here it a trace
for it.
https://dl.dropboxusercontent.com/s/w1dr3abdesxcp66/Buddha2.bin.x86.trace.xz
[337M]

I tried to trim it but I only got an unplayable result. glretrace would segfult
in r600g.so so it could also be a problem with the driver. Replaying with
mesa-9.1.2 didn't segfault, instead I got this error message: glretrace:
../../src/mesa/main/fbobject.c:2014: reuse_framebuffer_texture_attachment:
Assertion `src_att-Renderbuffer != ((void *)0)' failed

I uploaded the full trace just to make sure there is nothing wrong with the
trace.

I'm using 32bit: brütal legend (steam), mesa-git, libdri-git and 64bit:
xf86-video-ati-7.1.0 xorg-server-1.13.4 kernel-3.9.3


./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules
--disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float
--disable-debug --enable-egl --disable-gbm --disable-gles1 --disable-gles2
--enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi
--disable-xa --disable-xorg --with-dri-drivers=
--with-gallium-drivers=,swrast,r600 PYTHON2=/usr/bin/python2.7
--with-egl-platforms=x11 --enable-gallium-egl --enable-gallium-llvm
--disable-openvg --disable-r600-llvm-compiler --disable-vdpau --disable-xvmc

-- 
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 64879] i915 doesn't do derivatives, neither gallium nor intel driver

[bugzilla-daemon]

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

--- Comment #4 from Marek Olšák mar...@gmail.com ---
FYI, the old failover module was actually capable of switching between a
hardware driver and softpipe in the middle of rendering. It should be possible
to implement something similar for i915g, though it might be a lot of work.

-- 
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 58731] New: radeon_uvd: Can't load firmware radeon/RV710_uvd.bin

[bugzilla-daemon]

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

   Summary: radeon_uvd: Can't load firmware radeon/RV710_uvd.bin
   Product: Drivers
   Version: 2.5
Kernel Version: 3.10.0-rc2
  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: smf.li...@ntlworld.com
Regression: No


Created an attachment (id=102361)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=102361)
dmesg output and other supporting information

[AMD/ATI] RV710 [Radeon HD 4350/4550] on M5A97 PRO and AMD Phenom(tm) II X6
1100T Processor (16Gbyte RAM) fails to load RV710_uvd.bin at boot. I have found
that request_firmware call is returning -2 (ENOENT) though the correct file
is available in /lib/firmware/radeon. On further investigation this appears to
stem from assign_firmware_buf not having a buffer available (buf-size=0). I
have attached an instrumented dmesg (lines tagged with SMF), lspci and
/lib/firmware/radion listings for information. I am assuming that this video
card should support the UVD functionality.
Please advise.

regards

Stuart Foster

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

PA_SC_RASTER_CONFIG

[Sylvain BERTRAND]

Hi,



In si.c, the PA_SC_RASTER_CONFIG register is set with a
golden value in 'si_init_golden_registers' function but get
set nearly immediately after in 'si_setup_rb' function at a finer
level (for each sh block of each se block).
If I remember well, that golden value would be again set to the
golden value in mesa.

Is there one golden value for all se/sh blocks? Or are there computed
(then overwritting the golden value) values for each se/sh? Why
mesa would overwrite its value (I have not checked in lastest
mesa)?

(drm-next-3.10 branch, head
28ff680d66b9c6b8dbe9436742e39a47a16ea396)



In drm-next-3.10 branch, commit
c9e065819056dd00ccecbf17a73ade03fa03ca8e, in
verde_golden_registers, many registers are set several times
in a row, expected? (that does not look like sequential
programing registers, maybe some register backbone block routing
trickery?)



Regards,

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

[Bug 64649] Anomaly 2 (Steam) exits with divide by 0 in r600g

[bugzilla-daemon]

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

--- Comment #17 from romula...@gmail.com ---
Created attachment 79726
  -- https://bugs.freedesktop.org/attachment.cgi?id=79726action=edit
Full GDB backtrace for git mesa Anomaly 2

-- 
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 64649] Anomaly 2 (Steam) exits with divide by 0 in r600g

[bugzilla-daemon]

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

romula...@gmail.com changed:

   What|Removed |Added

  Attachment #79726|0   |1
is obsolete||

-- 
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 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-daemon]

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

--- Comment #6 from Philip Prindeville phil...@redfish-solutions.com ---
Also seeing the following:

ftp://ftp.redfish-solutions.com/pub/Screenshot%20from%202013-05-20%2014:42:55.png

the background isn't set, and the bottom of the screen seems to have fragments
of OFF-screen backing store... which are ON-screen anyway.

It's not clear if this is related to the parse relocation error or is an
entirely different issue.

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

Radeon atombios power state can cause NULL pointer dereference

[Clément Calmels]

Hi,

My Packard Bell Dot M/A laptop (ATI x1200/rs690m) fails during resume:

[   73.033179] BUG: unable to handle kernel NULL pointer dereference at
0020 [   73.033184] IP: [a0418dc3]
radeon_pm_resume+0xda/0x137 [radeon] [   73.033227] PGD 0 
[   73.033231] Oops:  [#1] SMP 
[   73.033236] CPU 0 
[   73.033238] Modules linked in: cryptd aes_x86_64 aes_generic uinput
loop snd_hda_codec_realtek arc4 ath9k joydev snd_hda_intel radeon
ath9k_common ath9k_hw snd_hda_codec ath ttm snd_hwdep uvcvideo
drm_kms_helper mac80211 videodev snd_pcm snd_page_alloc snd_seq
snd_seq_device snd_timer drm v4l2_compat_ioctl32 media cfg80211
edac_mce_amd mperf acerhdf acer_wmi snd sp5100_tco sparse_keymap pcspkr
edac_core rfkill soundcore i2c_piix4 i2c_algo_bit k8temp psmouse
i2c_core evdev serio_raw video wmi shpchp processor ac battery
power_supply button ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif
ata_generic ahci libahci pata_atiixp libata ohci_hcd ehci_hcd usbcore
scsi_mod thermal thermal_sys r8169 mii usb_common [last unloaded:
scsi_wait_scan] [   73.033304] [   73.033310] Pid: 154, comm:
kworker/u:6 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.41-2+deb7u2 Packard
Bell DOTMA   /SJM11-YK [   73.033317] RIP:
0010:[a0418dc3]  [a0418dc3]
radeon_pm_resume+0xda/0x137 [radeon] [   73.033347] RSP:
0018:880037631db0  EFLAGS: 00010297 [   73.033350] RAX:
88006b8fa1d0 RBX: 88003715c000 RCX: 
[   73.033354] RDX:  RSI:  RDI:
88003715d3a8 [   73.033358] RBP: 88003715d3a8 R08:
0002 R09: 0028 [   73.033362] R10:
1700 R11: 1700 R12: 
[   73.033366] R13: 8142db90 R14: 88006d733c05 R15:
88006b6156d0 [   73.033372] FS:  7f96cf0ea700()
GS:88006fc0() knlGS: [   73.033376] CS:
0010 DS:  ES:  CR0: 8005003b [   73.033380] CR2:
0020 CR3: 01605000 CR4: 06f0
[   73.033385] DR0:  DR1:  DR2:
 [   73.033389] DR3:  DR6:
0ff0 DR7: 0400 [   73.033394] Process
kworker/u:6 (pid: 154, threadinfo 88003763, task
8800375415d0) [   73.033397] Stack: [   73.033399]
88006b737000 88003715c000 88006b737000 a03d5a26
[   73.033406]  88006cc57090  
81255b88 [   73.033411]  880037631d2c 88006cc57090
88006cc570f0  [   73.033417] Call Trace:
[   73.033439]  [a03d5a26] ? radeon_resume_kms+0x82/0x114
[radeon] [   73.033448]  [81255b88] ? pm_op+0xa1/0x141
[   73.033455]  [81255f4c] ? device_resume+0xa2/0xfc
[   73.033461]  [81255fba] ? async_resume+0x14/0x38
[   73.033469]  [810648cc] ? async_run_entry_fn+0x96/0x142
[   73.033475]  [8105b22d] ? process_one_work+0x161/0x264
[   73.033484]  [81059b3e] ? need_to_create_worker+0x9/0x1c
[   73.033489]  [8105c1ee] ? worker_thread+0xc2/0x145
[   73.033495]  [8105c12c] ?
manage_workers.isra.25+0x15b/0x15b [   73.033502]
[8105f329] ? kthread+0x76/0x7e [   73.033509]
[81354b34] ? kernel_thread_helper+0x4/0x10 [   73.033515]
[8105f2b3] ? kthread_worker_fn+0x139/0x139 [   73.033521]
[81354b30] ? gs_change+0x13/0x13 [   73.033523] Code: 14 00
00 8b 93 38 14 00 00 89 83 14 14 00 00 48 6b c0 30 48 03 83 08 14 00 00
89 93 2c 14 00 00 83 bb 48 14 00 00 01 48 8b 50 08 8b 52 20 66 89 93
30 14 00 00 48 8b 40 08 66 8b 40 22 66 89 83 [   73.033565] RIP
[a0418dc3] radeon_pm_resume+0xda/0x137 [radeon]
[   73.033593]  RSP 880037631db0 [   73.033596] CR2:
0020

Digging a little bit, the issue can be highlighted with this patch:

--- drivers/gpu/drm/radeon/radeon_atombios.c.orig   2013-05-23
21:54:50.514665155 +0200
+++ drivers/gpu/drm/radeon/radeon_atombios.c2013-05-24
00:20:43.149263167 +0200
@@ -2159,6 +2159,7 @@ static int radeon_atombios_parse_power_t
}
/* last mode is usually default */
if (rdev-pm.default_power_state_index == -1) {
+   WARN_ON(state_index == 0);
rdev-pm.power_state[state_index - 1].type =
POWER_STATE_TYPE_DEFAULT;
rdev-pm.default_power_state_index = state_index - 1;

In my case, the laptop report 0 for memory clock for all power states.
At the end of the for loop, state_index still equals 0, leading to a
wrong access in the rdev-pm.power_state array.
When switching memory clock in async mode (instead of sync mode)
within the bios, the laptop correctly reports its value (ie 333MHz).

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

Re: [PATCH v3 0/9] Clean up write-combining MTRR addition

[Andy Lutomirski]

On Mon, May 13, 2013 at 4:58 PM, Andy Lutomirski l...@amacapital.net wrote:
 A fair number of drivers (mostly graphics) add write-combining MTRRs.
 Most ignore errors and most add the MTRR even on PAT systems which don't
 need to use MTRRs.

 This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
 x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
 otherwise.  (Other architectures, if any, with a similar mechanism could
 implement them.)

That's the path to upstream for this?  Should it go through drm-next?
(Sorry for possible noob question -- I've never sent in anything other
than trivial fixes to drm stuff before.)

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

Re: [PATCH 00/33] devm improvement series, part 1, take 2

[Thierry Reding]

On Thu, May 16, 2013 at 01:15:28PM +0200, Wolfram Sang wrote:
 Lately, I have been experimenting how to improve the devm interface to make
 writing device drivers easier and less error prone while also getting rid of
 its subtle issues. I think it has more potential but still needs work and
 definately conistency, especiall in its usage.
 
 The first thing I come up with is a low hanging fruit regarding
 devm_ioremap_resouce(). This function already checks if the passed resource is
 valid and gives an error message if not. So, we can remove similar checks from
 the drivers and get rid of a bit of code and a number of inconsistent error
 strings.

Sorry for jumping in so late. I generally like the idea. One small
inconvenience is that devm_ioremap_resource() returns -EINVAL if
res == NULL, which means that drivers will now also return -EINVAL
in cases where no resource was returned. Typically drivers handle
this by returning something like -ENODEV, -ENXIO, -ENOENT. Some do
return -EINVAL but perhaps having a separate error code (and maybe
error message as well) for a missing resource would be helpful.

Doing this would be rather easy now that you've paved the way by
making devm_ioremap_resource() usage consistent across drivers.

Thierry


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

Radeon atombios power state can cause NULL pointer dereference

[Clément Calmels]

Hi,

My Packard Bell Dot M/A laptop (ATI x1200/rs690m) fails during resume:

[   73.033179] BUG: unable to handle kernel NULL pointer dereference at
0020 [   73.033184] IP: [a0418dc3]
radeon_pm_resume+0xda/0x137 [radeon] [   73.033227] PGD 0 
[   73.033231] Oops:  [#1] SMP 
[   73.033236] CPU 0 
[   73.033238] Modules linked in: cryptd aes_x86_64 aes_generic uinput
loop snd_hda_codec_realtek arc4 ath9k joydev snd_hda_intel radeon
ath9k_common ath9k_hw snd_hda_codec ath ttm snd_hwdep uvcvideo
drm_kms_helper mac80211 videodev snd_pcm snd_page_alloc snd_seq
snd_seq_device snd_timer drm v4l2_compat_ioctl32 media cfg80211
edac_mce_amd mperf acerhdf acer_wmi snd sp5100_tco sparse_keymap pcspkr
edac_core rfkill soundcore i2c_piix4 i2c_algo_bit k8temp psmouse
i2c_core evdev serio_raw video wmi shpchp processor ac battery
power_supply button ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif
ata_generic ahci libahci pata_atiixp libata ohci_hcd ehci_hcd usbcore
scsi_mod thermal thermal_sys r8169 mii usb_common [last unloaded:
scsi_wait_scan] [   73.033304] [   73.033310] Pid: 154, comm:
kworker/u:6 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.41-2+deb7u2 Packard
Bell DOTMA   /SJM11-YK [   73.033317] RIP:
0010:[a0418dc3]  [a0418dc3]
radeon_pm_resume+0xda/0x137 [radeon] [   73.033347] RSP:
0018:880037631db0  EFLAGS: 00010297 [   73.033350] RAX:
88006b8fa1d0 RBX: 88003715c000 RCX: 
[   73.033354] RDX:  RSI:  RDI:
88003715d3a8 [   73.033358] RBP: 88003715d3a8 R08:
0002 R09: 0028 [   73.033362] R10:
1700 R11: 1700 R12: 
[   73.033366] R13: 8142db90 R14: 88006d733c05 R15:
88006b6156d0 [   73.033372] FS:  7f96cf0ea700()
GS:88006fc0() knlGS: [   73.033376] CS:
0010 DS:  ES:  CR0: 8005003b [   73.033380] CR2:
0020 CR3: 01605000 CR4: 06f0
[   73.033385] DR0:  DR1:  DR2:
 [   73.033389] DR3:  DR6:
0ff0 DR7: 0400 [   73.033394] Process
kworker/u:6 (pid: 154, threadinfo 88003763, task
8800375415d0) [   73.033397] Stack: [   73.033399]
88006b737000 88003715c000 88006b737000 a03d5a26
[   73.033406]  88006cc57090  
81255b88 [   73.033411]  880037631d2c 88006cc57090
88006cc570f0  [   73.033417] Call Trace:
[   73.033439]  [a03d5a26] ? radeon_resume_kms+0x82/0x114
[radeon] [   73.033448]  [81255b88] ? pm_op+0xa1/0x141
[   73.033455]  [81255f4c] ? device_resume+0xa2/0xfc
[   73.033461]  [81255fba] ? async_resume+0x14/0x38
[   73.033469]  [810648cc] ? async_run_entry_fn+0x96/0x142
[   73.033475]  [8105b22d] ? process_one_work+0x161/0x264
[   73.033484]  [81059b3e] ? need_to_create_worker+0x9/0x1c
[   73.033489]  [8105c1ee] ? worker_thread+0xc2/0x145
[   73.033495]  [8105c12c] ?
manage_workers.isra.25+0x15b/0x15b [   73.033502]
[8105f329] ? kthread+0x76/0x7e [   73.033509]
[81354b34] ? kernel_thread_helper+0x4/0x10 [   73.033515]
[8105f2b3] ? kthread_worker_fn+0x139/0x139 [   73.033521]
[81354b30] ? gs_change+0x13/0x13 [   73.033523] Code: 14 00
00 8b 93 38 14 00 00 89 83 14 14 00 00 48 6b c0 30 48 03 83 08 14 00 00
89 93 2c 14 00 00 83 bb 48 14 00 00 01 48 8b 50 08 8b 52 20 66 89 93
30 14 00 00 48 8b 40 08 66 8b 40 22 66 89 83 [   73.033565] RIP
[a0418dc3] radeon_pm_resume+0xda/0x137 [radeon]
[   73.033593]  RSP 880037631db0 [   73.033596] CR2:
0020

Digging a little bit, the issue can be highlighted with this patch:

--- drivers/gpu/drm/radeon/radeon_atombios.c.orig   2013-05-23
21:54:50.514665155 +0200
+++ drivers/gpu/drm/radeon/radeon_atombios.c2013-05-24
00:20:43.149263167 +0200
@@ -2159,6 +2159,7 @@ static int radeon_atombios_parse_power_t
}
/* last mode is usually default */
if (rdev-pm.default_power_state_index == -1) {
+   WARN_ON(state_index == 0);
rdev-pm.power_state[state_index - 1].type =
POWER_STATE_TYPE_DEFAULT;
rdev-pm.default_power_state_index = state_index - 1;

In my case, the laptop report 0 for memory clock for all power states.
At the end of the for loop, state_index still equals 0, leading to a
wrong access in the rdev-pm.power_state array.
When switching memory clock in async mode (instead of sync mode)
within the bios, the laptop correctly reports its value (ie 333MHz).

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

Re: PA_SC_RASTER_CONFIG

[Michel Dänzer]

On Fre, 2013-05-24 at 02:15 +0200, Sylvain BERTRAND wrote:
 
 In si.c, the PA_SC_RASTER_CONFIG register is set with a
 golden value in 'si_init_golden_registers' function but get
 set nearly immediately after in 'si_setup_rb' function at a finer
 level (for each sh block of each se block).
 If I remember well, that golden value would be again set to the
 golden value in mesa.
 
 Is there one golden value for all se/sh blocks?

AFAIK, yes.

 Or are there computed (then overwritting the golden value) values for
 each se/sh?

AFAICT the code doing this is quite broken and should probably be
removed at this point.


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