[PATCH] drm/vma-manager: Don't unmap COW'd pages when zapping bo ptes

[Thomas Hellstrom]

On 11/20/2013 03:24 PM, Daniel Vetter wrote:
> On Wed, Nov 20, 2013 at 01:55:49AM -0800, Thomas Hellstrom wrote:
>> Not sure if there are any user-space users of private bo mappings, but
>> if there are, or will be, zapping the COW'd pages when, for example,
>> moving a bo would confuse the user immensely since the net effect for the
>> user would be that pages written to would lose their contents.
>>
>> Signed-off-by: Thomas Hellstrom 
> Presuming I'm not horribly confused about that all the vm slang in the
> kerneldoc means this changes is
>
> Reviewed-by: Daniel Vetter 
>
> Now I still hold that userspace creating anynomous bo mappings is rather
> crazy, but meh ;-) I guess the real question is whether we have anyone
> relying on this out there (or planing to), in which case we either need to
> funnel this through stable kernels or whack a drm feature flag onto
> drivers/kernels with this fixed. But I seriously hope the answer is no.
>
> Cheers, Daniel
>
Thanks for reviewing. I don't think there's a need to take this through 
stable, since I don't know of anyone using private VMAs,

Actually I'll need to hold off on this for a while since on some archs 
this may cause
ptes of shared pages to not be zapped. If the arch doesn't have 
PTE_SPECIAL, shared pages on MIXEDMAP vmas will come through as
vm_normal_page, and since page->mapping is usually (un)set to NULL by 
our drivers, this will result in false positives for COW'ed pages.

So that test is buggy, or us not setting page->mapping to the mapping we 
use is buggy. It's too late in the day to decide which.

/Thomas

[Bug 71817] Git Mesa r600g driver crashes while using llvm

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

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

--- Comment #2 from Krzysztof A. Sobiecki  ---
And the winner is:
88c8f1972976c506e8fb048100ed11fef1ca938b is the first bad commit
commit 88c8f1972976c506e8fb048100ed11fef1ca938b
Author: Vincent Lejeune 
Date:   Wed Oct 30 18:35:58 2013 +0100

r600/llvm: Store inputs in function arguments

:04 04 70bee8674c6b22eda966273cc1f736ed81da3829
10b9d66a3bd9c8328649515d5cf40ce20b022c1b Msrc

Thank You.

-- 
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/20131120/40087a52/attachment.html>

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

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

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

--- Comment #20 from Arek Ru?niak  ---
With Mesa 10.1.0-devel (git-0601598) & LLVM 3.4 (svn-r195266) still quits in
the same moment but log is a little bit different:
Sam3: AMDGPUInstrInfo.cpp:113: virtual void
llvm::AMDGPUInstrInfo::storeRegToStackSlot(llvm::MachineBasicBlock&,
llvm::MachineBasicBlock::iterator, unsigned int, bool, int, const
llvm::TargetRegisterClass*, const llvm::TargetRegisterInfo*) const: Assertion
`!"Not Implemented"' failed.

I don't try Brutal Legent, but Stalker game(by the wine) has the same issue and
log changes from AMDGPUInstrInfo.cpp:113 to AMDGPUInstrInfo.cpp:109 after
update mesa/llvm too.

-- 
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/20131120/5d3fd236/attachment.html>

[Ac100] [PATCH 00/31] ARM: tegra: use common reset and DMA bindings

[Martino Brandolini]

Dear all,
My ac100 screen is flickering so much. I realized I'm not using it anymore.
So if anyone wants to have it for free would be for me a huge pleasure to
give it away. I'm based in milan and I'll be in London for the next week.
Maybe someone needs it.

Martino


2013/11/20 Stephen Warren 

> On 11/20/2013 08:37 AM, Arnd Bergmann wrote:
> > On Friday 15 November 2013, Stephen Warren wrote:
> >> This series implements a common reset framework driver for Tegra, and
> >> updates all relevant Tegra drivers to use it. It also removes the custom
> >> DMA bindings and replaced them with the standard DMA DT bindings.
> >
> > The series is rather long, so I may have missed it, but I think you need
> one
> > more patch to the apbdma binding to document the use of #dma-cells, what
> > value it has, and what the format of the dma specifiers in slave drivers
> > needs to be.
>
> Yes, you're right. I will fold the following into "ARM: tegra: document
> use of standard DMA DT bindings":
>
> > diff --git a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> > index 0b1e577ab9d3..0b0f9498e265 100644
> > --- a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> > +++ b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> > @@ -11,6 +11,10 @@ Required properties:
> >See ../reset/reset.txt for details.
> >  - reset-names : Must include the following entries:
> >- dma
> > +- #iommu-cells : Must be <1>. This dictates the length of DMA
> specifiers in
> > +  client nodes' dmas properties. The specifier represents the DMA
> request
> > +  select value for the peripheral. For more details, consult the Tegra
> TRM's
> > +  documentation of the APB DMA channel control register REQ_SEL field.
> >
> >  Examples:
> >
> > @@ -36,4 +40,5 @@ apbdma: dma at 6000a000 {
> >   clocks = <_car 34>;
> >   resets = <_car 34>;
> >   reset-names = "dma";
> > + #iommu-cells = <1>;
> >  };
>
>
> ___
> Mailing list: https://launchpad.net/~ac100
> Post to : ac100 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ac100
> More help   : https://help.launchpad.net/ListHelp
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131120/f6493ab9/attachment-0001.html>

[PATCH 00/31] ARM: tegra: use common reset and DMA bindings

[Arnd Bergmann]

On Wednesday 20 November 2013, Stephen Warren wrote:
> > +- #iommu-cells : Must be <1>. This dictates the length of DMA specifiers in
> > +  client nodes' dmas properties. The specifier represents the DMA request
> > +  select value for the peripheral. For more details, consult the Tegra 
> > TRM's
> > +  documentation of the APB DMA channel control register REQ_SEL field.
> >  
> >  Examples:
> >  
> > @@ -36,4 +40,5 @@ apbdma: dma at 6000a000 {
> >   clocks = <_car 34>;
> >   resets = <_car 34>;
> >   reset-names = "dma";
> > + #iommu-cells = <1>;


s/iommu/dma/

Otherwise looks good. The dts files are correct, so I guess it's just
a typo here.

Arnd

[PATCH] intel: Use memset instead of VG_CLEAR

[Daniel Vetter]

On Wed, Nov 20, 2013 at 08:38:38AM -0800, Ian Romanick wrote:
> From: Ian Romanick 
> 
> The ioctl expects that certain fields will be zeroed, so we should allow
> the helper function to actually work in non-Valgrind builds.
> 
> Signed-off-by: Ian Romanick 
> Reported-by: Zhenyu Wang 
> Cc: Damien Lespiau 
> Cc: Daniel Vetter 

Reviewed-by: Daniel Vetter 
> ---
>  intel/intel_bufmgr_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index df6fcec..c11ed45 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -3033,7 +3033,7 @@ drm_intel_get_reset_stats(drm_intel_context *ctx,
>   if (ctx == NULL)
>   return -EINVAL;
>  
> - VG_CLEAR(stats);
> + memset(, 0, sizeof(stats));
>  
>   bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr;
>   stats.ctx_id = ctx->ctx_id;
> -- 
> 1.8.1.4
> 

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

[PATCH] intel: Use memset instead of VG_CLEAR

[Damien Lespiau]

On Wed, Nov 20, 2013 at 08:38:38AM -0800, Ian Romanick wrote:
> From: Ian Romanick 
> 
> The ioctl expects that certain fields will be zeroed, so we should allow
> the helper function to actually work in non-Valgrind builds.
> 
> Signed-off-by: Ian Romanick 
> Reported-by: Zhenyu Wang 
> Cc: Damien Lespiau 
> Cc: Daniel Vetter 

I was thinking that I missed it in the (lidrm) review, but it's actually
a newer patch that introduces the checks.

Lesson learned for next ioctl reviews (kernel), have a better pass on
the input validation and think about rejecting reserved values.

Reviewed-by: Damien Lespiau 

> ---
>  intel/intel_bufmgr_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index df6fcec..c11ed45 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -3033,7 +3033,7 @@ drm_intel_get_reset_stats(drm_intel_context *ctx,
>   if (ctx == NULL)
>   return -EINVAL;
>  
> - VG_CLEAR(stats);
> + memset(, 0, sizeof(stats));
>  
>   bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr;
>   stats.ctx_id = ctx->ctx_id;
> -- 
> 1.8.1.4
> 

[PATCH 00/31] ARM: tegra: use common reset and DMA bindings

[Arnd Bergmann]

On Friday 15 November 2013, Stephen Warren wrote:
> This series implements a common reset framework driver for Tegra, and
> updates all relevant Tegra drivers to use it. It also removes the custom
> DMA bindings and replaced them with the standard DMA DT bindings.

The series is rather long, so I may have missed it, but I think you need one
more patch to the apbdma binding to document the use of #dma-cells, what
value it has, and what the format of the dma specifiers in slave drivers
needs to be.

Arnd

[Bug 46161] [BISECTED]divide error on radeon modprobe

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

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

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 46161] [BISECTED]divide error on radeon modprobe

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

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

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 71816] Sacred: Gold Edition does not work with radeonsi

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

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

--- Comment #3 from darkbasic  ---
>> Does it work better if you move away 
>> /home/niko/.desura/games/sacred-gold/lib/lib1/libz.so.1 ?

It did the trick! Unfortunately it's dead slow and there is no audio.

-- 
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/20131120/e8b3782a/attachment.html>

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Just a small pile of fixes for bugs and a few regressions. I'm still
trying to track down a driver load hang on my g33 (which infuriatingly
doesn't happen when loading the module manually after boot), somehow
bisecting loves to go astray on this one :( And there's a (harmless)
locking WARN in the suspend code due to one of Jesse's vlv backlight
rework patches. Otherwise nothing outstanding afaik.

Cheers, Daniel


The following changes since commit ad40f83f5a89f6d723fd4db424b531f8dd7d3b49:

  Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2013-11-14 09:53:15 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-11-20

for you to fetch changes up to f727b490efd0941a8d720fd07012dcb7f0740f77:

  drm/i915: Fix gen3 self-refresh watermarks (2013-11-20 15:52:52 +0100)


Chris Wilson (2):
  drm/i915: Hold pc8 lock around toggling pc8.gpu_idle
  drm/i915: Do not enable package C8 on unsupported hardware

Daniel Vetter (7):
  drm/i915: flush cursors harder
  Partially revert "drm/i915: tune the RC6 threshold for stability"
  drm/i915: restore the early forcewake cleanup
  drm/i915/tv: add ->get_config callback
  drm/i915: encoder->get_config is no longer optional
  drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
  drm/i915: Fix gen3 self-refresh watermarks

Duncan Laurie (1):
  i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7

Jani Nikula (1):
  drm/i915/dp: set sink to power down mode on dp disable

Jesse Barnes (1):
  x86/early quirk: use gen6 stolen detection for VLV

 arch/x86/kernel/early-quirks.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_bios.c|  7 ++-
 drivers/gpu/drm/i915/intel_ddi.c | 20 
 drivers/gpu/drm/i915/intel_display.c | 33 +++--
 drivers/gpu/drm/i915/intel_dp.c  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  |  4 ++--
 drivers/gpu/drm/i915/intel_tv.c  |  8 
 drivers/gpu/drm/i915/intel_uncore.c  | 26 ++
 9 files changed, 81 insertions(+), 24 deletions(-)

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

[RFCv3 14/14] HACK: drm: allow FB's in drm_mode_object_find

[Rob Clark]

Ugg.. we do actually want to permit FB's in atomic case, since FB will
be looked up like any other object property value.

Currently we do the FB refcnt'ing dance in atomic->commit(), and would
rather not have to special case FB's or collect an FB ref when we look
up the property.  Not sure if it is better to rework the atomic FB
refcnt'ing or loosen this restriction?
---
 drivers/gpu/drm/drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8368ef5..f71f7af 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -405,7 +405,7 @@ struct drm_mode_object *drm_mode_object_find(struct 
drm_device *dev,

/* Framebuffers are reference counted and need their own lookup
 * function.*/
-   WARN_ON(type == DRM_MODE_OBJECT_FB);
+// WARN_ON(type == DRM_MODE_OBJECT_FB);

mutex_lock(>mode_config.idr_mutex);
obj = idr_find(>mode_config.crtc_idr, id);
-- 
1.8.4.2

[RFCv3 13/14] drm/msm: add atomic support

[Rob Clark]

TODO: probably can split this up into prep patch which splits the
msm_queue_fence_cb out of gem..
---
 drivers/gpu/drm/msm/Makefile |   1 +
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c |  48 +---
 drivers/gpu/drm/msm/mdp4/mdp4_kms.c  |   6 ++
 drivers/gpu/drm/msm/mdp4/mdp4_kms.h  |   1 +
 drivers/gpu/drm/msm/msm_atomic.c | 146 +++
 drivers/gpu/drm/msm/msm_drv.c|  22 +-
 drivers/gpu/drm/msm/msm_drv.h|   8 ++
 drivers/gpu/drm/msm/msm_gem.c|  24 +-
 drivers/gpu/drm/msm/msm_gem.h|  13 
 9 files changed, 218 insertions(+), 51 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/msm_atomic.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index e5fa12b..f7648d1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -18,6 +18,7 @@ msm-y := \
mdp4/mdp4_irq.o \
mdp4/mdp4_kms.o \
mdp4/mdp4_plane.o \
+   msm_atomic.o \
msm_drv.o \
msm_fb.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
index ba6ed7d..67c34d7 100644
--- a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
@@ -51,7 +51,6 @@ struct mdp4_crtc {

/* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
-   struct msm_fence_cb pageflip_cb;

 #define PENDING_CURSOR 0x1
 #define PENDING_FLIP   0x2
@@ -120,12 +119,16 @@ static void complete_flip(struct drm_crtc *crtc, struct 
drm_file *file)
spin_unlock_irqrestore(>event_lock, flags);
 }

-static void crtc_flush(struct drm_crtc *crtc)
+void mdp4_crtc_flush(struct drm_crtc *crtc)
 {
+   struct msm_drm_private *priv = crtc->dev->dev_private;
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct mdp4_kms *mdp4_kms = get_kms(crtc);
uint32_t i, flush = 0;

+   if (priv->pending_crtcs & (1 << crtc->id))
+   return;
+
for (i = 0; i < ARRAY_SIZE(mdp4_crtc->planes); i++) {
struct drm_plane *plane = mdp4_crtc->planes[i];
if (plane) {
@@ -148,23 +151,6 @@ static void request_pending(struct drm_crtc *crtc, 
uint32_t pending)
mdp4_irq_register(get_kms(crtc), _crtc->vblank);
 }

-static void pageflip_cb(struct msm_fence_cb *cb)
-{
-   struct mdp4_crtc *mdp4_crtc =
-   container_of(cb, struct mdp4_crtc, pageflip_cb);
-   struct drm_crtc *crtc = _crtc->base;
-   struct drm_framebuffer *fb = crtc->fb;
-
-   if (!fb)
-   return;
-
-   mdp4_plane_set_scanout(mdp4_crtc->plane, fb);
-   crtc_flush(crtc);
-
-   /* enable vblank to complete flip: */
-   request_pending(crtc, PENDING_FLIP);
-}
-
 static void unref_fb_worker(struct drm_flip_work *work, void *val)
 {
struct mdp4_crtc *mdp4_crtc =
@@ -374,7 +360,7 @@ static void mdp4_crtc_prepare(struct drm_crtc *crtc)
 static void mdp4_crtc_commit(struct drm_crtc *crtc)
 {
mdp4_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
-   crtc_flush(crtc);
+   mdp4_crtc_flush(crtc);
/* drop the ref to mdp clk's that we got in prepare: */
mdp4_disable(get_kms(crtc));
 }
@@ -405,23 +391,27 @@ static int mdp4_crtc_page_flip(struct drm_crtc *crtc,
 {
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct drm_device *dev = crtc->dev;
-   struct drm_gem_object *obj;
unsigned long flags;

+   spin_lock_irqsave(>event_lock, flags);
if (mdp4_crtc->event) {
+   spin_unlock_irqrestore(>event_lock, flags);
dev_err(dev->dev, "already pending flip!\n");
return -EBUSY;
}

-   obj = msm_framebuffer_bo(new_fb, 0);
-
-   spin_lock_irqsave(>event_lock, flags);
mdp4_crtc->event = event;
spin_unlock_irqrestore(>event_lock, flags);

update_fb(crtc, true, new_fb);

-   return msm_gem_queue_inactive_cb(obj, _crtc->pageflip_cb);
+   mdp4_plane_set_scanout(mdp4_crtc->plane, crtc->fb);
+   mdp4_crtc_flush(crtc);
+
+   /* enable vblank to complete flip: */
+   request_pending(crtc, PENDING_FLIP);
+
+   return 0;
 }

 static int mdp4_crtc_set_property(struct drm_crtc *crtc, void *state,
@@ -598,8 +588,8 @@ static void mdp4_crtc_err_irq(struct mdp4_irq *irq, 
uint32_t irqstatus)
 {
struct mdp4_crtc *mdp4_crtc = container_of(irq, struct mdp4_crtc, err);
struct drm_crtc *crtc = _crtc->base;
-   DBG("%s: error: %08x", mdp4_crtc->name, irqstatus);
-   crtc_flush(crtc);
+   DRM_ERROR("%s: error: %08x\n", mdp4_crtc->name, irqstatus);
+   mdp4_crtc_flush(crtc);
 }

 uint32_t mdp4_crtc_vblank(struct drm_crtc *crtc)
@@ -679,7 +669,7 @@ static void set_attach(struct drm_crtc *crtc, enum 
mdp4_pipe pipe_id,
mdp4_crtc->planes[pipe_id] = plane;
blend_setup(crtc);
if (mdp4_crtc->enabled && (plane != mdp4_crtc->plane))
- 

[RFCv3 12/14] drm: Atomic modeset ioctl

[Rob Clark]

From: Ville Syrj?l? 

The atomic modeset ioctl cna be used to push any number of new values
for object properties. The driver can then check the full device
configuration as single unit, and try to apply the changes atomically.

The ioctl simply takes a list of object IDs and property IDs and their
values. For setting values to blob properties, the property value
indicates the length of the data, and the actual data is passed via
another blob pointer.

The caller can demand non-blocking operation from the ioctl, and if the
driver can't satisfy that requirement an error will be returned.

The caller can also request to receive asynchronous completion events
after the operation has reached the hardware. An event is sent for each
object specified by the caller, whether or not the actual state of
that object changed. Each event also carries a framebuffer ID, which
indicates to user space that the specified object is no longer
accessing that framebuffer.

TODO: detailed error reporting?

v1: original
v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
v4: drop atomic event, align flags w/ pageflip (atomic flags should be
a strick superset of pageflip flags to keep things easier for the
drivers)

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c  | 157 +++-
 drivers/gpu/drm/drm_drv.c   |   1 +
 include/drm/drmP.h  |   6 ++
 include/drm/drm_crtc.h  |   2 +
 include/uapi/drm/drm.h  |  12 
 include/uapi/drm/drm_mode.h |  21 ++
 6 files changed, 198 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4b40a39..8368ef5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4037,7 +4037,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return -ENOENT;
crtc = obj_to_crtc(obj);

-   state = dev->driver->atomic_begin(dev, page_flip->flags);
+   state = dev->driver->atomic_begin(dev,
+   page_flip->flags | DRM_MODE_ATOMIC_NONBLOCK);
if (IS_ERR(state))
return PTR_ERR(state);

@@ -4451,3 +4452,157 @@ void drm_mode_config_cleanup(struct drm_device *dev)
idr_destroy(>mode_config.crtc_idr);
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);
+
+int drm_mode_atomic_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+   struct drm_mode_atomic *arg = data;
+   uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
long)(arg->objs_ptr);
+   uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
long)(arg->count_props_ptr);
+   uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
long)(arg->props_ptr);
+   uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
long)(arg->prop_values_ptr);
+   uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
long)(arg->blob_values_ptr);
+   unsigned int copied_objs = 0;
+   unsigned int copied_props = 0;
+   unsigned int copied_blobs = 0;
+   void *state;
+   int ret = 0;
+   unsigned int i, j;
+
+   if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS)
+   return -EINVAL;
+
+   /* can't test and expect an event at the same time. */
+   if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
+   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+   return -EINVAL;
+
+   state = dev->driver->atomic_begin(dev, arg->flags);
+   if (IS_ERR(state)) {
+   ret = PTR_ERR(state);
+   goto out;
+   }
+
+   for (i = 0; i < arg->count_objs; i++) {
+   uint32_t obj_id, count_props;
+   struct drm_mode_object *obj;
+
+   if (get_user(obj_id, objs_ptr + copied_objs)) {
+   ret = -EFAULT;
+   goto out;
+   }
+
+   obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
+   if (!obj || !obj->properties) {
+   ret = -ENOENT;
+   goto out;
+   }
+
+   if ((obj->type == DRM_MODE_OBJECT_CRTC) &&
+   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
+   struct drm_pending_vblank_event *e =
+   create_vblank_event(dev, file_priv, 
arg->user_data);
+   if (!e) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   ret = dev->driver->atomic_set_event(dev, state, obj, e);
+   if (ret) {
+   destroy_vblank_event(dev, file_priv, e);
+   goto out;
+   }
+   }
+
+   if (get_user(count_props, count_props_ptr + 

[RFCv3 11/14] drm: convert crtc to properties/state

[Rob Clark]

Break the mutable state of a crtc out into a separate structure
and use atomic properties mechanism to set crtc attributes.  This
makes it easier to have some helpers for crtc->set_property()
and for checking for invalid params.  The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.

This also re-works the locking a bit.. maybe some of these changes
should be rejuggled into different patch.  But now atomic plane updates
grab current (and if necessary, incoming) crtc locks for their
synchronization.
---
 drivers/gpu/drm/ast/ast_mode.c |   1 +
 drivers/gpu/drm/cirrus/cirrus_mode.c   |   1 +
 drivers/gpu/drm/drm_atomic_helper.c| 347 -
 drivers/gpu/drm/drm_crtc.c | 580 +
 drivers/gpu/drm/drm_fb_cma_helper.c|   9 +-
 drivers/gpu/drm/drm_fb_helper.c|  12 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   5 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c |   1 +
 drivers/gpu/drm/gma500/psb_drv.c   |   4 +-
 drivers/gpu/drm/gma500/psb_intel_display.c |   1 +
 drivers/gpu/drm/i915/intel_display.c   |  17 +-
 drivers/gpu/drm/i915/intel_fbdev.c |   6 +-
 drivers/gpu/drm/mgag200/mgag200_mode.c |   1 +
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c   |   5 +-
 drivers/gpu/drm/msm/msm_drv.c  |   7 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|   1 +
 drivers/gpu/drm/nouveau/nv50_display.c |   1 +
 drivers/gpu/drm/omapdrm/omap_crtc.c|  17 +-
 drivers/gpu/drm/omapdrm/omap_drv.c |   6 +-
 drivers/gpu/drm/qxl/qxl_display.c  |   2 +
 drivers/gpu/drm/radeon/radeon_display.c|   2 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |   2 +
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |   2 +
 drivers/gpu/drm/tegra/fb.c |   7 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |   1 +
 drivers/gpu/drm/udl/udl_modeset.c  |   2 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  12 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |   1 +
 include/drm/drm_atomic_helper.h|  41 ++
 include/drm/drm_crtc.h |  87 -
 include/drm/drm_fb_helper.h|   3 +-
 include/uapi/drm/drm_mode.h|   2 +
 34 files changed, 864 insertions(+), 327 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 7fc9f72..13f6943 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -619,6 +619,7 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
.cursor_move = ast_cursor_move,
.reset = ast_crtc_reset,
.set_config = drm_crtc_helper_set_config,
+   .set_property = drm_atomic_helper_crtc_set_property,
.gamma_set = ast_crtc_gamma_set,
.destroy = ast_crtc_destroy,
 };
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index adabc3d..9e0b713 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -363,6 +363,7 @@ static void cirrus_crtc_destroy(struct drm_crtc *crtc)
 static const struct drm_crtc_funcs cirrus_crtc_funcs = {
.gamma_set = cirrus_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
+   .set_property = drm_atomic_helper_crtc_set_property,
.destroy = cirrus_crtc_destroy,
 };

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0618113..aaab456 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -40,17 +40,22 @@ void *drm_atomic_helper_begin(struct drm_device *dev, 
uint32_t flags)
 {
struct drm_atomic_helper_state *state;
int nplanes = dev->mode_config.num_plane;
+   int ncrtcs  = dev->mode_config.num_crtc;
int sz;
void *ptr;

sz = sizeof(*state);
sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;
+   sz += (sizeof(state->crtcs) + sizeof(state->cstates)) * ncrtcs;

ptr = kzalloc(sz, GFP_KERNEL);

state = ptr;
ptr = [1];

+   ww_acquire_init(>ww_ctx, _ww_class);
+   INIT_LIST_HEAD(>locked_crtcs);
+
kref_init(>refcount);
state->dev = dev;
state->flags = flags;
@@ -61,6 +66,12 @@ void *drm_atomic_helper_begin(struct drm_device *dev, 
uint32_t flags)
state->pstates = ptr;
ptr = >pstates[nplanes];

+   state->crtcs = ptr;
+   ptr = >crtcs[ncrtcs];
+
+   state->cstates = ptr;
+   ptr = >cstates[ncrtcs];
+
return state;
 }
 EXPORT_SYMBOL(drm_atomic_helper_begin);
@@ -79,7 +90,16 @@ int drm_atomic_helper_set_event(struct drm_device *dev,
void *state, struct 

[RFCv3 10/14] drm: convert plane to properties/state

[Rob Clark]

Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes.  This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params.  The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.

The same should be done for CRTC, encoder, and connector, but this
patch only includes the first part (plane).
---
 drivers/gpu/drm/drm_atomic_helper.c | 137 +-
 drivers/gpu/drm/drm_crtc.c  | 399 +++-
 drivers/gpu/drm/drm_fb_helper.c |  17 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   4 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  13 +-
 drivers/gpu/drm/i915/intel_sprite.c |  21 +-
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c|   2 +-
 drivers/gpu/drm/msm/mdp4/mdp4_plane.c   |  18 +-
 drivers/gpu/drm/omapdrm/omap_crtc.c |   4 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  |   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|  30 ++-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   5 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_plane.c  |   6 +-
 include/drm/drm_atomic_helper.h |  37 ++-
 include/drm/drm_crtc.h  |  88 +-
 17 files changed, 607 insertions(+), 184 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 46c67b8..0618113 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -39,10 +39,12 @@
 void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags)
 {
struct drm_atomic_helper_state *state;
+   int nplanes = dev->mode_config.num_plane;
int sz;
void *ptr;

sz = sizeof(*state);
+   sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;

ptr = kzalloc(sz, GFP_KERNEL);

@@ -52,6 +54,13 @@ void *drm_atomic_helper_begin(struct drm_device *dev, 
uint32_t flags)
kref_init(>refcount);
state->dev = dev;
state->flags = flags;
+
+   state->planes = ptr;
+   ptr = >planes[nplanes];
+
+   state->pstates = ptr;
+   ptr = >pstates[nplanes];
+
return state;
 }
 EXPORT_SYMBOL(drm_atomic_helper_begin);
@@ -87,7 +96,19 @@ EXPORT_SYMBOL(drm_atomic_helper_set_event);
  */
 int drm_atomic_helper_check(struct drm_device *dev, void *state)
 {
-   return 0;  /* for now */
+   struct drm_atomic_helper_state *a = state;
+   int nplanes = dev->mode_config.num_plane;
+   int i, ret = 0;
+
+   for (i = 0; i < nplanes; i++) {
+   if (a->planes[i]) {
+   ret = drm_atomic_check_plane_state(a->planes[i], 
a->pstates[i]);
+   if (ret)
+   break;
+   }
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_check);

@@ -104,7 +125,19 @@ EXPORT_SYMBOL(drm_atomic_helper_check);
  */
 int drm_atomic_helper_commit(struct drm_device *dev, void *state)
 {
-   return 0;  /* for now */
+   struct drm_atomic_helper_state *a = state;
+   int nplanes = dev->mode_config.num_plane;
+   int i, ret = 0;
+
+   for (i = 0; i < nplanes; i++) {
+   if (a->planes[i]) {
+   ret = drm_atomic_commit_plane_state(a->planes[i], 
a->pstates[i]);
+   if (ret)
+   break;
+   }
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);

@@ -125,11 +158,111 @@ void _drm_atomic_helper_state_free(struct kref *kref)
 {
struct drm_atomic_helper_state *state =
container_of(kref, struct drm_atomic_helper_state, refcount);
+   struct drm_device *dev = state->dev;
+   int nplanes = dev->mode_config.num_plane;
+   int i;
+
+   for (i = 0; i < nplanes; i++) {
+   if (state->pstates[i]) {
+   state->planes[i]->state->state = NULL;
+   kfree(state->pstates[i]);
+   }
+   }
+
kfree(state);
 }
 EXPORT_SYMBOL(_drm_atomic_helper_state_free);

+int drm_atomic_helper_plane_set_property(struct drm_plane *plane, void *state,
+   struct drm_property *property, uint64_t val, void *blob_data)
+{
+   return drm_plane_set_property(plane,
+   drm_atomic_get_plane_state(plane, state),
+   property, val, blob_data);
+}
+EXPORT_SYMBOL(drm_atomic_helper_plane_set_property);
+
+void drm_atomic_helper_init_plane_state(struct drm_plane *plane,
+   struct drm_plane_state *pstate, void *state)
+{
+   /* snapshot current state: */
+   *pstate = *plane->state;
+

[RFCv3 09/14] drm: Refactor object property check code

[Rob Clark]

From: Ville Syrj?l? 

Refactor the code to check whether an object has a specific property
to a new function.

v1: original
v2: rebase on atomic -- Rob Clark
v3: EINVAL->ENOENT

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8fc2ab4..2f8ab02 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3427,6 +3427,19 @@ static int drm_mode_set_obj_prop(struct drm_mode_object 
*obj,
return -EINVAL;
 }

+static bool object_has_prop(const struct drm_mode_object *obj, u32 prop_id)
+{
+   int i;
+
+   if (!obj->properties)
+   return false;
+
+   for (i = 0; i < obj->properties->count; i++)
+   if (obj->properties->ids[i] == prop_id)
+   return true;
+   return false;
+}
+
 /* call with mode_config mutex held */
 static int drm_mode_set_obj_prop_id(struct drm_device *dev, void *state,
uint32_t obj_id, uint32_t obj_type,
@@ -3435,20 +3448,10 @@ static int drm_mode_set_obj_prop_id(struct drm_device 
*dev, void *state,
struct drm_mode_object *arg_obj;
struct drm_mode_object *prop_obj;
struct drm_property *property;
-   int i;

arg_obj = drm_mode_object_find(dev, obj_id, obj_type);
-   if (!arg_obj)
+   if (!(arg_obj && object_has_prop(arg_obj, prop_id)))
return -ENOENT;
-   if (!arg_obj->properties)
-   return -EINVAL;
-
-   for (i = 0; i < arg_obj->properties->count; i++)
-   if (arg_obj->properties->ids[i] == prop_id)
-   break;
-
-   if (i == arg_obj->properties->count)
-   return -EINVAL;

prop_obj = drm_mode_object_find(dev, prop_id,
DRM_MODE_OBJECT_PROPERTY);
-- 
1.8.4.2

[RFCv3 08/14] drm: Allow drm_mode_object_find() to look up an object of any type

[Rob Clark]

From: Ville Syrj?l? 

To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c | 3 ++-
 include/drm/drm_crtc.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b81baae..8fc2ab4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -362,7 +362,8 @@ struct drm_mode_object *drm_mode_object_find(struct 
drm_device *dev,

mutex_lock(>mode_config.idr_mutex);
obj = idr_find(>mode_config.crtc_idr, id);
-   if (!obj || (obj->type != type) || (obj->id != id))
+   if (!obj || (type != DRM_MODE_OBJECT_ANY && obj->type != type) ||
+   (obj->id != id))
obj = NULL;
mutex_unlock(>mode_config.idr_mutex);

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a18d240..0bdb8af 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -52,6 +52,7 @@ struct drm_object_property_values;
 #define DRM_MODE_OBJECT_BLOB 0x
 #define DRM_MODE_OBJECT_PLANE 0x
 #define DRM_MODE_OBJECT_BRIDGE 0xbdbdbdbd
+#define DRM_MODE_OBJECT_ANY 0

 struct drm_mode_object {
uint32_t id;
-- 
1.8.4.2

[RFCv3 07/14] drm: split propvals out and blob property support

[Rob Clark]

Split property values out into a different struct, so we can later
move property values into state structs.  This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.

And since we are touching all the same code, add support for mutable
blob properties, which will also be needed for atomic modeset.
---
 drivers/gpu/drm/drm_crtc.c  | 79 +
 drivers/gpu/drm/drm_fb_helper.c |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c   |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |  6 ++-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c   |  8 +--
 drivers/gpu/drm/gma500/psb_intel_lvds.c |  6 ++-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c | 19 +--
 drivers/gpu/drm/i2c/ch7006_drv.c|  4 +-
 drivers/gpu/drm/i915/intel_display.c|  3 +-
 drivers/gpu/drm/i915/intel_dp.c |  3 +-
 drivers/gpu/drm/i915/intel_hdmi.c   |  3 +-
 drivers/gpu/drm/i915/intel_sdvo.c   | 19 +--
 drivers/gpu/drm/i915/intel_tv.c |  6 ++-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |  3 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |  4 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  |  6 ++-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c   |  3 +-
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c|  3 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |  4 +-
 include/drm/drm_crtc.h  | 11 +++-
 21 files changed, 142 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 61ce72d..b81baae 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -90,6 +90,14 @@ void drm_warn_on_modeset_not_all_locked(struct drm_device 
*dev)
 }
 EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);

+static int drm_mode_set_obj_prop(struct drm_mode_object *obj,
+   void *state, struct drm_property *property,
+   uint64_t value, void *blob_data);
+static struct drm_property_blob *drm_property_create_blob(struct drm_device 
*dev,
+   int length, void *data);
+static void drm_property_destroy_blob(struct drm_device *dev,
+   struct drm_property_blob *blob);
+
 /* Avoid boilerplate.  I'm tired of typing. */
 #define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
@@ -644,6 +652,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
goto out;

crtc->base.properties = >properties;
+   crtc->base.propvals = >propvals;

list_add_tail(>head, >mode_config.crtc_list);
dev->mode_config.num_crtc++;
@@ -733,6 +742,7 @@ int drm_connector_init(struct drm_device *dev,
goto out;

connector->base.properties = >properties;
+   connector->base.propvals = >propvals;
connector->dev = dev;
connector->funcs = funcs;
connector->connector_type = connector_type;
@@ -906,6 +916,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
goto out;

plane->base.properties = >properties;
+   plane->base.propvals = >propvals;
plane->dev = dev;
plane->funcs = funcs;
plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
@@ -1712,7 +1723,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
goto out;
}

-   if (put_user(connector->properties.values[i],
+   if (put_user(connector->propvals.values[i],
 prop_values + copied)) {
ret = -EFAULT;
goto out;
@@ -3021,19 +3032,33 @@ void drm_object_attach_property(struct drm_mode_object 
*obj,
}

obj->properties->ids[count] = property->base.id;
-   obj->properties->values[count] = init_val;
+   obj->propvals->values[count] = init_val;
obj->properties->count++;
 }
 EXPORT_SYMBOL(drm_object_attach_property);

 int drm_object_property_set_value(struct drm_mode_object *obj,
- struct drm_property *property, uint64_t val)
+ struct drm_object_property_values *propvals,
+ struct drm_property *property, uint64_t val,
+ void *blob_data)
 {
int i;

for (i = 0; i < obj->properties->count; i++) {
if (obj->properties->ids[i] == property->base.id) {
-   obj->properties->values[i] = val;
+   struct drm_device *dev = property->dev;
+   if (property->flags & DRM_MODE_PROP_BLOB) {
+   struct drm_property_blob *blob, *old_blob = 
NULL;
+   old_blob = 

[RFCv3 06/14] drm: helpers to find mode objects

[Rob Clark]

Add a few more useful helpers to find mode objects.
---
 include/drm/drm_crtc.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a9b9977..d3abc9c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1170,6 +1170,15 @@ extern int drm_format_vert_chroma_subsampling(uint32_t 
format);
 extern const char *drm_get_format_name(uint32_t format);

 /* Helpers */
+
+static inline struct drm_plane *drm_plane_find(struct drm_device *dev,
+   uint32_t id)
+{
+   struct drm_mode_object *mo;
+   mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_PLANE);
+   return mo ? obj_to_plane(mo) : NULL;
+}
+
 static inline struct drm_crtc *drm_crtc_find(struct drm_device *dev,
uint32_t id)
 {
@@ -1186,4 +1195,20 @@ static inline struct drm_encoder 
*drm_encoder_find(struct drm_device *dev,
return mo ? obj_to_encoder(mo) : NULL;
 }

+static inline struct drm_connector *drm_connector_find(struct drm_device *dev,
+   uint32_t id)
+{
+   struct drm_mode_object *mo;
+   mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_CONNECTOR);
+   return mo ? obj_to_connector(mo) : NULL;
+}
+
+static inline struct drm_property_blob *
+drm_property_blob_find(struct drm_device *dev, uint32_t id)
+{
+   struct drm_mode_object *mo;
+   mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_BLOB);
+   return mo ? obj_to_blob(mo) : NULL;
+}
+
 #endif /* __DRM_CRTC_H__ */
-- 
1.8.4.2

[RFCv3 05/14] drm: add DRM_MODE_PROP_SIGNED property flag

[Rob Clark]

Flag for range property types indicating that the value is a signed
integer rather than unsigned.  For range properties, the signed flag
will trigger use of signed integer comparisions, to handle negative
values properly.
---
 drivers/gpu/drm/drm_crtc.c  | 15 +++
 include/drm/drm_crtc.h  |  9 +
 include/uapi/drm/drm_mode.h |  2 ++
 3 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4d33816..61ce72d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3263,11 +3263,18 @@ EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 static bool drm_property_change_is_valid(struct drm_property *property,
 uint64_t value)
 {
-   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   if (property->flags & DRM_MODE_PROP_IMMUTABLE) {
return false;
-   if (property->flags & DRM_MODE_PROP_RANGE) {
-   if (value < property->values[0] || value > property->values[1])
-   return false;
+   } else if (property->flags & DRM_MODE_PROP_RANGE) {
+   if (property->flags & DRM_MODE_PROP_SIGNED) {
+   int64_t svalue = U642I64(value);
+   if (svalue < U642I64(property->values[0]) ||
+   svalue > U642I64(property->values[1]))
+   return false;
+   } else {
+   if (value < property->values[0] || value > 
property->values[1])
+   return false;
+   }
return true;
} else if (property->flags & DRM_MODE_PROP_BITMASK) {
int i;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4141074..a9b9977 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -65,6 +65,15 @@ struct drm_object_properties {
uint64_t values[DRM_OBJECT_MAX_PROPERTY];
 };

+static inline int64_t U642I64(uint64_t val)
+{
+   return (int64_t)*((int64_t *));
+}
+static inline uint64_t I642U64(int64_t val)
+{
+   return (uint64_t)*((uint64_t *));
+}
+
 /*
  * Note on terminology:  here, for brevity and convenience, we refer to 
connector
  * control chips as 'CRTCs'.  They can control any type of connector, VGA, 
LVDS,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 536897a..9fed70e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -260,6 +260,8 @@ struct drm_mode_get_connector {
  * be changed dynamically, assuming the pixel format does not change.
  */
 #define DRM_MODE_PROP_DYNAMIC  (1<<24)
+/* Indicates that numeric property values are signed rather than unsigned: */
+#define DRM_MODE_PROP_SIGNED   (1<<25)

 struct drm_mode_property_enum {
__u64 value;
-- 
1.8.4.2

[RFCv3 04/14] drm: add DRM_MODE_PROP_DYNAMIC property flag

[Rob Clark]

This indicates to userspace that the property is something that can
be set dynamically without requiring a "test" step to check if the
hw is capable.  This allows a userspace compositor, such as weston,
to avoid an extra ioctl to check whether it needs to fall-back to
GPU to composite some surface prior to submission of GPU render
commands.
---
 include/uapi/drm/drm_mode.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 73cfd1e..536897a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -251,6 +251,15 @@ struct drm_mode_get_connector {
 #define DRM_MODE_PROP_BLOB (1<<4)
 #define DRM_MODE_PROP_BITMASK  (1<<5) /* bitmask of enumerated types */
 #define DRM_MODE_PROP_OBJECT   (1<<6) /* drm mode object */
+/* Properties that are not dynamic cannot safely be changed without a
+ * atomic-modeset / atomic-pageflip test step.  But if userspace is
+ * only changing dynamic properties, it is guaranteed that the change
+ * will not exceed hw limits, so no test step is required.
+ *
+ * Note that fb_id properties are a bit ambiguous.. they of course can
+ * be changed dynamically, assuming the pixel format does not change.
+ */
+#define DRM_MODE_PROP_DYNAMIC  (1<<24)

 struct drm_mode_property_enum {
__u64 value;
-- 
1.8.4.2

[RFCv3 03/14] drm: add object property type

[Rob Clark]

An object property is an id (idr) for a drm mode object.  This
will allow a property to be used set/get a framebuffer, CRTC, etc.
---
 drivers/gpu/drm/drm_crtc.c  | 34 ++
 include/drm/drm_crtc.h  | 10 ++
 include/uapi/drm/drm_mode.h |  1 +
 3 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 55f37db..4d33816 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2828,6 +2828,8 @@ struct drm_property *drm_property_create(struct 
drm_device *dev, int flags,
if (!property)
return NULL;

+   property->dev = dev;
+
if (num_values) {
property->values = kzalloc(sizeof(uint64_t)*num_values, 
GFP_KERNEL);
if (!property->values)
@@ -2931,6 +2933,23 @@ struct drm_property *drm_property_create_range(struct 
drm_device *dev, int flags
 }
 EXPORT_SYMBOL(drm_property_create_range);

+struct drm_property *drm_property_create_object(struct drm_device *dev,
+int flags, const char *name, uint32_t 
type)
+{
+   struct drm_property *property;
+
+   flags |= DRM_MODE_PROP_OBJECT;
+
+   property = drm_property_create(dev, flags, name, 1);
+   if (!property)
+   return NULL;
+
+   property->values[0] = type;
+
+   return property;
+}
+EXPORT_SYMBOL(drm_property_create_object);
+
 int drm_property_add_enum(struct drm_property *property, int index,
  uint64_t value, const char *name)
 {
@@ -3259,6 +3278,11 @@ static bool drm_property_change_is_valid(struct 
drm_property *property,
} else if (property->flags & DRM_MODE_PROP_BLOB) {
/* Only the driver knows */
return true;
+   } else if (property->flags & DRM_MODE_PROP_OBJECT) {
+   /* a zero value for an object property translates to null: */
+   if (value == 0)
+   return true;
+   return drm_property_get_obj(property, value) != NULL;
} else {
int i;
for (i = 0; i < property->num_values; i++)
@@ -3335,9 +3359,9 @@ static int drm_mode_plane_set_obj_prop(struct drm_plane 
*plane,
return ret;
 }

-static int drm_mode_set_obj_prop(struct drm_device *dev,
-   struct drm_mode_object *obj, void *state,
-   struct drm_property *property, uint64_t value, void *blob_data)
+static int drm_mode_set_obj_prop(struct drm_mode_object *obj,
+   void *state, struct drm_property *property, 
+   uint64_t value, void *blob_data)
 {
if (drm_property_change_is_valid(property, value)) {
switch (obj->type) {
@@ -3351,6 +3375,8 @@ static int drm_mode_set_obj_prop(struct drm_device *dev,
return drm_mode_plane_set_obj_prop(obj_to_plane(obj),
state, property, value, blob_data);
}
+   } else {
+   DRM_DEBUG("invalid value: %s = %llx\n", property->name, value);
}

return -EINVAL;
@@ -3385,7 +3411,7 @@ static int drm_mode_set_obj_prop_id(struct drm_device 
*dev, void *state,
return -ENOENT;
property = obj_to_property(prop_obj);

-   return drm_mode_set_obj_prop(dev, arg_obj, state, property,
+   return drm_mode_set_obj_prop(arg_obj, state, property, 
value, blob_data);
 }

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3650254..4141074 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -306,6 +306,7 @@ struct drm_property {
char name[DRM_PROP_NAME_LEN];
uint32_t num_values;
uint64_t *values;
+   struct drm_device *dev;

struct list_head enum_blob_list;
 };
@@ -1041,6 +1042,8 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max);
+struct drm_property *drm_property_create_object(struct drm_device *dev,
+int flags, const char *name, uint32_t 
type);
 extern void drm_property_destroy(struct drm_device *dev, struct drm_property 
*property);
 extern int drm_property_add_enum(struct drm_property *property, int index,
 uint64_t value, const char *name);
@@ -1059,6 +1062,13 @@ extern int drm_mode_crtc_set_gamma_size(struct drm_crtc 
*crtc,
 int gamma_size);
 extern struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
uint32_t id, uint32_t type);
+
+static inline struct drm_mode_object *
+drm_property_get_obj(struct drm_property *property, uint64_t value)
+{
+   return 

[RFCv3 02/14] drm: convert crtc to ww_mutex

[Rob Clark]

At the moment, this doesn't do anything.  But for atomic we will have an
ww_acquire_ctx associated with the state, to simplify the locking and
avoid potential deadlock when we cannot control the locking order.
---
 drivers/gpu/drm/drm_crtc.c   | 20 +++-
 drivers/gpu/drm/i915/intel_display.c | 16 
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 10 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 12 
 include/drm/drm_crtc.h   |  3 ++-
 5 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 81ac351..55f37db 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -52,7 +52,7 @@ void drm_modeset_lock_all(struct drm_device *dev)
mutex_lock(>mode_config.mutex);

list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   mutex_lock_nest_lock(>mutex, >mode_config.mutex);
+   mutex_lock_nest_lock(>mutex.base, 
>mode_config.mutex);
 }
 EXPORT_SYMBOL(drm_modeset_lock_all);

@@ -65,7 +65,7 @@ void drm_modeset_unlock_all(struct drm_device *dev)
struct drm_crtc *crtc;

list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   mutex_unlock(>mutex);
+   ww_mutex_unlock(>mutex);

mutex_unlock(>mode_config.mutex);
 }
@@ -84,7 +84,7 @@ void drm_warn_on_modeset_not_all_locked(struct drm_device 
*dev)
return;

list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   WARN_ON(!mutex_is_locked(>mutex));
+   WARN_ON(!ww_mutex_is_locked(>mutex));

WARN_ON(!mutex_is_locked(>mode_config.mutex));
 }
@@ -613,6 +613,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
 }
 EXPORT_SYMBOL(drm_framebuffer_remove);

+static DEFINE_WW_CLASS(crtc_ww_class);
+
 /**
  * drm_crtc_init - Initialise a new CRTC object
  * @dev: DRM device
@@ -634,8 +636,8 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
crtc->invert_dimensions = false;

drm_modeset_lock_all(dev);
-   mutex_init(>mutex);
-   mutex_lock_nest_lock(>mutex, >mode_config.mutex);
+   ww_mutex_init(>mutex, _ww_class);
+   mutex_lock_nest_lock(>mutex.base, >mode_config.mutex);

ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_CRTC);
if (ret)
@@ -2284,7 +2286,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
crtc = obj_to_crtc(obj);

-   mutex_lock(>mutex);
+   ww_mutex_lock(>mutex, NULL);
if (req->flags & DRM_MODE_CURSOR_BO) {
if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
ret = -ENXIO;
@@ -2308,7 +2310,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
}
 out:
-   mutex_unlock(>mutex);
+   ww_mutex_unlock(>mutex);

return ret;

@@ -3657,7 +3659,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return -ENOENT;
crtc = obj_to_crtc(obj);

-   mutex_lock(>mutex);
+   ww_mutex_lock(>mutex, NULL);
if (crtc->fb == NULL) {
/* The framebuffer is currently unbound, presumably
 * due to a hotplug event, that userspace has not
@@ -3741,7 +3743,7 @@ out:
drm_framebuffer_unreference(fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
-   mutex_unlock(>mutex);
+   ww_mutex_unlock(>mutex);

return ret;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3cddd50..741188f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2232,11 +2232,11 @@ void intel_display_handle_reset(struct drm_device *dev)
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);

-   mutex_lock(>mutex);
+   ww_mutex_lock(>mutex, NULL);
if (intel_crtc->active)
dev_priv->display.update_plane(crtc, crtc->fb,
   crtc->x, crtc->y);
-   mutex_unlock(>mutex);
+   ww_mutex_unlock(>mutex);
}
 }

@@ -7550,7 +7550,7 @@ bool intel_get_load_detect_pipe(struct drm_connector 
*connector,
if (encoder->crtc) {
crtc = encoder->crtc;

-   mutex_lock(>mutex);
+   ww_mutex_lock(>mutex, NULL);

old->dpms_mode = connector->dpms;
old->load_detect_temp = false;
@@ -7581,7 +7581,7 @@ bool intel_get_load_detect_pipe(struct drm_connector 
*connector,
return false;
}

-   mutex_lock(>mutex);
+   ww_mutex_lock(>mutex, NULL);
intel_encoder->new_crtc = to_intel_crtc(crtc);
to_intel_connector(connector)->new_encoder = intel_encoder;

@@ -7609,7 +7609,7 @@ bool 

[RFCv3 01/14] drm: add atomic fxns

[Rob Clark]

The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically.  This will be the basis of atomic-
modeset and nuclear-pageflip.

The basic flow is:

   state = dev->atomic_begin();
   for (... one or more ...)
  obj->set_property(obj, state, prop, value);
   if (dev->atomic_check(state))
  dev->atomic_commit(state);
   dev->atomic_end(state);

The split of check and commit steps is to allow for ioctls with a
test-only flag (which would skip the commit step).
---
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/ast/ast_drv.c   |   6 ++
 drivers/gpu/drm/ast/ast_drv.h   |   1 +
 drivers/gpu/drm/cirrus/cirrus_drv.c |   6 ++
 drivers/gpu/drm/cirrus/cirrus_drv.h |   1 +
 drivers/gpu/drm/drm_atomic_helper.c | 135 ++
 drivers/gpu/drm/drm_crtc.c  | 141 +---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   7 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c  |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c   |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |   4 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c   |   4 +-
 drivers/gpu/drm/gma500/psb_drv.c|   7 ++
 drivers/gpu/drm/gma500/psb_drv.h|   1 +
 drivers/gpu/drm/gma500/psb_intel_drv.h  |   4 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c |   4 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.c |   8 ++
 drivers/gpu/drm/i915/intel_crt.c|   4 +-
 drivers/gpu/drm/i915/intel_dp.c |   4 +-
 drivers/gpu/drm/i915/intel_drv.h|   1 +
 drivers/gpu/drm/i915/intel_hdmi.c   |   4 +-
 drivers/gpu/drm/i915/intel_lvds.c   |   4 +-
 drivers/gpu/drm/i915/intel_sdvo.c   |   4 +-
 drivers/gpu/drm/i915/intel_tv.c |   5 +-
 drivers/gpu/drm/mgag200/mgag200_drv.c   |   7 ++
 drivers/gpu/drm/mgag200/mgag200_drv.h   |   1 +
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c|   4 +-
 drivers/gpu/drm/msm/mdp4/mdp4_plane.c   |   4 +-
 drivers/gpu/drm/msm/msm_drv.c   |   6 ++
 drivers/gpu/drm/msm/msm_drv.h   |   1 +
 drivers/gpu/drm/nouveau/dispnv04/overlay.c  |   8 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |   3 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |   7 ++
 drivers/gpu/drm/nouveau/nouveau_drm.h   |   1 +
 drivers/gpu/drm/omapdrm/omap_crtc.c |   7 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  |   6 ++
 drivers/gpu/drm/omapdrm/omap_drv.h  |   5 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|   4 +-
 drivers/gpu/drm/qxl/qxl_display.c   |   4 +-
 drivers/gpu/drm/qxl/qxl_drv.c   |   9 ++
 drivers/gpu/drm/radeon/radeon_connectors.c  |   9 +-
 drivers/gpu/drm/radeon/radeon_drv.c |   9 ++
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   |   7 ++
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   4 +-
 drivers/gpu/drm/shmobile/shmob_drm_drv.c|   7 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c |   6 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h |   1 +
 drivers/gpu/drm/tilcdc/tilcdc_slave.c   |   3 +-
 drivers/gpu/drm/udl/udl_connector.c |   6 +-
 drivers/gpu/drm/udl/udl_drv.c   |   8 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |   7 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   4 +-
 include/drm/drmP.h  |  77 +++
 include/drm/drm_atomic_helper.h | 100 
 include/drm/drm_crtc.h  |  14 +--
 61 files changed, 622 insertions(+), 104 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_atomic_helper.c
 create mode 100644 include/drm/drm_atomic_helper.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index cc08b84..4a2e320 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,7 +13,8 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
-   drm_rect.o drm_vma_manager.o drm_flip_work.o
+   drm_rect.o drm_vma_manager.o drm_flip_work.o \
+   drm_atomic_helper.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5137f15..90ba5f1 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -216,6 +216,12 @@ static struct drm_driver driver = {
.dumb_map_offset = 

[RFCv3 00/14] Atomic/nuclear modeset/pageflip

[Rob Clark]

Yet another installment of atomic/nuclear modeset/pageflip.  Sorry it
took a while since the previous iteration, other tasks came up.  But
I hope to not be interrupted so much, because I don't want to spend
the rest of my life rebasing this patchset ;-)

Compared to previous version, I've converted the crtc lock to ww_mutex.
It is not yet used for the drm_modeset_lock_all() path, due to no
ww version of mutex_lock_nest_lock().. but lock_all() should not be
used in any atomic code path.

Now drm_modeset_lock_crtc() depends on 'struct drm_atomic_helper_state',
so either I need to decide that it is sufficient for all drivers to use
or extend 'struct drm_atomic_helper_state' (and drop 'helper' from the
name), or add a new driver vfunc(s) to get ww_ctx from state and manage
the list of locked crtcs.  So please speak up if you think you need to
completely replace the atomic helpers, because otherwise I don't think
it is worth the extra complexity/indirection.

There is one slight oddity.. for NONBLOCK atomic updates we would end
up needing to hold locks aquired in userspace thread calling in to
ioctl, and potentially release them later from drivers worker thread
when rendering is complete.  Which is obviously a no-go.  What is
done instead is to drop the locks in atomic->end() and re-aquire them
(if needed) when the driver calls back drm_atomic_helper_commit().
I am thinking that we probably want to add to 'struct drm_device'
bitmasks of pending crtc/planes to protect against a synchronous
atomic update while there is a pending async update.

And finally, I need to go back and flesh out the error propagation, in
case of EDEADLK, and do some testing with deadlock injection.

Oh, and I might either squash 'drm: convert crtc to ww_mutex' into one
of the later patches, or try to figure out a better way to split out
the mutex->ww_mutex change.  Splitting it out from 'drm: convert crtc
to properties/state' the way it currently is didn't really add much
benefit.

-

Description from original RFC (with updated links):

This patchset is the merging of Ville's atomic modeset ioctl, and
the drm_{crtc,plane}_state stuff from my original nuclear pageflip
RFC.

It is currently working on msm with an updated version of Ville's
glplane test app (removing cursor properties and atomic event):

  https://github.com/robclark/glplane

the libdrm bits can be found here:

  https://github.com/robclark/libdrm/commits/atomic

The msm part is on top of msm-next, the complete branch can be found:

  http://cgit.freedesktop.org/~robclark/linux/log/?h=global-thermonuclear-war-4

Compared to my earlier nuclear pageflip RFC, there is now a set of
drm_atomic helpers which do most of the non-hw-specific work for
the different drivers.

Unlike the crtc helpers, it is intended that the atomic helpers can
be used piecemeal by the drivers, either using all or overriding
parts as needed.

A naive driver, with no special constraints or hw support for atomic
updates may simply add the following to their driver struct:

.atomic_begin = drm_atomic_helper_begin,
.atomic_set_event = drm_atomic_helper_set_event,
.atomic_check = drm_atomic_helper_check,
.atomic_commit= drm_atomic_helper_commit,
.atomic_end   = drm_atomic_helper_end,
.atomic_helpers   = _atomic_helper_funcs,

In addition, if you're plane/crtc doesn't already have it's own
custom properties, then add to your plane/crtc_funcs:

.set_property = drm_atomic_helper_{plane,crtc}_set_property,

A driver which can have (for example) conflicting modes across
multiple crtcs (for example, bandwidth limitations or clock/pll
configuration restrictions), can wrap drm_atomic_helper_check()
with their own driver specific .atomic_check() function.

A driver which can support true atomic updates can wrap
drm_atomic_helper_commit().

A driver with custom properties should override the appropriate
get_state(), check_state(), and commit_state() functions in
.atomic_helpers if it uses the drm-atomic-helpers.  Otherwise it
is free to use _atomic_helper_funcs as-is.

Rob Clark (11):
  drm: add atomic fxns
  drm: convert crtc to ww_mutex
  drm: add object property type
  drm: add DRM_MODE_PROP_DYNAMIC property flag
  drm: add DRM_MODE_PROP_SIGNED property flag
  drm: helpers to find mode objects
  drm: split propvals out and blob property support
  drm: convert plane to properties/state
  drm: convert crtc to properties/state
  drm/msm: add atomic support
  HACK: drm: allow FB's in drm_mode_object_find

Ville Syrj?l? (3):
  drm: Allow drm_mode_object_find() to look up an object of any type
  drm: Refactor object property check code
  drm: Atomic modeset ioctl

 drivers/gpu/drm/Makefile|3 +-
 drivers/gpu/drm/ast/ast_drv.c   |6 +
 drivers/gpu/drm/ast/ast_drv.h   |1 +
 drivers/gpu/drm/ast/ast_mode.c  |1 +
 

[PATCH] drm/vma-manager: Don't unmap COW'd pages when zapping bo ptes

[Daniel Vetter]

On Wed, Nov 20, 2013 at 01:55:49AM -0800, Thomas Hellstrom wrote:
> Not sure if there are any user-space users of private bo mappings, but
> if there are, or will be, zapping the COW'd pages when, for example,
> moving a bo would confuse the user immensely since the net effect for the
> user would be that pages written to would lose their contents.
> 
> Signed-off-by: Thomas Hellstrom 

Presuming I'm not horribly confused about that all the vm slang in the
kerneldoc means this changes is

Reviewed-by: Daniel Vetter 

Now I still hold that userspace creating anynomous bo mappings is rather
crazy, but meh ;-) I guess the real question is whether we have anyone
relying on this out there (or planing to), in which case we either need to
funnel this through stable kernels or whack a drm feature flag onto
drivers/kernels with this fixed. But I seriously hope the answer is no.

Cheers, Daniel
> ---
>  include/drm/drm_vma_manager.h |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> index c18a593..347077d 100644
> --- a/include/drm/drm_vma_manager.h
> +++ b/include/drm/drm_vma_manager.h
> @@ -231,9 +231,9 @@ static inline void drm_vma_node_unmap(struct 
> drm_vma_offset_node *node,
> struct address_space *file_mapping)
>  {
>   if (file_mapping && drm_vma_node_has_offset(node))
> - unmap_mapping_range(file_mapping,
> - drm_vma_node_offset_addr(node),
> - drm_vma_node_size(node) << PAGE_SHIFT, 1);
> + unmap_shared_mapping_range
> + (file_mapping, drm_vma_node_offset_addr(node),
> +  drm_vma_node_size(node) << PAGE_SHIFT);
>  }
>  
>  /**
> -- 
> 1.7.10.4
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 45121] [TRIVIAL]Not all PCIID 1002:68e1 are Mobility

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

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

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 50881] [TRIVIAL]Error compiling nouveau inside the kernel (not as a module) when ACPI is a module

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

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

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 71812] VDPAU: MPEG-4 ASP Garbling/Corruption

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

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

--- Comment #6 from Alex Deucher  ---
(In reply to comment #5)
> Also; was I right to have posted this in Drivers/Gallium/r600 as opposed to
> Drivers/DRI/R600 ?

Yes.  Gallium/R600 is 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/20131120/03178b06/attachment.html>

[Bug 46161] [BISECTED]divide error on radeon modprobe

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

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

--- Comment #6 from Brad  Jackson  ---
It was fixed in one of the releases shortly after I reported it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 46161] [BISECTED]divide error on radeon modprobe

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #5 from Alex Deucher  ---
Can you try a newer kernel, I believe this should be fixed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 45121] [TRIVIAL]Not all PCIID 1002:68e1 are Mobility

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
dpm is enabled by default in 3.13 and obsoletes the old pm methods.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 69321] starting openCL crashes/boots system

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

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

--- Comment #9 from udo  ---
Yes, at least the immediate boot does not occur.
Thanks for the patch!

-- 
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/20131120/086566d4/attachment-0001.html>

[pull] radeon fixes 3.13

[Alex Deucher]

Hi Dave,

More fixes for radeon.  This adds new queries for tiling on CIK, and
fixes a crash in handling acpi atif backlight events on CIK.

The following changes since commit 3a118989d58ca9b99f56f16a6fccbe34a9d8047e:

  drm/radeon: enable DPM by default in TN asics (2013-11-15 15:57:38 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.13

for you to fetch changes up to 7272c9d2286525d4c6bce788243cf2b6f306d15c:

  drm/radeon: hook up backlight functions for CI and KV family. (2013-11-19 
15:57:29 -0500)


Michel D?nzer (2):
  drm/radeon/cik: Return backend map information to userspace
  drm/radeon/cik: Add macrotile mode array query

Samuel Li (1):
  drm/radeon: hook up backlight functions for CI and KV family.

 drivers/gpu/drm/radeon/cik.c |  3 +++
 drivers/gpu/drm/radeon/radeon.h  |  1 +
 drivers/gpu/drm/radeon/radeon_asic.c |  4 
 drivers/gpu/drm/radeon/radeon_drv.c  |  3 ++-
 drivers/gpu/drm/radeon/radeon_kms.c  | 11 ++-
 include/uapi/drm/radeon_drm.h|  2 ++
 6 files changed, 22 insertions(+), 2 deletions(-)

[PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation

[Jean-Francois Moine]

On Wed, 20 Nov 2013 10:09:59 +
Mark Brown  wrote:

> On Wed, Nov 20, 2013 at 10:23:42AM +0100, Jean-Francois Moine wrote:
> 
> > But now, I am wondering again about these `empty`codecs:
> > - in a DT context, should we continue to add / modify such codecs?
> > - what do you think about my generic DT codec? (indeed, I would do a new
> >   version according to the previous remarks)
> 
> We still want to be able to have users just name the CODEC on their
> board rather than have to type in all the details from the datasheet,
> if we're going to try to amalgamate the drivers it should still let
> people do that.

OK. But it seems to me that the codec is not tied to the board, but
rather to the audio connector / transmitter.

In the case of the tda998x HDMI transmitter, either i2s or s/pdif may
be used, thanks to the actual codecs 'hdmi' and 'spdif tx'. But they
don't work the same way: the 'hdmi' codec handles both playback and
record, and recording is disabled by program in the sound device,
while the 'spdif tx' codec is selected by the codec-dai-name
("dit-hifi" - it is "dir-hifi" for recording). It would be nice if
these codecs would have the same behaviour...

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation

[Mark Brown]

On Wed, Nov 20, 2013 at 01:34:58PM +0100, Jean-Francois Moine wrote:
> Mark Brown  wrote:

> > We still want to be able to have users just name the CODEC on their
> > board rather than have to type in all the details from the datasheet,
> > if we're going to try to amalgamate the drivers it should still let
> > people do that.

> OK. But it seems to me that the codec is not tied to the board, but
> rather to the audio connector / transmitter.

No, not at all.  The majority of these devices are simple CODECs, DACs
and ADCs with no register control which are soldered down onto the
board.  What's connected beyond them is irrelevant.  If anything the
devices that don't have fixed functions are even more likely to want or
need to have specific code, for example code could be written to enforce
the results of HDMI capability discovery.

> In the case of the tda998x HDMI transmitter, either i2s or s/pdif may
> be used, thanks to the actual codecs 'hdmi' and 'spdif tx'. But they
> don't work the same way: the 'hdmi' codec handles both playback and
> record, and recording is disabled by program in the sound device,
> while the 'spdif tx' codec is selected by the codec-dai-name
> ("dit-hifi" - it is "dir-hifi" for recording). It would be nice if
> these codecs would have the same behaviour...

Well, send patches refactoring one or the other then...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131120/14f218c0/attachment.pgp>

[Bug 15850] Switcheroo: LVDS on radeon not working after suspend

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

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

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |OBSOLETE

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 15779] [radeon X1300 KMS] infinite atombios loop on Xorg startup

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

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

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |OBSOLETE

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 71816] Sacred: Gold Edition does not work with radeonsi

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

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

--- Comment #2 from darkbasic  ---
Program received signal SIGABRT, Aborted.
0x7fa80bcfacd9 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x7fa80bcfacd9 in raise () from /lib64/libc.so.6
#1  0x7fa80bcfc0d8 in abort () from /lib64/libc.so.6
#2  0x7fa80bcf3e06 in ?? () from /lib64/libc.so.6
#3  0x7fa80bcf3eb2 in __assert_fail () from /lib64/libc.so.6
#4  0x7fa80a97067c in ?? () from /usr/lib64/libglamor.so.0
#5  0x7fa80a977434 in ?? () from /usr/lib64/libglamor.so.0
#6  0x7fa80a97854c in ?? () from /usr/lib64/libglamor.so.0
#7  0x7fa80a978d2e in ?? () from /usr/lib64/libglamor.so.0
#8  0x7fa80a9798bd in ?? () from /usr/lib64/libglamor.so.0
#9  0x005696cb in ?? ()
#10 0x0055c801 in CompositePicture ()
#11 0x0055e467 in ?? ()
#12 0x00561b89 in ?? ()
#13 0x00437853 in ?? ()
#14 0x004283dd in _start ()


Uhm... it isn't of much use :(

I compiled with -O0 -g3 and I enabled debug in xorg-server, xf86-video-ati,
glamor and mesa. Why do I still lack 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/20131120/b6d051b5/attachment.html>

[patch] drm/nouveau/disp: add a comment on confusing loop

[walter harms]

Am 13.11.2013 08:45, schrieb Dan Carpenter:
> The "ret = -EIO" is deliberate.  It's a very uncommon thing to do and it
> upsets static checkers because they normally would expect "ret == -EIO".
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> index 1bd4c63..2bc45ae 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> @@ -322,6 +322,7 @@ nouveau_dp_train(struct nouveau_disp *disp, const struct 
> nouveau_dp_func *func,
>   while (*link_bw > (dp->dpcd[1] * 27000))
>   link_bw++;
>  
> + /* set ret to -EIO on the last loop iteration */
>   while ((ret = -EIO) && link_bw[0]) {
>   /* find minimum required lane count at this link rate */
>   dp->link_nr = dp->dpcd[2] & DPCD_RC02_MAX_LANE_COUNT;


It is sensible to do so now,
but in the long runs it pays to rewrite that as it confuses not only
static checkers but also the brains of people trying to understand
the code.

just my 2 cents,
re,
 wh

[PULL] ttm-fixes-3.13

[Thomas Hellstrom]

Hi, Dave!

The set_need_resched() removal fix and yet another fix in
ttm_bo_move_memcpy().

The following changes since commit a3483353ca4e6dbeef2ed62ebed01af109b5b27a:

  drm: check for !kdev in drm_unplug_minor() (2013-11-15 20:49:02 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux ttm-fixes-3.13

for you to fetch changes up to c58f009e01c918717379c206a63baa66f56a77f9:

  drm/ttm: Remove set_need_resched from the ttm fault handler (2013-11-20 
03:46:54 -0800)


Thomas Hellstrom (2):
  drm/ttm: Don't move non-existing data
  drm/ttm: Remove set_need_resched from the ttm fault handler

 drivers/gpu/drm/ttm/ttm_bo.c  |   35 ++-
 drivers/gpu/drm/ttm/ttm_bo_util.c |7 +--
 drivers/gpu/drm/ttm/ttm_bo_vm.c   |   26 --
 include/drm/ttm/ttm_bo_api.h  |4 +++-
 4 files changed, 62 insertions(+), 10 deletions(-)

[PULL] vmwgfx-fixes-3.13

[Thomas Hellstrom]

Hi, Dave.

Below is a fix for a false lockep warning,
and the vmwgfx prime implementation.

The following changes since commit a3483353ca4e6dbeef2ed62ebed01af109b5b27a:

  drm: check for !kdev in drm_unplug_minor() (2013-11-15 20:49:02 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-3.13

for you to fetch changes up to c486d4f894d7c7d0e4148426360aa354384f6dc8:

  drm/vmwgfx: Make vmwgfx dma buffers prime aware (2013-11-18 04:12:24 -0800)


Thomas Hellstrom (6):
  drm/ttm: Allow execbuf util reserves without ticket
  drm/vmwgfx: Fix false lockdep warning
  drm/ttm: Add a minimal prime implementation for ttm base objects
  drm/vmwgfx: Hook up the prime ioctls
  drm/vmwgfx: Make surfaces prime-aware
  drm/vmwgfx: Make vmwgfx dma buffers prime aware

 drivers/gpu/drm/ttm/ttm_execbuf_util.c   |   32 ++--
 drivers/gpu/drm/ttm/ttm_object.c |  254 +-
 drivers/gpu/drm/vmwgfx/Makefile  |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |7 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   14 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c|  137 
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   63 
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |   30 ++--
 include/drm/ttm/ttm_execbuf_util.h   |3 +-
 include/drm/ttm/ttm_object.h |   61 ++-
 10 files changed, 533 insertions(+), 70 deletions(-)
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c

[PATCH] drm/vma-manager: Don't unmap COW'd pages when zapping bo ptes

[Thomas Hellstrom]

On 11/20/2013 11:14 AM, David Herrmann wrote:
> Hi
>
> On Wed, Nov 20, 2013 at 10:55 AM, Thomas Hellstrom
>  wrote:
>> Not sure if there are any user-space users of private bo mappings, but
>> if there are, or will be, zapping the COW'd pages when, for example,
>> moving a bo would confuse the user immensely since the net effect for the
>> user would be that pages written to would lose their contents.
> You're only talking about moving bos, but what happens when you evict
> a bo? You *must* clear COW mappings, too. Otherwise, they might still
> get read-access to the evicted bo.

Hmm. When I talk about COW'd pages, I mean individual anonymous pages.
If there is a COW mapping left in a VMA, it points to an anonymous page 
and will never access the evicted bo.
All (read-only-enabled) ptes pointing to the evicted bo would still be 
zapped, so I'm afraid I don't understand your comment?

>
> Note that we currently cause SIGBUS on access to mmap'd bos if they
> are evicted and cannot be restored (think: user-space mapped the
> VESA-FB but a real driver took over). So maybe we want two independent
> helpers here?
It shouldn't be needed.

Thanks,
Thomas


>
> Thanks
> David
>
>> Signed-off-by: Thomas Hellstrom 
>> ---
>>   include/drm/drm_vma_manager.h |6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
>> index c18a593..347077d 100644
>> --- a/include/drm/drm_vma_manager.h
>> +++ b/include/drm/drm_vma_manager.h
>> @@ -231,9 +231,9 @@ static inline void drm_vma_node_unmap(struct 
>> drm_vma_offset_node *node,
>>struct address_space *file_mapping)
>>   {
>>  if (file_mapping && drm_vma_node_has_offset(node))
>> -   unmap_mapping_range(file_mapping,
>> -   drm_vma_node_offset_addr(node),
>> -   drm_vma_node_size(node) << PAGE_SHIFT, 
>> 1);
>> +   unmap_shared_mapping_range
>> +   (file_mapping, drm_vma_node_offset_addr(node),
>> +drm_vma_node_size(node) << PAGE_SHIFT);
>>   }
>>
>>   /**
>> --
>> 1.7.10.4

[PATCH] drm/vma-manager: Don't unmap COW'd pages when zapping bo ptes

[David Herrmann]

Hi

On Wed, Nov 20, 2013 at 10:55 AM, Thomas Hellstrom
 wrote:
> Not sure if there are any user-space users of private bo mappings, but
> if there are, or will be, zapping the COW'd pages when, for example,
> moving a bo would confuse the user immensely since the net effect for the
> user would be that pages written to would lose their contents.

You're only talking about moving bos, but what happens when you evict
a bo? You *must* clear COW mappings, too. Otherwise, they might still
get read-access to the evicted bo.

Note that we currently cause SIGBUS on access to mmap'd bos if they
are evicted and cannot be restored (think: user-space mapped the
VESA-FB but a real driver took over). So maybe we want two independent
helpers here?

Thanks
David

> Signed-off-by: Thomas Hellstrom 
> ---
>  include/drm/drm_vma_manager.h |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> index c18a593..347077d 100644
> --- a/include/drm/drm_vma_manager.h
> +++ b/include/drm/drm_vma_manager.h
> @@ -231,9 +231,9 @@ static inline void drm_vma_node_unmap(struct 
> drm_vma_offset_node *node,
>   struct address_space *file_mapping)
>  {
> if (file_mapping && drm_vma_node_has_offset(node))
> -   unmap_mapping_range(file_mapping,
> -   drm_vma_node_offset_addr(node),
> -   drm_vma_node_size(node) << PAGE_SHIFT, 1);
> +   unmap_shared_mapping_range
> +   (file_mapping, drm_vma_node_offset_addr(node),
> +drm_vma_node_size(node) << PAGE_SHIFT);
>  }
>
>  /**
> --
> 1.7.10.4

[PATCH 00/31] ARM: tegra: use common reset and DMA bindings

[Stephen Warren]

On 11/20/2013 10:03 AM, Arnd Bergmann wrote:
> On Wednesday 20 November 2013, Stephen Warren wrote:
>>> +- #iommu-cells : Must be <1>. This dictates the length of DMA specifiers in
>>> +  client nodes' dmas properties. The specifier represents the DMA request
>>> +  select value for the peripheral. For more details, consult the Tegra 
>>> TRM's
>>> +  documentation of the APB DMA channel control register REQ_SEL field.
>>>  
>>>  Examples:
>>>  
>>> @@ -36,4 +40,5 @@ apbdma: dma at 6000a000 {
>>>   clocks = <_car 34>;
>>>   resets = <_car 34>;
>>>   reset-names = "dma";
>>> + #iommu-cells = <1>;
> 
> 
> s/iommu/dma/
> 
> Otherwise looks good. The dts files are correct, so I guess it's just
> a typo here.

Thanks, fixed locally.

[PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation

[Jean-Francois Moine]

On Tue, 19 Nov 2013 14:12:24 +0200
Jyri Sarha  wrote:

> Signed-off-by: Jyri Sarha 
> ---
>  Documentation/devicetree/bindings/sound/hdmi.txt |   17 +
>  sound/soc/codecs/hdmi.c  |   10 ++
>  2 files changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt
[snip]

A couple of months ago, I proposed a 'generic DT based simple
codec' (http://www.spinics.net/lists/arm-kernel/msg274322.html) which
was supposed to replace all of the `empty` codecs in a DT context.
These codecs do nothing except defining some audio parameters.
They are mainly spdif tx/rx, hdmi, bt-sco, dmic, wm8727 and wm8782.

This generic codec would have been used for the tda998x which is the
HDMI transmitter of the Cubox. But, as its utility was not clear yet,
I switched to the 'spdif transmitter' codec which has DT support. This
last codec works fine without change, with either i2s or spdif input in
the tda998x. It is well suited to the Cubox because the Marvell Armada
510 audio subsystem does not support sound recording (nor does the
tda998x while the 'hdmi' code provides recording), and also because it
supports a wider range of rates than the 'hdmi'codec (I have no problem
with 22.05kHz audio).

But now, I am wondering again about these `empty`codecs:
- in a DT context, should we continue to add / modify such codecs?
- what do you think about my generic DT codec? (indeed, I would do a new
  version according to the previous remarks)

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation

[Mark Brown]

On Wed, Nov 20, 2013 at 10:23:42AM +0100, Jean-Francois Moine wrote:

> But now, I am wondering again about these `empty`codecs:
> - in a DT context, should we continue to add / modify such codecs?
> - what do you think about my generic DT codec? (indeed, I would do a new
>   version according to the previous remarks)

We still want to be able to have users just name the CODEC on their
board rather than have to type in all the details from the datasheet,
if we're going to try to amalgamate the drivers it should still let
people do that.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131120/09c87c68/attachment-0001.pgp>

[PATCH 00/31] ARM: tegra: use common reset and DMA bindings

[Stephen Warren]

On 11/20/2013 08:37 AM, Arnd Bergmann wrote:
> On Friday 15 November 2013, Stephen Warren wrote:
>> This series implements a common reset framework driver for Tegra, and
>> updates all relevant Tegra drivers to use it. It also removes the custom
>> DMA bindings and replaced them with the standard DMA DT bindings.
> 
> The series is rather long, so I may have missed it, but I think you need one
> more patch to the apbdma binding to document the use of #dma-cells, what
> value it has, and what the format of the dma specifiers in slave drivers
> needs to be.

Yes, you're right. I will fold the following into "ARM: tegra: document
use of standard DMA DT bindings":

> diff --git a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt 
> b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> index 0b1e577ab9d3..0b0f9498e265 100644
> --- a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> +++ b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> @@ -11,6 +11,10 @@ Required properties:
>See ../reset/reset.txt for details.
>  - reset-names : Must include the following entries:
>- dma
> +- #iommu-cells : Must be <1>. This dictates the length of DMA specifiers in
> +  client nodes' dmas properties. The specifier represents the DMA request
> +  select value for the peripheral. For more details, consult the Tegra TRM's
> +  documentation of the APB DMA channel control register REQ_SEL field.
>  
>  Examples:
>  
> @@ -36,4 +40,5 @@ apbdma: dma at 6000a000 {
>   clocks = <_car 34>;
>   resets = <_car 34>;
>   reset-names = "dma";
> + #iommu-cells = <1>;
>  };

[Bug 71816] Sacred: Gold Edition does not work with radeonsi

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

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

--- Comment #1 from Michel D?nzer  ---
(In reply to comment #1)
> libGL: OpenDriver: trying /usr/lib32/dri/radeonsi_dri.so
> libGL error: dlopen /usr/lib32/dri/radeonsi_dri.so failed
> (/home/niko/.desura/games/sacred-gold/lib/lib1/libz.so.1: version
> `ZLIB_1.2.0' not found (required by /usr/lib32/llvm/libLLVM-3.4svn.so))
> libGL error: unable to load driver: radeonsi_dri.so

Looks like the game ships its own version of libz.so.1, which doesn't provide
something the system version provides and which LLVM expects, so the radeonsi
(and swrast) driver fails to load, and libGL falls back to GLX indirect
rendering.

Does it work better if you move away
/home/niko/.desura/games/sacred-gold/lib/lib1/libz.so.1 ?


We'd need to see a gdb backtrace of the X server crash, but it's probably
basically a consequence of indirect rendering, which is undesirable anyway.

-- 
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/20131120/8a8de5f3/attachment.html>

[PATCH] intel: Use memset instead of VG_CLEAR

[Ian Romanick]

From: Ian Romanick 

The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.

Signed-off-by: Ian Romanick 
Reported-by: Zhenyu Wang 
Cc: Damien Lespiau 
Cc: Daniel Vetter 
---
 intel/intel_bufmgr_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..c11ed45 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3033,7 +3033,7 @@ drm_intel_get_reset_stats(drm_intel_context *ctx,
if (ctx == NULL)
return -EINVAL;

-   VG_CLEAR(stats);
+   memset(, 0, sizeof(stats));

bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr;
stats.ctx_id = ctx->ctx_id;
-- 
1.8.1.4

[Bug 71817] Git Mesa r600g driver crashes while using llvm

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

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

--- Comment #1 from Krzysztof A. Sobiecki  ---
Tried LLVM version 1:3.4~svn194202-1~exp1 and it have the same problem, and I
think it worked with an older Mesa. Will bisect Mesa in the future.

-- 
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/20131120/31526e70/attachment.html>

[Bug 69321] starting openCL crashes/boots system

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

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

--- Comment #8 from Tom Stellard  ---
Created attachment 89507
  --> https://bugs.freedesktop.org/attachment.cgi?id=89507=edit
Fix

Does this patch fix the 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/20131120/f04eb1af/attachment.html>

[PATCH] drm/ttm: Use VM_PFNMAP for shared bo maps

[Thomas Hellstrom]

VM_PFNMAP is faster than VM_MIXEDMAP due to reduced page administration so
use it for shared maps where we don't have any Copy-On-Write pages. For
private maps, we continue to use VM_MIXEDMAP.

This might also help a bit for bo mmap dirty tracking, if implemented,
depending on the used interface.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c |   19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index ac617f3..05f4bd9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -206,7 +206,11 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
pfn = page_to_pfn(page);
}

-   ret = vm_insert_mixed(, address, pfn);
+   if (vma->vm_flags & VM_MIXEDMAP)
+   ret = vm_insert_mixed(, address, pfn);
+   else
+   ret = vm_insert_pfn(, address, pfn);
+
/*
 * Somebody beat us to this PTE or prefaulting to
 * an already populated PTE, or prefaulting error.
@@ -303,9 +307,15 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct 
*vma,
 * Note: We're transferring the bo reference to
 * vma->vm_private_data here.
 */
-
vma->vm_private_data = bo;
-   vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTDUMP;
+
+   /*
+* PFNMAP is faster than MIXEDMAP due to reduced page
+* administration. So use MIXEDMAP only if private VMA, where
+* we need to support COW.
+*/
+   vma->vm_flags |= (vma->vm_flags & VM_SHARED) ? VM_PFNMAP : VM_MIXEDMAP;
+   vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
return 0;
 out_unref:
ttm_bo_unref();
@@ -320,7 +330,8 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct 
ttm_buffer_object *bo)

vma->vm_ops = _bo_vm_ops;
vma->vm_private_data = ttm_bo_reference(bo);
-   vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+   vma->vm_flags |= (vma->vm_flags & VM_SHARED) ? VM_PFNMAP : VM_MIXEDMAP;
+   vma->vm_flags |= VM_IO | VM_DONTEXPAND;
return 0;
 }
 EXPORT_SYMBOL(ttm_fbdev_mmap);
-- 
1.7.10.4

[PATCH] drm/vma-manager: Don't unmap COW'd pages when zapping bo ptes

[Thomas Hellstrom]

Not sure if there are any user-space users of private bo mappings, but
if there are, or will be, zapping the COW'd pages when, for example,
moving a bo would confuse the user immensely since the net effect for the
user would be that pages written to would lose their contents.

Signed-off-by: Thomas Hellstrom 
---
 include/drm/drm_vma_manager.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index c18a593..347077d 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -231,9 +231,9 @@ static inline void drm_vma_node_unmap(struct 
drm_vma_offset_node *node,
  struct address_space *file_mapping)
 {
if (file_mapping && drm_vma_node_has_offset(node))
-   unmap_mapping_range(file_mapping,
-   drm_vma_node_offset_addr(node),
-   drm_vma_node_size(node) << PAGE_SHIFT, 1);
+   unmap_shared_mapping_range
+   (file_mapping, drm_vma_node_offset_addr(node),
+drm_vma_node_size(node) << PAGE_SHIFT);
 }

 /**
-- 
1.7.10.4

[Bug 71817] New: Git Mesa r600g driver crashes while using llvm

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

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

  Priority: medium
Bug ID: 71817
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Git Mesa r600g driver crashes while using llvm
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: sobkas at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 89502
  --> https://bugs.freedesktop.org/attachment.cgi?id=89502=edit
Gdb output after using glxinfo

R600g crashes while I try to use LLVM support in it.
LLVM: 1:3.4~svn194296-1~exp1
Mesa: e7a5905d8a3960b0981750f8131e3af9acbfcdb8

Error message before segfault:
0x6af6c0: i32 = GlobalAddress<<4 x float> (i32)* @llvm.R600.interp.const> 0
[ORD=1]

Even running glxinfo causes this error.

-- 
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/20131120/4a68f84a/attachment.html>

[Bug 71812] VDPAU: MPEG-4 ASP Garbling/Corruption

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

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

--- Comment #5 from Adam Hirst  ---
Also; was I right to have posted this in Drivers/Gallium/r600 as opposed to
Drivers/DRI/R600 ?

-- 
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/20131120/ba4e7d11/attachment.html>

[Bug 71816] New: Sacred: Gold Edition does not work with radeonsi

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

29: error: unexpected identifier
`GtkPaned', expected character `}'
/home/niko/.kde4/share/config/gtkrc:10: error: unexpected identifier
`gtk-theme-name', expected keyword - e.g. `style'
/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc:29: error: unexpected identifier
`GtkPaned', expected character `}'
/home/niko/.kde4/share/config/gtkrc:10: error: unexpected identifier
`gtk-theme-name', expected keyword - e.g. `style'
$XDG_CONFIG_HOME not set, falling back to $HOME/.config.$XDG_CACHE_HOME not
set, falling back to $HOME/.cache.$XDG_CONFIG_HOME not set, falling back to
$HOME/.config.$XDG_CACHE_HOME not set, falling back to $HOME/.cache.




glxinfo | grep OpenGL:

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TAHITI
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.1.0-devel
(git-15d8e05)
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.1.0-devel (git-15d8e05)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:




glxinfo-x86 | grep OpenGL:

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TAHITI
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.1.0-devel
(git-15d8e05)
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.1.0-devel (git-15d8e05)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:




My distro is Gentoo amd64, my video card is AMD HD 7950. I have kernel 3.13,
xorg-server 1.14.4 + DRI loader entrypoint patch and the whole graphic stack
from git including LLVM. 32 bit graphic stack is from git too: I'm using
Gentoo's multilib. The 32 bit graphic stack works flawlessly because I play
lots of Steam games which are 32-bit only, some of them very demanding like
Left 4 Dead 2. glxgears-x86 works too.

I have the 32-bit zlib of course:

[ebuild   R] sys-libs/zlib-1.2.8-r1  USE="minizip -static-libs" ABI_X86="32
(64) (-x32)" 0 kB

>>> /usr/lib32/pkgconfig/zlib.pc
>>> /usr/lib32/pkgconfig/minizip.pc
>>> /usr/lib32/libz.so
>>> /usr/lib32/libminizip.so.1 -> libminizip.so.1.0.0
>>> /usr/lib32/libminizip.so -> libminizip.so.1.0.0
>>> /usr/lib32/libminizip.so.1.0.0
>>> /lib32/libz.so.1 -> libz.so.1.2.8
>>> /lib32/libz.so.1.2.8


The game works flawlessly with fglrx. This is the second game which does not
start at all with radeon: the other one is Worms Reloaded which is a Steam
game. Another user reported that Worms Reloaded works flawlessly with r600g, so
do I have some strange problem with my 32-bit stack or is this bug peculiar to
radeonsi?

-- 
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/20131120/4b3db92e/attachment-0001.html>