[PATCH v7 03/11] drm/i915: return EACCES for check_cmd() failures

[Matthew Auld]

On 25 October 2016 at 00:19, Robert Bragg  wrote:
> check_cmd() is checking whether a command adheres to certain
> restrictions that ensure it's safe to execute within a privileged batch
> buffer. Returning false implies a privilege problem, not that the
> command is invalid.
>
> The distinction makes the difference between allowing the buffer to be
> executed as an unprivileged batch buffer or returning an EINVAL error to
> userspace without executing anything.
>
> In a case where userspace may want to test whether it can successfully
> write to a register that needs privileges the distinction may be
> important and an EINVAL error may be considered fatal.
>
> In particular this is currently true for Mesa, which includes a test for
> whether OACONTROL can be written too, but Mesa treats any error when
> flushing a batch buffer as fatal, calling exit(1).
>
> As it is currently Mesa can gracefully handle a failure to write to
> OACONTROL if the command parser is disabled, but if we were to remove
> OACONTROL from the parser's whitelist then the returned EINVAL would
> break Mesa applications as they attempt an OACONTROL write.
>
> This bumps the command parser version from 7 to 8, as the change is
> visible to userspace.
>
> Signed-off-by: Robert Bragg 
Seems reasonable.

Reviewed-by: Matthew Auld 

[Intel-gfx] [PATCH] drm: Release reference from blob lookup after replacing property

[Chris Wilson]

On Tue, Oct 25, 2016 at 05:27:21PM -0400, Sean Paul wrote:
> On Tue, Oct 25, 2016 at 3:46 PM, Chris Wilson  
> wrote:
> > drm_property_lookup_blob() returns a reference to the returned blob, and
> > drm_atomic_replace_property_blob() takes a references to the blob it
> > stores, so afterwards we are left owning a reference to the new_blob that
> > we never release, and thus leak memory every time we update a property
> > such as during drm_atomic_helper_legacy_gamma_set().
> >
> > Based on a patch by Felix Monninger 
> >
> > Reported-by: Felix Monninger 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=98420
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 1b5a32df9a9a..3b35ab793100 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -416,19 +416,24 @@ drm_atomic_replace_property_blob_from_id(struct 
> > drm_crtc *crtc,
> >  ssize_t expected_size,
> >  bool *replaced)
> >  {
> > -   struct drm_device *dev = crtc->dev;
> > struct drm_property_blob *new_blob = NULL;
> >
> > if (blob_id != 0) {
> > -   new_blob = drm_property_lookup_blob(dev, blob_id);
> > +   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
> 
> I think this could be further simplified by making use of
> drm_property_lookup_blob() returning NULL for blob_id == 0
> 
> Then you could do something like:
> 
> static int
> drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
>  struct drm_property_blob **old_blob,
>  uint64_t blob_id,
>  ssize_t expected_size,
>  bool *replaced)
> {
> struct drm_property_blob *blob = NULL;
> int ret = 0;
> 
> blob = drm_property_lookup_blob(crtc->dev, blob_id);

Not sure. I think the orignal code would have been clearer as

blob = NULL;
if (id) {
blob = drm_property_lookup_blob(dev, id);
if (!blob)
return -ENOENT;

if (blob->length != expected_size)
return -EINVAL;
}

i.e. the code currently reports if the blob_id doesn't match an existing
blob, and only removes the current blob if passed in 0.

Otherwise it becomes like:

struct drm_property_blob *blob;
int ret = -EINVAL;

blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (!blob_id || 
(blob && (expected_size == 0 || expected_size == blob->length))) {
drm_atomic_replace_property_blob(old_blob, blob, replaced);
ret = 0;
}
drm_property_unreference_blob(blob);

for which I'm actually favouring the existing code for the extra whitespace.

If we insisted on a single return path:

struct drm_property_blob *new_blob = NULL;
int ret = -EINVAL;

if (blob_id != 0) {
new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (new_blob == NULL)
goto out;

if (expected_size > 0 && expected_size != new_blob->length)
goto out;
}

drm_atomic_replace_property_blob(blob, new_blob, replaced);
ret = 0;

out:
drm_property_unreference_blob(new_blob);
return ret;

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 183311] New: Firefox Support phone /(/1~877~424~6647/)/ Firefox phone number ::USA

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

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

Bug ID: 183311
   Summary: Firefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USA
   Product: Drivers
   Version: 2.5
Kernel Version: Firefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USA
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: tala at t3t97d1d.com
Regression: No

Firefox Support phone /(/1~877~424~6647/)/ Firefox phone number
::USA
Firefox Support phone /(/1~877~424~6647/)/ Firefox phone number
::USA
Firefox Support phone /(/1~877~424~6647/)/ Firefox phone number
::USA
Firefox Support phone /(/1~877~424~6647/)/ Firefox phone number
::USA
Firefox Support phone /(/1~877~424~6647/)/ Firefox phone number
::USA
Firefox Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number ::USAFirefox Support phone /(/1~877~424~6647/)/
Firefox phone number ::USAFirefox Support phone
/(/1~877~424~6647/)/ Firefox phone number ::USAFirefox Support
phone /(/1~877~424~6647/)/ Firefox phone number ::USAFirefox
Support phone /(/1~877~424~6647/)/ Firefox phone number
::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox phone
number ::USAFirefox Support phone /(/1~877~424~6647/)/ Firefox
phone number
::https://www.jotform.com/answers/971342-Contact-MOZILLA-Firefox-1-877-424-6647-Firefox-tech-support-phone-number-1-877-424-6647-Thunderbird-Emai
https://www.jotform.com/answers/971344-Firefox-Phone-Number-Firefox-Support-Number
https://www.jotform.com/answers/971344-Firefox-Phone-Number-1-877-424-6647-Firefox-Support-Number
https://wiki.openstack.org/wiki/Firefox_Phone_Number_@@**%22_1~877~424~6647_%22**@@_Firefox_Support_Number

[PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Matthew Auld]

On 25 October 2016 at 00:19, Robert Bragg  wrote:
> Gen graphics hardware can be set up to periodically write snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace via the
> i915 perf interface.
>
> v2:
>Make sure to initialize ->specific_ctx_id when opening, without
>relying on _pin_notify hook, in case ctx already pinned.
> v3:
>Revert back to pinning ctx upfront when opening stream, removing
>need to hook in to pinning and to update OACONTROL on the fly.
>
> Cc: Chris Wilson 
> Signed-off-by: Robert Bragg 
> Signed-off-by: Zhenyu Wang 
>
> fix enable hsw
Random bit of cruft ?

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   65 ++-
>  drivers/gpu/drm/i915/i915_perf.c | 1000 
> +-
>  drivers/gpu/drm/i915/i915_reg.h  |  338 +
>  include/uapi/drm/i915_drm.h  |   70 ++-
>  4 files changed, 1444 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3448d05..ea24814 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> bool sprites_scaled;
>  };
>
> +struct i915_oa_format {
> +   u32 format;
> +   int size;
> +};
> +
>  struct i915_oa_reg {
> i915_reg_t addr;
> u32 value;
> @@ -1784,11 +1789,6 @@ struct i915_perf_stream_ops {
>  */
> void (*disable)(struct i915_perf_stream *stream);
>
> -   /* Return: true if any i915 perf records are ready to read()
> -* for this stream.
> -*/
> -   bool (*can_read)(struct i915_perf_stream *stream);
> -
> /* Call poll_wait, passing a wait queue that will be woken
>  * once there is something ready to read() for the stream
>  */
> @@ -1798,9 +1798,7 @@ struct i915_perf_stream_ops {
>
> /* For handling a blocking read, wait until there is something
>  * to ready to read() for the stream. E.g. wait on the same
> -* wait queue that would be passed to poll_wait() until
> -* ->can_read() returns true (if its safe to call ->can_read()
> -* without the i915 perf lock held).
> +* wait queue that would be passed to poll_wait().
>  */
> int (*wait_unlocked)(struct i915_perf_stream *stream);
>
> @@ -1840,11 +1838,28 @@ struct i915_perf_stream {
> struct list_head link;
>
> u32 sample_flags;
> +   int sample_size;
>
> struct i915_gem_context *ctx;
> bool enabled;
>
> -   struct i915_perf_stream_ops *ops;
> +   const struct i915_perf_stream_ops *ops;
> +};
> +
> +struct i915_oa_ops {
> +   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
> +   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
> +   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
> +   void (*oa_enable)(struct drm_i915_private *dev_priv);
> +   void (*oa_disable)(struct drm_i915_private *dev_priv);
> +   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
> +   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
> +   u32 ctx_id);
> +   int (*read)(struct i915_perf_stream *stream,
> +   char __user *buf,
> +   size_t count,
> +   size_t *offset);
> +   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
>  };
>
>  struct drm_i915_private {
> @@ -2149,16 +2164,46 @@ struct drm_i915_private {
>
> struct {
> bool initialized;
> +
> struct mutex lock;
> struct list_head streams;
>
> +   spinlock_t hook_lock;
> +
> struct {
> -   u32 metrics_set;
> +   struct i915_perf_stream *exclusive_stream;
> +
> +   u32 specific_ctx_id;
Can we just get rid of this, now that the vma remains pinned we can
simply get the ggtt address at the time of configuring the OA_CONTROL
register ?

> +
> +   struct hrtimer poll_check_timer;
> +   wait_queue_head_t poll_wq;
> +   atomic_t pollin;
> +
> +   bool periodic;
> +   int period_exponent;
> +   int timestamp_frequency;
> +
> +   int tail_margin;
> +
> +   int metrics_set;
>
> const struct i915_oa_reg *mux_regs;
> int mux_regs_len;
> const struct i915_oa_reg *b_counter_regs;
> int b_counter_regs_len;
> +
> +   struct {
> +   struct i915_vma *vma;
> +   u8 *vaddr;
> +   int format;
> +

[PATCH v2] drm: Release reference from blob lookup after replacing property

[Chris Wilson]

From: Felix Monninger 

drm_property_lookup_blob() returns a reference to the returned blob, and
drm_atomic_replace_property_blob() takes a references to the blob it
stores, so afterwards we are left owning a reference to the new_blob that
we never release, and thus leak memory every time we update a property
such as during drm_atomic_helper_legacy_gamma_set().

v2: update credentials, drm_property_unreference_blob() is NULL safe and
NULL is passed consistently to it throughout drm_atomic.c so do so here.

Reported-by: Felix Monninger 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98420
Signed-off-by: Felix Monninger 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_atomic.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1b5a32df9a9a..e0760c138355 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -416,18 +416,21 @@ drm_atomic_replace_property_blob_from_id(struct drm_crtc 
*crtc,
 ssize_t expected_size,
 bool *replaced)
 {
-   struct drm_device *dev = crtc->dev;
struct drm_property_blob *new_blob = NULL;

if (blob_id != 0) {
-   new_blob = drm_property_lookup_blob(dev, blob_id);
+   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (new_blob == NULL)
return -EINVAL;
-   if (expected_size > 0 && expected_size != new_blob->length)
+
+   if (expected_size > 0 && expected_size != new_blob->length) {
+   drm_property_unreference_blob(new_blob);
return -EINVAL;
+   }
}

drm_atomic_replace_property_blob(blob, new_blob, replaced);
+   drm_property_unreference_blob(new_blob);

return 0;
 }
-- 
2.10.1

[PATCH] drm/nouveau: fix nv84 fence context leak

[Lucas Stach]

uevent based fences hold a reference to the fence context,
just like the legacy ones. So they need to drop this reference
in the same way.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 4bb9ab8..098044c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -586,5 +586,5 @@ static const struct fence_ops nouveau_fence_ops_uevent = {
.enable_signaling = nouveau_fence_enable_signaling,
.signaled = nouveau_fence_is_signaled,
.wait = fence_default_wait,
-   .release = NULL
+   .release = nouveau_fence_release
 };
-- 
2.7.4

linux-next: Tree for Oct 25

[Paul Gortmaker]

On Mon, Oct 24, 2016 at 11:31 PM, Stephen Rothwell  
wrote:
> Hi all,
>
> There will probably be no linux-next releases next week while I attend
> the Kernel Summit.
>
> Changes since 20161024:
>
> The pm tree gained a conflict against the imx-mxs tree.
>
> The mali-dp tree gained a conflict against the drm-misc tree.
>
> The sunxi tree gained a build failure so I used the version from
> next-20161024.
>
> The akpm-current tree still had its build failures for which I applied
> 2 patches.
>
> Non-merge commits (relative to Linus' tree): 2174
>  2622 files changed, 187829 insertions(+), 38953 deletions(-)

The i386 allmodconfig fails with bad 32/64 math for about the last 5 days.

ERROR: "__umoddi3" [drivers/gpu/drm/i915/i915.ko] undefined!

http://kisskb.ellerman.id.au/kisskb/buildresult/12840554/

git bisect says:

first bad commit: [4d60c5fd3f8751ea751d6dc6cfe0c1620420ccf8]
drm/i915/gvt: vGPU PCI configuration space virtualization

Authors/maintainers added to Cc/To list.   Guessing folks weren't
aware of the regression.

Thanks,
Paul.

[PATCH] drm: Release reference from blob lookup after replacing property

[Chris Wilson]

drm_property_lookup_blob() returns a reference to the returned blob, and
drm_atomic_replace_property_blob() takes a references to the blob it
stores, so afterwards we are left owning a reference to the new_blob that
we never release, and thus leak memory every time we update a property
such as during drm_atomic_helper_legacy_gamma_set().

Based on a patch by Felix Monninger 

Reported-by: Felix Monninger 
References: https://bugs.freedesktop.org/show_bug.cgi?id=98420
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_atomic.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1b5a32df9a9a..3b35ab793100 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -416,19 +416,24 @@ drm_atomic_replace_property_blob_from_id(struct drm_crtc 
*crtc,
 ssize_t expected_size,
 bool *replaced)
 {
-   struct drm_device *dev = crtc->dev;
struct drm_property_blob *new_blob = NULL;

if (blob_id != 0) {
-   new_blob = drm_property_lookup_blob(dev, blob_id);
+   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (new_blob == NULL)
return -EINVAL;
-   if (expected_size > 0 && expected_size != new_blob->length)
+
+   if (expected_size > 0 && expected_size != new_blob->length) {
+   drm_property_unreference_blob(new_blob);
return -EINVAL;
+   }
}

drm_atomic_replace_property_blob(blob, new_blob, replaced);

+   if (new_blob)
+   drm_property_unreference_blob(new_blob);
+
return 0;
 }

-- 
2.10.1

[PATCH] drm/amd/powerplay: mark symbols static where possible

[Deucher, Alexander]

> -Original Message-
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Tuesday, October 25, 2016 4:15 AM
> To: Baoyou Xie
> Cc: Deucher, Alexander; Dave Airlie; Zhu, Rex; Zhou, Jammy; Huang,
> JinHuiEric; StDenis, Tom; Edward O'Callaghan; Prosyak, Vitaly; Yang, Eric;
> Yang, Young; Huang, Ray; Dan Carpenter; Cui, Flora; Nils Wallménius; Liu,
> Monk; Wang, Ken; Min, Frank; dri-devel; Linux Kernel Mailing List;
> xie.baoyou at zte.com.cn; han.fei at zte.com.cn; tang.qiang007 at zte.com.cn
> Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where
> possible
> 
> On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote:
> > On 25 October 2016 at 04:51, Arnd Bergmann  wrote:
> > > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> > > The function has no callers, so the easiest way would be to remove it
> > > entirely, but it's possible that there are plans to add users soon.
> > >
> > > It was assumed that this function will be used soon, so this patch remains
> > it.
> > if it still not be used in 4.10, then we can remove it.
> > is it right?
> 
> There is no such rule in general, it's up to the maintainer and
> it depends on the specific reason for why the function ended up
> being unused in the first place.
> 
> However, we can expect the maintainer to come up with some solution
> to address the warning. Possible options include:
> 
> - calling the function from where it was meant to be used
> - removing the function
> - adding __maybe_unused
> - adding an #if 0
> 
> I have not looked at this specific example and do not know
> which of them would be appropriate here. If you look at the
> output of 'git log -p
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c'
> you might find it out yourself.

This is mostly fallout from a big cleanup/re-org of the powerplay code in the 
4.9.  Rex said he was going to use these soon.  

Alex

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Tobias Jakobi]

Hello Shuah,


Shuah Khan wrote:
> On 10/19/2016 04:27 PM, Shuah Khan wrote:
>> On 10/19/2016 08:16 AM, Inki Dae wrote:
>>> Hi Shuah,
>>>
>>> 2016-10-13 8:11 GMT+09:00 Shuah Khan :
 Hi Inki,

 On 08/15/2016 10:40 PM, Inki Dae wrote:

>>
>> okay the very first commit that added IOMMU support
>> introduced the code that rejects non-contig gem memory
>> type without IOMMU.
>>
>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>> Author: Inki Dae 
>> Date:   Sat Oct 20 07:53:42 2012 -0700
>>
>> drm/exynos: add iommu support for exynos drm framework
>>

 I haven't given up on this yet. I am still seeing the following failure:

 Additional debug messages I added:
 [   15.287403] exynos_drm_gem_create_ioctl() 1
 [   15.287419] exynos_drm_gem_create() flags 1

 [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous 
 GEM memory is not supported.

 Additional debug message I added:
 [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
 framebuffer

 This is what happens:

 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG 
 request
 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
check_fb_gem_memory_type()

 At this point, there is no recovery and lightdm fails

 xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
 allocations are not supported in some exynos drm versions: The following
 commit introduced this change:

 https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9

 excerpts from the diff:-   if (create_gem->buf_type == 
 ARMSOC_BO_SCANOUT)
 -   create_exynos.flags = EXYNOS_BO_CONTIG;
 -   else
 -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
 +
 +   /* Contiguous allocations are not supported in some exynos drm 
 versions.
 +* When they are supported all allocations are effectively 
 contiguous
 +* anyway, so for simplicity we always request non contiguous 
 buffers.
 +*/
 +   create_exynos.flags = EXYNOS_BO_NONCONTIG;

>>>
>>> Above comment, "Contiguous allocations are not supported in some
>>> exynos drm versions.", seems wrong assumption.
>>> The root cause, contiguous allocation is not supported, would be that
>>> they used Linux kernel which didn't have CMA region enough - as
>>> default 16MB, or didn't declare CMA region enough for the DMA device.
>>> So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
>>> should manage the error case if the allocation failed.
>>
>> This assumption doesn't sound correct and forcing NONCONTIG isn't right
>> either. 
>>
>>>
 There might have been logic on exynos_drm that forced Contig when it 
 coudn't
 support NONCONTIG. At least, that is what this comment suggests. This 
 assumption
 doesn't appear to be a good one and not sure if this change was made to 
 fix a bug.

 After the IOMMU support, this assumption is no longer true. Hence, with 
 IOMMU
 support, latest kernels have a mismatch with the installed 
 xf86-video-armsoc

 This is what I am running into. This leads to the following question:

 1. How do we ensure exynos_drm kernel changes don't break user-space
specifically xf86-video-armsoc
 2. This seems to have gone undetected for a while. I see a change in
exynos_drm_gem_dumb_create() that is probably addressing this type
of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
handling for IOMMU NONCONTIG case.
>>>
>>> Seems this patch has a problem. This patch forces to flag NONCONTIG if
>>> iommu is enabled. The flag should be depend on the argument from
>>> user-space.
>>> I.e., if user-space requested a gem allocation with CONTIG flag, then
>>> Exynos drm driver should allocate contiguous memory even though iommu
>>> is enabled.
>>>

 Anyway, I am interested in getting the exynos_drm kernel side code
 and xf86-video-armsoc in sync to resolve the issue.

 Could you recommend a going forward plan?
>>>
>>> My opinion are,
>>>
>>> 1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
> 
> Okay more on this. I fixed xf86-video-armso to ask for EXYNOS_BO_CONTIG
> for ARMSOC_BO_SCANOUT and EXYNOS_BO_NONCONTIG in all other cases.
> 
> Revert of the commit: 3be1f6273441fe95dd442f44064387322e16b7e9
> 
> With this change, now display manager starts just fine. However, it turns
> out xf86-video-armsoc is obsoleted in favor of xf86-video-modesetting. The
> last update to xf86-video-armsoc git was 3 years ago.
IIRC xf86-video-armsoc was created to facilitate integration with the

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

[Luis R. Rodriguez]

On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote:
> A recent change to the mm code in:
> 87744ab3832b83ba71b931f86f9cfdb000d07da5
> mm: fix cache mode tracking in vm_insert_mixed()
> 
> started enforcing checking the memory type against the registered list for
> amixed pfn insertion mappings. It happens that the drm drivers for a number
> of gpus relied on this being broken. Currently the driver only inserted
> VRAM mappings into the tracking table when they came from the kernel,
> and userspace mappings never landed in the table. This led to a regression
> where all the mapping end up as UC instead of WC now.

Eek.

> I've considered a number of solutions but since this needs to be fixed
> in fixes and not next, and some of the solutions were going to introduce
> overhead that hadn't been there before I didn't consider them viable at
> this stage. These mainly concerned hooking into the TTM io reserve APIs,
> but these API have a bunch of fast paths I didn't want to unwind to add
> this to.
> 
> The solution I've decided on is to add a new API like the arch_phys_wc
> APIs (these would have worked but wc_del didn't take a range), and
> use them from the drivers to add a WC compatible mapping to the table
> for all VRAM on those GPUs. This means we can then create userspace
> mapping that won't get degraded to UC.

Is anything on a driver to be able to tell when this is actually needed ?
How will driver developers know? Can you add a bit of documentation to
the API? If its transitive towards a secondary solution indicating so
would help driver developers.

  Luis

[PATCH 1/2] drm: Add a new connector property for link status

[Manasi Navare]

Chris,

Would you be able to make the necessary changes in the suerspace
driver so I can do some testing tomorrow?

Manasi

On Tue, Oct 25, 2016 at 06:16:34PM -0700, Manasi Navare wrote:
> A new optional connector property is added for keeping
> track of whether the link is good (link training passed) or
> link is bad (link training  failed). If the link status property
> is Bad, then userspace should fire off a new modeset at the current
> mode even if there have not been any changes in the mode list
> or connector status.
> 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Chris Wilson 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_connector.c | 32 
>  include/drm/drm_connector.h |  1 +
>  include/drm/drm_crtc.h  |  6 ++
>  include/uapi/drm/drm_mode.h |  4 
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2db7fb5..b4ce19f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -588,6 +588,11 @@ int drm_display_info_set_bus_formats(struct 
> drm_display_info *info,
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> + { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> + { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> +};
> +
>  int drm_connector_create_standard_properties(struct drm_device *dev)
>  {
>   struct drm_property *prop;
> @@ -845,6 +850,33 @@ int drm_mode_create_suggested_offset_properties(struct 
> drm_device *dev)
>  EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
>  
>  /**
> + * drm_mode_create_link_status_property - Create link status property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time it's needed, must be attached to desired
> + * connectors.
> + * This property is used to indicate whether link sttaus is Good or Bad as
> + * a result fo link training
> + */
> +int drm_mode_create_link_status_property(struct drm_device *dev)
> +{
> + struct drm_property *link_status;
> +
> + if (dev->mode_config.link_status_property)
> + return 0;
> +
> + link_status =
> + drm_property_create_enum(dev, 0, "link-status",
> +  drm_link_status_enum_list,
> +  ARRAY_SIZE(drm_link_status_enum_list));
> +
> + dev->mode_config.scaling_mode_property = link_status;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_link_status_property);
> +
> +/**
>   * drm_mode_connector_set_path_property - set tile property on connector
>   * @connector: connector to set property on.
>   * @path: path to use for property; must not be NULL.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fc9d475..7234c0c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -759,6 +759,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  int drm_mode_create_scaling_mode_property(struct drm_device *dev);
>  int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>  int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
> +int drm_mode_create_link_status_property(struct drm_device *dev);
>  
>  int drm_mode_connector_set_path_property(struct drm_connector *connector,
>const char *path);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index fa1aa21..3e9c833 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1343,6 +1343,12 @@ struct drm_mode_config {
>*/
>   struct drm_property *suggested_y_property;
>  
> + /**
> +  * @link_status_property: Optional connector property for link status
> +  * of the connector as a result of link training.
> +  */
> +  struct drm_property *link_status_property;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
>  
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 084b50a..f1b0afd 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -121,6 +121,10 @@
>  #define DRM_MODE_DIRTY_ON   1
>  #define DRM_MODE_DIRTY_ANNOTATE 2
>  
> +/* Link Status options */
> +#define DRM_MODE_LINK_STATUS_GOOD0
> +#define DRM_MODE_LINK_STATUS_BAD 1
> +
>  struct drm_mode_modeinfo {
>   __u32 clock;
>   __u16 hdisplay;
> -- 
> 1.9.1
> 

[PATCH 2/2] drm/i915: Set link status property for DP connector

[Manasi Navare]

The link status connector property is attached to the drm
object in DP initialization.
This also defines a helper function to set the property value.
This will be used to set the link sttaus to Bad in case
of link training failures.

Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3c2293b..dd0d372 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4674,6 +4674,22 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
 }

 static int
+intel_dp_set_link_status_property(struct drm_connector *connector,
+ uint64_t val)
+{
+   struct drm_device *dev = connector->dev;
+   int ret = 0;
+
+   ret = drm_object_property_set_value(>base,
+   
dev->mode_config.link_status_property,
+   val);
+   if (ret)
+   return ret;
+
+   return ret;
+}
+
+static int
 intel_dp_connector_register(struct drm_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -4940,6 +4956,11 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port 
port)
connector->dev->mode_config.scaling_mode_property,
DRM_MODE_SCALE_ASPECT);
intel_connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
+   } else {
+   drm_mode_create_link_status_property(connector->dev);
+   drm_object_attach_property(>base,
+  
connector->dev->mode_config.link_status_property,
+  DRM_MODE_LINK_STATUS_GOOD);
}
 }

-- 
1.9.1

[PATCH 1/2] drm: Add a new connector property for link status

[Manasi Navare]

A new optional connector property is added for keeping
track of whether the link is good (link training passed) or
link is bad (link training  failed). If the link status property
is Bad, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in the mode list
or connector status.

Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 32 
 include/drm/drm_connector.h |  1 +
 include/drm/drm_crtc.h  |  6 ++
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2db7fb5..b4ce19f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -588,6 +588,11 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)

+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+
 int drm_connector_create_standard_properties(struct drm_device *dev)
 {
struct drm_property *prop;
@@ -845,6 +850,33 @@ int drm_mode_create_suggested_offset_properties(struct 
drm_device *dev)
 EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);

 /**
+ * drm_mode_create_link_status_property - Create link status property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ * This property is used to indicate whether link sttaus is Good or Bad as
+ * a result fo link training
+ */
+int drm_mode_create_link_status_property(struct drm_device *dev)
+{
+   struct drm_property *link_status;
+
+   if (dev->mode_config.link_status_property)
+   return 0;
+
+   link_status =
+   drm_property_create_enum(dev, 0, "link-status",
+drm_link_status_enum_list,
+ARRAY_SIZE(drm_link_status_enum_list));
+
+   dev->mode_config.scaling_mode_property = link_status;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_link_status_property);
+
+/**
  * drm_mode_connector_set_path_property - set tile property on connector
  * @connector: connector to set property on.
  * @path: path to use for property; must not be NULL.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fc9d475..7234c0c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -759,6 +759,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_link_status_property(struct drm_device *dev);

 int drm_mode_connector_set_path_property(struct drm_connector *connector,
 const char *path);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa1aa21..3e9c833 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1343,6 +1343,12 @@ struct drm_mode_config {
 */
struct drm_property *suggested_y_property;

+   /**
+* @link_status_property: Optional connector property for link status
+* of the connector as a result of link training.
+*/
+struct drm_property *link_status_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 084b50a..f1b0afd 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -121,6 +121,10 @@
 #define DRM_MODE_DIRTY_ON   1
 #define DRM_MODE_DIRTY_ANNOTATE 2

+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD  0
+#define DRM_MODE_LINK_STATUS_BAD   1
+
 struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
-- 
1.9.1

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Ville Syrjälä]

On Mon, Oct 10, 2016 at 03:19:47PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> We don't want all planes to be added to the state whenever a
> plane with fixed zpos gets enabled/disabled. This is true
> especially for eg. cursor planes on i915, as we want cursor
> updates to go through w/o throttling. Same holds for drivers
> that don't support zpos at all (i915 actually falls into this
> category right now since we've not yet added zpos support).
> 
> Allow drivers more freedom by letting them deal with zpos
> themselves instead of doing it in drm_atomic_helper_check_planes()
> unconditionally. Easiest solution seems to be to move the call
> up to drm_atomic_helper_check(). But as some drivers might want
> to use that function without the zpos handling, let's provide
> two variants: the normal one, and one that deals with zpos.
> 
> Cc: Marek Szyprowski 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Laurent Pinchart 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Lyude 
> Cc: Maarten Lankhorst 
> Cc: stable at vger.kernel.org
> Fixes: 44d1240d006c ("drm: add generic zpos property")
> Signed-off-by: Ville Syrjälä 

Ping. Can I get some buy-in from the relevant folks?

> ---
>  drivers/gpu/drm/drm_atomic_helper.c| 46 
> +++---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  2 +-
>  drivers/gpu/drm/sti/sti_drv.c  |  2 +-
>  include/drm/drm_atomic_helper.h|  2 ++
>  5 files changed, 47 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c3f83476f996..cd19281cdefb 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -594,10 +594,6 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>   struct drm_plane_state *plane_state;
>   int i, ret = 0;
>  
> - ret = drm_atomic_normalize_zpos(dev, state);
> - if (ret)
> - return ret;
> -
>   for_each_plane_in_state(state, plane, plane_state, i) {
>   const struct drm_plane_helper_funcs *funcs;
>  
> @@ -673,6 +669,48 @@ int drm_atomic_helper_check(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_check);
>  
> +/**
> + * drm_atomic_helper_check_with_zpos - validate state object, dealing with 
> zpos
> + * @dev: DRM device
> + * @state: the driver state object
> + *
> + * Check the state object to see if the requested state is physically 
> possible.
> + * Only crtcs and planes have check callbacks, so for any additional (global)
> + * checking that a driver needs it can simply wrap that around this function.
> + * Drivers without such needs can directly use this as their ->atomic_check()
> + * callback.
> + *
> + * This just wraps the two parts of the state checking for planes and modeset
> + * state in the default order: First it calls 
> drm_atomic_helper_check_modeset(),
> + * followed by drm_atomic_normalize_zpos(), and finally
> + * drm_atomic_helper_check_planes(). The assumption is that the
> + * ->atomic_check functions depend upon an updated adjusted_mode.clock to
> + * e.g. properly compute watermarks.
> + *
> + * RETURNS:
> + * Zero for success or -errno
> + */
> +int drm_atomic_helper_check_with_zpos(struct drm_device *dev,
> +   struct drm_atomic_state *state)
> +{
> + int ret;
> +
> + ret = drm_atomic_helper_check_modeset(dev, state);
> + if (ret)
> + return ret;
> +
> + ret = drm_atomic_normalize_zpos(dev, state);
> + if (ret)
> + return ret;
> +
> + ret = drm_atomic_helper_check_planes(dev, state);
> + if (ret)
> + return ret;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_check_with_zpos);
> +
>  static void
>  disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
>  {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 40ce841eb952..5c0930af01fa 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -190,7 +190,7 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer 
> *fb, int index)
>  static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
>   .fb_create = exynos_user_fb_create,
>   .output_poll_changed = exynos_drm_output_poll_changed,
> - .atomic_check = drm_atomic_helper_check,
> + .atomic_check = drm_atomic_helper_check_with_zpos,
>   .atomic_commit = exynos_atomic_commit,
>  };
>  
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index bd9c3bb9252c..2cfd35f3f2f6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -231,7 +231,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
>   struct 

[Intel-gfx] [PATCH] drm: Release reference from blob lookup after replacing property

[Sean Paul]

On Tue, Oct 25, 2016 at 3:46 PM, Chris Wilson  
wrote:
> drm_property_lookup_blob() returns a reference to the returned blob, and
> drm_atomic_replace_property_blob() takes a references to the blob it
> stores, so afterwards we are left owning a reference to the new_blob that
> we never release, and thus leak memory every time we update a property
> such as during drm_atomic_helper_legacy_gamma_set().
>
> Based on a patch by Felix Monninger 
>
> Reported-by: Felix Monninger 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98420
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/drm_atomic.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1b5a32df9a9a..3b35ab793100 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -416,19 +416,24 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_crtc *crtc,
>  ssize_t expected_size,
>  bool *replaced)
>  {
> -   struct drm_device *dev = crtc->dev;
> struct drm_property_blob *new_blob = NULL;
>
> if (blob_id != 0) {
> -   new_blob = drm_property_lookup_blob(dev, blob_id);
> +   new_blob = drm_property_lookup_blob(crtc->dev, blob_id);

I think this could be further simplified by making use of
drm_property_lookup_blob() returning NULL for blob_id == 0

Then you could do something like:

static int
drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
 struct drm_property_blob **old_blob,
 uint64_t blob_id,
 ssize_t expected_size,
 bool *replaced)
{
struct drm_property_blob *blob = NULL;
int ret = 0;

blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (blob && expected_size > 0 && expected_size != blob->length) {
ret = -EINVAL;
goto out;
}
}

drm_atomic_replace_property_blob(blob, blob, replaced);
out:
drm_property_unreference_blob(blob);
return 0;
}

> if (new_blob == NULL)
> return -EINVAL;
> -   if (expected_size > 0 && expected_size != new_blob->length)
> +
> +   if (expected_size > 0 && expected_size != new_blob->length) {
> +   drm_property_unreference_blob(new_blob);
> return -EINVAL;
> +   }
> }
>
> drm_atomic_replace_property_blob(blob, new_blob, replaced);
>
> +   if (new_blob)
> +   drm_property_unreference_blob(new_blob);
> +
> return 0;
>  }
>
> --
> 2.10.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO

[Chen-Yu Tsai]

On Tue, Oct 25, 2016 at 4:09 PM, Archit Taneja  
wrote:
> Hi,
>
> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>
>> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
>> an enable pin on the bridge IC, or indirectly controlling a power
>> switch.
>>
>> Add support for it.
>
>
> Does the bridge on your platform have an active/passive DAC, or is it a
> smarter encoder chip that is capable of doing more? If so, it might be
> good to have a separate DT compatible string to it, like what's done
> in the patch titled:
>
> drm: bridge: vga-dac: Add adi,adv7123 compatible string
>
> so that we can switch to a different driver later if needed.

The chip is GM7123. It is not configurable. It just takes the LCD RGB/SYNC
signals and converts them to analog. The only things you can change are
putting it into sleep mode and tweaking the output drive strength by
changing the external reference resistor. The latter would be a hardware
design decision. I would say this qualifies as "dumb".

I revisited the board schematics, and the enable GPIO actually toggles
an external LDO regulator. So this might be better modeled as a regulator
supply?


Thanks
ChenYu

>
> Thanks,
> Archit
>
>
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
>>  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 28
>> ++
>>  2 files changed, 30 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..d3484822bf77 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in
>> Documentation/devicetree/bindings/graph.txt.
>>  - Video port 0 for RGB input
>>  - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- enable-gpios: GPIO pin to enable or disable the bridge
>>
>>  Example
>>  ---
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..b487e5e9b56d 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -10,6 +10,7 @@
>>   * the License, or (at your option) any later version.
>>   */
>>
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connectorconnector;
>>
>> struct i2c_adapter  *ddc;
>> +   struct gpio_desc*enable_gpio;
>>  };
>>
>>  static inline struct dumb_vga *
>> @@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>>  }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> +   if (vga->enable_gpio)
>> +   gpiod_set_value_cansleep(vga->enable_gpio, 1);
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> +   if (vga->enable_gpio)
>> +   gpiod_set_value_cansleep(vga->enable_gpio, 0);
>> +}
>> +
>>  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> +   .enable = dumb_vga_enable,
>> +   .disable= dumb_vga_disable,
>>  };
>>
>>  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> +   vga->enable_gpio = devm_gpiod_get_optional(>dev, "enable",
>> +  GPIOD_OUT_LOW);
>> +   if (IS_ERR(vga->enable_gpio)) {
>> +   ret = PTR_ERR(vga->enable_gpio);
>> +   dev_err(>dev, "failed to request GPIO: %d\n", ret);
>> +   return ret;
>> +   }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(>dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

[PATCH v7 01/11] drm/i915: Add i915 perf infrastructure

[Matthew Auld]

> +
> +/* Note we copy the properties from userspace outside of the i915 perf
> + * mutex to avoid an awkward lockdep with mmap_sem.
> + *
> + * Note this function only validates properties in isolation it doesn't
> + * validate that the combination of properties makes sense or that all
> + * properties necessary for a particular kind of stream have been set.
> + */
> +static int read_properties_unlocked(struct drm_i915_private *dev_priv,
> +   u64 __user *uprops,
> +   u32 n_props,
> +   struct perf_open_properties *props)
> +{
> +   u64 __user *uprop = uprops;
> +   int i;
> +
> +   memset(props, 0, sizeof(struct perf_open_properties));
> +
> +   if (!n_props) {
> +   DRM_ERROR("No i915 perf properties given");
> +   return -EINVAL;
> +   }
> +
> +   if (n_props > DRM_I915_PERF_PROP_MAX) {
> +   DRM_ERROR("More i915 perf properties specified than exist");
> +   return -EINVAL;
> +   }
> +
> +   for (i = 0; i < n_props; i++) {
> +   u64 id, value;
> +   int ret;
> +
> +   ret = get_user(id, (u64 __user *)uprop);
> +   if (ret)
> +   return ret;
> +
> +   ret = get_user(value, (u64 __user *)uprop + 1);
> +   if (ret)
> +   return ret;
Do we really need all of these __user casts, they seem redundant, no?

Otherwise looks good so:
Reviewed-by: Matthew Auld 

[PATCH 04/20] drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

[Daniel Vetter]

On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote:
> Cc: Dave Airlie 
> Signed-off-by: Stefan Christ 
> ---
>  drivers/gpu/drm/ast/ast_fb.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index c017a93..b604fdd 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -150,14 +150,10 @@ static void ast_imageblit(struct fb_info *info,
>  
>  static struct fb_ops astfb_ops = {
>   .owner = THIS_MODULE,
> - .fb_check_var = drm_fb_helper_check_var,
> - .fb_set_par = drm_fb_helper_set_par,
> + DRM_FB_HELPER_DEFAULT_OPS,
>   .fb_fillrect = ast_fillrect,
>   .fb_copyarea = ast_copyarea,
>   .fb_imageblit = ast_imageblit,

Ah, here's the likely reason for not sharing these, ast/cirrus have their
special dirtying stuff for fbdev emulation. And because the fbdev mmap
must have a stable pointer it can't use the ttm bo mmap magic of
automatically picking the right place for the mmap.

I'd say just leave these 2 drivers out as special cases.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Sean Paul]

On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä
 wrote:
> On Mon, Oct 10, 2016 at 03:19:47PM +0300, ville.syrjala at linux.intel.com 
> wrote:
>> From: Ville Syrjälä 
>>
>> We don't want all planes to be added to the state whenever a
>> plane with fixed zpos gets enabled/disabled. This is true
>> especially for eg. cursor planes on i915, as we want cursor
>> updates to go through w/o throttling. Same holds for drivers
>> that don't support zpos at all (i915 actually falls into this
>> category right now since we've not yet added zpos support).
>>
>> Allow drivers more freedom by letting them deal with zpos
>> themselves instead of doing it in drm_atomic_helper_check_planes()
>> unconditionally. Easiest solution seems to be to move the call
>> up to drm_atomic_helper_check(). But as some drivers might want
>> to use that function without the zpos handling, let's provide
>> two variants: the normal one, and one that deals with zpos.
>>
>> Cc: Marek Szyprowski 
>> Cc: Benjamin Gaignard 
>> Cc: Vincent Abriou 
>> Cc: Laurent Pinchart 
>> Cc: Inki Dae 
>> Cc: Joonyoung Shim 
>> Cc: Seung-Woo Kim 
>> Cc: Kyungmin Park 
>> Cc: Lyude 
>> Cc: Maarten Lankhorst 
>> Cc: stable at vger.kernel.org
>> Fixes: 44d1240d006c ("drm: add generic zpos property")
>> Signed-off-by: Ville Syrjälä 
>
> Ping. Can I get some buy-in from the relevant folks?
>

Reviewed-by: Sean Paul 

FWIW :)

>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c| 46 
>> +++---
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c |  2 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  2 +-
>>  drivers/gpu/drm/sti/sti_drv.c  |  2 +-
>>  include/drm/drm_atomic_helper.h|  2 ++
>>  5 files changed, 47 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index c3f83476f996..cd19281cdefb 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -594,10 +594,6 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>>   struct drm_plane_state *plane_state;
>>   int i, ret = 0;
>>
>> - ret = drm_atomic_normalize_zpos(dev, state);
>> - if (ret)
>> - return ret;
>> -
>>   for_each_plane_in_state(state, plane, plane_state, i) {
>>   const struct drm_plane_helper_funcs *funcs;
>>
>> @@ -673,6 +669,48 @@ int drm_atomic_helper_check(struct drm_device *dev,
>>  }
>>  EXPORT_SYMBOL(drm_atomic_helper_check);
>>
>> +/**
>> + * drm_atomic_helper_check_with_zpos - validate state object, dealing with 
>> zpos
>> + * @dev: DRM device
>> + * @state: the driver state object
>> + *
>> + * Check the state object to see if the requested state is physically 
>> possible.
>> + * Only crtcs and planes have check callbacks, so for any additional 
>> (global)
>> + * checking that a driver needs it can simply wrap that around this 
>> function.
>> + * Drivers without such needs can directly use this as their 
>> ->atomic_check()
>> + * callback.
>> + *
>> + * This just wraps the two parts of the state checking for planes and 
>> modeset
>> + * state in the default order: First it calls 
>> drm_atomic_helper_check_modeset(),
>> + * followed by drm_atomic_normalize_zpos(), and finally
>> + * drm_atomic_helper_check_planes(). The assumption is that the
>> + * ->atomic_check functions depend upon an updated adjusted_mode.clock to
>> + * e.g. properly compute watermarks.
>> + *
>> + * RETURNS:
>> + * Zero for success or -errno
>> + */
>> +int drm_atomic_helper_check_with_zpos(struct drm_device *dev,
>> +   struct drm_atomic_state *state)
>> +{
>> + int ret;
>> +
>> + ret = drm_atomic_helper_check_modeset(dev, state);
>> + if (ret)
>> + return ret;
>> +
>> + ret = drm_atomic_normalize_zpos(dev, state);
>> + if (ret)
>> + return ret;
>> +
>> + ret = drm_atomic_helper_check_planes(dev, state);
>> + if (ret)
>> + return ret;
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(drm_atomic_helper_check_with_zpos);
>> +
>>  static void
>>  disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
>>  {
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> index 40ce841eb952..5c0930af01fa 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -190,7 +190,7 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer 
>> *fb, int index)
>>  static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
>>   .fb_create = exynos_user_fb_create,
>>   .output_poll_changed = exynos_drm_output_poll_changed,
>> - .atomic_check = drm_atomic_helper_check,
>> + .atomic_check = drm_atomic_helper_check_with_zpos,
>>   .atomic_commit = exynos_atomic_commit,
>>  };
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> 

[PATCH 02/20] drm/amdgpu: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

[Daniel Vetter]

On Thu, Sep 29, 2016 at 10:48:38PM +0200, Stefan Christ wrote:
> Cc: Alex Deucher 
> Cc: Christian König 
> Signed-off-by: Stefan Christ 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 9191467..6b80982 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -50,14 +50,10 @@ struct amdgpu_fbdev {
>  
>  static struct fb_ops amdgpufb_ops = {
>   .owner = THIS_MODULE,
> - .fb_check_var = drm_fb_helper_check_var,
> - .fb_set_par = drm_fb_helper_set_par,
> + DRM_FB_HELPER_DEFAULT_OPS,
>   .fb_fillrect = drm_fb_helper_cfb_fillrect,
>   .fb_copyarea = drm_fb_helper_cfb_copyarea,
>   .fb_imageblit = drm_fb_helper_cfb_imageblit,
> - .fb_pan_display = drm_fb_helper_pan_display,
> - .fb_blank = drm_fb_helper_blank,
> - .fb_setcmap = drm_fb_helper_setcmap,
>   .fb_debug_enter = drm_fb_helper_debug_enter,
>   .fb_debug_leave = drm_fb_helper_debug_leave,

Ok, wanted to start vacuuming stuff up, but then realized that this
doesn't share the fb_fillrect, fb_copyarea, fb_imageblit and
fb_debug_enter/leave funcs. Not sharing fb_mmap makes sense, because that
must be special. But all the others can be shared. Any reasons for not
doing so?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge

[Chen-Yu Tsai]

On Tue, Oct 25, 2016 at 4:13 PM, Archit Taneja  
wrote:
>
>
> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>
>> The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB
>> output from the LCD interface to VGA signals.
>>
>> Enable this part of the display pipeline.
>
>
> I couldn't find the enable-gpios binding for the bridge that you
> introduced in the previous patch. Is that intentional?

Error on my part. Thanks for spotting that.

ChenYu

>
> Thanks,
> Archit
>
>
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56
>> +
>>  1 file changed, 56 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> index 9a74637f677f..05a49b2147f1 100644
>> --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> @@ -63,6 +63,49 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> +   bridge {
>> +   compatible = "dumb-vga-dac";
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port at 0 {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   reg = <0>;
>> +
>> +   vga_bridge_in: endpoint at 0 {
>> +   reg = <0>;
>> +   remote-endpoint =
>> <_out_vga>;
>> +   };
>> +   };
>> +
>> +   port at 1 {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   reg = <1>;
>> +
>> +   vga_bridge_out: endpoint at 0 {
>> +   reg = <0>;
>> +   remote-endpoint = <_con_in>;
>> +   };
>> +   };
>> +   };
>> +   };
>> +
>> +   vga {
>> +   compatible = "vga-connector";
>> +
>> +   port {
>> +   vga_con_in: endpoint {
>> +   remote-endpoint = <_bridge_out>;
>> +   };
>> +   };
>> +   };
>> +
>> wifi_pwrseq: wifi_pwrseq {
>> compatible = "mmc-pwrseq-simple";
>> reset-gpios = < 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
>> @@ -245,6 +288,19 @@
>> status = "okay";
>>  };
>>
>> + {
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <_rgb888_pins>;
>> +   status = "okay";
>> +};
>> +
>> +_out {
>> +   tcon0_out_vga: endpoint at 0 {
>> +   reg = <0>;
>> +   remote-endpoint = <_bridge_in>;
>> +   };
>> +};
>> +
>>   {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins_a>;
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

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

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

--- Comment #57 from hofmann.zachary at gmail.com ---
As smoki mentioned, many of the troubles started after Valve's texture
streaming changes to TF2. They'd certainly know what changed in their code, but
for someone like me they're impossible to get a hold of.

http://www.teamfortress.com/post.php?id=19733

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

[PATCH] drm/amd/powerplay: mark symbols static where possible

[Baoyou Xie]

On 25 October 2016 at 16:15, Arnd Bergmann  wrote:

> On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote:
> > On 25 October 2016 at 04:51, Arnd Bergmann  wrote:
> > > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> > > The function has no callers, so the easiest way would be to remove it
> > > entirely, but it's possible that there are plans to add users soon.
> > >
> > > It was assumed that this function will be used soon, so this patch
> remains
> > it.
> > if it still not be used in 4.10, then we can remove it.
> > is it right?
>
> There is no such rule in general, it's up to the maintainer and
> it depends on the specific reason for why the function ended up
> being unused in the first place.
>
> However, we can expect the maintainer to come up with some solution
> to address the warning. Possible options include:
>
> - calling the function from where it was meant to be used
> - removing the function
> - adding __maybe_unused
> - adding an #if 0
>
> I have not looked at this specific example and do not know
> which of them would be appropriate here. If you look at the
> output of 'git log -p drivers/gpu/drm/amd/amdgpu/../
> powerplay/hwmgr/smu7_hwmgr.c'
> you might find it out yourself.
>
>
Good idea :)

hi, Daniel:
could you tell me the git tree that you use? it's better to work on
your git tree.

Arnd
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161025/87a8f6d9/attachment.html>

[PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Tue, 25 Oct 2016 08:44:22 +0200
Daniel Vetter  wrote:

> > +   /* start the subdevices */
> > +   ret = component_bind_all(dev, drm);
> > +   if (ret < 0)
> > +   goto out2;
> > +
> > +   ret = drm_dev_register(drm, 0);
> 
> This needs to be the very last step in your driver load sequence.
> Kerneldoc explains why. Similar, but inverted for unloading:
> drm_dev_unregister is the very first thing you must call.

Thanks, and also for embedding the drm device.

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

[PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Mon, 24 Oct 2016 16:04:19 +0200
Maxime Ripard  wrote:

> Hi,

Hi Maxime,

> On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> > Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> > engine, DE2.
> > This patch adds a DRM video driver for this device.
> > 
> > Signed-off-by: Jean-Francois Moine 
> 
> Output from checkpatch:
> total: 0 errors, 20 warnings, 83 checks, 1799 lines checked
> 
> > ---
> >  .../bindings/display/sunxi/sunxi-de2.txt   |  83 +++
> >  drivers/gpu/drm/Kconfig|   2 +
> >  drivers/gpu/drm/Makefile   |   1 +
> >  drivers/gpu/drm/sunxi/Kconfig  |  21 +
> >  drivers/gpu/drm/sunxi/Makefile |   7 +
> >  drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +
> >  drivers/gpu/drm/sunxi/de2_crtc.h   |  63 +++
> >  drivers/gpu/drm/sunxi/de2_de.c | 591 
> > +
> >  drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
> >  drivers/gpu/drm/sunxi/de2_drv.c| 378 +
> >  drivers/gpu/drm/sunxi/de2_plane.c  | 119 +
> >  11 files changed, 1787 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> >  create mode 100644 drivers/gpu/drm/sunxi/Kconfig
> >  create mode 100644 drivers/gpu/drm/sunxi/Makefile
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
> > 
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt 
> > b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> > new file mode 100644
> > index 000..f9cd67a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> > @@ -0,0 +1,83 @@
> > +Allwinner sunxi Display Engine 2 subsystem
> > +==
> > +
> > +The sunxi DE2 subsystem contains a display controller (DE2),
> 
> sunxi is a made up name, and doesn't really mean anything. You can
> call it either sun8i (because it was introduced in that family).

OK.

> > +one or two LCD controllers (TCON) and their external interfaces.
> > +
> > +Display controller
> > +==
> > +
> > +Required properties:
> > +
> > +- compatible: value should be one of the following
> > +   "allwinner,sun8i-a83t-display-engine"
> > +   "allwinner,sun8i-h3-display-engine"
> > +
> > +- clocks: must include clock specifiers corresponding to entries in the
> > +   clock-names property.
> > +
> > +- clock-names: must contain
> > +   "gate": for DE activation
> > +   "clock": DE clock
> 
> We've been calling them bus and mod.

I can understand "bus" (which is better than "apb"), but why "mod"?

> > +
> > +- resets: phandle to the reset of the device
> > +
> > +- ports: phandle's to the LCD ports
> 
> Please use the OF graph.

These ports are references to the graph of nodes. See
http://www.kernelhub.org/?msg=911825=2

[snip]
> > diff --git a/drivers/gpu/drm/sunxi/de2_crtc.c 
> > b/drivers/gpu/drm/sunxi/de2_crtc.c
> > new file mode 100644
> > index 000..dae0fab
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sunxi/de2_crtc.c
> > @@ -0,0 +1,475 @@
> > +/*
> > + * Allwinner DRM driver - DE2 CRTC
> > + *
> > + * Copyright (C) 2016 Jean-Francois Moine 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "de2_drm.h"
> > +#include "de2_crtc.h"
> > +
> > +/* I/O map */
> > +
> > +struct tcon {
> > +   u32 gctl;
> > +#defineTCON_GCTL_TCON_En BIT(31)
> > +   u32 gint0;
> > +#defineTCON_GINT0_TCON1_Vb_Int_En BIT(30)
> > +#defineTCON_GINT0_TCON1_Vb_Int_Flag BIT(14)
> > +   u32 gint1;
> > +   u32 dum0[13];
> > +   u32 tcon0_ctl;  /* 0x40 */
> > +#defineTCON0_CTL_TCON_En BIT(31)
> > +   u32 dum1[19];
> > +   u32 tcon1_ctl;  /* 0x90 */
> > +#defineTCON1_CTL_TCON_En BIT(31)
> > +#defineTCON1_CTL_Interlace_En BIT(20)
> > +#defineTCON1_CTL_Start_Delay_SHIFT 4
> > +#defineTCON1_CTL_Start_Delay_MASK GENMASK(8, 4)
> > +   u32 basic0; /* XI/YI */
> > +   u32 basic1; /* LS_XO/LS_YO */
> > +   u32 basic2; /* XO/YO */
> > +   u32 basic3; 

[PATCH v4 0/3] drm/bridge: add Silicon Image SiI8620 driver

[Andrzej Hajda]

Hi Archit,

Gently ping.

Regards
Andrzej

On 07.10.2016 09:02, Andrzej Hajda wrote:
> Hi Archit,
>
> In the 4th iteration the only change is relocation of mhl.h file to 
> include/drm/bridge.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (3):
>   video: add header file for Mobile High-Definition Link (MHL) interface
>   dt-bindings: add Silicon Image SiI8620 bridge bindings
>   drm/bridge: add Silicon Image SiI8620 driver
>
>  .../bindings/video/bridge/sil-sii8620.txt  |   33 +
>  drivers/gpu/drm/bridge/Kconfig |7 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/sil-sii8620.c   | 1557 
> 
>  drivers/gpu/drm/bridge/sil-sii8620.h   | 1517 +++
>  include/drm/bridge/mhl.h   |  292 
>  6 files changed, 3407 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>  create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
>  create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h
>  create mode 100644 include/drm/bridge/mhl.h
>

[RFC v2] ARM: memory: da8xx-ddrctl: new driver

[Bartosz Golaszewski]

Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.

Signed-off-by: Bartosz Golaszewski 
---
 .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++
 drivers/memory/Kconfig |   8 +
 drivers/memory/Makefile|   1 +
 drivers/memory/da8xx-ddrctl.c  | 175 +
 4 files changed, 204 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
 create mode 100644 drivers/memory/da8xx-ddrctl.c

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt 
b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
new file mode 100644
index 000..7e271dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
@@ -0,0 +1,20 @@
+* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
+
+The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs 
features
+a set of registers which allow to tweak the controller's behavior.
+
+Documentation:
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
+
+Required properties:
+
+- compatible:  "ti,da850-ddr-controller" - for da850 SoC based boards
+- reg: a tuple containing the base address of the memory
+   controller and the size of the memory area to map
+
+Example for da850 shown below.
+
+ddrctl {
+   compatible = "ti,da850-ddr-controller";
+   reg = <0xB000 0x100>;
+};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 4b4c0c3..ec80e35 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -134,6 +134,14 @@ config MTK_SMI
  mainly help enable/disable iommu and control the power domain and
  clocks for each local arbiter.

+config DA8XX_DDRCTL
+   bool "Texas Instruments da8xx DDR2/mDDR driver"
+   depends on ARCH_DAVINCI_DA8XX
+   help
+ This driver is for the DDR2/mDDR Memory Controller present on
+ Texas Instruments da8xx SoCs. It's used to tweak various memory
+ controller configuration options.
+
 source "drivers/memory/samsung/Kconfig"
 source "drivers/memory/tegra/Kconfig"

diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index b20ae38..e88097fb 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MVEBU_DEVBUS)+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 obj-$(CONFIG_JZ4780_NEMC)  += jz4780-nemc.o
 obj-$(CONFIG_MTK_SMI)  += mtk-smi.o
+obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o

 obj-$(CONFIG_SAMSUNG_MC)   += samsung/
 obj-$(CONFIG_TEGRA_MC) += tegra/
diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
new file mode 100644
index 000..66022df
--- /dev/null
+++ b/drivers/memory/da8xx-ddrctl.c
@@ -0,0 +1,175 @@
+/*
+ * TI da8xx DDR2/mDDR controller driver
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ *   Bartosz Golaszewski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * REVISIT: Linux doesn't have a good framework for the kind of performance
+ * knobs this driver controls. We can't use device tree properties as it deals
+ * with hardware configuration rather than description. We also don't want to
+ * commit to maintaining some random sysfs attributes.
+ *
+ * For now we just hardcode the register values for the boards that need
+ * some changes (as is the case for the LCD controller on da850-lcdk - the
+ * first board we support here). When linux gets an appropriate framework,
+ * we'll easily convert the driver to it.
+ */
+
+struct da8xx_ddrctl_config_knob {
+   const char *name;
+   u32 reg;
+   u32 mask;
+   u32 offset;
+};
+
+static const struct da8xx_ddrctl_config_knob da8xx_ddrctl_knobs[] = {
+   {
+   .name = "da850-pbbpr",
+   .reg = 0x20,
+   .mask = 0xff00,
+   .offset = 0,
+   },
+};
+
+struct da8xx_ddrctl_setting {
+   const char *name;
+   u32 val;
+};
+
+struct da8xx_ddrctl_board_settings {
+   const char *board;
+   const struct da8xx_ddrctl_setting *settings;
+};
+
+static const struct da8xx_ddrctl_setting da850_lcdk_ddrctl_settings[] = {
+   {
+   .name = "da850-pbbpr",
+   .val = 0x20,
+   },
+   { }
+};
+
+static const struct da8xx_ddrctl_board_settings da8xx_ddrctl_board_confs[] = {
+   {
+   .board = "ti,da850-lcdk",
+   .settings = da850_lcdk_ddrctl_settings,
+   },
+};
+
+static const struct da8xx_ddrctl_config_knob *

[RFC v2] da850: DDR2/mDDR memory controller driver

[Bartosz Golaszewski]

This is a follow-up for the series[1] adding new bus and memory drivers
to better support the TI LCD controller on the da850-lcdk board.

The general consensus of the discussion that followed was that DT is
not the right tool for this kind of SoC performance tweaks.

In order to avoid committing to stable DT bindings, we only introduce
two common properties (compatible and reg) while the configuration
register values are hard-coded for each board (currently only lcdk).

In the future, once linux gets a proper framework for performance
knobs, we'll convert this driver to using the better solution.

I'm sending a single patch this time as RFC to get some reviews and
see it the approach is viewed as correct.

[1] https://lkml.org/lkml/2016/10/17/613

v1 -> v2:
- changed the compatible string to make it more descriptive
- changed the DT bindings description to describe the device, not the
  driver's functionalities
- switched to using of_machine_is_compatible() instead of handcoding
  the same functionality
- used platform_get_resource() instead of ioremapping registers by hand

Bartosz Golaszewski (1):
  ARM: memory: da8xx-ddrctl: new driver

 .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++
 drivers/memory/Kconfig |   8 +
 drivers/memory/Makefile|   1 +
 drivers/memory/da8xx-ddrctl.c  | 175 +
 4 files changed, 204 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
 create mode 100644 drivers/memory/da8xx-ddrctl.c

-- 
2.9.3

[PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Rodrigo Vivi]

On Tue, Oct 25, 2016 at 5:09 AM, Jani Nikula
 wrote:
> On Sat, 22 Oct 2016, Manasi Navare  wrote:
>> This function provides a way for the driver to redo a
>> modeset on the current mode and retry the link training
>> at a lower link rate/lane count/bpp. This will get called
>> incase the link training fails during the current modeset.
>
> Based on discussions on #intel-gfx, I would dodge all the problems here
> by having the userspace do the modeset.

This is not like going back to UMS times?

> If we add a connector property to indicate the link status (and this
> does not have to be DP or link training specific, really), we can set
> that to "bad", and fire off the hotplug uevent. Then userspace has the
> information to force a modeset on that connector even if the mode has
> not changed. (Credits to Ville for the idea.)

This would require changes in all user space drivers out there right?
Ok, maybe faster than fix vblank layer for good...

>
> If we find a solution later on that allows us to handle all of this in
> kernel, we can do so, and remove the property or always report
> "good". Drivers can choose different approaches, depending on the
> capabilities of the hardware, for instance.

So, is this temporary then? While we update the vblank layer?

> Deferring this to the userspace does not regress anything now, because
> currently we just completely fail and end up with a black screen. The
> property would allow an enlightened userspace to fix that. And userspace
> can't rely on the property being there, as it's currently not there.

Also this discussion remind me about the PSR where we refused to give control
to userspace or create any property and kmd should control all cases.
Should we revisit that and change userspace to control PSR?

Thanks,
Rodrigo.

>
>
> BR,
> Jani.
>
>
>>
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: Jani Nikula 
>> Cc: Daniel Vetter 
>> Cc: Ville Syrjala 
>> Signed-off-by: Manasi Navare 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c | 58 
>> +
>>  include/drm/drm_atomic_helper.h |  1 +
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index f936276..0c1614e 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
>> drm_connector *connector,
>>  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
>>
>>  /**
>> + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
>> + * @connector: DRM connector
>> + *
>> + * Provides a way to redo a modeset with the current mode so that it can
>> + * drop the bpp, link rate/lane count and retry the link training.
>> + *
>> + * Returns:
>> + * Returns 0 on success, negative errno numbers on failure.
>> + */
>> +int
>> +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
>> +{
>> + struct drm_device *dev = connector->dev;
>> + struct drm_modeset_acquire_ctx ctx;
>> + struct drm_atomic_state *state;
>> + struct drm_connector_state *connector_state;
>> + struct drm_crtc_state *crtc_state;
>> + int ret = 0;
>> +
>> + drm_modeset_acquire_init(, 0);
>> + state = drm_atomic_state_alloc(dev);
>> + if (!state) {
>> + ret = -ENOMEM;
>> + goto fail;
>> + }
>> + state->acquire_ctx = 
>> +retry:
>> + ret = 0;
>> + connector_state = drm_atomic_get_connector_state(state, connector);
>> + if (IS_ERR(connector_state)) {
>> + ret = PTR_ERR(connector_state);
>> + goto fail;
>> + }
>> + if (!connector_state->crtc)
>> + goto fail;
>> +
>> + crtc_state = drm_atomic_get_existing_crtc_state(state,
>> + connector_state->crtc);
>> + crtc_state->connectors_changed = true;
>> + ret = drm_atomic_commit(state);
>> +fail:
>> + if (ret == -EDEADLK) {
>> + drm_atomic_state_clear(state);
>> + drm_modeset_backoff();
>> + goto retry;
>> + }
>> +
>> + if (state)
>> + drm_atomic_state_put(state);
>> +
>> + drm_modeset_drop_locks();
>> + drm_modeset_acquire_fini();
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(drm_atomic_helper_connector_modeset);
>> +
>> +/**
>>   * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
>>   *  ->best_encoder callback
>>   * @connector: Connector control structure
>> diff --git a/include/drm/drm_atomic_helper.h 
>> b/include/drm/drm_atomic_helper.h
>> index 7ff92b0..8de24dc 100644
>> --- a/include/drm/drm_atomic_helper.h
>> +++ b/include/drm/drm_atomic_helper.h
>> @@ -126,6 +126,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>>   uint32_t flags);
>>  int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
>>   

[PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Manasi Navare]

On Tue, Oct 25, 2016 at 03:09:39PM +0300, Jani Nikula wrote:
> On Sat, 22 Oct 2016, Manasi Navare  wrote:
> > This function provides a way for the driver to redo a
> > modeset on the current mode and retry the link training
> > at a lower link rate/lane count/bpp. This will get called
> > incase the link training fails during the current modeset.
> 
> Based on discussions on #intel-gfx, I would dodge all the problems here
> by having the userspace do the modeset.
> 
> If we add a connector property to indicate the link status (and this
> does not have to be DP or link training specific, really), we can set
> that to "bad", and fire off the hotplug uevent. Then userspace has the
> information to force a modeset on that connector even if the mode has
> not changed. (Credits to Ville for the idea.)
> 
> If we find a solution later on that allows us to handle all of this in
> kernel, we can do so, and remove the property or always report
> "good". Drivers can choose different approaches, depending on the
> capabilities of the hardware, for instance.
> 
> Deferring this to the userspace does not regress anything now, because
> currently we just completely fail and end up with a black screen. The
> property would allow an enlightened userspace to fix that. And userspace
> can't rely on the property being there, as it's currently not there.
> 
> 
> BR,
> Jani.
> 
>

Thanks for your feedback Jani. I will try implementing this, but isn't this 
going
to require changes in all the userspace drivers (modesetting driver, ChromeOS) 
to
make use of this new property to trigger another modeset?
How easy would it be to have all the userspace drivers adopt this change?

Regards
Manasi

> >
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 58 
> > +
> >  include/drm/drm_atomic_helper.h |  1 +
> >  2 files changed, 59 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index f936276..0c1614e 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> > drm_connector *connector,
> >  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
> >  
> >  /**
> > + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> > + * @connector: DRM connector
> > + *
> > + * Provides a way to redo a modeset with the current mode so that it can
> > + * drop the bpp, link rate/lane count and retry the link training.
> > + *
> > + * Returns:
> > + * Returns 0 on success, negative errno numbers on failure.
> > + */
> > +int
> > +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> > +{
> > +   struct drm_device *dev = connector->dev;
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   struct drm_atomic_state *state;
> > +   struct drm_connector_state *connector_state;
> > +   struct drm_crtc_state *crtc_state;
> > +   int ret = 0;
> > +
> > +   drm_modeset_acquire_init(, 0);
> > +   state = drm_atomic_state_alloc(dev);
> > +   if (!state) {
> > +   ret = -ENOMEM;
> > +   goto fail;
> > +   }
> > +   state->acquire_ctx = 
> > +retry:
> > +   ret = 0;
> > +   connector_state = drm_atomic_get_connector_state(state, connector);
> > +   if (IS_ERR(connector_state)) {
> > +   ret = PTR_ERR(connector_state);
> > +   goto fail;
> > +   }
> > +   if (!connector_state->crtc)
> > +   goto fail;
> > +
> > +   crtc_state = drm_atomic_get_existing_crtc_state(state,
> > +   connector_state->crtc);
> > +   crtc_state->connectors_changed = true;
> > +   ret = drm_atomic_commit(state);
> > +fail:
> > +   if (ret == -EDEADLK) {
> > +   drm_atomic_state_clear(state);
> > +   drm_modeset_backoff();
> > +   goto retry;
> > +   }
> > +
> > +   if (state)
> > +   drm_atomic_state_put(state);
> > +
> > +   drm_modeset_drop_locks();
> > +   drm_modeset_acquire_fini();
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL(drm_atomic_helper_connector_modeset);
> > +
> > +/**
> >   * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
> >   *  ->best_encoder callback
> >   * @connector: Connector control structure
> > diff --git a/include/drm/drm_atomic_helper.h 
> > b/include/drm/drm_atomic_helper.h
> > index 7ff92b0..8de24dc 100644
> > --- a/include/drm/drm_atomic_helper.h
> > +++ b/include/drm/drm_atomic_helper.h
> > @@ -126,6 +126,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> > uint32_t flags);
> >  int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
> >  int mode);
> > +int drm_atomic_helper_connector_modeset(struct 

[Bug 176311] Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip

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

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

Vedran Miletić  changed:

   What|Removed |Added

   Tree|Mainline|Fedora
 Kernel Version|4.7.5-200.fc24.x86_64   |4.8.4-200.fc24.x86_64

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

[Bug 176311] Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip

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

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

--- Comment #3 from Vedran Miletić  ---
Created attachment 242721
  --> https://bugzilla.kernel.org/attachment.cgi?id=242721=edit
xorg log

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

[Bug 176311] Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip

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

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

--- Comment #2 from Vedran Miletić  ---
Created attachment 242711
  --> https://bugzilla.kernel.org/attachment.cgi?id=242711=edit
dmesg

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

[PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Jani Nikula]

On Sat, 22 Oct 2016, Manasi Navare  wrote:
> This function provides a way for the driver to redo a
> modeset on the current mode and retry the link training
> at a lower link rate/lane count/bpp. This will get called
> incase the link training fails during the current modeset.

Based on discussions on #intel-gfx, I would dodge all the problems here
by having the userspace do the modeset.

If we add a connector property to indicate the link status (and this
does not have to be DP or link training specific, really), we can set
that to "bad", and fire off the hotplug uevent. Then userspace has the
information to force a modeset on that connector even if the mode has
not changed. (Credits to Ville for the idea.)

If we find a solution later on that allows us to handle all of this in
kernel, we can do so, and remove the property or always report
"good". Drivers can choose different approaches, depending on the
capabilities of the hardware, for instance.

Deferring this to the userspace does not regress anything now, because
currently we just completely fail and end up with a black screen. The
property would allow an enlightened userspace to fix that. And userspace
can't rely on the property being there, as it's currently not there.


BR,
Jani.


>
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 58 
> +
>  include/drm/drm_atomic_helper.h |  1 +
>  2 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f936276..0c1614e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> drm_connector *connector,
>  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
>  
>  /**
> + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> + * @connector: DRM connector
> + *
> + * Provides a way to redo a modeset with the current mode so that it can
> + * drop the bpp, link rate/lane count and retry the link training.
> + *
> + * Returns:
> + * Returns 0 on success, negative errno numbers on failure.
> + */
> +int
> +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + struct drm_connector_state *connector_state;
> + struct drm_crtc_state *crtc_state;
> + int ret = 0;
> +
> + drm_modeset_acquire_init(, 0);
> + state = drm_atomic_state_alloc(dev);
> + if (!state) {
> + ret = -ENOMEM;
> + goto fail;
> + }
> + state->acquire_ctx = 
> +retry:
> + ret = 0;
> + connector_state = drm_atomic_get_connector_state(state, connector);
> + if (IS_ERR(connector_state)) {
> + ret = PTR_ERR(connector_state);
> + goto fail;
> + }
> + if (!connector_state->crtc)
> + goto fail;
> +
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + connector_state->crtc);
> + crtc_state->connectors_changed = true;
> + ret = drm_atomic_commit(state);
> +fail:
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + drm_modeset_backoff();
> + goto retry;
> + }
> +
> + if (state)
> + drm_atomic_state_put(state);
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_modeset);
> +
> +/**
>   * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
>   *  ->best_encoder callback
>   * @connector: Connector control structure
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 7ff92b0..8de24dc 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -126,6 +126,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   uint32_t flags);
>  int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
>int mode);
> +int drm_atomic_helper_connector_modeset(struct drm_connector *connector);
>  struct drm_encoder *
>  drm_atomic_helper_best_encoder(struct drm_connector *connector);

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

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

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

--- Comment #38 from Vedran Miletić  ---
(In reply to Micael Bergeron from comment #37)
> The number of shaders is quite astonishing.
> 
> Could using the r600 shader compiler LLVM (--enable-r600-llvm-compiler) fix
> this?
> 

I don't see this option but judging by the name, this enables LLVM's R600
backend as a shader compiler on EG/NI cards and does not apply for SI+.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161025/1adffc11/attachment.html>

[Intel-gfx] [PATCH v4] dma-buf: Rename struct fence to dma_fence

[Daniel Vetter]

On Tue, Oct 25, 2016 at 01:00:45PM +0100, Chris Wilson wrote:
> I plan to usurp the short name of struct fence for a core kernel struct,
> and so I need to rename the specialised fence/timeline for DMA
> operations to make room.
> 
> A consensus was reached in
> https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
> that making clear this fence applies to DMA operations was a good thing.
> Since then the patch has grown a bit as usage increases, so hopefully it
> remains a good thing!
> 
> (v2...: rebase, rerun spatch)
> v3: Compile on msm, spotted a manual fixup that I broke.
> v4: Try again for msm, sorry Daniel

Fourth times's the charm it seems. Applied to drm-misc, thanks.
-Daniel

> 
> coccinelle script:
> @@
> 
> @@
> - struct fence
> + struct dma_fence
> @@
> 
> @@
> - struct fence_ops
> + struct dma_fence_ops
> @@
> 
> @@
> - struct fence_cb
> + struct dma_fence_cb
> @@
> 
> @@
> - struct fence_array
> + struct dma_fence_array
> @@
> 
> @@
> - enum fence_flag_bits
> + enum dma_fence_flag_bits
> @@
> 
> @@
> (
> - fence_init
> + dma_fence_init
> |
> - fence_release
> + dma_fence_release
> |
> - fence_free
> + dma_fence_free
> |
> - fence_get
> + dma_fence_get
> |
> - fence_get_rcu
> + dma_fence_get_rcu
> |
> - fence_put
> + dma_fence_put
> |
> - fence_signal
> + dma_fence_signal
> |
> - fence_signal_locked
> + dma_fence_signal_locked
> |
> - fence_default_wait
> + dma_fence_default_wait
> |
> - fence_add_callback
> + dma_fence_add_callback
> |
> - fence_remove_callback
> + dma_fence_remove_callback
> |
> - fence_enable_sw_signaling
> + dma_fence_enable_sw_signaling
> |
> - fence_is_signaled_locked
> + dma_fence_is_signaled_locked
> |
> - fence_is_signaled
> + dma_fence_is_signaled
> |
> - fence_is_later
> + dma_fence_is_later
> |
> - fence_later
> + dma_fence_later
> |
> - fence_wait_timeout
> + dma_fence_wait_timeout
> |
> - fence_wait_any_timeout
> + dma_fence_wait_any_timeout
> |
> - fence_wait
> + dma_fence_wait
> |
> - fence_context_alloc
> + dma_fence_context_alloc
> |
> - fence_array_create
> + dma_fence_array_create
> |
> - to_fence_array
> + to_dma_fence_array
> |
> - fence_is_array
> + dma_fence_is_array
> |
> - trace_fence_emit
> + trace_dma_fence_emit
> |
> - FENCE_TRACE
> + DMA_FENCE_TRACE
> |
> - FENCE_WARN
> + DMA_FENCE_WARN
> |
> - FENCE_ERR
> + DMA_FENCE_ERR
> )
>  (
>  ...
>  )
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Gustavo Padovan 
> Acked-by: Sumit Semwal 
> Acked-by: Christian König 
> ---
>  Documentation/sync_file.txt|  14 +-
>  drivers/base/Kconfig   |   6 +-
>  drivers/dma-buf/Kconfig|   2 +-
>  drivers/dma-buf/Makefile   |   2 +-
>  drivers/dma-buf/dma-buf.c  |  28 +--
>  .../dma-buf/{fence-array.c => dma-fence-array.c}   |  91 
>  drivers/dma-buf/{fence.c => dma-fence.c}   | 199 -
>  drivers/dma-buf/reservation.c  |  94 
>  drivers/dma-buf/seqno-fence.c  |  18 +-
>  drivers/dma-buf/sw_sync.c  |  48 ++---
>  drivers/dma-buf/sync_debug.c   |  13 +-
>  drivers/dma-buf/sync_debug.h   |   9 +-
>  drivers/dma-buf/sync_file.c|  63 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  54 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  58 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c |  24 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |  48 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  10 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  26 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  26 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  79 +++
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   6 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   6 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   6 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  12 

[PATCH 4/4] reservation: revert "wait only with non-zero timeout specified (v3)" v2

[Christian König]

From: Christian König 

This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.

Otherwise signaling might never be activated on the fences. This can
result in infinite waiting with hardware which has unreliable interrupts.

v2: still return one when the timeout is zero and we don't have any fences.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou  (v1)
Reviewed-by: Alex Deucher 
---
 drivers/dma-buf/reservation.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 9566a62..debb91d 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -379,10 +379,7 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
 {
struct fence *fence;
unsigned seq, shared_count, i = 0;
-   long ret = timeout;
-
-   if (!timeout)
-   return reservation_object_test_signaled_rcu(obj, wait_all);
+   long ret = timeout ? timeout : 1;

 retry:
fence = NULL;
-- 
2.5.0

[PATCH 3/4] drm/ttm: fix ttm_bo_wait

[Christian König]

From: Christian König 

reservation_object_wait_timeout_rcu() should enable signaling even with a zero
timeout, but ttm_bo_wait() can also be called from atomic context and then it
is not a good idea to do this.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 608c585..478d563 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1605,7 +1605,14 @@ EXPORT_SYMBOL(ttm_bo_unmap_virtual);
 int ttm_bo_wait(struct ttm_buffer_object *bo,
bool interruptible, bool no_wait)
 {
-   long timeout = no_wait ? 0 : 15 * HZ;
+   long timeout = 15 * HZ;
+
+   if (no_wait) {
+   if (reservation_object_test_signaled_rcu(bo->resv, true))
+   return 0;
+   else
+   return -EBUSY;
+   }

timeout = reservation_object_wait_timeout_rcu(bo->resv, true,
  interruptible, timeout);
-- 
2.5.0

[PATCH 2/4] dma-buf/fence: revert "don't wait when specified timeout is zero"

[Christian König]

From: Christian König 

This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.

When we don't call the wait function software signaling might never be
activated. This can cause infinite polling loops with unreliable interrupt
driven hardware.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Reviewed-by: Alex Deucher 
---
 drivers/dma-buf/fence.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index fb915ab..64478f9 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -159,9 +159,6 @@ fence_wait_timeout(struct fence *fence, bool intr, signed 
long timeout)
if (WARN_ON(timeout < 0))
return -EINVAL;

-   if (timeout == 0)
-   return fence_is_signaled(fence);
-
trace_fence_wait_start(fence);
ret = fence->ops->wait(fence, intr, timeout);
trace_fence_wait_end(fence);
-- 
2.5.0

[PATCH 1/4] dma-buf/fence: make timeout handling in fence_default_wait consistent

[Christian König]

From: Christian König 

Kernel functions taking a timeout usually return 1 on success even
when they get a zero timeout.

Signen-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Reviewed-by: Alex Deucher 
---
 drivers/dma-buf/fence.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 4d51f9e..fb915ab 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -335,18 +335,20 @@ fence_default_wait_cb(struct fence *fence, struct 
fence_cb *cb)
  * @timeout:   [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
  *
  * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the
- * remaining timeout in jiffies on success.
+ * remaining timeout in jiffies on success. If timeout is zero the value one is
+ * returned if the fence is already signaled for consistency with other
+ * functions taking a jiffies timeout.
  */
 signed long
 fence_default_wait(struct fence *fence, bool intr, signed long timeout)
 {
struct default_wait_cb cb;
unsigned long flags;
-   signed long ret = timeout;
+   signed long ret = timeout ? timeout : 1;
bool was_set;

if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
-   return timeout;
+   return ret;

spin_lock_irqsave(fence->lock, flags);

-- 
2.5.0

Fixing zero timeout handling for fence functions

[Christian König]

Hi Sumit,

sending this once more with all the patches in once set, cause the last one
turned out to be a bit chaotic because I send from the wrong branch.

The following patch set fixes the handling in the fence and reservation object
wait function when the timeout is zero.

An AMD developer introduced this a while ago to work around some issues in TTM
and our amdgpu driver, but essentially this effort was a bit flawed because
even with a zero timeout enable_signalling() should be called.

Otherwise someone busy waiting for the fence might never be signaled when you
have hardware with faulty interrupts for example.

Please review and/or comment,
Christian.

[v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Matthias Brugger]

On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
[...]
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
[...]
>> +
>> +/* Firmware */
>> +#define PS_FW_NAME "ps864x_fw.bin"
>> +
>
> From where I can download this firmware image?
>

I suppose this FW bits have to be added to linux-firmware repository 
first, before this patch can be accepted.

Regards,
Matthias

[PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge

[Archit Taneja]

On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
> The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB
> output from the LCD interface to VGA signals.
>
> Enable this part of the display pipeline.

I couldn't find the enable-gpios binding for the bridge that you
introduced in the previous patch. Is that intentional?

Thanks,
Archit

>
> Signed-off-by: Chen-Yu Tsai 
> ---
>  arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 
> +
>  1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
> b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> index 9a74637f677f..05a49b2147f1 100644
> --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> @@ -63,6 +63,49 @@
>   stdout-path = "serial0:115200n8";
>   };
>
> + bridge {
> + compatible = "dumb-vga-dac";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <_bridge_out>;
> + };
> + };
> + };
> +
>   wifi_pwrseq: wifi_pwrseq {
>   compatible = "mmc-pwrseq-simple";
>   reset-gpios = < 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
> @@ -245,6 +288,19 @@
>   status = "okay";
>  };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_rgb888_pins>;
> + status = "okay";
> +};
> +
> +_out {
> + tcon0_out_vga: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <_bridge_in>;
> + };
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins_a>;
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9

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

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

--- Comment #15 from Alex Deucher  ---
Created attachment 127542
  --> https://bugs.freedesktop.org/attachment.cgi?id=127542=edit
possible fix

Does this patch fix the issue?

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

[PATCH v2] drm/mediatek: fixed the calc method of data rate per lane

[Jitao Shi]

Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
Ths_exit)/(htotal*bpp/lane_number))

Signed-off-by: Jitao Shi 
---
Change since v1:
 - phy_timing2 and phy_timing3 refer clock cycle time.
 - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |  103 +++-
 1 file changed, 67 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..ade6f46 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
 #define LD0_WAKEUP_EN  BIT(2)

 #define DSI_PHY_TIMECON0   0x110
-#define LPX(0xff << 0)
-#define HS_PRPR(0xff << 8)
-#define HS_ZERO(0xff << 16)
-#define HS_TRAIL   (0xff << 24)
+#define LPX(5 << 0)
+#define HS_PRPR(6 << 8)
+#define HS_ZERO(10 << 16)
+#define HS_TRAIL   (8 << 24)

 #define DSI_PHY_TIMECON1   0x114
-#define TA_GO  (0xff << 0)
-#define TA_SURE(0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO  (20 << 0)
+#define TA_SURE(7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)

 #define DSI_PHY_TIMECON2   0x118
 #define CONT_DET   (0xff << 0)
@@ -158,28 +158,14 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
 }

-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
+ u32 phy_timing1, u32 phy_timing2,
+ u32 phy_timing3)
 {
-   u32 timcon0, timcon1, timcon2, timcon3;
-   unsigned int ui, cycle_time;
-   unsigned int lpx;
-
-   ui = 1000 / dsi->data_rate + 0x01;
-   cycle_time = 8000 / dsi->data_rate + 0x01;
-   lpx = 5;
-
-   timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
-   timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
-   timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
-   timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
-  NS_TO_CYCLE(0x40, cycle_time);
-
-   writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
-   writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
-   writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
-   writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
+   writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
+   writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
+   writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
+   writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
 }

 static void mtk_dsi_enable(struct mtk_dsi *dsi)
@@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 {
struct device *dev = dsi->dev;
int ret;
+   u64 bit_clock, total_bits;
+   u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
+   u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
+   u32 ui, cycle_time;

if (++dsi->refcount != 1)
return 0;

+   switch (dsi->format) {
+   case MIPI_DSI_FMT_RGB565:
+   bit_per_pixel = 16;
+   break;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   bit_per_pixel = 18;
+   break;
+   case MIPI_DSI_FMT_RGB666:
+   case MIPI_DSI_FMT_RGB888:
+   default:
+   bit_per_pixel = 24;
+   break;
+   }
+   /**
+* data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+* vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+* mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+*+ Thstrail + Ths_exit + Ths_zero) /
+*   (htotal * byte_per_pixel /lane_number)
+*/
+   bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+   htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+dsi->vm.hsync_len;
+   htotal_bits = htotal * bit_per_pixel;
+
/**
-

[PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO

[Archit Taneja]

Hi,

On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> an enable pin on the bridge IC, or indirectly controlling a power
> switch.
>
> Add support for it.

Does the bridge on your platform have an active/passive DAC, or is it a
smarter encoder chip that is capable of doing more? If so, it might be
good to have a separate DT compatible string to it, like what's done
in the patch titled:

drm: bridge: vga-dac: Add adi,adv7123 compatible string

so that we can switch to a different driver later if needed.

Thanks,
Archit

>
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
>  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 28 
> ++
>  2 files changed, 30 insertions(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt 
> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> index 003bc246a270..d3484822bf77 100644
> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> @@ -16,6 +16,8 @@ graph bindings specified in 
> Documentation/devicetree/bindings/graph.txt.
>  - Video port 0 for RGB input
>  - Video port 1 for VGA output
>
> +Optional properties:
> +- enable-gpios: GPIO pin to enable or disable the bridge
>
>  Example
>  ---
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index afec232185a7..b487e5e9b56d 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -10,6 +10,7 @@
>   * the License, or (at your option) any later version.
>   */
>
> +#include 
>  #include 
>  #include 
>
> @@ -23,6 +24,7 @@ struct dumb_vga {
>   struct drm_connectorconnector;
>
>   struct i2c_adapter  *ddc;
> + struct gpio_desc*enable_gpio;
>  };
>
>  static inline struct dumb_vga *
> @@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>   return 0;
>  }
>
> +static void dumb_vga_enable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> +
> + if (vga->enable_gpio)
> + gpiod_set_value_cansleep(vga->enable_gpio, 1);
> +}
> +
> +static void dumb_vga_disable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> +
> + if (vga->enable_gpio)
> + gpiod_set_value_cansleep(vga->enable_gpio, 0);
> +}
> +
>  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>   .attach = dumb_vga_attach,
> + .enable = dumb_vga_enable,
> + .disable= dumb_vga_disable,
>  };
>
>  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
> @@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>   return -ENOMEM;
>   platform_set_drvdata(pdev, vga);
>
> + vga->enable_gpio = devm_gpiod_get_optional(>dev, "enable",
> +GPIOD_OUT_LOW);
> + if (IS_ERR(vga->enable_gpio)) {
> + ret = PTR_ERR(vga->enable_gpio);
> + dev_err(>dev, "failed to request GPIO: %d\n", ret);
> + return ret;
> + }
> +
>   vga->ddc = dumb_vga_retrieve_ddc(>dev);
>   if (IS_ERR(vga->ddc)) {
>   if (PTR_ERR(vga->ddc) == -ENODEV) {
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/2] drm/msm: Don't provide 'is_enabled' PLL clk_ops

[Stephen Boyd]

On 10/25, Archit Taneja wrote:
> The DSI/HDMI PLLs in MSM require resources like interface clocks, power
> domains to be enabled before we can access their registers.
> 
> The clock framework doesn't have a mechanism at the moment where we can
> tie such resources to a clock, so we make sure that the KMS driver enables
> these resources whenever a PLL is expected to be in use.
> 
> One place where we can't ensure the resource dependencies are met is when
> the clock framework tries to disable unused clocks. The KMS driver doesn't
> know when the clock framework calls the is_enabled clk_op, and hence can't
> enable interface clocks/power domains beforehand.
> 
> We remove the is_enabled clk_ops from the PLL clocks for now since they
> aren't mandatory. This needs to be revisited, since bootloaders can enable
> display, the enable count maintained by clock framework wouldn't work in
> such cases.
> 
> Cc: Stephen Boyd 
> Signed-off-by: Archit Taneja 
> ---

Why not use the CLK_IGNORE_UNUSED flag for now? That does
essentially the same thing without requiring us to reintroduce
this code later on.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC v2] ARM: memory: da8xx-ddrctl: new driver

[Kevin Hilman]

Kevin Hilman  writes:

> Bartosz Golaszewski  writes:
>
>> Create a new driver for the da8xx DDR2/mDDR controller and implement
>> support for writing to the Peripheral Bus Burst Priority Register.
>>
>> Signed-off-by: Bartosz Golaszewski 
>> ---
>>  .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++
>>  drivers/memory/Kconfig |   8 +
>>  drivers/memory/Makefile|   1 +
>>  drivers/memory/da8xx-ddrctl.c  | 175 
>> +
>>  4 files changed, 204 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>>  create mode 100644 drivers/memory/da8xx-ddrctl.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> new file mode 100644
>> index 000..7e271dd
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> @@ -0,0 +1,20 @@
>> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory 
>> controller
>> +
>> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs 
>> features
>> +a set of registers which allow to tweak the controller's behavior.
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible:   "ti,da850-ddr-controller" - for da850 SoC based 
>> boards
>> +- reg:  a tuple containing the base address of the 
>> memory
>> +controller and the size of the memory area to map
>> +
>> +Example for da850 shown below.
>> +
>> +ddrctl {
>> +compatible = "ti,da850-ddr-controller";
>> +reg = <0xB000 0x100>;
>> +};
>
> Axel's series for the USB PHY reminded me that the PHY also has some
> config registers in this same area, and his series creates a syscon for
> a similar range of registers.
>
> Could you create a syscon for the SYSCFG0 registers, which would then
> be used by ths driver and your other drivers/bus driver?  Then the
> binding  would just reference the sysconf via phandle, and your driver
> can use syscon_regmap_lookup_by_phandle()

Nevermind. I though that the config register in this driver was also in
SYSCFG0, but I see now that it's in the reg region of the DDR controller
itself, so no syscon is needed.

Kevin

[Nouveau] noveau: emergency shutdown handling is overcomplex and broken

[Pavel Machek]

On Tue 2016-10-25 13:09:25, Karol Herbst wrote:
> Thanks for the pointer.
> 
> But I don't like this patch. If you find a bug, make a bug report or
> just fix it if you know the fix already. Or write something in
> IRC. Or

I found a bug, and this is my bug report. Can you take care and fix
it?

Pavel



> write on the Mailing list as a general question or something else
> 
> But I really don't agree on doing it this way. You would have needed
> like the same amount of time to actual fix the problem.
> 
> Anyway, for adding a printk:
> 
> struct nvkm_subdev *subdev = >subdev;
> nvkm_error(subdev, "message");
> 
> 2016-10-25 12:50 GMT+02:00 Pavel Machek :
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
> > index b9703c0..adb1deb 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
> > @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum 
> > nvkm_therm_thrs thrs,
> > struct work_struct *work;
> >
> > work = kmalloc(sizeof(*work), GFP_ATOMIC);
> > +   /* FIXME:
> > +  1) this is total overkill, orderly_poweroff() 
> > already
> > +  uses schedule_work internally
> > +  2) it would  be good to at least printk what is 
> > going on
> > +   */
> > if (work) {
> > INIT_WORK(work, nv_poweroff_work);
> > schedule_work(work);
> >
> > GFP_ATOMIC is not reliable. Plus, see the fixme.
> >
> > Best regards,
> > 
> > Pavel
> >
> > --
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) 
> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> >
> > ___
> > Nouveau mailing list
> > Nouveau at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161025/fd2c04d2/attachment.sig>

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

[Thomas Gleixner]

On Mon, 24 Oct 2016, Dave Airlie wrote:
> A recent change to the mm code in:
> 87744ab3832b83ba71b931f86f9cfdb000d07da5

nit: 12 digits of the SHA1 are sufficient :)

> +int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
> +{
> + enum page_cache_mode type = _PAGE_CACHE_MODE_WC;

Empty line between variable declaration and code please

> + return io_reserve_memtype(start, start + size, );

Other than that:

Reviewed-by: Thomas Gleixner 

[Nouveau] noveau: emergency shutdown handling is overcomplex and broken

[Karol Herbst]

Thanks for the pointer.

But I don't like this patch. If you find a bug, make a bug report or
just fix it if you know the fix already. Or write something in IRC. Or
write on the Mailing list as a general question or something else

But I really don't agree on doing it this way. You would have needed
like the same amount of time to actual fix the problem.

Anyway, for adding a printk:

struct nvkm_subdev *subdev = >subdev;
nvkm_error(subdev, "message");

2016-10-25 12:50 GMT+02:00 Pavel Machek :
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
> index b9703c0..adb1deb 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
> @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum 
> nvkm_therm_thrs thrs,
> struct work_struct *work;
>
> work = kmalloc(sizeof(*work), GFP_ATOMIC);
> +   /* FIXME:
> +  1) this is total overkill, orderly_poweroff() 
> already
> +  uses schedule_work internally
> +  2) it would  be good to at least printk what is 
> going on
> +   */
> if (work) {
> INIT_WORK(work, nv_poweroff_work);
> schedule_work(work);
>
> GFP_ATOMIC is not reliable. Plus, see the fixme.
>
> Best regards,
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>

[PATCH] drm/radeon: drop register readback in cayman_cp_int_cntl_setup

[Lucas Stach]

Am Dienstag, den 25.10.2016, 09:21 +0200 schrieb Christian König:
> Am 24.10.2016 um 23:32 schrieb Lucas Stach:
> > 
> > The read is taking a considerable amount of time (about 50us on
> > this
> > machine). The register does not ever hold anything other than the
> > ring
> > ID that is updated in this exact function, so there is no need for
> > the read modify write cycle.
> > 
> > This chops off a big chunk of the time spent in hardirq disabled
> > context, as this function is called multiple times in the interrupt
> > handler. With this change applied radeon won't show up in the list
> > of the worst IRQ latency offenders anymore, where it was a regular
> > before.
> > 
> > Signed-off-by: Lucas Stach 
> 
> Ups, and to make it even worse SRBM_GFX_CNTL is explicitly documented
> to 
> be a write only register.
> 
> That it takes a considerable amount of time is probably because the
> SRBM 
> runs into an error condition when you read it.
> 
> So patch is Reviewed-by: Christian König 
> and 
> please also add a CC:stable on that.
> 
> Do we have other occasions where we try to use a read modify write
> cycle?

No, that's the only occasion where this specific register is read back
(including newer generations that use it like cik).

Regards,
Lucas

[PATCH v4] dma-buf: Rename struct fence to dma_fence

[Chris Wilson]

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

A consensus was reached in
https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
that making clear this fence applies to DMA operations was a good thing.
Since then the patch has grown a bit as usage increases, so hopefully it
remains a good thing!

(v2...: rebase, rerun spatch)
v3: Compile on msm, spotted a manual fixup that I broke.
v4: Try again for msm, sorry Daniel

coccinelle script:
@@

@@
- struct fence
+ struct dma_fence
@@

@@
- struct fence_ops
+ struct dma_fence_ops
@@

@@
- struct fence_cb
+ struct dma_fence_cb
@@

@@
- struct fence_array
+ struct dma_fence_array
@@

@@
- enum fence_flag_bits
+ enum dma_fence_flag_bits
@@

@@
(
- fence_init
+ dma_fence_init
|
- fence_release
+ dma_fence_release
|
- fence_free
+ dma_fence_free
|
- fence_get
+ dma_fence_get
|
- fence_get_rcu
+ dma_fence_get_rcu
|
- fence_put
+ dma_fence_put
|
- fence_signal
+ dma_fence_signal
|
- fence_signal_locked
+ dma_fence_signal_locked
|
- fence_default_wait
+ dma_fence_default_wait
|
- fence_add_callback
+ dma_fence_add_callback
|
- fence_remove_callback
+ dma_fence_remove_callback
|
- fence_enable_sw_signaling
+ dma_fence_enable_sw_signaling
|
- fence_is_signaled_locked
+ dma_fence_is_signaled_locked
|
- fence_is_signaled
+ dma_fence_is_signaled
|
- fence_is_later
+ dma_fence_is_later
|
- fence_later
+ dma_fence_later
|
- fence_wait_timeout
+ dma_fence_wait_timeout
|
- fence_wait_any_timeout
+ dma_fence_wait_any_timeout
|
- fence_wait
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- fence_array_create
+ dma_fence_array_create
|
- to_fence_array
+ to_dma_fence_array
|
- fence_is_array
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
 (
 ...
 )

Signed-off-by: Chris Wilson 
Reviewed-by: Gustavo Padovan 
Acked-by: Sumit Semwal 
Acked-by: Christian König 
---
 Documentation/sync_file.txt|  14 +-
 drivers/base/Kconfig   |   6 +-
 drivers/dma-buf/Kconfig|   2 +-
 drivers/dma-buf/Makefile   |   2 +-
 drivers/dma-buf/dma-buf.c  |  28 +--
 .../dma-buf/{fence-array.c => dma-fence-array.c}   |  91 
 drivers/dma-buf/{fence.c => dma-fence.c}   | 199 -
 drivers/dma-buf/reservation.c  |  94 
 drivers/dma-buf/seqno-fence.c  |  18 +-
 drivers/dma-buf/sw_sync.c  |  48 ++---
 drivers/dma-buf/sync_debug.c   |  13 +-
 drivers/dma-buf/sync_debug.h   |   9 +-
 drivers/dma-buf/sync_file.c|  63 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  54 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  58 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c |  24 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |  48 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  26 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  26 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  79 +++
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  12 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/si_dma.c|   6 +-
 drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h|   4 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c  |  67 +++---
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  |  26 +--
 drivers/gpu/drm/amd/scheduler/sched_fence.c|  48 +++--
 drivers/gpu/drm/drm_atomic.c 

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Shuah Khan]

On 10/25/2016 11:57 AM, Tobias Jakobi wrote:
> Hello Shuah,
> 
> 
> Shuah Khan wrote:
>> On 10/19/2016 04:27 PM, Shuah Khan wrote:
>>> On 10/19/2016 08:16 AM, Inki Dae wrote:
 Hi Shuah,

 2016-10-13 8:11 GMT+09:00 Shuah Khan :
> Hi Inki,
>
> On 08/15/2016 10:40 PM, Inki Dae wrote:
>
>>>
>>> okay the very first commit that added IOMMU support
>>> introduced the code that rejects non-contig gem memory
>>> type without IOMMU.
>>>
>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>> Author: Inki Dae 
>>> Date:   Sat Oct 20 07:53:42 2012 -0700
>>>
>>> drm/exynos: add iommu support for exynos drm framework
>>>
>
> I haven't given up on this yet. I am still seeing the following failure:
>
> Additional debug messages I added:
> [   15.287403] exynos_drm_gem_create_ioctl() 1
> [   15.287419] exynos_drm_gem_create() flags 1
>
> [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous 
> GEM memory is not supported.
>
> Additional debug message I added:
> [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
> framebuffer
>
> This is what happens:
>
> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG 
> request
> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>check_fb_gem_memory_type()
>
> At this point, there is no recovery and lightdm fails
>
> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
> allocations are not supported in some exynos drm versions: The following
> commit introduced this change:
>
> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>
> excerpts from the diff:-   if (create_gem->buf_type == 
> ARMSOC_BO_SCANOUT)
> -   create_exynos.flags = EXYNOS_BO_CONTIG;
> -   else
> -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
> +
> +   /* Contiguous allocations are not supported in some exynos drm 
> versions.
> +* When they are supported all allocations are effectively 
> contiguous
> +* anyway, so for simplicity we always request non contiguous 
> buffers.
> +*/
> +   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>

 Above comment, "Contiguous allocations are not supported in some
 exynos drm versions.", seems wrong assumption.
 The root cause, contiguous allocation is not supported, would be that
 they used Linux kernel which didn't have CMA region enough - as
 default 16MB, or didn't declare CMA region enough for the DMA device.
 So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
 should manage the error case if the allocation failed.
>>>
>>> This assumption doesn't sound correct and forcing NONCONTIG isn't right
>>> either. 
>>>

> There might have been logic on exynos_drm that forced Contig when it 
> coudn't
> support NONCONTIG. At least, that is what this comment suggests. This 
> assumption
> doesn't appear to be a good one and not sure if this change was made to 
> fix a bug.
>
> After the IOMMU support, this assumption is no longer true. Hence, with 
> IOMMU
> support, latest kernels have a mismatch with the installed 
> xf86-video-armsoc
>
> This is what I am running into. This leads to the following question:
>
> 1. How do we ensure exynos_drm kernel changes don't break user-space
>specifically xf86-video-armsoc
> 2. This seems to have gone undetected for a while. I see a change in
>exynos_drm_gem_dumb_create() that is probably addressing this type
>of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>handling for IOMMU NONCONTIG case.

 Seems this patch has a problem. This patch forces to flag NONCONTIG if
 iommu is enabled. The flag should be depend on the argument from
 user-space.
 I.e., if user-space requested a gem allocation with CONTIG flag, then
 Exynos drm driver should allocate contiguous memory even though iommu
 is enabled.

>
> Anyway, I am interested in getting the exynos_drm kernel side code
> and xf86-video-armsoc in sync to resolve the issue.
>
> Could you recommend a going forward plan?

 My opinion are,

 1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
>>
>> Okay more on this. I fixed xf86-video-armso to ask for EXYNOS_BO_CONTIG
>> for ARMSOC_BO_SCANOUT and EXYNOS_BO_NONCONTIG in all other cases.
>>
>> Revert of the commit: 3be1f6273441fe95dd442f44064387322e16b7e9
>>
>> With this change, now display manager starts just fine. However, it turns
>> out xf86-video-armsoc is 

noveau: emergency shutdown handling is overcomplex and broken

[Pavel Machek]

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
index b9703c0..adb1deb 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
@@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum 
nvkm_therm_thrs thrs,
struct work_struct *work;

work = kmalloc(sizeof(*work), GFP_ATOMIC);
+   /* FIXME:
+  1) this is total overkill, orderly_poweroff() already
+  uses schedule_work internally
+  2) it would  be good to at least printk what is 
going on
+   */
if (work) {
INIT_WORK(work, nv_poweroff_work);
schedule_work(work);

GFP_ATOMIC is not reliable. Plus, see the fixme.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161025/253afc2e/attachment.sig>

[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API

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

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

--- Comment #19 from Andy Furniss  ---
(In reply to Marek Olšák from comment #18)
> (In reply to Andy Furniss from comment #17)
> > mpv: state_tracker/st_sampler_view.c:481:
> > st_get_texture_sampler_view_from_stobj: Assertion `stObj->base.MinLayer ==
> > view->u.tex.first_layer' failed.
> 
> That's unrelated.

Oops, yea, should have checked better - just it needed the same version/command
line with mpv as this bug to trigger, but it does start later =

commit e5cc84dd43be066c1dd418e32f5ad258e31a150a

Author: Brian Paul 
Date:   Fri Sep 30 16:41:46 2016 -0600

st/mesa: optimize pipe_sampler_view validation

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

[Bug 98405] No signal on HDMI output after upgrade to kernel 4.8.3-1

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

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

--- Comment #2 from petr.m at seznam.cz ---
https://bugzilla.suse.com/show_bug.cgi?id=1006420

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

[Bug 98405] No signal on HDMI output after upgrade to kernel 4.8.3-1

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

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

--- Comment #1 from petr.m at seznam.cz ---
Created attachment 127540
  --> https://bugs.freedesktop.org/attachment.cgi?id=127540=edit
Kernel mesages for 4.7.6-1 and 4.8.3-1 kernels

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

[PATCH] drm: convert DT component matching to component_match_add_release()

[Sean Paul]

On Wed, Oct 19, 2016 at 6:28 AM, Russell King
 wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King 

Applied to drm-misc, thanks!

Sean

> ---
> Can we please get this patch from May merged into the drm-misc or
> whatever trees so that we don't end up with conflicts?  I've no idea
> who looks after drm-misc, as they have _still_ failed to add
> themselves to MAINTAINERS.
>
>  drivers/gpu/drm/arm/hdlcd_drv.c |  3 ++-
>  drivers/gpu/drm/arm/malidp_drv.c|  4 +++-
>  drivers/gpu/drm/armada/armada_drv.c |  2 +-
>  drivers/gpu/drm/drm_of.c| 28 
> +++--
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  5 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  4 +++-
>  drivers/gpu/drm/msm/msm_drv.c   | 12 ++-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  6 --
>  drivers/gpu/drm/sti/sti_drv.c   |  5 +++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c   |  3 ++-
>  drivers/gpu/drm/tilcdc/tilcdc_external.c|  4 +++-
>  include/drm/drm_of.h| 12 +++
>  13 files changed, 73 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index fb6a418ce6be..6477d1a65266 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
> return -EAGAIN;
> }
>
> -   component_match_add(>dev, , compare_dev, port);
> +   drm_of_component_match_add(>dev, , compare_dev, port);
> +   of_node_put(port);
>
> return component_master_add_with_match(>dev, _master_ops,
>match);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358b8f15..9f4739452a25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device 
> *pdev)
> return -EAGAIN;
> }
>
> -   component_match_add(>dev, , malidp_compare_dev, port);
> +   drm_of_component_match_add(>dev, , malidp_compare_dev,
> +  port);
> +   of_node_put(port);
> return component_master_add_with_match(>dev, _master_ops,
>match);
>  }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 1e0e68f608e4..94e46da9a758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
> continue;
> }
>
> -   component_match_add(dev, match, compare_of, remote);
> +   drm_of_component_match_add(dev, match, compare_of, remote);
> of_node_put(remote);
> }
>  }
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index bc98bb94264d..47848ed8ca48 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -6,6 +6,11 @@
>  #include 
>  #include 
>
> +static void drm_release_of(struct device *dev, void *data)
> +{
> +   of_node_put(data);
> +}
> +
>  /**
>   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>   * @dev: DRM device
> @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>
>  /**
> + * drm_of_component_match_add - Add a component helper OF node match rule
> + * @master: master device
> + * @matchptr: component match pointer
> + * @compare: compare function used for matching component
> + * @node: of_node
> + */
> +void drm_of_component_match_add(struct device *master,
> +   struct component_match **matchptr,
> +   int (*compare)(struct device *, void *),
> +   struct device_node *node)
> +{
> +   of_node_get(node);
> +   component_match_add_release(master, matchptr, drm_release_of,
> +   compare, node);
> +}
> +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> +
> +/**
>   * drm_of_component_probe - Generic probe function for a component based 
> master
>   * @dev: master device containing the OF node
>   * @compare_of: compare function used for matching components
> @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
> continue;
> }
>
> -   component_match_add(dev, , compare_of, port);
> +   drm_of_component_match_add(dev, , compare_of, port);
>   

[PATCH v3] dma-buf: Rename struct fence to dma_fence

[Chris Wilson]

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

A consensus was reached in
https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
that making clear this fence applies to DMA operations was a good thing.
Since then the patch has grown a bit as usage increases, so hopefully it
remains a good thing!

(v2...: rebase, rerun spatch)
v3: Compile on msm, spotted a manual fixup that I broke.

coccinelle script:
@@

@@
- struct fence
+ struct dma_fence
@@

@@
- struct fence_ops
+ struct dma_fence_ops
@@

@@
- struct fence_cb
+ struct dma_fence_cb
@@

@@
- struct fence_array
+ struct dma_fence_array
@@

@@
- enum fence_flag_bits
+ enum dma_fence_flag_bits
@@

@@
(
- fence_init
+ dma_fence_init
|
- fence_release
+ dma_fence_release
|
- fence_free
+ dma_fence_free
|
- fence_get
+ dma_fence_get
|
- fence_get_rcu
+ dma_fence_get_rcu
|
- fence_put
+ dma_fence_put
|
- fence_signal
+ dma_fence_signal
|
- fence_signal_locked
+ dma_fence_signal_locked
|
- fence_default_wait
+ dma_fence_default_wait
|
- fence_add_callback
+ dma_fence_add_callback
|
- fence_remove_callback
+ dma_fence_remove_callback
|
- fence_enable_sw_signaling
+ dma_fence_enable_sw_signaling
|
- fence_is_signaled_locked
+ dma_fence_is_signaled_locked
|
- fence_is_signaled
+ dma_fence_is_signaled
|
- fence_is_later
+ dma_fence_is_later
|
- fence_later
+ dma_fence_later
|
- fence_wait_timeout
+ dma_fence_wait_timeout
|
- fence_wait_any_timeout
+ dma_fence_wait_any_timeout
|
- fence_wait
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- fence_array_create
+ dma_fence_array_create
|
- to_fence_array
+ to_dma_fence_array
|
- fence_is_array
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
 (
 ...
 )

Signed-off-by: Chris Wilson 
Reviewed-by: Gustavo Padovan 
Acked-by: Sumit Semwal 
Acked-by: Christian König 
---
 Documentation/sync_file.txt|   8 +-
 drivers/base/Kconfig   |   6 +-
 drivers/dma-buf/Makefile   |   2 +-
 drivers/dma-buf/dma-buf.c  |  28 +--
 .../dma-buf/{fence-array.c => dma-fence-array.c}   |  91 
 drivers/dma-buf/{fence.c => dma-fence.c}   | 195 -
 drivers/dma-buf/reservation.c  |  94 
 drivers/dma-buf/seqno-fence.c  |  18 +-
 drivers/dma-buf/sw_sync.c  |  48 ++---
 drivers/dma-buf/sync_debug.c   |  13 +-
 drivers/dma-buf/sync_debug.h   |   9 +-
 drivers/dma-buf/sync_file.c|  63 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  54 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  58 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c |  24 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |  48 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  26 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  26 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  79 +++
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  12 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/si_dma.c|   6 +-
 drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h|   4 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c  |  67 +++---
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  |  26 +--
 drivers/gpu/drm/amd/scheduler/sched_fence.c|  48 +++--
 drivers/gpu/drm/drm_atomic.c   |   2 +-
 drivers/gpu/drm/drm_atomic_helper.c|   8 +-
 

[Intel-gfx] [PATCH v2] dma-buf: Rename struct fence to dma_fence

[Daniel Vetter]

On Tue, Oct 25, 2016 at 10:25:49AM +0100, Chris Wilson wrote:
> I plan to usurp the short name of struct fence for a core kernel struct,
> and so I need to rename the specialised fence/timeline for DMA
> operations to make room.
> 
> A consensus was reached in
> https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
> that making clear this fence applies to DMA operations was a good thing.
> Since then the patch has grown a bit as usage increases, so hopefully it
> remains a good thing!
> 
> (v2...: rebase, rerun spatch)
> 
> coccinelle script:
> @@
> 
> @@
> - struct fence
> + struct dma_fence
> @@
> 
> @@
> - struct fence_ops
> + struct dma_fence_ops
> @@
> 
> @@
> - struct fence_cb
> + struct dma_fence_cb
> @@
> 
> @@
> - struct fence_array
> + struct dma_fence_array
> @@
> 
> @@
> - enum fence_flag_bits
> + enum dma_fence_flag_bits
> @@
> 
> @@
> (
> - fence_init
> + dma_fence_init
> |
> - fence_release
> + dma_fence_release
> |
> - fence_free
> + dma_fence_free
> |
> - fence_get
> + dma_fence_get
> |
> - fence_get_rcu
> + dma_fence_get_rcu
> |
> - fence_put
> + dma_fence_put
> |
> - fence_signal
> + dma_fence_signal
> |
> - fence_signal_locked
> + dma_fence_signal_locked
> |
> - fence_default_wait
> + dma_fence_default_wait
> |
> - fence_add_callback
> + dma_fence_add_callback
> |
> - fence_remove_callback
> + dma_fence_remove_callback
> |
> - fence_enable_sw_signaling
> + dma_fence_enable_sw_signaling
> |
> - fence_is_signaled_locked
> + dma_fence_is_signaled_locked
> |
> - fence_is_signaled
> + dma_fence_is_signaled
> |
> - fence_is_later
> + dma_fence_is_later
> |
> - fence_later
> + dma_fence_later
> |
> - fence_wait_timeout
> + dma_fence_wait_timeout
> |
> - fence_wait_any_timeout
> + dma_fence_wait_any_timeout
> |
> - fence_wait
> + dma_fence_wait
> |
> - fence_context_alloc
> + dma_fence_context_alloc
> |
> - fence_array_create
> + dma_fence_array_create
> |
> - to_fence_array
> + to_dma_fence_array
> |
> - fence_is_array
> + dma_fence_is_array
> |
> - trace_fence_emit
> + trace_dma_fence_emit
> |
> - FENCE_TRACE
> + DMA_FENCE_TRACE
> |
> - FENCE_WARN
> + DMA_FENCE_WARN
> |
> - FENCE_ERR
> + DMA_FENCE_ERR
> )
>  (
>  ...
>  )
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Gustavo Padovan 
> Acked-by: Sumit Semwal 
> Acked-by: Christian König 

Let's see how bad of a conflict-ride this is going to be. Applied to
drm-misc, thanks.
-Daniel

> ---
>  Documentation/sync_file.txt|   8 +-
>  drivers/base/Kconfig   |   6 +-
>  drivers/dma-buf/Makefile   |   2 +-
>  drivers/dma-buf/dma-buf.c  |  28 +--
>  .../dma-buf/{fence-array.c => dma-fence-array.c}   |  91 
>  drivers/dma-buf/{fence.c => dma-fence.c}   | 195 -
>  drivers/dma-buf/reservation.c  |  94 
>  drivers/dma-buf/seqno-fence.c  |  18 +-
>  drivers/dma-buf/sw_sync.c  |  48 ++---
>  drivers/dma-buf/sync_debug.c   |  13 +-
>  drivers/dma-buf/sync_debug.h   |   9 +-
>  drivers/dma-buf/sync_file.c|  63 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  54 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  58 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c |  24 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |  48 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  10 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  26 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  26 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  80 +++
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   6 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   6 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   6 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  12 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   6 +-
>  

[PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

[Daniel Vetter]

On Tue, Oct 25, 2016 at 10:52:33AM +0100, Brian Starkey wrote:
> Hi Daniel,
> 
> On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey  
> > wrote:
> > > > 
> > > > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > > > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > > > index f4315bc..6e6fca2 100644
> > > > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > > > @@ -1369,7 +1369,6 @@ const struct drm_connector_helper_funcs
> > > > > tda998x_connector_helper_funcs = {
> > > > > 
> > > > >  static void tda998x_connector_destroy(struct drm_connector 
> > > > > *connector)
> > > > >  {
> > > > > -   drm_connector_unregister(connector);
> > > > > drm_connector_cleanup(connector);
> > > > >  }
> > > > > 
> > > > > @@ -1441,16 +1440,10 @@ static int tda998x_bind(struct device *dev,
> > > > > struct device *master, void *data)
> > > > > if (ret)
> > > > > goto err_connector;
> > > > > 
> > > > > -   ret = drm_connector_register(>connector);
> > > > > -   if (ret)
> > > > > -   goto err_sysfs;
> > > > > -
> > > > 
> > > > 
> > > > Instead of smashing all these patches into one, what about checking here
> > > > for midlayer driver set with:
> > > > 
> > > > /* register here for drivers still using midlayer load/unload */
> > > > if (dev->driver->load)
> > > > drm_connector_register(connector),
> > > > 
> > > > Similar in other places. That way we wouldn't need to switch the world 
> > > > in
> > > > one patch.
> > > 
> > > 
> > > I don't think that helps. If we do that in isolation (first), then
> > > mali-dp and hdlcd won't get their connectors registered because their
> > > bind order is:
> > > 
> > > drm_dev_register();
> > > component_bind_all();
> > > 
> > > If we change the mali-dp/hdlcd bind order first, then tda998x will
> > > explode on drm_connector_register() until it's patched to remove that.
> > > 
> > > As I mentioned in my mail to Russell, the only way I can see to avoid
> > > patching all three drivers in one go is:
> > >  1) Add (probably open-coded) drm_connector_register_all() to the end
> > > of bind in hdlcd and mali-dp
> > >  2) Patch tda998x to remove drm_connector_register()
> > >  3) Reorder hdlcd/mali-dp bind and remove the connector registration
> > > added in 1)
> > > 
> > > We can do that, but it's extra churn for the same result, and none of
> > > the 5 patches will really make sense in isolation anyway.
> > 
> > I thought there's also armada to take care of, which this patch would
> > break? Maybe even another driver, so the hack would still be useful
> > for those other drivers.
> 
> OK it seems like this situation has got very confused. In short, this
> patch does not break armada. Russell previously tested the tda998x
> patch against armada and reported no issues.
> Drivers with a ->load() callback don't need to register the connector
> anymore, because drm_dev_register() does it for them.
> 
> As far as I know, this patch touching these three drivers is
> sufficient to allow all current users of tda998x to continue using it,
> whilst also allowing armada and tilcdc to be de-midlayered.

Ah, makes sense. Should I apply this to drm-misc so it's in a shared tree?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm/msm: Don't provide 'is_enabled' PLL clk_ops

[Archit Taneja]

The DSI/HDMI PLLs in MSM require resources like interface clocks, power
domains to be enabled before we can access their registers.

The clock framework doesn't have a mechanism at the moment where we can
tie such resources to a clock, so we make sure that the KMS driver enables
these resources whenever a PLL is expected to be in use.

One place where we can't ensure the resource dependencies are met is when
the clock framework tries to disable unused clocks. The KMS driver doesn't
know when the clock framework calls the is_enabled clk_op, and hence can't
enable interface clocks/power domains beforehand.

We remove the is_enabled clk_ops from the PLL clocks for now since they
aren't mandatory. This needs to be revisited, since bootloaders can enable
display, the enable count maintained by clock framework wouldn't work in
such cases.

Cc: Stephen Boyd 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c  | 10 --
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 10 --
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c| 13 -
 3 files changed, 33 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
index 598fdaf..80b7fc3 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
@@ -248,15 +248,6 @@ static int dsi_pll_28nm_clk_set_rate(struct clk_hw *hw, 
unsigned long rate,
return 0;
 }

-static int dsi_pll_28nm_clk_is_enabled(struct clk_hw *hw)
-{
-   struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
-   struct dsi_pll_28nm *pll_28nm = to_pll_28nm(pll);
-
-   return pll_28nm_poll_for_ready(pll_28nm, POLL_MAX_READS,
-   POLL_TIMEOUT_US);
-}
-
 static unsigned long dsi_pll_28nm_clk_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
 {
@@ -312,7 +303,6 @@ static unsigned long dsi_pll_28nm_clk_recalc_rate(struct 
clk_hw *hw,
.recalc_rate = dsi_pll_28nm_clk_recalc_rate,
.prepare = msm_dsi_pll_helper_clk_prepare,
.unprepare = msm_dsi_pll_helper_clk_unprepare,
-   .is_enabled = dsi_pll_28nm_clk_is_enabled,
 };

 /*
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
index 38c90e1..b3d3ec7 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
@@ -156,15 +156,6 @@ static int dsi_pll_28nm_clk_set_rate(struct clk_hw *hw, 
unsigned long rate,
return 0;
 }

-static int dsi_pll_28nm_clk_is_enabled(struct clk_hw *hw)
-{
-   struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
-   struct dsi_pll_28nm *pll_28nm = to_pll_28nm(pll);
-
-   return pll_28nm_poll_for_ready(pll_28nm, POLL_MAX_READS,
-   POLL_TIMEOUT_US);
-}
-
 static unsigned long dsi_pll_28nm_clk_recalc_rate(struct clk_hw *hw,
  unsigned long parent_rate)
 {
@@ -206,7 +197,6 @@ static unsigned long dsi_pll_28nm_clk_recalc_rate(struct 
clk_hw *hw,
.recalc_rate = dsi_pll_28nm_clk_recalc_rate,
.prepare = msm_dsi_pll_helper_clk_prepare,
.unprepare = msm_dsi_pll_helper_clk_unprepare,
-   .is_enabled = dsi_pll_28nm_clk_is_enabled,
 };

 /*
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
index aa94a55..f3334e8 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
@@ -672,25 +672,12 @@ static void hdmi_8996_pll_unprepare(struct clk_hw *hw)
 {
 }

-static int hdmi_8996_pll_is_enabled(struct clk_hw *hw)
-{
-   struct hdmi_pll_8996 *pll = hw_clk_to_pll(hw);
-   u32 status;
-   int pll_locked;
-
-   status = hdmi_pll_read(pll, REG_HDMI_PHY_QSERDES_COM_C_READY_STATUS);
-   pll_locked = status & BIT(0);
-
-   return pll_locked;
-}
-
 static struct clk_ops hdmi_8996_pll_ops = {
.set_rate = hdmi_8996_pll_set_clk_rate,
.round_rate = hdmi_8996_pll_round_rate,
.recalc_rate = hdmi_8996_pll_recalc_rate,
.prepare = hdmi_8996_pll_prepare,
.unprepare = hdmi_8996_pll_unprepare,
-   .is_enabled = hdmi_8996_pll_is_enabled,
 };

 static const char * const hdmi_pll_parents[] = {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/2] drm/msm/dsi: Queue HPD helper work in attach/detach callbacks

[Archit Taneja]

The msm/dsi host drivers calls drm_helper_hpd_irq_event in the
mipi_dsi_host attach/detatch callbacks.

mipi_dsi_attach()/mipi_dsi_detach() from a panel/bridge
driver could be called from a context where the drm_device's
mode_config.mutex is already held, resulting in a deadlock.
Queue it as work instead.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index f05ed0e..6f24002 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -139,6 +139,7 @@ struct msm_dsi_host {

u32 err_work_state;
struct work_struct err_work;
+   struct work_struct hpd_work;
struct workqueue_struct *workqueue;

/* DSI 6G TX buffer*/
@@ -1294,6 +1295,14 @@ static void dsi_sw_reset_restore(struct msm_dsi_host 
*msm_host)
wmb();  /* make sure dsi controller enabled again */
 }

+static void dsi_hpd_worker(struct work_struct *work)
+{
+   struct msm_dsi_host *msm_host =
+   container_of(work, struct msm_dsi_host, hpd_work);
+
+   drm_helper_hpd_irq_event(msm_host->dev);
+}
+
 static void dsi_err_worker(struct work_struct *work)
 {
struct msm_dsi_host *msm_host =
@@ -1480,7 +1489,7 @@ static int dsi_host_attach(struct mipi_dsi_host *host,

DBG("id=%d", msm_host->id);
if (msm_host->dev)
-   drm_helper_hpd_irq_event(msm_host->dev);
+   queue_work(msm_host->workqueue, _host->hpd_work);

return 0;
 }
@@ -1494,7 +1503,7 @@ static int dsi_host_detach(struct mipi_dsi_host *host,

DBG("id=%d", msm_host->id);
if (msm_host->dev)
-   drm_helper_hpd_irq_event(msm_host->dev);
+   queue_work(msm_host->workqueue, _host->hpd_work);

return 0;
 }
@@ -1748,6 +1757,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
/* setup workqueue */
msm_host->workqueue = alloc_ordered_workqueue("dsi_drm_work", 0);
INIT_WORK(_host->err_work, dsi_err_worker);
+   INIT_WORK(_host->hpd_work, dsi_hpd_worker);

msm_dsi->host = _host->base;
msm_dsi->id = msm_host->id;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 0/2] drm/msm: Fixes for issues seen on DB410c

[Archit Taneja]

The ADV7533 driver and DT bindings for MDSS hardware are both available
in 4.9, which is sufficient to boot with HDMI display on DB410c.

With the drm/msm and ADV7533 enabled, the system hangs during boot.
One reason is that the PLL driver tries to access registers without
the necessary interface clocks enabled. The other reason is a
deadlock caused by calling drm_hpd_helper_irq_event in a context
that might already hold drm_device's mode_config.mutex.

Archit Taneja (2):
  drm/msm/dsi: Queue HPD helper work in attach/detach callbacks
  drm/msm: Don't provide 'is_enabled' PLL clk_ops

 drivers/gpu/drm/msm/dsi/dsi_host.c  | 14 --
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c  | 10 --
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 10 --
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c| 13 -
 4 files changed, 12 insertions(+), 35 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[RFC] ARM: memory: da8xx-ddrctl: new driver

[Bartosz Golaszewski]

2016-10-24 19:00 GMT+02:00 Mark Rutland :
> On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
>> +
>> + dev = >dev;
>> + node = dev->of_node;
>> +
>> + /* Find the board name. */
>> + for (parent = node;
>> +  !of_node_is_root(parent);
>> +  parent = of_get_parent(parent));
>> +
>> + ret = of_property_read_string(parent, "compatible", );
>> + if (ret) {
>> + dev_err(dev, "unable to read the soc model\n");
>> + return ret;
>> + }
>
> I can see that you want to expose sysfs knobs for this, but is it really
> necessary to match boards like this? It's very fragile, and commits us
> to maintaining a database of board data (i.e. a board file).
>
> I am very much not keen on that.
>

I Mark,

I don't want to expose any new sysfs interface.

The initial idea was to follow the way the ti-aemif driver is
implemented and expose DT bindings for the memory controller knobs
(initially only the Peripheral Bus Burst Priority Register, tweaking
which is required to make LCDC work correctly on da850 based boards as
mentioned by Kevin). This was rejected as it's not hardware
description but configuration, so it should not be controlled by DT
properties.

The correct approach for this kind of performance knobs doesn't exist
yet. There was a BoF during this year's ELCE in Berlin during which
several ideas were discussed, but no code has been written so far.

Using sysfs would have exactly the same disadvantage - committing to a
stable interface that would have to be maintained indefinitely.

In the end it was decided that a fairly good, temporary solution would
be to create a driver for the da850 DDR controller which would
hardcode the required tweaks for several boards (as the LCDC issue is
known to affect more TI SoCs and boards). Once a framework for
performance knobs is implemented and merged, it would be easy to port
the driver to it as we would not have implemented any stable
interface.

The same solution would be used for the SYSCFG registers on the da8xx SoCs.

Hope that clarifies the need for this patch a bit. I will address all
other issues in v2.

Best regards,
Bartosz Golaszewski

[Bug 176961] resume from suspend not working with nvidia980 Ti, drivers 352 - 370, kernels 3.16 - 4.4

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

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

--- Comment #4 from emailjonathananderson-fedora at yahoo.com ---
Good question. 
Can you please direct me how to test this?

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

[PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

[Brian Starkey]

On Tue, Oct 25, 2016 at 12:19:19PM +0200, Daniel Vetter wrote:
>On Tue, Oct 25, 2016 at 10:52:33AM +0100, Brian Starkey wrote:
>
>Ah, makes sense. Should I apply this to drm-misc so it's in a shared tree?

Honestly, I don't know. I didn't entirely follow what it was Russell
wanted in terms of getting this merged:

>On Sat, Oct 22, 2016 at 02:40:22PM +0100, Russell King - ARM Linux wrote:
>>So, what I would like to see is a single patch against Linus' 4.8.0
>>commit fixing mali-dp, hdlcd and any other driver, together with
>>removing drm_connector_register() from TDA998x.  This is so the patch
>>can be shared between all interested parties without forcing everyone
>>to 4.9-rc1.  Looking at the diff between 4.8 and 4.9-rc1 for
>>drivers/gpu/drm/arm, that shouldn't result in any merge conflicts -
>>and if you want to follow on from that with 4.9-rc1 development, you
>>can always merge 4.9-rc1 on top of that commit.

Looks like Jyri's series which depends on this is also dependent on
Russell's tree, so might be best to wait for him to get back online.

-Brian

>-Daniel
>-- 
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
>

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

[Ingo Molnar]

* Dave Airlie  wrote:

> A recent change to the mm code in:
> 87744ab3832b83ba71b931f86f9cfdb000d07da5
> mm: fix cache mode tracking in vm_insert_mixed()
> 
> started enforcing checking the memory type against the registered list for
> amixed pfn insertion mappings. It happens that the drm drivers for a number
> of gpus relied on this being broken. Currently the driver only inserted
> VRAM mappings into the tracking table when they came from the kernel,
> and userspace mappings never landed in the table. This led to a regression
> where all the mapping end up as UC instead of WC now.
> 
> I've considered a number of solutions but since this needs to be fixed
> in fixes and not next, and some of the solutions were going to introduce
> overhead that hadn't been there before I didn't consider them viable at
> this stage. These mainly concerned hooking into the TTM io reserve APIs,
> but these API have a bunch of fast paths I didn't want to unwind to add
> this to.
> 
> The solution I've decided on is to add a new API like the arch_phys_wc
> APIs (these would have worked but wc_del didn't take a range), and
> use them from the drivers to add a WC compatible mapping to the table
> for all VRAM on those GPUs. This means we can then create userspace
> mapping that won't get degraded to UC.
> 
> v1.1: use CONFIG_X86_PAT
> Cc: Toshi Kani 
> Cc: Borislav Petkov 
> Cc: H. Peter Anvin 
> Cc: Andy Lutomirski 
> Cc: Denys Vlasenko 
> Cc: Brian Gerst 
> Cc: x86 at kernel.org
> Cc: mcgrof at suse.com
> Cc: Dan Williams 
> Signed-off-by: Dave Airlie 
> ---
>  arch/x86/include/asm/io.h |  6 ++
>  arch/x86/mm/pat.c | 13 +
>  include/linux/io.h| 13 +
>  3 files changed, 32 insertions(+)

These changes look good to me in principle:

  Acked-by: Ingo Molnar 

I think it would be best to merge these fixes via the DRM tree?

Thanks,

Ingo

[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

[Jani Nikula]

On Mon, 24 Oct 2016, Paul Bolle  wrote:
> [Detailed post, but please give it a quick scan.]

Please file the information in the bug you filed. Please attach dmesg
(again, on the bug) with drm.debug=14 and running your patch.

BR,
Jani.

>
> On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
>> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> > start.
>> 
>> That would be between v4.7 and v4.8. (I guess my report was
>> ambiguous.)
>> 
>> That might take some time. Because bisecting always takes a long time
>> and especially since hitting this WARNING sometimes takes over an hour.
>> Anyhow, please prod me if I stay silent for too long.
>
> 0) So I've lost my courage to do a bisect when my first attempt landed
> me in v4.6-rc3. This is about for issue popping up between v4.7 and
> v4.8-rc1.
>
> 1) So I used the most reliable debugging tool that I actually
> understand: printk():
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index fbcfed63a76e..791de414cf1e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
> intel_crtc_state *crtc_state
> return DRM_PLANE_HELPER_NO_SCALING;
>  
> crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
> -   cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> +   if (WARN_ON_ONCE(!crtc_clock))
> +   return DRM_PLANE_HELPER_NO_SCALING;
>  
> -   if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
> +   cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> +   if (WARN_ON_ONCE(cdclk < crtc_clock)) {
> +   printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", 
> cdclk, crtc_clock);
> return DRM_PLANE_HELPER_NO_SCALING;
> +   }
> +
> +   printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= 
> %d\n", cdclk, crtc_clock);
>  
> /*
>  * skl max scale is lower of:
>
> 2) This taught me that crtc_clock always is 373250 on my machine. cdclk
> mostly is 45, but every now and then it briefly is 337500.
>
> 3) Now the interesting pattern is that cdclk drops to 337500 only after
> two quick calls of skl_max_scale() with cdclk set to 45, and a
> roughly 300ms pause before the third call of that function. Example:
>
> <7>[23758.501933] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.515211] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
>
> This pattern of cdclk being 337500 after roughly 300ms is surprisingly
> stable.
>
> 4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
> that sets cdclk to 337500 and triggers this issue. Ideas?
>
> To be continued,
>
>
> Paul Bolle

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/radeon/pm: autoswitch power state when in balanced mode

[Alex Deucher]

On Mon, Oct 24, 2016 at 5:31 PM, Lucas Stach  wrote:
> Am Montag, den 24.10.2016, 12:41 -0400 schrieb Alex Deucher:
>> On Mon, Oct 24, 2016 at 5:46 AM, Christian König
>>  wrote:
>> >
>> > Am 23.10.2016 um 01:05 schrieb Lucas Stach:
>> > >
>> > >
>> > > The current default of always using the performance power state
>> > > leads
>> > > to increased power consumption of mobile devices, which have a
>> > > dedicated
>> > > battery power state. Switch between the performance and battery
>> > > power
>> > > state automatically, dpending on the current AC power status,
>> > > when the
>> > > user asked for the balanced power state.
>> > >
>> > > The user can still override this logic by asking for the
>> > > performance
>> > > or battery power state explicitly.
>> > >
>> > > Signed-off-by: Lucas Stach 
>> >
>> >
>> > Nice addition, the only thing I can of hand see is that you
>> > probably want to
>> > remove the "balanced states don't exist at the moment" comment when
>> > you
>> > actually implement them (or abuse them).
>> >
>> > Apart from that I'm not so deep into the PM stuff, so patch is only
>> > Acked-by: Christian König .
>>
>> IIRC, I had a similar patch years ago, and it was generally shot down
>> since it moved policy into the driver.  Also, certain userspace
>> packages like tlp do this already.  That said, I'm happy to apply it
>> if there are no objections.
>
> I can relate to that argument. But as there is an explicit "battery"
> power state that's a strong hint that the hardware is designed to use
> this state when running on battery power. This patch does not add any
> new policy, but merely changes the one already present in the kernel
> (clearly always using the "performance" power state in balanced mode
> already is a policy on its own).
>
> Also this patch doesn't prevent userspace to implement a different
> policy.
>
> I don't care deeply enough to try to convince anyone if there is
> objection to this patch, but I think driving the hardware in the
> designed way by default without the user needing to install additional
> tools is a good thing.

Applied.  Thanks!

Alex

[PATCH][V2] drm/amd/powerplay: fix spelling mistake and add KERN_WARNING to printks

[Alex Deucher]

On Tue, Oct 25, 2016 at 3:43 AM, Christian König
 wrote:
> Am 25.10.2016 um 01:14 schrieb Colin King:
>>
>> From: Colin Ian King 
>>
>> Fix trivial spelling mistake cant't -> can't and add KERN_WARNING to
>> printk messages.  Remove redundant spaces before \n too (thanks to
>> Joe Perches for spotting those).
>>
>> Signed-off-by: Colin Ian King 
>
>
> Reviewed-by: Christian König .
>

Applied.  Thanks!

Alex

>
>> ---
>>   drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  | 4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 ++--
>>   4 files changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> index 76310ac..62e99d7 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> @@ -2125,7 +2125,7 @@ uint32_t fiji_get_offsetof(uint32_t type, uint32_t
>> member)
>> return offsetof(SMU73_Discrete_DpmTable,
>> LowSclkInterruptThreshold);
>> }
>> }
>> -   printk("cant't get the offset of type %x member %x \n", type,
>> member);
>> +   printk(KERN_WARNING "can't get the offset of type %x member %x\n",
>> type, member);
>> return 0;
>>   }
>>   @@ -2150,7 +2150,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
>> return SMU73_MAX_LEVELS_MVDD;
>> }
>>   - printk("cant't get the mac of %x \n", value);
>> +   printk(KERN_WARNING "can't get the mac of %x\n", value);
>> return 0;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> index 8c889ca..0cc20a8 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> @@ -2140,7 +2140,7 @@ uint32_t iceland_get_offsetof(uint32_t type,
>> uint32_t member)
>> return offsetof(SMU71_Discrete_DpmTable,
>> LowSclkInterruptThreshold);
>> }
>> }
>> -   printk("cant't get the offset of type %x member %x \n", type,
>> member);
>> +   printk(KERN_WARNING "can't get the offset of type %x member %x\n",
>> type, member);
>> return 0;
>>   }
>>   @@ -2163,7 +2163,7 @@ uint32_t iceland_get_mac_definition(uint32_t
>> value)
>> return SMU71_MAX_LEVELS_MVDD;
>> }
>>   - printk("cant't get the mac of %x \n", value);
>> +   printk(KERN_WARNING "can't get the mac of %x\n", value);
>> return 0;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
>> index 4ccc0b7..7236c51 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
>> @@ -2174,7 +2174,7 @@ uint32_t polaris10_get_offsetof(uint32_t type,
>> uint32_t member)
>> return offsetof(SMU74_Discrete_DpmTable,
>> LowSclkInterruptThreshold);
>> }
>> }
>> -   printk("cant't get the offset of type %x member %x \n", type,
>> member);
>> +   printk(KERN_WARNING "can't get the offset of type %x member %x\n",
>> type, member);
>> return 0;
>>   }
>>   @@ -2201,7 +2201,7 @@ uint32_t polaris10_get_mac_definition(uint32_t
>> value)
>> return SMU7_UVD_MCLK_HANDSHAKE_DISABLE;
>> }
>>   - printk("cant't get the mac of %x \n", value);
>> +   printk(KERN_WARNING "can't get the mac of %x\n", value);
>> return 0;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
>> index de2a24d..d08f6f1 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
>> @@ -2651,7 +2651,7 @@ uint32_t tonga_get_offsetof(uint32_t type, uint32_t
>> member)
>> return offsetof(SMU72_Discrete_DpmTable,
>> LowSclkInterruptThreshold);
>> }
>> }
>> -   printk("cant't get the offset of type %x member %x\n", type,
>> member);
>> +   printk(KERN_WARNING "can't get the offset of type %x member %x\n",
>> type, member);
>> return 0;
>>   }
>>   @@ -2675,7 +2675,7 @@ uint32_t tonga_get_mac_definition(uint32_t value)
>> case SMU_MAX_LEVELS_MVDD:
>> return SMU72_MAX_LEVELS_MVDD;
>> }
>> -   printk("cant't get the mac value %x\n", value);
>> +   printk(KERN_WARNING "can't get the mac value %x\n", value);
>> return 0;
>>   }
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: drop register readback in cayman_cp_int_cntl_setup

[Alex Deucher]

On Tue, Oct 25, 2016 at 7:01 AM, Lucas Stach  wrote:
> Am Dienstag, den 25.10.2016, 09:21 +0200 schrieb Christian König:
>> Am 24.10.2016 um 23:32 schrieb Lucas Stach:
>> >
>> > The read is taking a considerable amount of time (about 50us on
>> > this
>> > machine). The register does not ever hold anything other than the
>> > ring
>> > ID that is updated in this exact function, so there is no need for
>> > the read modify write cycle.
>> >
>> > This chops off a big chunk of the time spent in hardirq disabled
>> > context, as this function is called multiple times in the interrupt
>> > handler. With this change applied radeon won't show up in the list
>> > of the worst IRQ latency offenders anymore, where it was a regular
>> > before.
>> >
>> > Signed-off-by: Lucas Stach 
>>
>> Ups, and to make it even worse SRBM_GFX_CNTL is explicitly documented
>> to
>> be a write only register.
>>
>> That it takes a considerable amount of time is probably because the
>> SRBM
>> runs into an error condition when you read it.
>>
>> So patch is Reviewed-by: Christian König 
>> and
>> please also add a CC:stable on that.
>>
>> Do we have other occasions where we try to use a read modify write
>> cycle?
>
> No, that's the only occasion where this specific register is read back
> (including newer generations that use it like cik).
>

Applied, including cc to stable.

Thanks,

Alex

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

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

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

--- Comment #56 from Amarildo  ---
Didn't work, hang is still there. I couldn't even go to tty2 this time.

amd-staging-4.7 compiled this morning
mesa-git
llvm-git

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

linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

Today's linux-next merge of the mali-dp tree got a conflict in:

  drivers/gpu/drm/arm/malidp_planes.c

between commit:

  ea0e1ce20f73 ("drm/arm: Use per-plane rotation property")

from the drm-misc tree and commit:

  9ebb89762c30 ("drm: mali-dp: Refactor plane initialisation")

from the mali-dp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/arm/malidp_planes.c
index abaca03b9d36,9020c0d8399c..
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@@ -254,23 -284,33 +284,30 @@@ int malidp_de_planes_init(struct drm_de
if (ret < 0)
goto cleanup;

+   drm_plane_helper_add(>base,
+_de_plane_helper_funcs);
+   plane->hwdev = malidp->dev;
+   plane->layer = >layers[i];
+ 
+   /* Skip the features which the SMART layer doesn't have */
+   if (id == DE_SMART)
+   continue;
+ 
 -  if (!drm->mode_config.rotation_property) {
 +  /* SMART layer can't be rotated */
 +  if (id != DE_SMART) {
unsigned long flags = DRM_ROTATE_0 |
  DRM_ROTATE_90 |
  DRM_ROTATE_180 |
  DRM_ROTATE_270 |
  DRM_REFLECT_X |
  DRM_REFLECT_Y;
 -  drm->mode_config.rotation_property =
 -  drm_mode_create_rotation_property(drm, flags);
 +  drm_plane_create_rotation_property(>base,
 + DRM_ROTATE_0,
 + flags);
}

-   drm_plane_helper_add(>base,
-_de_plane_helper_funcs);
-   plane->hwdev = malidp->dev;
-   plane->layer = >layers[i];
 -  if (drm->mode_config.rotation_property)
 -  drm_object_attach_property(>base.base,
 - 
drm->mode_config.rotation_property,
 - DRM_ROTATE_0);
 -
+   malidp_hw_write(malidp->dev, MALIDP_ALPHA_LUT,
+   plane->layer->base + MALIDP_LAYER_COMPOSE);
}

kfree(formats);

[PATCH 3/3] drm/bridge: Add ITE IT6251 bridge driver

[Archit Taneja]

Hi,

On 10/17/2016 10:03 PM, Marek Vasut wrote:
> Add driver for the ITE IT6251 LVDS-to-eDP bridge.
>
> Signed-off-by: Marek Vasut 
> Cc: Daniel Vetter 
> Cc: Sean Cross 
> ---
>  drivers/gpu/drm/bridge/Kconfig  |   9 +
>  drivers/gpu/drm/bridge/Makefile |   1 +
>  drivers/gpu/drm/bridge/ite-it6251.c | 606 
> 
>  3 files changed, 616 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ite-it6251.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 10e12e7..e9c96b9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -39,6 +39,15 @@ config DRM_DW_HDMI_AHB_AUDIO
> Designware HDMI block.  This is used in conjunction with
> the i.MX6 HDMI driver.
>
> +config DRM_ITE_IT6251
> + tristate "ITE IT6251 LVDS/eDP bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + select REGMAP_I2C
> + ---help---
> +   ITE IT6251 LVDS-eDP bridge chip driver.
> +
>  config DRM_NXP_PTN3460
>   tristate "NXP PTN3460 DP/LVDS bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index cdf3a3c..736dba7 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_ITE_IT6251) += ite-it6251.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> diff --git a/drivers/gpu/drm/bridge/ite-it6251.c 
> b/drivers/gpu/drm/bridge/ite-it6251.c
> new file mode 100644
> index 000..a19bb4d
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it6251.c
> @@ -0,0 +1,606 @@
> +/*

We're trying to mention the bridge name, and what encoding it does for all 
bridge
drivers. Could you describe it here too? Thanks.

> + * Copyright (C) 2014 Sean Cross 
> + *
> + * Rework for mainline: Marek Vasut 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

This shouldn't be needed.

> +#include 
> +#include 

This too.

> +#include 
> +#include 
> +#include 
> +
> +#include "drmP.h"
> +#include "drm_crtc.h"
> +#include "drm_crtc_helper.h"
> +#include "drm_atomic_helper.h"
> +
> +struct it6251_bridge {
> + struct i2c_client   *client;
> + struct i2c_client   *lvds_client;
> + struct regmap   *regmap;
> + struct regmap   *lvds_regmap;
> + struct regulator*regulator;
> +
> + struct drm_connectorconnector;
> + struct drm_bridge   bridge;
> + struct drm_panel*panel;
> +};
> +
> +/* Register definitions */
> +#define IT6251_VENDOR_ID_LOW 0x00
> +#define IT6251_VENDOR_ID_HIGH0x01
> +#define IT6251_DEVICE_ID_LOW 0x02
> +#define IT6251_DEVICE_ID_HIGH0x03
> +#define IT6251_SYSTEM_STATUS 0x0d
> +#define IT6251_SYSTEM_STATUS_RINTSTATUS  BIT(0)
> +#define IT6251_SYSTEM_STATUS_RHPDSTATUS  BIT(1)
> +#define IT6251_SYSTEM_STATUS_RVIDEOSTABLEBIT(2)
> +#define IT6251_SYSTEM_STATUS_RPLL_IOLOCK BIT(3)
> +#define IT6251_SYSTEM_STATUS_RPLL_XPLOCK BIT(4)
> +#define IT6251_SYSTEM_STATUS_RPLL_SPLOCK BIT(5)
> +#define IT6251_SYSTEM_STATUS_RAUXFREQ_LOCK   BIT(6)
> +#define IT6251_REF_STATE 0x0e
> +#define IT6251_REF_STATE_MAIN_LINK_DISABLED  BIT(0)
> +#define IT6251_REF_STATE_AUX_CHANNEL_READBIT(1)
> +#define IT6251_REF_STATE_CR_PATTERN  BIT(2)
> +#define IT6251_REF_STATE_EQ_PATTERN  BIT(3)
> +#define IT6251_REF_STATE_NORMAL_OPERATIONBIT(4)
> +#define IT6251_REF_STATE_MUTED   BIT(5)
> +#define IT6251_RPCLK_CNT_LOW 0x13
> +#define IT6251_RPCLK_CNT_HIGH0x14
> +#define IT6251_RPC_REQ   0x2b
> +#define IT6251_RPC_REQ_RPC_FIFOFULL  BIT(6)
> +#define IT6251_RPC_REQ_RPC_FIFOEMPTY BIT(7)
> +#define IT6251_PCLK_CNT_LOW  0x57
> +#define IT6251_PCLK_CNT_HIGH 0x58
> +#define IT6251_DPHDEW_LOW0xa5
> +#define IT6251_DPHDEW_HIGH   0xa6
> +#define IT6251_DPVDEW_LOW

[Bug 98352] [ctg bat] igt@kms_flip@basic-flip-vs-wf_vblank

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

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

Chris Wilson  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #4 from Chris Wilson  ---
The modeline is inconsistent. Closing for BAT as we skip over this
inconsistency, will address in a separate non-BAT test with kms_setmode.

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

[Bug 98410] Applications crash when exiting

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

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

--- Comment #5 from cismalescumlord at programmer.net ---
Added dmesg files, but only kernel 4.8.3.1 is in the Tumbleweed repositories.
The best I can do with a bisect is between 4.7.6.1 and 4.8.3.1 which probably
isn't much help.

Would a meaningful backtrace of the crash help?

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

[Bug 98410] Applications crash when exiting

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

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

--- Comment #4 from cismalescumlord at programmer.net ---
Created attachment 127539
  --> https://bugs.freedesktop.org/attachment.cgi?id=127539=edit
dmesg when booting kernel 4.7.6.1

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

[Bug 98410] Applications crash when exiting

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

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

--- Comment #3 from cismalescumlord at programmer.net ---
Created attachment 127538
  --> https://bugs.freedesktop.org/attachment.cgi?id=127538=edit
dmseg taken after kate crashes

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

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

[Ying Liu]

On Mon, Oct 24, 2016 at 7:50 PM, Philipp Zabel  
wrote:
> Am Freitag, den 21.10.2016, 16:49 +0800 schrieb Ying Liu:
>> On Fri, Oct 21, 2016 at 4:18 PM, Philipp Zabel  
>> wrote:
>> > Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu:
>> >> On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel > >> pengutronix.de> wrote:
>> >> > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu:
>> >> >> >> Does the clip thing potentially change the user's request by force?
>> >> >> >> For example, the user request an unreasonable big resolution.
>> >> >> >
>> >> >> > The user is allowed to ask for destination coordinates extending 
>> >> >> > outside
>> >> >> > the crtc dimensions. This will chop off the parts that aren't 
>> >> >> > visible,
>> >> >> > and it will chop off the corresponding areas of the source as well.
>> >> >>
>> >> >> How about returning -EINVAL in this case which stands for
>> >> >> an atomic check failure?
>> >> >
>> >> > Say the user requests to display a 640x480+0,0 source framebuffer at
>> >> > destination offset -320,0 on a 320x240 screen, unscaled. The expectation
>> >> > would be to see the upper right quarter of the framebuffer on the
>> >> > screen, at least if the hardware was actually able to position overlays
>> >> > partially offscreen.
>> >> > If we can also fulfill that expectation by clipping the source rectangle
>> >> > to 320,240+320,0 and changing the destination rectangle to 320x240+0,0,
>> >> > why should -EINVAL be returned?
>> >>
>> >> Well, IIUC, there are two kinds of clipping.
>> >> 1) Clipping a rectangle from a fb according to src_x/y and src_w/h.
>> >> 2) Clipping done by drm_plane_helper_check_state(), which potentially
>> >> changes src/dst->x1/2 and src/dst->y1/2(in other words, src_x/y,
>> >> src_w/h and crtc_x/y/w/h, though not directly).
>> >>
>> >> 1) is fine, no problem.
>> >> I doubt 2) is wrong as the users' original request could be changed.
>> >> That's why I mentioned returning -EINVAL.
>> >>
>> >> Moreover, before and after applying the patch, I think the
>> >> ->atomic_check behavior consistency is broken. For example,
>> >> negative crtc_x or crtc_y for overlay are changed from unacceptable
>> >> to potentially acceptable just because 2) may change their equivalent
>> >> dst_>x/y1.
>> >
>> > I fail to see what's wrong with 2) as long as we can keep the observable
>> > behaviour exactly the same as if the user request was unchanged.
>>
>> It seems the behavior could change - negative crtc_x or crtc_y for
>> overlay make ->atomic_check return -EINVAL before(overlay hw state
>> machine has nothing changed), and potentially successful after(overlay
>> hw state machine changes).
>
> That in itself doesn't seem so bad. One thing we can't do though is
> 'position' at any negative crtc_x/y due to the fact that when clipping
> the src.x1/y1 still must be even for chroma subsampled pixel formats and
> the x1 still must result in scanline start addresses aligned to 8-byte
> boundaries. So for 32-bit framebuffer depth negative x offsets must be
> even, and for 16-bit framebuffer depth only negative x offsets that are
> a multiple of 4 are possible.

I think the alignment requirements from HW can be guaranteed by
proper ->atomic_check implementation.
The main concern about this patch is still the clipping 2) itself.
Besides the negative crtc_x/y example, another one is that
'modetest -P 24:1280x800' may run successfully on the i.MX6Q
SabreSD board with the 1024x768 LVDS primary display.
IMO, this may confuse the userspace.
Note that this test case cannot pass atomic check before
applying this patch.

Regards,
Liu Ying

>
> regards
> Philipp
>

[Bug 98410] Applications crash when exiting

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

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

--- Comment #2 from cismalescumlord at programmer.net ---
Created attachment 127537
  --> https://bugs.freedesktop.org/attachment.cgi?id=127537=edit
dmesg after booting kernel 4.8.3.1

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

[RFC v2] ARM: memory: da8xx-ddrctl: new driver

[Kevin Hilman]

Bartosz Golaszewski  writes:

> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++
>  drivers/memory/Kconfig |   8 +
>  drivers/memory/Makefile|   1 +
>  drivers/memory/da8xx-ddrctl.c  | 175 
> +
>  4 files changed, 204 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>  create mode 100644 drivers/memory/da8xx-ddrctl.c
>
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt 
> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> new file mode 100644
> index 000..7e271dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory 
> controller
> +
> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs 
> features
> +a set of registers which allow to tweak the controller's behavior.
> +
> +Documentation:
> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> +
> +Required properties:
> +
> +- compatible:"ti,da850-ddr-controller" - for da850 SoC based 
> boards
> +- reg:   a tuple containing the base address of the 
> memory
> + controller and the size of the memory area to map
> +
> +Example for da850 shown below.
> +
> +ddrctl {
> + compatible = "ti,da850-ddr-controller";
> + reg = <0xB000 0x100>;
> +};

Axel's series for the USB PHY reminded me that the PHY also has some
config registers in this same area, and his series creates a syscon for
a similar range of registers.

Could you create a syscon for the SYSCFG0 registers, which would then
be used by ths driver and your other drivers/bus driver?  Then the
binding  would just reference the sysconf via phandle, and your driver
can use syscon_regmap_lookup_by_phandle()

> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 4b4c0c3..ec80e35 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -134,6 +134,14 @@ config MTK_SMI
> mainly help enable/disable iommu and control the power domain and
> clocks for each local arbiter.
>  
> +config DA8XX_DDRCTL
> + bool "Texas Instruments da8xx DDR2/mDDR driver"
> + depends on ARCH_DAVINCI_DA8XX
> + help
> +   This driver is for the DDR2/mDDR Memory Controller present on
> +   Texas Instruments da8xx SoCs. It's used to tweak various memory
> +   controller configuration options.
> +
>  source "drivers/memory/samsung/Kconfig"
>  source "drivers/memory/tegra/Kconfig"
>  
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index b20ae38..e88097fb 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_MVEBU_DEVBUS)  += mvebu-devbus.o
>  obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
>  obj-$(CONFIG_JZ4780_NEMC)+= jz4780-nemc.o
>  obj-$(CONFIG_MTK_SMI)+= mtk-smi.o
> +obj-$(CONFIG_DA8XX_DDRCTL)   += da8xx-ddrctl.o
>  
>  obj-$(CONFIG_SAMSUNG_MC) += samsung/
>  obj-$(CONFIG_TEGRA_MC)   += tegra/
> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
> new file mode 100644
> index 000..66022df
> --- /dev/null
> +++ b/drivers/memory/da8xx-ddrctl.c
> @@ -0,0 +1,175 @@
> +/*
> + * TI da8xx DDR2/mDDR controller driver
> + *
> + * Copyright (C) 2016 BayLibre SAS
> + *
> + * Author:
> + *   Bartosz Golaszewski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * REVISIT: Linux doesn't have a good framework for the kind of performance
> + * knobs this driver controls. We can't use device tree properties as it 
> deals
> + * with hardware configuration rather than description. We also don't want to
> + * commit to maintaining some random sysfs attributes.
> + *
> + * For now we just hardcode the register values for the boards that need
> + * some changes (as is the case for the LCD controller on da850-lcdk - the
> + * first board we support here). When linux gets an appropriate framework,
> + * we'll easily convert the driver to it.
> + */
> +
> +struct da8xx_ddrctl_config_knob {
> + const char *name;
> + u32 reg;
> + u32 mask;
> + u32 offset;

nit: call this shift instead, which will also map well onto the regmap
accessors (which you'll use when switching to syscon.)

> +};
> +
> +static const struct da8xx_ddrctl_config_knob 

[PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

[Brian Starkey]

Hi Daniel,

On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote:
>On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey  
>wrote:
>>>
 diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
 b/drivers/gpu/drm/i2c/tda998x_drv.c
 index f4315bc..6e6fca2 100644
 --- a/drivers/gpu/drm/i2c/tda998x_drv.c
 +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
 @@ -1369,7 +1369,6 @@ const struct drm_connector_helper_funcs
 tda998x_connector_helper_funcs = {

  static void tda998x_connector_destroy(struct drm_connector *connector)
  {
 -   drm_connector_unregister(connector);
 drm_connector_cleanup(connector);
  }

 @@ -1441,16 +1440,10 @@ static int tda998x_bind(struct device *dev,
 struct device *master, void *data)
 if (ret)
 goto err_connector;

 -   ret = drm_connector_register(>connector);
 -   if (ret)
 -   goto err_sysfs;
 -
>>>
>>>
>>> Instead of smashing all these patches into one, what about checking here
>>> for midlayer driver set with:
>>>
>>> /* register here for drivers still using midlayer load/unload */
>>> if (dev->driver->load)
>>> drm_connector_register(connector),
>>>
>>> Similar in other places. That way we wouldn't need to switch the world in
>>> one patch.
>>
>>
>> I don't think that helps. If we do that in isolation (first), then
>> mali-dp and hdlcd won't get their connectors registered because their
>> bind order is:
>>
>> drm_dev_register();
>> component_bind_all();
>>
>> If we change the mali-dp/hdlcd bind order first, then tda998x will
>> explode on drm_connector_register() until it's patched to remove that.
>>
>> As I mentioned in my mail to Russell, the only way I can see to avoid
>> patching all three drivers in one go is:
>>  1) Add (probably open-coded) drm_connector_register_all() to the end
>> of bind in hdlcd and mali-dp
>>  2) Patch tda998x to remove drm_connector_register()
>>  3) Reorder hdlcd/mali-dp bind and remove the connector registration
>> added in 1)
>>
>> We can do that, but it's extra churn for the same result, and none of
>> the 5 patches will really make sense in isolation anyway.
>
>I thought there's also armada to take care of, which this patch would
>break? Maybe even another driver, so the hack would still be useful
>for those other drivers.

OK it seems like this situation has got very confused. In short, this
patch does not break armada. Russell previously tested the tda998x
patch against armada and reported no issues.
Drivers with a ->load() callback don't need to register the connector
anymore, because drm_dev_register() does it for them.

As far as I know, this patch touching these three drivers is
sufficient to allow all current users of tda998x to continue using it,
whilst also allowing armada and tilcdc to be de-midlayered.

>And it would have been useful if malidp/hdlcd
>wouldn't have started out with the wrong init ordering ;-)

Yeah, believe me I know -_-
Hindsight is always 20/20 something something

Thanks,
-Brian

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

[Intel-gfx] [PATCH v2 1/8] drm/dp: Factor out helper to distinguish between branch and sink devices

[Jani Nikula]

On Tue, 25 Oct 2016, Daniel Vetter  wrote:
> On Mon, Oct 24, 2016 at 08:10:46PM +0300, Jani Nikula wrote:
>> On Mon, 24 Oct 2016, Imre Deak  wrote:
>> > This check is open-coded in a few places, so it makes sense to simplify
>> > things by having a helper for it similar to the rest of DPCD feature
>> > helpers.
>> >
>> > v2: (Jani)
>> > - Move the helper to drm_dp_helper.h.
>> > - Split out this change to a separate patch.
>> >
>> > Cc: Jani Nikula 
>> > Cc: dri-devel at lists.freedesktop.org
>> > Signed-off-by: Imre Deak 
>> 
>> DP 1.4 has changed the name of "branch" devices, but I think this is
>> good.
>> 
>> Reviewed-by: Jani Nikula 
>
> Applied to drm-misc, thanks.

Thanks, but... that actually makes this series harder to land. We can't
move forward with the i915 changes before a backmerge to dinq with this
helper included.

BR,
Jani.

> -Daniel
>> 
>> 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dp.c | 11 ---
>> >  include/drm/drm_dp_helper.h |  6 ++
>> >  2 files changed, 10 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> > b/drivers/gpu/drm/i915/intel_dp.c
>> > index f30db8f..3c2293b 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > @@ -1459,8 +1459,7 @@ static void intel_dp_print_hw_revision(struct 
>> > intel_dp *intel_dp)
>> >if ((drm_debug & DRM_UT_KMS) == 0)
>> >return;
>> >  
>> > -  if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
>> > -DP_DWN_STRM_PORT_PRESENT))
>> > +  if (!drm_dp_is_branch(intel_dp->dpcd))
>> >return;
>> >  
>> >len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
>> > @@ -1478,8 +1477,7 @@ static void intel_dp_print_sw_revision(struct 
>> > intel_dp *intel_dp)
>> >if ((drm_debug & DRM_UT_KMS) == 0)
>> >return;
>> >  
>> > -  if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
>> > -DP_DWN_STRM_PORT_PRESENT))
>> > +  if (!drm_dp_is_branch(intel_dp->dpcd))
>> >return;
>> >  
>> >len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
>> > @@ -3615,8 +3613,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>> >if (!is_edp(intel_dp) && !intel_dp->sink_count)
>> >return false;
>> >  
>> > -  if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
>> > -DP_DWN_STRM_PORT_PRESENT))
>> > +  if (!drm_dp_is_branch(intel_dp->dpcd))
>> >return true; /* native DP sink */
>> >  
>> >if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
>> > @@ -4134,7 +4131,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>> >return connector_status_connected;
>> >  
>> >/* if there's no downstream port, we're done */
>> > -  if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
>> > +  if (!drm_dp_is_branch(dpcd))
>> >return connector_status_connected;
>> >  
>> >/* If we're HPD-aware, SINK_COUNT changes dynamically */
>> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> > index 2a79882..55bbeb0 100644
>> > --- a/include/drm/drm_dp_helper.h
>> > +++ b/include/drm/drm_dp_helper.h
>> > @@ -690,6 +690,12 @@ drm_dp_tps3_supported(const u8 
>> > dpcd[DP_RECEIVER_CAP_SIZE])
>> >dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED;
>> >  }
>> >  
>> > +static inline bool
>> > +drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
>> > +{
>> > +  return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
>> > +}
>> > +
>> >  /*
>> >   * DisplayPort AUX channel
>> >   */
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Shuah Khan]

On 10/19/2016 04:27 PM, Shuah Khan wrote:
> On 10/19/2016 08:16 AM, Inki Dae wrote:
>> Hi Shuah,
>>
>> 2016-10-13 8:11 GMT+09:00 Shuah Khan :
>>> Hi Inki,
>>>
>>> On 08/15/2016 10:40 PM, Inki Dae wrote:
>>>
>
> okay the very first commit that added IOMMU support
> introduced the code that rejects non-contig gem memory
> type without IOMMU.
>
> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
> Author: Inki Dae 
> Date:   Sat Oct 20 07:53:42 2012 -0700
>
> drm/exynos: add iommu support for exynos drm framework
>
>>>
>>> I haven't given up on this yet. I am still seeing the following failure:
>>>
>>> Additional debug messages I added:
>>> [   15.287403] exynos_drm_gem_create_ioctl() 1
>>> [   15.287419] exynos_drm_gem_create() flags 1
>>>
>>> [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM 
>>> memory is not supported.
>>>
>>> Additional debug message I added:
>>> [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
>>> framebuffer
>>>
>>> This is what happens:
>>>
>>> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG 
>>> request
>>> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
>>> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>>>check_fb_gem_memory_type()
>>>
>>> At this point, there is no recovery and lightdm fails
>>>
>>> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
>>> allocations are not supported in some exynos drm versions: The following
>>> commit introduced this change:
>>>
>>> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>>>
>>> excerpts from the diff:-   if (create_gem->buf_type == 
>>> ARMSOC_BO_SCANOUT)
>>> -   create_exynos.flags = EXYNOS_BO_CONTIG;
>>> -   else
>>> -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>> +
>>> +   /* Contiguous allocations are not supported in some exynos drm 
>>> versions.
>>> +* When they are supported all allocations are effectively 
>>> contiguous
>>> +* anyway, so for simplicity we always request non contiguous 
>>> buffers.
>>> +*/
>>> +   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>>
>>
>> Above comment, "Contiguous allocations are not supported in some
>> exynos drm versions.", seems wrong assumption.
>> The root cause, contiguous allocation is not supported, would be that
>> they used Linux kernel which didn't have CMA region enough - as
>> default 16MB, or didn't declare CMA region enough for the DMA device.
>> So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
>> should manage the error case if the allocation failed.
> 
> This assumption doesn't sound correct and forcing NONCONTIG isn't right
> either. 
> 
>>
>>> There might have been logic on exynos_drm that forced Contig when it coudn't
>>> support NONCONTIG. At least, that is what this comment suggests. This 
>>> assumption
>>> doesn't appear to be a good one and not sure if this change was made to fix 
>>> a bug.
>>>
>>> After the IOMMU support, this assumption is no longer true. Hence, with 
>>> IOMMU
>>> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>>>
>>> This is what I am running into. This leads to the following question:
>>>
>>> 1. How do we ensure exynos_drm kernel changes don't break user-space
>>>specifically xf86-video-armsoc
>>> 2. This seems to have gone undetected for a while. I see a change in
>>>exynos_drm_gem_dumb_create() that is probably addressing this type
>>>of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>>>handling for IOMMU NONCONTIG case.
>>
>> Seems this patch has a problem. This patch forces to flag NONCONTIG if
>> iommu is enabled. The flag should be depend on the argument from
>> user-space.
>> I.e., if user-space requested a gem allocation with CONTIG flag, then
>> Exynos drm driver should allocate contiguous memory even though iommu
>> is enabled.
>>
>>>
>>> Anyway, I am interested in getting the exynos_drm kernel side code
>>> and xf86-video-armsoc in sync to resolve the issue.
>>>
>>> Could you recommend a going forward plan?
>>
>> My opinion are,
>>
>> 1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc

Okay more on this. I fixed xf86-video-armso to ask for EXYNOS_BO_CONTIG
for ARMSOC_BO_SCANOUT and EXYNOS_BO_NONCONTIG in all other cases.

Revert of the commit: 3be1f6273441fe95dd442f44064387322e16b7e9

With this change, now display manager starts just fine. However, it turns
out xf86-video-armsoc is obsoleted in favor of xf86-video-modesetting. The
last update to xf86-video-armsoc git was 3 years ago.

I am not sure where to send the fix and doesn't look like it is being
maintained actively. I can pursue it further and try to get this into
xf86-video-armsoc provided I can find the maintainer for this seemingly
inactive project.

I brought in the 

gma500: color distortion on framebuffer console unbind

[Baruch Siach]

Hi Patrik,

On Thu, Oct 20, 2016 at 12:39:35AM +0200, Patrik Jakobsson wrote:
> Sorry for late reply. Could be that we're not restoring the state
> properly. Not sure though that we guarantee that the framebuffer
> contents is valid after unbind. Perhaps take a look at what other
> drivers do. I see the same issue on my PSB systems which run SDVO so
> it is at least not LVDS related. Unfortunately I wont have time to
> look at anything gma500 related at the moment. Feel free to dig into
> this and I'll also put it on my todo-list.

Thanks for taking the time to reproduce this issue. This rules out any local 
board layout issue on my side. For the record, my hardware is the Advantech 
SIMB-M02 Mini-ITX board.

I should have mentioned that the issue persists after unbind. That is, when I 
run fb-test only after unbind, I see the same corrupted display. So 
framebuffer content invalidation on console unbind is unlikely to be the issue 
here.

One more point that we see a similar issue with our Qt based application that 
uses the "linuxfb" plugin. The interesting twist here is that SOMETIMES the 
display corruption issue just disappears after a few minutes. The application 
is idle during that time. Not sure what to make of that.

Thanks,
baruch

> On Mon, Oct 10, 2016 at 10:01 AM, Baruch Siach  wrote:
> > I am using the gma500 driver of the latest stable kernel, 4.8.1. My 
> > hardware is Atom N2600 processor integrated graphics controller, PCI PID: 
> > 0x0be1. Output is LVDS. The system starts with framebuffer console 
> > enabled. Later in the boot process I unbind the console with the following 
> > command:
> >
> >   echo 0 > /sys/class/vtconsole/vtcon1/bind
> >
> > Immediately as the console is unbound some colors on the screen appear
> > distorted. The links below show the output of 'fb-test'
> > (https://github.com/prpplague/fb-test-app) before and after unbind.
> >
> >   http://filebin.ca/2xxwlwtBBzBN/display-good.jpg
> >   http://filebin.ca/2xxxTyIboJnR/display-bad.jpg
> >
> > Suggestions are welcome.

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH] drm/amd/powerplay: mark symbols static where possible

[Baoyou Xie]

On 25 October 2016 at 04:51, Arnd Bergmann  wrote:

> On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> > @@ -1341,7 +1341,7 @@ int smu7_disable_dpm_tasks(struct pp_hwmgr *hwmgr)
> > return result;
> >  }
> >
> > -int smu7_reset_asic_tasks(struct pp_hwmgr *hwmgr)
> > +static int smu7_reset_asic_tasks(struct pp_hwmgr *hwmgr)
> >  {
> >
> > return 0;
> >
>
> This needs to be done differently:
>
> ../drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:1344:12:
> error: 'smu7_reset_asic_tasks' defined but not used
> [-Werror=unused-function]
>
> The function has no callers, so the easiest way would be to remove it
> entirely, but it's possible that there are plans to add users soon.
>
> It was assumed that this function will be used soon, so this patch remains
it.
if it still not be used in 4.10, then we can remove it.
is it right?


> Arnd
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161025/9d0d6ea4/attachment.html>

[PATCH v2] dma-buf: Rename struct fence to dma_fence

[Chris Wilson]

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

A consensus was reached in
https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
that making clear this fence applies to DMA operations was a good thing.
Since then the patch has grown a bit as usage increases, so hopefully it
remains a good thing!

(v2...: rebase, rerun spatch)

coccinelle script:
@@

@@
- struct fence
+ struct dma_fence
@@

@@
- struct fence_ops
+ struct dma_fence_ops
@@

@@
- struct fence_cb
+ struct dma_fence_cb
@@

@@
- struct fence_array
+ struct dma_fence_array
@@

@@
- enum fence_flag_bits
+ enum dma_fence_flag_bits
@@

@@
(
- fence_init
+ dma_fence_init
|
- fence_release
+ dma_fence_release
|
- fence_free
+ dma_fence_free
|
- fence_get
+ dma_fence_get
|
- fence_get_rcu
+ dma_fence_get_rcu
|
- fence_put
+ dma_fence_put
|
- fence_signal
+ dma_fence_signal
|
- fence_signal_locked
+ dma_fence_signal_locked
|
- fence_default_wait
+ dma_fence_default_wait
|
- fence_add_callback
+ dma_fence_add_callback
|
- fence_remove_callback
+ dma_fence_remove_callback
|
- fence_enable_sw_signaling
+ dma_fence_enable_sw_signaling
|
- fence_is_signaled_locked
+ dma_fence_is_signaled_locked
|
- fence_is_signaled
+ dma_fence_is_signaled
|
- fence_is_later
+ dma_fence_is_later
|
- fence_later
+ dma_fence_later
|
- fence_wait_timeout
+ dma_fence_wait_timeout
|
- fence_wait_any_timeout
+ dma_fence_wait_any_timeout
|
- fence_wait
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- fence_array_create
+ dma_fence_array_create
|
- to_fence_array
+ to_dma_fence_array
|
- fence_is_array
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
 (
 ...
 )

Signed-off-by: Chris Wilson 
Reviewed-by: Gustavo Padovan 
Acked-by: Sumit Semwal 
Acked-by: Christian König 
---
 Documentation/sync_file.txt|   8 +-
 drivers/base/Kconfig   |   6 +-
 drivers/dma-buf/Makefile   |   2 +-
 drivers/dma-buf/dma-buf.c  |  28 +--
 .../dma-buf/{fence-array.c => dma-fence-array.c}   |  91 
 drivers/dma-buf/{fence.c => dma-fence.c}   | 195 -
 drivers/dma-buf/reservation.c  |  94 
 drivers/dma-buf/seqno-fence.c  |  18 +-
 drivers/dma-buf/sw_sync.c  |  48 ++---
 drivers/dma-buf/sync_debug.c   |  13 +-
 drivers/dma-buf/sync_debug.h   |   9 +-
 drivers/dma-buf/sync_file.c|  63 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  54 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  58 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c |  24 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |  48 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  26 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  26 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  80 +++
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  12 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/si_dma.c|   6 +-
 drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h|   4 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c  |  67 +++---
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  |  26 +--
 drivers/gpu/drm/amd/scheduler/sched_fence.c|  48 +++--
 drivers/gpu/drm/drm_atomic.c   |   2 +-
 drivers/gpu/drm/drm_atomic_helper.c|   8 +-
 drivers/gpu/drm/drm_fops.c |   6 +-
 

[PATCH] drm/amd/powerplay: mark symbols static where possible

[Baoyou Xie]

On 25 October 2016 at 04:07, Deucher, Alexander 
wrote:

> > -Original Message-
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Monday, October 24, 2016 3:49 PM
> > To: Alex Deucher
> > Cc: Baoyou Xie; Deucher, Alexander; Dave Airlie; Zhu, Rex; Zhou, Jammy;
> > Huang, JinHuiEric; StDenis, Tom; Edward O'Callaghan; Prosyak, Vitaly;
> Yang,
> > Eric; Yang, Young; Huang, Ray; Dan Carpenter; Cui, Flora; Nils
> Wallménius; Liu,
> > Monk; Wang, Ken; Min, Frank; tang.qiang007 at zte.com.cn;
> > xie.baoyou at zte.com.cn; LKML; Maling list - DRI developers;
> > han.fei at zte.com.cn
> > Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where
> > possible
> >
> > On Monday, October 24, 2016 12:36:52 PM CEST Alex Deucher wrote:
> > > On Sat, Oct 22, 2016 at 4:56 AM, Baoyou Xie 
> > wrote:
> > > > We get a few warnings when building kernel with W=1:
> > > >
> > drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5:
> > warning: no previous prototype for 'fiji_setup_pwr_virus' [-Wmissing-
> > prototypes]
> > > > drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smc.c:2052:5:
> > warning: no previous prototype for 'fiji_program_mem_timing_parameters'
> > [-Wmissing-prototypes]
> > > >
> > drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/polaris10_smumgr.c:
> > 175:5: warning: no previous prototype for 'polaris10_avfs_event_mgr' [-
> > Wmissing-prototypes]
> > > >
> > drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1020:5:
> > warning: no previous prototype for 'cz_tf_reset_acp_boot_level' [-
> > Wmissing-prototypes]
> > > >
> > drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:92:26:
> > warning: no previous prototype for 'cast_phw_smu7_power_state' [-
> > Wmissing-prototypes]
> > > > 
> > > >
> > > > In fact, these functions are only used in the file in which they are
> > > > declared and don't need a declaration, but can be made static.
> > > > So this patch marks these functions with 'static'.
> > > >
> > > > Signed-off-by: Baoyou Xie 
> > >
> > > This was already applied the last time you sent it out.  Sorry if I
> > > didn't mention that previously.
> >
> > For some reason the patch hasn't made it into linux-next, so I can see
> > why Baoyou was getting confused here. Can you clarify what the timeline
> > is for the AMD DRM driver patches from between they get applied to the
> > AMD tree to when they make it into linux-next?
> >
>
> It came in late enough last cycle that it didn't make it into 4.9 (this is
> just a clean up not a critical bug fix), so I queued it for 4.10.  I try to
> reply when I apply a patch, but sometimes I miss one here and there.  Once
> Dave starts the drm-next tree for 4.10, it will be included in my pull
> request.  Pending -next patches are in my drm-next--wip
> tree until I send Dave a formal request.
>
> > I've occasionally had a hard time with DRM (and a few other subsystems)
> > with bugfix patches trying to find out whether they got lost or
> > whether they just haven't made it into -next but are in some other tree.
> >
>
> For bug fixes we usually send Dave ~weekly pull requests for each -rc as
> necessary.  For -next stuff, each driver usually sends at least one,
> sometimes several pull requests for the next merge window.
>
> Alex
>
> > Baoyou, when you resend a patch, please try to list explicitly why
> > you are resending it, when it was last sent, and what kind of reply
> > you got (integrating any Ack, listing what changes you did, and
> > if there are no other changes, why you think you have to resend it).
> >
> >   Arnd
>

OK, I see.
Thanks for the detailed reply!
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161025/43f3f22d/attachment-0001.html>

[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API

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

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

--- Comment #18 from Marek Olšák  ---
(In reply to Andy Furniss from comment #17)
> mpv: state_tracker/st_sampler_view.c:481:
> st_get_texture_sampler_view_from_stobj: Assertion `stObj->base.MinLayer ==
> view->u.tex.first_layer' failed.

That's unrelated.

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

[PATCH v2] drm/fb-helper: Don't call dirty callback for untouched clips

[Takashi Iwai]

On Tue, 25 Oct 2016 10:09:30 +0200,
Daniel Vetter wrote:
> 
> On Tue, Oct 25, 2016 at 08:46:28AM +0200, Takashi Iwai wrote:
> > On Fri, 21 Oct 2016 14:52:07 +0200,
> > Ville Syrjälä wrote:
> > > 
> > > On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wrote:
> > > > Since 4.7 kernel, we've seen the error messages like
> > > > 
> > > >  kernel: [TTM] Buffer eviction failed
> > > >  kernel: qxl :00:02.0: object_init failed for (4026540032, 
> > > > 0x0001)
> > > >  kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate 
> > > > VRAM BO
> > > > 
> > > > on QXL when switching and accessing on VT.  The culprit was the
> > > > generic deferred_io code (qxl driver switched to it since 4.7).
> > > > There is a race between the dirty clip update and the call of
> > > > callback.
> > > > 
> > > > In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
> > > > while it kicks off the update worker outside the spinlock.  Meanwhile
> > > > the update worker clears the dirty clip in the spinlock, too.  Thus,
> > > > when drm_fb_helper_dirty() is called concurrently, schedule_work() is
> > > > called after the clip is cleared in the first worker call.
> > > > 
> > > > This patch addresses it by validating the clip before calling the
> > > > dirty fb callback.
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
> > > > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
> > > > Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support')
> > > > Cc: 
> > > > Signed-off-by: Takashi Iwai 
> > > 
> > > Reviewed-by: Ville Syrjälä 
> > 
> > Daniel, could you pick this if it's OK as a quick fix?  Currently
> > qxl driver is utterly broken, and we should recover it ASAP.  On top
> > of this, we can put a more comprehensive fix covering both this and
> > dirtyfb ioctl code paths.
> 
> I thought I've pinged Dave already to pick up, I'll poke him again.

Thanks!


Takashi

[PATCH] drm/amd/powerplay: mark symbols static where possible

[Arnd Bergmann]

On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote:
> On 25 October 2016 at 04:51, Arnd Bergmann  wrote:
> > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> > The function has no callers, so the easiest way would be to remove it
> > entirely, but it's possible that there are plans to add users soon.
> >
> > It was assumed that this function will be used soon, so this patch remains
> it.
> if it still not be used in 4.10, then we can remove it.
> is it right?

There is no such rule in general, it's up to the maintainer and
it depends on the specific reason for why the function ended up
being unused in the first place.

However, we can expect the maintainer to come up with some solution
to address the warning. Possible options include:

- calling the function from where it was meant to be used
- removing the function
- adding __maybe_unused
- adding an #if 0

I have not looked at this specific example and do not know
which of them would be appropriate here. If you look at the
output of 'git log -p 
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c'
you might find it out yourself.

Arnd

[Intel-gfx] [PATCH v2 1/8] drm/dp: Factor out helper to distinguish between branch and sink devices

[Daniel Vetter]

On Tue, Oct 25, 2016 at 10:46:44AM +0300, Jani Nikula wrote:
> On Tue, 25 Oct 2016, Daniel Vetter  wrote:
> > On Mon, Oct 24, 2016 at 08:10:46PM +0300, Jani Nikula wrote:
> >> On Mon, 24 Oct 2016, Imre Deak  wrote:
> >> > This check is open-coded in a few places, so it makes sense to simplify
> >> > things by having a helper for it similar to the rest of DPCD feature
> >> > helpers.
> >> >
> >> > v2: (Jani)
> >> > - Move the helper to drm_dp_helper.h.
> >> > - Split out this change to a separate patch.
> >> >
> >> > Cc: Jani Nikula 
> >> > Cc: dri-devel at lists.freedesktop.org
> >> > Signed-off-by: Imre Deak 
> >> 
> >> DP 1.4 has changed the name of "branch" devices, but I think this is
> >> good.
> >> 
> >> Reviewed-by: Jani Nikula 
> >
> > Applied to drm-misc, thanks.
> 
> Thanks, but... that actually makes this series harder to land. We can't
> move forward with the i915 changes before a backmerge to dinq with this
> helper included.

Oh garbage, I thought it was 1/1. Should wait for coffee to kick in first.
I guess just apply it to drm-intel also, and we'll deal with the fallout
(I can't rebase and all that).
-Daniel

> 
> BR,
> Jani.
> 
> > -Daniel
> >> 
> >> 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_dp.c | 11 ---
> >> >  include/drm/drm_dp_helper.h |  6 ++
> >> >  2 files changed, 10 insertions(+), 7 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> > b/drivers/gpu/drm/i915/intel_dp.c
> >> > index f30db8f..3c2293b 100644
> >> > --- a/drivers/gpu/drm/i915/intel_dp.c
> >> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> > @@ -1459,8 +1459,7 @@ static void intel_dp_print_hw_revision(struct 
> >> > intel_dp *intel_dp)
> >> >  if ((drm_debug & DRM_UT_KMS) == 0)
> >> >  return;
> >> >  
> >> > -if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> >> > -  DP_DWN_STRM_PORT_PRESENT))
> >> > +if (!drm_dp_is_branch(intel_dp->dpcd))
> >> >  return;
> >> >  
> >> >  len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 
> >> > 1);
> >> > @@ -1478,8 +1477,7 @@ static void intel_dp_print_sw_revision(struct 
> >> > intel_dp *intel_dp)
> >> >  if ((drm_debug & DRM_UT_KMS) == 0)
> >> >  return;
> >> >  
> >> > -if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> >> > -  DP_DWN_STRM_PORT_PRESENT))
> >> > +if (!drm_dp_is_branch(intel_dp->dpcd))
> >> >  return;
> >> >  
> >> >  len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 
> >> > 2);
> >> > @@ -3615,8 +3613,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >> >  if (!is_edp(intel_dp) && !intel_dp->sink_count)
> >> >  return false;
> >> >  
> >> > -if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> >> > -  DP_DWN_STRM_PORT_PRESENT))
> >> > +if (!drm_dp_is_branch(intel_dp->dpcd))
> >> >  return true; /* native DP sink */
> >> >  
> >> >  if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
> >> > @@ -4134,7 +4131,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> >> >  return connector_status_connected;
> >> >  
> >> >  /* if there's no downstream port, we're done */
> >> > -if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
> >> > DP_DWN_STRM_PORT_PRESENT))
> >> > +if (!drm_dp_is_branch(dpcd))
> >> >  return connector_status_connected;
> >> >  
> >> >  /* If we're HPD-aware, SINK_COUNT changes dynamically */
> >> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> >> > index 2a79882..55bbeb0 100644
> >> > --- a/include/drm/drm_dp_helper.h
> >> > +++ b/include/drm/drm_dp_helper.h
> >> > @@ -690,6 +690,12 @@ drm_dp_tps3_supported(const u8 
> >> > dpcd[DP_RECEIVER_CAP_SIZE])
> >> >  dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED;
> >> >  }
> >> >  
> >> > +static inline bool
> >> > +drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> >> > +{
> >> > +return dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
> >> > DP_DWN_STRM_PORT_PRESENT;
> >> > +}
> >> > +
> >> >  /*
> >> >   * DisplayPort AUX channel
> >> >   */
> >> 
> >> -- 
> >> Jani Nikula, Intel Open Source Technology Center
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/amd/powerplay: mark symbols static where possible

[Daniel Vetter]

On Tue, Oct 25, 2016 at 09:09:01AM +0200, Christian König wrote:
> Am 25.10.2016 um 08:41 schrieb Daniel Vetter:
> > On Mon, Oct 24, 2016 at 10:41:16PM +0200, Arnd Bergmann wrote:
> > > On Monday, October 24, 2016 8:07:16 PM CEST Deucher, Alexander wrote:
> > > > > > > In fact, these functions are only used in the file in which they 
> > > > > > > are
> > > > > > > declared and don't need a declaration, but can be made static.
> > > > > > > So this patch marks these functions with 'static'.
> > > > > > > 
> > > > > > > Signed-off-by: Baoyou Xie 
> > > > > > This was already applied the last time you sent it out.  Sorry if I
> > > > > > didn't mention that previously.
> > > > > For some reason the patch hasn't made it into linux-next, so I can see
> > > > > why Baoyou was getting confused here. Can you clarify what the 
> > > > > timeline
> > > > > is for the AMD DRM driver patches from between they get applied to the
> > > > > AMD tree to when they make it into linux-next?
> > > > > 
> > > > It came in late enough last cycle that it didn't make it into 4.9 (this 
> > > > is just a clean up not a critical bug fix), so I queued it for 4.10.  I 
> > > > try to reply when I apply a patch, but sometimes I miss one here and 
> > > > there.  Once Dave starts the drm-next tree for 4.10, it will be 
> > > > included in my pull request.  Pending -next patches are in my 
> > > > drm-next--wip tree until I send Dave a formal request.
> > > > 
> > > > > I've occasionally had a hard time with DRM (and a few other 
> > > > > subsystems)
> > > > > with bugfix patches trying to find out whether they got lost or
> > > > > whether they just haven't made it into -next but are in some other 
> > > > > tree.
> > > > > 
> > > > For bug fixes we usually send Dave ~weekly pull requests for each -rc 
> > > > as necessary.  For -next stuff, each driver usually sends at least one, 
> > > > sometimes several pull requests for the next merge window.
> > > Ok, got it. Thanks for the detailed reply!
> > > 
> > > Do you think it would be appropriate to include your drm-next-wip tree in
> > > linux-next? I think this is how a lot of the multi-level maintainer
> > > setups work as it give faster feedback about when things break.
> > tbh I think all drm drivers should be in linux-next. The early head-ups
> > about conflicts are really useful. Same for nouveau, but given that
> > nouveau is developed in a userspace git repo that's harder to pull off.
> 
> Mhm, in general I agree that seeing merge conflicts and getting a bit more
> testing earlier would be a good idea.
> 
> But Alex has the practice of regenerating his -wip branches multiple times.
> That is usually not a problem because the only one occasionally basing work
> on that branch is me, but it would be if you start to merge it somewhere.

linux-next is fine with rebasing branches. drm-intel is in there since
years, and we've only very recently stopped rebasing our main branch. What
Alex might need to change is switching the branch name for each kernel
release, i.e. amd-wip instead of amd-4.10-wip. And be more careful with
making sure only stuff heading for the current merge window shows up in
there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

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

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

--- Comment #55 from Amarildo  ---
Seems that hang handling wasn't implemented at all for some GPU's:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd?h=amd-staging-4.7=196cbffe7a4e23ad672b25a4226e53ea5479166c

I haven't yet tried playing TF2 with amd-staging-4.7 (though I have been using
it for a few days). I'll try it this morning.

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

[PATCH v2] drm/fb-helper: Don't call dirty callback for untouched clips

[Daniel Vetter]

On Tue, Oct 25, 2016 at 08:46:28AM +0200, Takashi Iwai wrote:
> On Fri, 21 Oct 2016 14:52:07 +0200,
> Ville Syrjälä wrote:
> > 
> > On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wrote:
> > > Since 4.7 kernel, we've seen the error messages like
> > > 
> > >  kernel: [TTM] Buffer eviction failed
> > >  kernel: qxl :00:02.0: object_init failed for (4026540032, 0x0001)
> > >  kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate 
> > > VRAM BO
> > > 
> > > on QXL when switching and accessing on VT.  The culprit was the
> > > generic deferred_io code (qxl driver switched to it since 4.7).
> > > There is a race between the dirty clip update and the call of
> > > callback.
> > > 
> > > In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
> > > while it kicks off the update worker outside the spinlock.  Meanwhile
> > > the update worker clears the dirty clip in the spinlock, too.  Thus,
> > > when drm_fb_helper_dirty() is called concurrently, schedule_work() is
> > > called after the clip is cleared in the first worker call.
> > > 
> > > This patch addresses it by validating the clip before calling the
> > > dirty fb callback.
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
> > > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
> > > Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support')
> > > Cc: 
> > > Signed-off-by: Takashi Iwai 
> > 
> > Reviewed-by: Ville Syrjälä 
> 
> Daniel, could you pick this if it's OK as a quick fix?  Currently
> qxl driver is utterly broken, and we should recover it ASAP.  On top
> of this, we can put a more comprehensive fix covering both this and
> dirtyfb ioctl code paths.

I thought I've pinged Dave already to pick up, I'll poke him again.
-Daniel

> 
> 
> thanks,
> 
> Takashi
> 
> > 
> > > ---
> > > v1->v2: simplified the code as suggested by Ville
> > > 
> > >  drivers/gpu/drm/drm_fb_helper.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 03414bde1f15..aae7df01864d 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -644,7 +644,9 @@ static void drm_fb_helper_dirty_work(struct 
> > > work_struct *work)
> > >   clip->x2 = clip->y2 = 0;
> > >   spin_unlock_irqrestore(>dirty_lock, flags);
> > >  
> > > - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, _copy, 1);
> > > + /* call dirty callback only when it has been really touched */
> > > + if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2)
> > > + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, _copy, 1);
> > >  }
> > >  
> > >  /**
> > > -- 
> > > 2.10.1
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API

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

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

--- Comment #17 from Andy Furniss  ---
(In reply to Tom Stellard from comment #12)
> (In reply to Marek Olšák from comment #11)

> > The test case seems pretty trivial I wonder how many other apps are 
> > affected.

I don't know the answer to that, but I've just noticed that a debug build of
mesa will catch the issue with mpv -

mpv: state_tracker/st_sampler_view.c:481:
st_get_texture_sampler_view_from_stobj: Assertion `stObj->base.MinLayer ==
view->u.tex.first_layer' failed.

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

[PATCH][V2] drm/amd/powerplay: fix spelling mistake and add KERN_WARNING to printks

[Christian König]

Am 25.10.2016 um 01:14 schrieb Colin King:
> From: Colin Ian King 
>
> Fix trivial spelling mistake cant't -> can't and add KERN_WARNING to
> printk messages.  Remove redundant spaces before \n too (thanks to
> Joe Perches for spotting those).
>
> Signed-off-by: Colin Ian King 

Reviewed-by: Christian König .

> ---
>   drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  | 4 ++--
>   drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 4 ++--
>   drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 ++--
>   drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 ++--
>   4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
> index 76310ac..62e99d7 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
> @@ -2125,7 +2125,7 @@ uint32_t fiji_get_offsetof(uint32_t type, uint32_t 
> member)
>   return offsetof(SMU73_Discrete_DpmTable, 
> LowSclkInterruptThreshold);
>   }
>   }
> - printk("cant't get the offset of type %x member %x \n", type, member);
> + printk(KERN_WARNING "can't get the offset of type %x member %x\n", 
> type, member);
>   return 0;
>   }
>   
> @@ -2150,7 +2150,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
>   return SMU73_MAX_LEVELS_MVDD;
>   }
>   
> - printk("cant't get the mac of %x \n", value);
> + printk(KERN_WARNING "can't get the mac of %x\n", value);
>   return 0;
>   }
>   
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
> index 8c889ca..0cc20a8 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
> @@ -2140,7 +2140,7 @@ uint32_t iceland_get_offsetof(uint32_t type, uint32_t 
> member)
>   return offsetof(SMU71_Discrete_DpmTable, 
> LowSclkInterruptThreshold);
>   }
>   }
> - printk("cant't get the offset of type %x member %x \n", type, member);
> + printk(KERN_WARNING "can't get the offset of type %x member %x\n", 
> type, member);
>   return 0;
>   }
>   
> @@ -2163,7 +2163,7 @@ uint32_t iceland_get_mac_definition(uint32_t value)
>   return SMU71_MAX_LEVELS_MVDD;
>   }
>   
> - printk("cant't get the mac of %x \n", value);
> + printk(KERN_WARNING "can't get the mac of %x\n", value);
>   return 0;
>   }
>   
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
> index 4ccc0b7..7236c51 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
> @@ -2174,7 +2174,7 @@ uint32_t polaris10_get_offsetof(uint32_t type, uint32_t 
> member)
>   return offsetof(SMU74_Discrete_DpmTable, 
> LowSclkInterruptThreshold);
>   }
>   }
> - printk("cant't get the offset of type %x member %x \n", type, member);
> + printk(KERN_WARNING "can't get the offset of type %x member %x\n", 
> type, member);
>   return 0;
>   }
>   
> @@ -2201,7 +2201,7 @@ uint32_t polaris10_get_mac_definition(uint32_t value)
>   return SMU7_UVD_MCLK_HANDSHAKE_DISABLE;
>   }
>   
> - printk("cant't get the mac of %x \n", value);
> + printk(KERN_WARNING "can't get the mac of %x\n", value);
>   return 0;
>   }
>   
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
> index de2a24d..d08f6f1 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
> @@ -2651,7 +2651,7 @@ uint32_t tonga_get_offsetof(uint32_t type, uint32_t 
> member)
>   return offsetof(SMU72_Discrete_DpmTable, 
> LowSclkInterruptThreshold);
>   }
>   }
> - printk("cant't get the offset of type %x member %x\n", type, member);
> + printk(KERN_WARNING "can't get the offset of type %x member %x\n", 
> type, member);
>   return 0;
>   }
>   
> @@ -2675,7 +2675,7 @@ uint32_t tonga_get_mac_definition(uint32_t value)
>   case SMU_MAX_LEVELS_MVDD:
>   return SMU72_MAX_LEVELS_MVDD;
>   }
> - printk("cant't get the mac value %x\n", value);
> + printk(KERN_WARNING "can't get the mac value %x\n", value);
>   
>   return 0;
>   }