[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, &arg) == -22

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103107

--- Comment #4 from Daniel Vetter  ---
(In reply to Chris Wilson from comment #2)
> Just your regular invalid negative test.

Also just your regular lack of invalid tests for the new flag.

Either way, pls fix this somehow. If you really insist the invalid tests aren't
useful at all, then remove them.

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


RE: [RFC 2/7] drm: Add Plane CTM property

2017-11-08 Thread Shankar, Uma


>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Brian Starkey
>Sent: Tuesday, November 7, 2017 11:10 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: Re: [RFC 2/7] drm: Add Plane CTM property
>
>Hi Uma,
>
>On Tue, Nov 07, 2017 at 05:36:26PM +0530, Uma Shankar wrote:
>>Add a blob property for plane CSC usage.
>>
>>v2: Rebase
>>
>>Signed-off-by: Uma Shankar 
>>---
>> drivers/gpu/drm/drm_atomic.c|   10 ++
>> drivers/gpu/drm/drm_atomic_helper.c |3 +++
>> drivers/gpu/drm/drm_mode_config.c   |7 +++
>> include/drm/drm_mode_config.h   |6 ++
>> include/drm/drm_plane.h |8 
>> 5 files changed, 34 insertions(+)
>>
>>diff --git a/drivers/gpu/drm/drm_atomic.c
>>b/drivers/gpu/drm/drm_atomic.c index 30853c7..45aede5 100644
>>--- a/drivers/gpu/drm/drm_atomic.c
>>+++ b/drivers/gpu/drm/drm_atomic.c
>>@@ -766,6 +766,14 @@ static int drm_atomic_plane_set_property(struct
>drm_plane *plane,
>>  val, -1, &replaced);
>>  state->color_mgmt_changed |= replaced;
>>  return ret;
>>+ } else if (property == config->plane_ctm_property) {
>>+ ret = drm_atomic_replace_property_blob_from_id(dev,
>>+ &state->ctm,
>>+ val,
>>+ sizeof(struct drm_color_ctm),
>>+ &replaced);
>>+ state->color_mgmt_changed |= replaced;
>>+ return ret;
>>  } else {
>>  return -EINVAL;
>>  }
>>@@ -827,6 +835,8 @@ static int drm_atomic_plane_set_property(struct
>drm_plane *plane,
>>  } else if (property == config->plane_degamma_lut_property) {
>>  *val = (state->degamma_lut) ?
>>  state->degamma_lut->base.id : 0;
>>+ } else if (property == config->plane_ctm_property) {
>>+ *val = (state->ctm) ? state->ctm->base.id : 0;
>>  } else {
>>  return -EINVAL;
>>  }
>>diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>>b/drivers/gpu/drm/drm_atomic_helper.c
>>index ba924cf..d3154e0 100644
>>--- a/drivers/gpu/drm/drm_atomic_helper.c
>>+++ b/drivers/gpu/drm/drm_atomic_helper.c
>>@@ -3398,6 +3398,8 @@ void
>>__drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>
>>  if (state->degamma_lut)
>>  drm_property_blob_get(state->degamma_lut);
>>+ if (state->ctm)
>>+ drm_property_blob_get(state->ctm);
>>  state->color_mgmt_changed = false;
>> }
>> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>>@@ -3445,6 +3447,7 @@ void
>__drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
>>  drm_crtc_commit_put(state->commit);
>>
>>  drm_property_blob_put(state->degamma_lut);
>>+ drm_property_blob_put(state->ctm);
>> }
>> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>>
>>diff --git a/drivers/gpu/drm/drm_mode_config.c
>>b/drivers/gpu/drm/drm_mode_config.c
>>index 118f6ac..bccc70e 100644
>>--- a/drivers/gpu/drm/drm_mode_config.c
>>+++ b/drivers/gpu/drm/drm_mode_config.c
>>@@ -362,6 +362,13 @@ static int
>drm_mode_create_standard_properties(struct drm_device *dev)
>>  return -ENOMEM;
>>  dev->mode_config.plane_degamma_lut_size_property = prop;
>>
>>+ prop = drm_property_create(dev,
>>+ DRM_MODE_PROP_BLOB,
>>+ "PLANE_CTM", 0);
>
>I do wonder if "PLANE_" is really needed here, as the property will only ever 
>be
>found on a plane (same would apply to all three property names).

This is just to explicitly separate out the names from the crtc (pipe) 
properties. 
(Similar properties exist for pipe already). It will create confusion, hence 
explicitly called
them out appending with a  "PLANE" prefix.

>
>>+ if (!prop)
>>+ return -ENOMEM;
>>+ dev->mode_config.plane_ctm_property = prop;
>>+
>>  return 0;
>> }
>>
>>diff --git a/include/drm/drm_mode_config.h
>>b/include/drm/drm_mode_config.h index 6ee2df6..3bf7fc6 100644
>>--- a/include/drm/drm_mode_config.h
>>+++ b/include/drm/drm_mode_config.h
>>@@ -727,6 +727,12 @@ struct drm_mode_config {
>>   * size of the degamma LUT as supported by the driver (read-only).
>>   */
>>  struct drm_property *plane_degamma_lut_size_property;
>>+ /**
>>+  * @plane_ctm_property: Optional CRTC property to set the
>>+  * matrix used to convert colors after the lookup in the
>>+  * degamma LUT.
>>+  */
>
>Copy-paste error - should be "Optional plane property"

Yeah indeed, thanks for spotting it. Will fix in next set.

Regards,
Uma Shankar

>
>Thanks,
>-Brian
>
>>+ struct drm_property *plane_ctm_property;
>>
>>  /**
>>   * @suggested_x_property: Optional connector property with a hint for
>>diff --git a

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101731

Józef Kucia  changed:

   What|Removed |Added

   See Also||https://bugs.winehq.org/sho
   ||w_bug.cgi?id=43273

--- Comment #77 from Józef Kucia  ---
This bug should be fixed now in Wine main git tree. The fix will be included in
the next development release.

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


[Bug 103613] Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103613

--- Comment #4 from Michel Dänzer  ---
Created attachment 135295
  --> https://bugs.freedesktop.org/attachment.cgi?id=135295&action=edit
Use the correct ScrnInfoPtr in redisplay_dirty

Does this xf86-video-amdgpu patch fix it?

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


[Bug 103613] Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103613

Michel Dänzer  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org
   |.org|
Product|DRI |xorg
  Component|DRM/AMDgpu  |Driver/AMDgpu
Version|DRI git |git
 QA Contact||xorg-t...@lists.x.org

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


Re: [PATCH 04/10] gpu: host1x: Lock classes during job submission

2017-11-08 Thread Dmitry Osipenko
On 07.11.2017 15:28, Mikko Perttunen wrote:
> On 05.11.2017 18:46, Dmitry Osipenko wrote:
>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>> ...
>>>
>>> +static int mlock_id_for_class(unsigned int class)
>>> +{
>>> +#if HOST1X_HW >= 6
>>> +    switch (class)
>>> +    {
>>> +    case HOST1X_CLASS_HOST1X:
>>> +    return 0;
>>> +    case HOST1X_CLASS_VIC:
>>> +    return 17;
>>
>> What is the meaning of returned ID values that you have defined here? Why VIC
>> should have different ID on T186?
> 
> On T186, MLOCKs are not "generic" - the HW knows that each MLOCK corresponds 
> to
> a specific class. Therefore we must map that correctly.
> 

Okay.

>>
>>> +    default:
>>> +    return -EINVAL;
>>> +    }
>>> +#else
>>> +    switch (class)
>>> +    {
>>> +    case HOST1X_CLASS_HOST1X:
>>> +    return 0;
>>> +    case HOST1X_CLASS_GR2D:
>>> +    return 1;
>>> +    case HOST1X_CLASS_GR2D_SB:
>>> +    return 2;
>>
>> Note that we are allowing to switch 2d classes in the same jobs context and
>> currently jobs class is somewhat hardcoded to GR2D.
>>
>> Even though that GR2D and GR2D_SB use different register banks, is it okay to
>> trigger execution of different classes simultaneously? Would syncpoint
>> differentiate classes on OP_DONE event?
> 
> Good point, we might need to use the same lock for these two.
> 
>>
>> I suppose that MLOCK (the module lock) implies the whole module locking,
>> wouldn't it make sense to just use the module ID's defined in the TRM?
> 
> Can you point out where these are defined?

See INDMODID / REGF_MODULEID fields of HOST1X_CHANNEL_INDOFF2_0 /
HOST1X_SYNC_REGF_ADDR_0 registers, bit numbers of HOST1X_SYNC_INTSTATUS_0 /
HOST1X_SYNC_INTC0MASK_0 / HOST1X_SYNC_MOD_TEARDOWN_0.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 04/10] gpu: host1x: Lock classes during job submission

2017-11-08 Thread Mikko Perttunen

On 05.11.2017 18:46, Dmitry Osipenko wrote:

On 05.11.2017 14:01, Mikko Perttunen wrote:

>> ...


+static int mlock_id_for_class(unsigned int class)
+{
+#if HOST1X_HW >= 6
+   switch (class)
+   {
+   case HOST1X_CLASS_HOST1X:
+   return 0;
+   case HOST1X_CLASS_VIC:
+   return 17;


What is the meaning of returned ID values that you have defined here? Why VIC
should have different ID on T186?


On T186, MLOCKs are not "generic" - the HW knows that each MLOCK 
corresponds to a specific class. Therefore we must map that correctly.





+   default:
+   return -EINVAL;
+   }
+#else
+   switch (class)
+   {
+   case HOST1X_CLASS_HOST1X:
+   return 0;
+   case HOST1X_CLASS_GR2D:
+   return 1;
+   case HOST1X_CLASS_GR2D_SB:
+   return 2;


Note that we are allowing to switch 2d classes in the same jobs context and
currently jobs class is somewhat hardcoded to GR2D.

Even though that GR2D and GR2D_SB use different register banks, is it okay to
trigger execution of different classes simultaneously? Would syncpoint
differentiate classes on OP_DONE event?


Good point, we might need to use the same lock for these two.



I suppose that MLOCK (the module lock) implies the whole module locking,
wouldn't it make sense to just use the module ID's defined in the TRM?


Can you point out where these are defined?

Mikko

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


Re: [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel

2017-11-08 Thread Dmitry Osipenko
On 07.11.2017 16:11, Mikko Perttunen wrote:
> On 05.11.2017 19:14, Dmitry Osipenko wrote:
>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>> Add an option to host1x_channel_request to interruptibly wait for a
>>> free channel. This allows IOCTLs that acquire a channel to block
>>> the userspace.
>>>
>>
>> Wouldn't it be more optimal to request channel and block after job's pining,
>> when all patching and checks are completed? Note that right now we have 
>> locking
>> around submission in DRM, which I suppose should go away by making locking 
>> fine
>> grained.
> 
> That would be possible, but I don't think it should matter much since 
> contention
> here should not be the common case.
> 
>>
>> Or maybe it would be more optimal to just iterate over channels, like I
>> suggested before [0]?
> 
> Somehow I hadn't noticed this before, but this would break the invariant of
> having one client/class per channel.
> 

Yes, currently there is a weak relation of channel and clients device, but seems
channels device is only used for printing dev_* messages and device could be
borrowed from the channels job. I don't see any real point of hardwiring channel
to a specific device or client.

> In general since we haven't seen any issues downstream with the model
> implemented here, I'd like to try to go with this and if we have problems with
> channel allocation then we could revisit.
> 

I'd prefer to collect some real numbers first, will test it with our grate /
mesa stuff. Also, we should have a host1x_test, maybe something similar to
submission perf test but using multiple contexts.

> 
>>
>> [0]
>> https://github.com/cyndis/linux/commit/9e6d87f40afb01fbe13ba65c73cb617bdfcd80b2#commitcomment-25012960
>>
>>
>>> Signed-off-by: Mikko Perttunen 
>>> ---
>>>  drivers/gpu/drm/tegra/drm.c  |  9 +
>>>  drivers/gpu/drm/tegra/gr2d.c |  6 +++---
>>>  drivers/gpu/drm/tegra/gr3d.c |  6 +++---
>>>  drivers/gpu/host1x/channel.c | 40 ++--
>>>  drivers/gpu/host1x/channel.h |  1 +
>>>  include/linux/host1x.h   |  2 +-
>>>  6 files changed, 43 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
>>> index 658bc8814f38..19f77c1a76c0 100644
>>> --- a/drivers/gpu/drm/tegra/drm.c
>>> +++ b/drivers/gpu/drm/tegra/drm.c
>>> @@ -389,7 +389,8 @@ static int host1x_waitchk_copy_from_user(struct
>>> host1x_waitchk *dest,
>>>   * Request a free hardware host1x channel for this user context, or if the
>>>   * context already has one, bump its refcount.
>>>   *
>>> - * Returns 0 on success, or -EBUSY if there were no free hardware channels.
>>> + * Returns 0 on success, -EINTR if wait for a free channel was interrupted,
>>> + * or other error.
>>>   */
>>>  int tegra_drm_context_get_channel(struct tegra_drm_context *context)
>>>  {
>>> @@ -398,10 +399,10 @@ int tegra_drm_context_get_channel(struct
>>> tegra_drm_context *context)
>>>  mutex_lock(&context->lock);
>>>
>>>  if (context->pending_jobs == 0) {
>>> -    context->channel = host1x_channel_request(client->dev);
>>> -    if (!context->channel) {
>>> +    context->channel = host1x_channel_request(client->dev, true);
>>> +    if (IS_ERR(context->channel)) {
>>>  mutex_unlock(&context->lock);
>>> -    return -EBUSY;
>>> +    return PTR_ERR(context->channel);
>>>  }
>>>  }
>>>
>>> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
>>> index 3db3bcac48b9..c1853402f69b 100644
>>> --- a/drivers/gpu/drm/tegra/gr2d.c
>>> +++ b/drivers/gpu/drm/tegra/gr2d.c
>>> @@ -32,9 +32,9 @@ static int gr2d_init(struct host1x_client *client)
>>>  unsigned long flags = HOST1X_SYNCPT_HAS_BASE;
>>>  struct gr2d *gr2d = to_gr2d(drm);
>>>
>>> -    gr2d->channel = host1x_channel_request(client->dev);
>>> -    if (!gr2d->channel)
>>> -    return -ENOMEM;
>>> +    gr2d->channel = host1x_channel_request(client->dev, false);
>>> +    if (IS_ERR(gr2d->channel))
>>> +    return PTR_ERR(gr2d->channel);
>>>
>>>  client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
>>>  if (!client->syncpts[0]) {
>>> diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
>>> index 279438342c8c..793a91d577cb 100644
>>> --- a/drivers/gpu/drm/tegra/gr3d.c
>>> +++ b/drivers/gpu/drm/tegra/gr3d.c
>>> @@ -42,9 +42,9 @@ static int gr3d_init(struct host1x_client *client)
>>>  unsigned long flags = HOST1X_SYNCPT_HAS_BASE;
>>>  struct gr3d *gr3d = to_gr3d(drm);
>>>
>>> -    gr3d->channel = host1x_channel_request(client->dev);
>>> -    if (!gr3d->channel)
>>> -    return -ENOMEM;
>>> +    gr3d->channel = host1x_channel_request(client->dev, false);
>>> +    if (IS_ERR(gr3d->channel))
>>> +    return PTR_ERR(gr3d->channel);
>>>
>>>  client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
>>>  if (!client->syncpts[0]) {
>>> diff --git a/drivers/gpu/host1x/channel.c b/drivers/gpu/host1x/chann

Re: [PATCH v3 7/7] drm/bridge: tc358767: add copyright lines

2017-11-08 Thread Chris Healy
Acked-by: Chris Healy 

On Tue, Nov 7, 2017 at 8:56 AM, Andrey Gusakov
 wrote:
> Add copyright lines for Zodiac who paid for driver development.
>
> Signed-off-by: Andrey Gusakov 
> ---
>  drivers/gpu/drm/bridge/tc358767.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 37e33f2..69d2af3 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -6,6 +6,8 @@
>   *
>   * Copyright (C) 2016 Pengutronix, Philipp Zabel 
>   *
> + * Copyright (C) 2016 Zodiac Inflight Innovations
> + *
>   * Initially based on: drivers/gpu/drm/i2c/tda998x_drv.c
>   *
>   * Copyright (C) 2012 Texas Instruments
> --
> 1.7.10.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel

2017-11-08 Thread Mikko Perttunen

On 05.11.2017 19:14, Dmitry Osipenko wrote:

On 05.11.2017 14:01, Mikko Perttunen wrote:

Add an option to host1x_channel_request to interruptibly wait for a
free channel. This allows IOCTLs that acquire a channel to block
the userspace.



Wouldn't it be more optimal to request channel and block after job's pining,
when all patching and checks are completed? Note that right now we have locking
around submission in DRM, which I suppose should go away by making locking fine
grained.


That would be possible, but I don't think it should matter much since 
contention here should not be the common case.




Or maybe it would be more optimal to just iterate over channels, like I
suggested before [0]?


Somehow I hadn't noticed this before, but this would break the invariant 
of having one client/class per channel.


In general since we haven't seen any issues downstream with the model 
implemented here, I'd like to try to go with this and if we have 
problems with channel allocation then we could revisit.


Mikko



[0]
https://github.com/cyndis/linux/commit/9e6d87f40afb01fbe13ba65c73cb617bdfcd80b2#commitcomment-25012960


Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.c  |  9 +
 drivers/gpu/drm/tegra/gr2d.c |  6 +++---
 drivers/gpu/drm/tegra/gr3d.c |  6 +++---
 drivers/gpu/host1x/channel.c | 40 ++--
 drivers/gpu/host1x/channel.h |  1 +
 include/linux/host1x.h   |  2 +-
 6 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 658bc8814f38..19f77c1a76c0 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -389,7 +389,8 @@ static int host1x_waitchk_copy_from_user(struct 
host1x_waitchk *dest,
  * Request a free hardware host1x channel for this user context, or if the
  * context already has one, bump its refcount.
  *
- * Returns 0 on success, or -EBUSY if there were no free hardware channels.
+ * Returns 0 on success, -EINTR if wait for a free channel was interrupted,
+ * or other error.
  */
 int tegra_drm_context_get_channel(struct tegra_drm_context *context)
 {
@@ -398,10 +399,10 @@ int tegra_drm_context_get_channel(struct 
tegra_drm_context *context)
mutex_lock(&context->lock);

if (context->pending_jobs == 0) {
-   context->channel = host1x_channel_request(client->dev);
-   if (!context->channel) {
+   context->channel = host1x_channel_request(client->dev, true);
+   if (IS_ERR(context->channel)) {
mutex_unlock(&context->lock);
-   return -EBUSY;
+   return PTR_ERR(context->channel);
}
}

diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 3db3bcac48b9..c1853402f69b 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -32,9 +32,9 @@ static int gr2d_init(struct host1x_client *client)
unsigned long flags = HOST1X_SYNCPT_HAS_BASE;
struct gr2d *gr2d = to_gr2d(drm);

-   gr2d->channel = host1x_channel_request(client->dev);
-   if (!gr2d->channel)
-   return -ENOMEM;
+   gr2d->channel = host1x_channel_request(client->dev, false);
+   if (IS_ERR(gr2d->channel))
+   return PTR_ERR(gr2d->channel);

client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
if (!client->syncpts[0]) {
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 279438342c8c..793a91d577cb 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -42,9 +42,9 @@ static int gr3d_init(struct host1x_client *client)
unsigned long flags = HOST1X_SYNCPT_HAS_BASE;
struct gr3d *gr3d = to_gr3d(drm);

-   gr3d->channel = host1x_channel_request(client->dev);
-   if (!gr3d->channel)
-   return -ENOMEM;
+   gr3d->channel = host1x_channel_request(client->dev, false);
+   if (IS_ERR(gr3d->channel))
+   return PTR_ERR(gr3d->channel);

client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
if (!client->syncpts[0]) {
diff --git a/drivers/gpu/host1x/channel.c b/drivers/gpu/host1x/channel.c
index 9d8cad12f9d8..eebcd51261df 100644
--- a/drivers/gpu/host1x/channel.c
+++ b/drivers/gpu/host1x/channel.c
@@ -43,6 +43,7 @@ int host1x_channel_list_init(struct host1x_channel_list 
*chlist,
bitmap_zero(chlist->allocated_channels, num_channels);

mutex_init(&chlist->lock);
+   sema_init(&chlist->sema, num_channels);

return 0;
 }
@@ -99,6 +100,8 @@ static void release_channel(struct kref *kref)
host1x_cdma_deinit(&channel->cdma);

clear_bit(channel->id, chlist->allocated_channels);
+
+   up(&chlist->sema);
 }

 void host1x_channel_put(struct host1x_channel *channel)
@@ -107,19 +110,30 @@ void host1x_channel_put(struct host1x_channel *channel)
 }
 EXPORT_SYMBOL(host

Re: [PATCH v5 08/12] drm/arc: Use drm_gem_cma_print_info()

2017-11-08 Thread Alexey Brodkin
Hi Noralf,

On Tue, 2017-11-07 at 20:13 +0100, Noralf Trønnes wrote:
> There is a new core debugfs file that prints fb/gem info:
> /dri//framebuffer
> 
> Use drm_gem_cma_print_info() to provide info to that output instead
> of using drm_fb_cma_debugfs_show().
> 
> Cc: Alexey Brodkin 
> Signed-off-by: Noralf Trønnes 
> Reviewed-by: Laurent Pinchart 

I think I acked the previous version but anyways,

Acked-by: Alexey Brodkin 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model

2017-11-08 Thread Mikko Perttunen

On 05.11.2017 19:43, Dmitry Osipenko wrote:

On 05.11.2017 14:01, Mikko Perttunen wrote:

In the traditional channel allocation model, a single hardware channel
was allocated for each client. This is simple from an implementation
perspective but prevents use of hardware scheduling.

This patch implements a channel allocation model where when a user
submits a job for a context, a hardware channel is allocated for
that context. The same channel is kept for as long as there are
incomplete jobs for that context. This way we can use hardware
scheduling and channel isolation between userspace processes, but
also prevent idling contexts from taking up hardware resources.



The dynamic channels resources (pushbuf) allocation is very expensive,
neglecting all benefits that this model should bring at least in non-IOMMU case.
We could have statically preallocated channels resources or defer resources 
freeing.


This is true. I'll try to figure out a nice way to keep the pushbuf 
allocations.





For now, this patch only adapts VIC to the new model.



I think VIC's conversion should be a distinct patch.


Sure.

Cheers,
Mikko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/bridge: dw-hdmi: fix EDID parsing

2017-11-08 Thread Russell King
Parsing the EDID for HDMI and audio information in the get_modes()
callback is incorrect - this only parses the EDID read from the
connector, not any override or firmware provided EDID.

The correct place to parse the EDID for these parameters is the
fill_modes() callback, after we've called the helper.  Move the parsing
there.  This caused problems for Luís Mendes.

Cc: 
Reported-by: Luís Mendes 
Tested-by: Luís Mendes 
Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 9fe407f49986..2516a1c18a10 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1905,10 +1905,7 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
edid->width_cm, edid->height_cm);
 
-   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
-   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
-   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
@@ -1920,6 +1917,29 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return ret;
 }
 
+static int dw_hdmi_connector_fill_modes(struct drm_connector *connector,
+   uint32_t maxX, uint32_t maxY)
+{
+   struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
+   connector);
+   int ret;
+
+   ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
+
+   if (connector->edid_blob_ptr) {
+   struct edid *edid = (void *)connector->edid_blob_ptr->data;
+
+   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
+   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
+   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
+   } else {
+   hdmi->sink_is_hdmi = false;
+   hdmi->sink_has_audio = false;
+   }
+
+   return ret;
+}
+
 static void dw_hdmi_connector_force(struct drm_connector *connector)
 {
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
@@ -1933,7 +1953,7 @@ static void dw_hdmi_connector_force(struct drm_connector 
*connector)
 }
 
 static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = dw_hdmi_connector_fill_modes,
.detect = dw_hdmi_connector_detect,
.destroy = drm_connector_cleanup,
.force = dw_hdmi_connector_force,
-- 
2.7.4

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


[PATCH] drm/cirrus drm/virtio: add create_handle support.

2017-11-08 Thread Lepton Wu
Add create_handle support to cirrus and virtio fb which are used
in virtual machines. Without this, screenshot tool in chromium OS
can't work.

Signed-off-by: Lepton Wu 
---
 drivers/gpu/drm/cirrus/cirrus_main.c |  9 +
 drivers/gpu/drm/virtio/virtgpu_display.c | 12 
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index b5f528543956..26df1e8cd490 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -13,6 +13,14 @@
 
 #include "cirrus_drv.h"
 
+static int cirrus_create_handle(struct drm_framebuffer *fb,
+   struct drm_file* file_priv,
+   unsigned int* handle)
+{
+   struct cirrus_framebuffer *cirrus_fb = to_cirrus_framebuffer(fb);
+
+   return drm_gem_handle_create(file_priv, cirrus_fb->obj, handle);
+}
 
 static void cirrus_user_framebuffer_destroy(struct drm_framebuffer *fb)
 {
@@ -24,6 +32,7 @@ static void cirrus_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 }
 
 static const struct drm_framebuffer_funcs cirrus_fb_funcs = {
+   .create_handle = cirrus_create_handle,
.destroy = cirrus_user_framebuffer_destroy,
 };
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index b6d52055a11f..274b4206ca96 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -71,7 +71,19 @@ virtio_gpu_framebuffer_surface_dirty(struct drm_framebuffer 
*fb,
return virtio_gpu_surface_dirty(virtio_gpu_fb, clips, num_clips);
 }
 
+static int
+virtio_gpu_framebuffer_create_handle(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int *handle)
+{
+   struct virtio_gpu_framebuffer *virtio_gpu_fb =
+   to_virtio_gpu_framebuffer(fb);
+
+   return drm_gem_handle_create(file_priv, virtio_gpu_fb->obj, handle);
+}
+
 static const struct drm_framebuffer_funcs virtio_gpu_fb_funcs = {
+   .create_handle = virtio_gpu_framebuffer_create_handle,
.destroy = virtio_gpu_user_framebuffer_destroy,
.dirty = virtio_gpu_framebuffer_surface_dirty,
 };
-- 
2.15.0.403.gc27cc4dac6-goog

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


[PATCH v2] display: panel: Add Tianma tm070rvhg71 display support (800x480)

2017-11-08 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- Provide more detailed ./Documentation/devicetree/bindings/display/panel
  entry to describe this panel device.
---
 .../bindings/display/panel/tianma,tm070rvhg71.txt  | 29 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 
 2 files changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt 
b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
new file mode 100644
index ..02562867444d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
@@ -0,0 +1,29 @@
+Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "tianma,tm070rvhg71
+- power-supply: single regulator to provide the supply voltage
+- backlight: phandle of the backlight device attached to the panel
+
+Required nodes:
+- port: LVDS port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX6Q based board
+
+   panel: panel-lvds0 {
+   compatible = "tianma,tm070rvhg71";
+   backlight = <&backlight_lvds>;
+   power-supply = <®_lvds>;
+
+   port {
+   panel_in_lvds0: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3d2cb8bc4d94..07188dc084df 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1831,6 +1831,30 @@ static const struct panel_desc tianma_tm070jdhg30 = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
 };
 
+static const struct display_timing tianma_tm070rvhg71_timing = {
+   .pixelclock = { 2770, 2920, 3960 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 12, 40, 212 },
+   .hback_porch = { 88, 88, 88 },
+   .hsync_len = { 1, 1, 40 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 1, 13, 88 },
+   .vback_porch = { 32, 32, 32 },
+   .vsync_len = { 1, 1, 3 },
+   .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc tianma_tm070rvhg71 = {
+   .timings = &tianma_tm070rvhg71_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+};
+
 static const struct drm_display_mode tpk_f07a_0102_mode = {
.clock = 33260,
.hdisplay = 800,
@@ -2113,6 +2137,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "tianma,tm070jdhg30",
.data = &tianma_tm070jdhg30,
}, {
+   .compatible = "tianma,tm070rvhg71",
+   .data = &tianma_tm070rvhg71,
+   }, {
.compatible = "tpk,f07a-0102",
.data = &tpk_f07a_0102,
}, {
-- 
2.11.0

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


Re: [PATCH 00/10] Dynamic Host1x channel allocation

2017-11-08 Thread Dmitry Osipenko
On 05.11.2017 14:01, Mikko Perttunen wrote:
> Hi all,
> 
> this adds support for a new model of hardware channel allocation for
> Host1x/TegraDRM. In the current model, one hardware channel is
> allocated for each client device at probe time. This is simple but
> does not allow for optimal use of hardware resources.
> 
> In the new model, we allocate channels dynamically when a
> "userspace channel", opened using the channel open IOCTL, has pending
> jobs. However, each userspace channel can only have one assigned
> channel at a time, ensuring current serialization behavior is kept.
> As such there is no change in programming model for the userspace.
> 
> The patch adapts VIC to use the new model - GR2D and GR3D are not
> modified, as the older Tegra chips they are found on do not have
> a large number of hardware channels and therefore it is not clear
> if the new model is beneficial (and I don't have access to those
> chips to test it out).
> 

I think it should be useful regardless of channels number and the main benefit
is probably that jobs arbitration is done on HW, that should prevent one process
to block other other for a long time.

> Tested using the host1x_test test suite, and also by running
> the performance test of host1x_test in parallel.
> 
> Thanks,
> Mikko
> 
> Mikko Perttunen (10):
>   gpu: host1x: Parameterize channel aperture size
>   gpu: host1x: Print MLOCK state in debug dumps on T186
>   gpu: host1x: Add lock around channel allocation
>   gpu: host1x: Lock classes during job submission
>   gpu: host1x: Add job done callback
>   drm/tegra: Deliver job completion callback to client
>   drm/tegra: Make syncpoints be per-context
>   drm/tegra: Implement dynamic channel allocation model
>   drm/tegra: Boot VIC in runtime resume
>   gpu: host1x: Optionally block when acquiring channel
> 
>  drivers/gpu/drm/tegra/drm.c|  82 +++--
>  drivers/gpu/drm/tegra/drm.h|  12 ++-
>  drivers/gpu/drm/tegra/gr2d.c   |   8 +-
>  drivers/gpu/drm/tegra/gr3d.c   |   8 +-
>  drivers/gpu/drm/tegra/vic.c| 120 
>  drivers/gpu/host1x/cdma.c  |  45 ++---
>  drivers/gpu/host1x/cdma.h  |   1 +
>  drivers/gpu/host1x/channel.c   |  47 --
>  drivers/gpu/host1x/channel.h   |   3 +
>  drivers/gpu/host1x/hw/cdma_hw.c| 122 
> +
>  drivers/gpu/host1x/hw/channel_hw.c |  74 +++
>  drivers/gpu/host1x/hw/debug_hw_1x06.c  |  18 +++-
>  drivers/gpu/host1x/hw/host1x01_hardware.h  |  10 ++
>  drivers/gpu/host1x/hw/host1x02_hardware.h  |  10 ++
>  drivers/gpu/host1x/hw/host1x04_hardware.h  |  10 ++
>  drivers/gpu/host1x/hw/host1x05_hardware.h  |  10 ++
>  drivers/gpu/host1x/hw/host1x06_hardware.h  |  10 ++
>  drivers/gpu/host1x/hw/hw_host1x01_channel.h|   2 +
>  drivers/gpu/host1x/hw/hw_host1x01_sync.h   |   6 ++
>  drivers/gpu/host1x/hw/hw_host1x02_channel.h|   2 +
>  drivers/gpu/host1x/hw/hw_host1x02_sync.h   |   6 ++
>  drivers/gpu/host1x/hw/hw_host1x04_channel.h|   2 +
>  drivers/gpu/host1x/hw/hw_host1x04_sync.h   |   6 ++
>  drivers/gpu/host1x/hw/hw_host1x05_channel.h|   2 +
>  drivers/gpu/host1x/hw/hw_host1x05_sync.h   |   6 ++
>  drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h |   5 +
>  drivers/gpu/host1x/hw/hw_host1x06_vm.h |   2 +
>  include/linux/host1x.h |   6 +-
>  28 files changed, 517 insertions(+), 118 deletions(-)
> 

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


[PATCH v5 0/8] Exynos DRM: rewrite IPP subsystem and userspace API

2017-11-08 Thread Marek Szyprowski
Dear all,

This patchset performs complete rewrite of Exynos DRM IPP subsystem and
its userspace API.

Why such rewrite is needed? Exynos DRM IPP API is over-engineered in
general, but not really extensible on the other side. It is also buggy,
with significant design flaws:
- Userspace API covers memory-2-memory picture operations together with
  CRTC writeback and duplicating features, which belongs to video plane.
- Lack of support of the all required image formats (for example NV12
  Samsung-tiled cannot be used due to lack of pixel format modifier
  support).
- Userspace API designed only to mimic hardware behaviour, not easy to
  understand.
- Lack of proper input validation in the core, drivers also didn't do that
  correctly, so it was possible to set incorrect parameters and easil
  trigger IOMMU fault or memory trash.
- Drivers were partially disfunctional or supported only a subset of modes.

Due to the above limitations and issues the Exynos DRM IPP API was not
used by any of the open-source projects. I assume that it is safe to remove
this broken API without any damage to open-source community. All remaining
users (mainly Tizen project related) will be updated to the new version.

This patchset changes Exynos DRM IPP subsystem to something useful. The
userspace API is much simpler, state-less and easy to understand. Also
the code of the core and driver is significantly smaller and easier to
understand. A new driver to Exynos Scaler hardware module available in
Exynos5420 and newer SoCs is also added on top of the provided changes.

Patches were tested on Exynos4412 based Odroid U3, Exynos5422
Odroid XU3 and Exynos5433 TM2 boards, on top of Linux next-20171106 kernel.

A simple userspace test tool has been sent together with v1 of this
patchset:
https://www.spinics.net/lists/linux-samsung-soc/msg60498.html

Tobias Jakobi has added support for this new API to his fork of libdrm and
mpv video player:
https://github.com/tobiasjakobi/libdrm/tree/ippv2
https://github.com/tobiasjakobi/mpv

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Changelog:

v5:
- fixed and reworked items pointed by Inki Dae:
  * formats and limits arrays are no longer NULL terminated, all functions
accessing them require explict array size argument
  * fixed return value for functions in GScaler, FIMC and Rotator drivers
  * simplified exynos_drm_ipp_task_set() function (removed temporary
buffer)
  * reworked FIMC driver sharing with V4L2 subsystem, now user can specify
mask of devices assigned to DRM driver (defaults to fimc.2 and fimc.3)
  * removed drivers specific task check (not used anymore)
- fixed issue pointed by Arnd Bergmann and Tobias Jakobi:
  * removed usage of timeval structures
- removed more dead-code from GScaler and FIMC drivers
- fixed IOMMU page fault caused by FIMC operation in 90 degree rotation
  mode
- added Ack from Rob Herring for Scaler driver
- generated patches with -B/40% to make Rotator, GScaler and FIMC patches
  easier to read (forced complete rewrite)

v4: https://www.spinics.net/lists/linux-samsung-soc/msg61066.html
- fixed Exynos GSC limits (alignment) and operation in 90 degree rotation
  mode
- fixed some style issues in Scaler driver (thanks to Andrzej)
- fixed copy/paste typos in commit messages
- improved debug messages, especially if provided parameters exceeds
  hardwave limits

v3: https://www.spinics.net/lists/linux-samsung-soc/msg60981.html
- fixed minor issues and added features pointed by other developers:
  * fixed missing ipp_unregister (Hoegeun)
  * added missing limits to FIMC and GSC driver (Hoegeun)
  * added more specific compatible strings to GSC driver (Hoegeun)
  * added Exynos5433 support to GSC driver (Hoegeun)
  * added autosuspend runtime PM to all IPP drivers (Tobias)
- added Exynos5433 support to Scaler driver (thanks to Andrzej)
- dropped Exynos5420 clk patch, which has been alredy merged

v2: https://www.spinics.net/lists/dri-devel/msg153418.html
- fixed minor issues pointed by other developers:
  * fixed possible null pointer dereferrence (Tobias)
  * changed limits_size to limits_count (Tobias)
  * renamed struct exynos_drm_ipp_format to drm_exynos_ipp_format (Andrzej)
  * added proper return value from exynos_drm_ipp_get_res_ioctl when no IPP
driver is present (Andrzej)
  * properly aligned all uapi structures to be 32/64 bit safe (Emil)
  * properly initialize all strucutres
- added new Exynos Scaler driver from Andrzej Pietrasiewicz

v1: https://www.spinics.net/lists/linux-samsung-soc/msg60492.html
- initial version of IPP v2

My previous works in this area:

"[RFC v2 0/2] Exynos DRM: add Picture Processor extension"
https://www.spinics.net/lists/dri-devel/msg140669.html
- removed usage of DRM objects and properties - replaced them with simple
  list of parameters with predefined IDs

"[RFC 0/4] Exynos DRM: add Picture Processor extension"
https://www.spinics.net/lists/linux-samsung-soc/msg59323.html
- moved this feature from D

[PATCH v5 3/8] drm/exynos: rotator: Convert driver to IPP v2 core API

2017-11-08 Thread Marek Szyprowski
This patch adapts Exynos DRM Rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/Kconfig  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1274 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |   19 -
 4 files changed, 448 insertions(+), 848 deletions(-)
 rewrite drivers/gpu/drm/exynos/exynos_drm_rotator.c (72%)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 2e097a81df12..c10c9ca0d8b4 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -105,7 +105,7 @@ config DRM_EXYNOS_FIMC
 
 config DRM_EXYNOS_ROTATOR
bool "Rotator"
-   depends on BROKEN
+   select DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos Rotator for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index aaed23f397d7..26d82bbd9080 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -260,6 +260,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = 
{
DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
+   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
dissimilarity index 72%
index 79282a820ecc..1a76dd3d52e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -1,828 +1,446 @@
-/*
- * Copyright (C) 2012 Samsung Electronics Co.Ltd
- * Authors:
- * YoungJun Cho 
- * Eunchul Kim 
- *
- * 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 Foundationr
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include "regs-rotator.h"
-#include "exynos_drm_drv.h"
-#include "exynos_drm_ipp.h"
-
-/*
- * Rotator supports image crop/rotator and input/output DMA operations.
- * input DMA reads image data from the memory.
- * output DMA writes image data to memory.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > Rotator H/W > Memory.
- */
-
-/*
- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. need to add supported list in prop_list.
- */
-
-#define get_rot_context(dev)   platform_get_drvdata(to_platform_device(dev))
-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
-   struct rot_context, ippdrv);
-#define rot_read(offset)   readl(rot->regs + (offset))
-#define rot_write(cfg, offset) writel(cfg, rot->regs + (offset))
-
-enum rot_irq_status {
-   ROT_IRQ_STATUS_COMPLETE = 8,
-   ROT_IRQ_STATUS_ILLEGAL  = 9,
-};
-
-/*
- * A structure of limitation.
- *
- * @min_w: minimum width.
- * @min_h: minimum height.
- * @max_w: maximum width.
- * @max_h: maximum height.
- * @align: align size.
- */
-struct rot_limit {
-   u32 min_w;
-   u32 min_h;
-   u32 max_w;
-   u32 max_h;
-   u32 align;
-};
-
-/*
- * A structure of limitation table.
- *
- * @ycbcr420_2p: case of YUV.
- * @rgb888: case of RGB.
- */
-struct rot_limit_table {
-   struct rot_limitycbcr420_2p;
-   struct rot_limitrgb888;
-};
-
-/*
- * A structure of rotator context.
- * @ippdrv: prepare initialization using ippdrv.
- * @regs_res: register resources.
- * @regs: memory mapped io registers.
- * @clock: rotator gate clock.
- * @limit_tbl: limitation of rotator.
- * @irq: irq number.
- * @cur_buf_id: current operation buffer id.
- * @suspended: suspended state.
- */
-struct rot_context {
-   struct exynos_drm_ippdrvippdrv;
-   struct resource *regs_res;
-   void __iomem*regs;
-   struct clk  *clock;
-   struct rot_limit_table  *limit_tbl;
-   int irq;
-   int cur_buf_id[EXYNOS_DRM_OPS_MAX];
-   boolsuspended;
-};
-
-static void rotator_reg_set_irq(struct rot_context *rot, bool enable)
-{
-   u32 val = rot_read(ROT_CONFIG);
-
-   if (enable == true)
-   val |= ROT_CONFIG_IRQ;
-   else
-   val &= ~ROT_CONFIG_IRQ;
-
-   rot_write(val, ROT_CONFIG);
-}
-
-static u32 rotator_reg_get_fmt(struct rot_context *rot)
-{
-   u32 val = rot_read(ROT_CONTROL);
-
-   val &= ROT_CONTROL_FMT_MASK;
-
-

[PATCH v5 4/8] drm/exynos: gsc: Convert driver to IPP v2 core API

2017-11-08 Thread Marek Szyprowski
This patch adapts Exynos DRM GScaler driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.

During the conversion driver has been adapted to support more specific
compatible strings to distinguish between Exynos5250 and Exynos5420
(different hardware limits). Support for Exynos5433 variant
has been added too (different limits table, removed dependency
on ARCH_EXYNOS5).

Signed-off-by: Marek Szyprowski 
Tested-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/Kconfig  |3 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |1 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 3199 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.h |   24 -
 4 files changed, 1399 insertions(+), 1828 deletions(-)
 rewrite drivers/gpu/drm/exynos/exynos_drm_gsc.c (43%)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index c10c9ca0d8b4..9b66a9838dca 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -111,7 +111,8 @@ config DRM_EXYNOS_ROTATOR
 
 config DRM_EXYNOS_GSC
bool "GScaler"
-   depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   depends on VIDEO_SAMSUNG_EXYNOS_GSC=n
+   select DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos GSC for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 26d82bbd9080..72344b74387d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -263,6 +263,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = 
{
DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
+   DRM_COMPONENT_DRIVER
}, {
&exynos_drm_platform_driver,
DRM_VIRTUAL_DEVICE
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
dissimilarity index 43%
index 0506b2b17ac1..b6ab58429c1c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1,1803 +1,1396 @@
-/*
- * Copyright (C) 2012 Samsung Electronics Co.Ltd
- * Authors:
- * Eunchul Kim 
- * Jinyoung Jeon 
- * Sangmin Lee 
- *
- * 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 
-
-#include 
-#include 
-#include "regs-gsc.h"
-#include "exynos_drm_drv.h"
-#include "exynos_drm_ipp.h"
-#include "exynos_drm_gsc.h"
-
-/*
- * GSC stands for General SCaler and
- * supports image scaler/rotator and input/output DMA operations.
- * input DMA reads image data from the memory.
- * output DMA writes image data to memory.
- * GSC supports image rotation and image effect functions.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > GSC H/W > Memory.
- * Writeback operation : supports cloned screen with FIMD.
- * FIMD > GSC H/W > Memory.
- * Output operation : supports direct display using local path.
- * Memory > GSC H/W > FIMD, Mixer.
- */
-
-/*
- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. added check_prepare api for right register.
- * 5. need to add supported list in prop_list.
- * 6. check prescaler/scaler optimization.
- */
-
-#define GSC_MAX_DEVS   4
-#define GSC_MAX_SRC4
-#define GSC_MAX_DST16
-#define GSC_RESET_TIMEOUT  50
-#define GSC_BUF_STOP   1
-#define GSC_BUF_START  2
-#define GSC_REG_SZ 16
-#define GSC_WIDTH_ITU_709  1280
-#define GSC_SC_UP_MAX_RATIO65536
-#define GSC_SC_DOWN_RATIO_7_8  74898
-#define GSC_SC_DOWN_RATIO_6_8  87381
-#define GSC_SC_DOWN_RATIO_5_8  104857
-#define GSC_SC_DOWN_RATIO_4_8  131072
-#define GSC_SC_DOWN_RATIO_3_8  174762
-#define GSC_SC_DOWN_RATIO_2_8  262144
-#define GSC_REFRESH_MIN12
-#define GSC_REFRESH_MAX60
-#define GSC_CROP_MAX   8192
-#define GSC_CROP_MIN   32
-#define GSC_SCALE_MAX  4224
-#define GSC_SCALE_MIN  32
-#define GSC_COEF_RATIO 7
-#define GSC_COEF_PHASE 9
-#define GSC_COEF_ATTR  16
-#define GSC_COEF_H_8T  8
-#define GSC_COEF_V_4T  4
-#define GSC_COEF_DEPTH 3
-
-#define get_gsc_context(dev)   platform_get_drvdata(to_platform_device(dev))
-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
-   struct gsc_context, ippdrv);
-#define gsc_read(offset)   readl(ctx->regs + (offset))
-#define gsc_write(cfg, offset) writel(cfg, ctx

[PATCH v5 1/8] drm/exynos: ipp: Remove Exynos DRM IPP subsystem

2017-11-08 Thread Marek Szyprowski
Exynos IPP will be rewritten, so remove current IPP core code and mark
existing drivers as BROKEN.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/Kconfig  |   11 +-
 drivers/gpu/drm/exynos/Makefile |1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |2 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1806 ---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  252 -
 include/uapi/drm/exynos_drm.h   |  192 +---
 7 files changed, 4 insertions(+), 2272 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 305dc3d4ff77..88cff0e039b6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,26 +94,21 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
 
-config DRM_EXYNOS_IPP
-   bool "Image Post Processor"
-   help
- Choose this option if you want to use IPP feature for DRM.
-
 config DRM_EXYNOS_FIMC
bool "FIMC"
-   depends on DRM_EXYNOS_IPP && MFD_SYSCON
+   depends on BROKEN && MFD_SYSCON
help
  Choose this option if you want to use Exynos FIMC for DRM.
 
 config DRM_EXYNOS_ROTATOR
bool "Rotator"
-   depends on DRM_EXYNOS_IPP
+   depends on BROKEN
help
  Choose this option if you want to use Exynos Rotator for DRM.
 
 config DRM_EXYNOS_GSC
bool "GScaler"
-   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
  Choose this option if you want to use Exynos GSC for DRM.
 
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index bdf4212dde7b..a51c5459bb13 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -18,7 +18,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index a6ff3a538c8a..04f286d450a4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -28,7 +28,6 @@
 #include "exynos_drm_plane.h"
 #include "exynos_drm_vidi.h"
 #include "exynos_drm_g2d.h"
-#include "exynos_drm_ipp.h"
 #include "exynos_drm_iommu.h"
 
 #define DRIVER_NAME"exynos"
@@ -115,14 +114,6 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY, exynos_drm_ipp_get_property,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY, exynos_drm_ipp_set_property,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF, exynos_drm_ipp_queue_buf,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL, exynos_drm_ipp_cmd_ctrl,
-   DRM_AUTH | DRM_RENDER_ALLOW),
 };
 
 static const struct file_operations exynos_drm_driver_fops = {
@@ -262,9 +253,6 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = 
{
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
-   }, {
-   DRV_PTR(ipp_driver, CONFIG_DRM_EXYNOS_IPP),
-   DRM_VIRTUAL_DEVICE
}, {
&exynos_drm_platform_driver,
DRM_VIRTUAL_DEVICE
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index f8bae4cb4823..b47f810d64d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -185,7 +185,6 @@ struct exynos_drm_g2d_private {
 
 struct drm_exynos_file_private {
struct exynos_drm_g2d_private   *g2d_priv;
-   struct device   *ipp_dev;
 };
 
 /*
@@ -293,6 +292,5 @@ extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
 extern struct platform_driver rotator_driver;
 extern struct platform_driver gsc_driver;
-extern struct platform_driver ipp_driver;
 extern struct platform_driver mic_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exyn

[PATCH v5 2/8] drm/exynos: ipp: Add IPP v2 framework

2017-11-08 Thread Marek Szyprowski
This patch adds Exynos IPP v2 subsystem and userspace API.

New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback connectors and additional DRM planes with
scaling features.

V2 IPP userspace API is not compatible with old IPP ioctls. This is a
significant change, but the old IPP subsystem in mainline Linux kernel was
partially disfunctional anyway and not used in any open-source project.

V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.

The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
  processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
  formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
  selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
  provided structures (source and destination buffers, operation rectangle,
  transformation, etc).

The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.

Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.

Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.

Signed-off-by: Marek Szyprowski 
Tested-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/Kconfig  |   3 +
 drivers/gpu/drm/exynos/Makefile |   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 894 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 173 ++
 include/uapi/drm/exynos_drm.h   | 238 +
 6 files changed, 1318 insertions(+)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 88cff0e039b6..2e097a81df12 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
 
+config DRM_EXYNOS_IPP
+   bool
+
 config DRM_EXYNOS_FIMC
bool "FIMC"
depends on BROKEN && MFD_SYSCON
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index a51c5459bb13..bdf4212dde7b 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -18,6 +18,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 04f286d450a4..aaed23f397d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -26,6 +26,7 @@
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_plane.h"
+#include "exynos_drm_ipp.h"
 #include "exynos_drm_vidi.h"
 #include "exynos_drm_g2d.h"
 #include "exynos_drm_iommu.h"
@@ -114,6 +115,14 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES, 
exynos_drm_ipp_get_res_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_LIMITS, 
exynos_drm_ipp_get_limits_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_COMMIT, exynos_drm_ipp_commit_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
 };
 
 static const struct file

[PATCH v5 7/8] ARM: dts: exynos: Add mem-2-mem Scaler devices

2017-11-08 Thread Marek Szyprowski
From: Andrzej Pietrasiewicz 

There are 3 scaler devices in Exynos5420 SoCs, all are a part of MSCL
power domain. MSCL power domain and SYSMMU controllers (two per each
scaler device) have been already added to exynos5420.dtsi earlier,
so bind them to newly added devices.

Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos5420.dtsi | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8aa2cc7aa125..0e742ab81e62 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -678,6 +678,35 @@
iommus = <&sysmmu_gscl1>;
};
 
+   scaler_0: scaler@1280 {
+   compatible = "samsung,exynos5420-scaler";
+   reg = <0x1280 0x1294>;
+   interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clock CLK_MSCL0>;
+   clock-names = "mscl";
+   power-domains = <&msc_pd>;
+   iommus = <&sysmmu_scaler0r>, <&sysmmu_scaler0w>;
+   };
+
+   scaler_1: scaler@1281 {
+   compatible = "samsung,exynos5420-scaler";
+   reg = <0x1281 0x1294>;
+   interrupts = <0 221 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clock CLK_MSCL1>;
+   clock-names = "mscl";
+   power-domains = <&msc_pd>;
+   iommus = <&sysmmu_scaler1r>, <&sysmmu_scaler1w>;
+   };
+   scaler_2: scaler@1282 {
+   compatible = "samsung,exynos5420-scaler";
+   reg = <0x1282 0x1294>;
+   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clock CLK_MSCL2>;
+   clock-names = "mscl";
+   power-domains = <&msc_pd>;
+   iommus = <&sysmmu_scaler2r>, <&sysmmu_scaler2w>;
+   };
+
jpeg_0: jpeg@11F5 {
compatible = "samsung,exynos5420-jpeg";
reg = <0x11F5 0x1000>;
@@ -812,6 +841,7 @@
interrupts = <22 4>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL0>, <&clock CLK_MSCL0>;
+   power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
 
@@ -821,6 +851,7 @@
interrupts = ;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL1>, <&clock CLK_MSCL1>;
+   power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
 
@@ -830,6 +861,7 @@
interrupts = ;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL2>, <&clock CLK_MSCL2>;
+   power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
 
@@ -840,6 +872,7 @@
interrupts = <27 2>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL0>, <&clock CLK_MSCL0>;
+   power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
 
@@ -850,6 +883,7 @@
interrupts = <22 6>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL1>, <&clock CLK_MSCL1>;
+   power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
 
@@ -860,6 +894,7 @@
interrupts = <19 6>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL2>, <&clock CLK_MSCL2>;
+   power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
 
-- 
2.14.2

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


[PATCH v5 6/8] drm/exynos: Add driver for Exynos Scaler module

2017-11-08 Thread Marek Szyprowski
From: Andrzej Pietrasiewicz 

Exynos Scaler is a hardware module, which processes graphic data fetched
from memory and transfers the resultant dato another memory buffer.
Graphics data can be up/down-scaled, rotated, flipped and converted color
space. Scaler hardware modules are a part of Exynos5420 and newer Exynos
SoCs.

Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/gpu/samsung-scaler.txt |  27 +
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_scaler.c | 693 +
 drivers/gpu/drm/exynos/regs-scaler.h   | 426 +
 7 files changed, 1157 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/samsung-scaler.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_scaler.c
 create mode 100644 drivers/gpu/drm/exynos/regs-scaler.h

diff --git a/Documentation/devicetree/bindings/gpu/samsung-scaler.txt 
b/Documentation/devicetree/bindings/gpu/samsung-scaler.txt
new file mode 100644
index ..9c3d98105dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-scaler.txt
@@ -0,0 +1,27 @@
+* Samsung Exynos Image Scaler
+
+Required properties:
+  - compatible : value should be one of the following:
+   (a) "samsung,exynos5420-scaler" for Scaler IP in Exynos5420
+   (b) "samsung,exynos5433-scaler" for Scaler IP in Exynos5433
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : Interrupt specifier for scaler interrupt, according to format
+specific to interrupt parent.
+
+  - clocks : Clock specifier for scaler clock, according to generic clock
+bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
+
+  - clock-names : Names of clocks. For exynos scaler, it should be "mscl"
+ on 5420 and "pclk", "aclk" and "aclk_xiu" on 5433.
+
+Example:
+   scaler@1280 {
+   compatible = "samsung,exynos5420-scaler";
+   reg = <0x1280 0x1294>;
+   interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clock CLK_MSCL0>;
+   clock-names = "mscl";
+   };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 73f06a3a8bec..bb6fad57e18a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -109,6 +109,12 @@ config DRM_EXYNOS_ROTATOR
help
  Choose this option if you want to use Exynos Rotator for DRM.
 
+config DRM_EXYNOS_SCALER
+   bool "Scaler"
+   select DRM_EXYNOS_IPP
+   help
+ Choose this option if you want to use Exynos Scaler for DRM.
+
 config DRM_EXYNOS_GSC
bool "GScaler"
depends on VIDEO_SAMSUNG_EXYNOS_GSC=n
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index bdf4212dde7b..3b323f1e0475 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -21,6 +21,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_SCALER)  += exynos_drm_scaler.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_MIC) += exynos_drm_mic.o
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 3bd671a5620c..da01ef9314fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -263,6 +263,9 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = 
{
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
DRM_COMPONENT_DRIVER
+   }, {
+   DRV_PTR(scaler_driver, CONFIG_DRM_EXYNOS_SCALER),
+   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
DRM_COMPONENT_DRIVER
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9dfe005805b9..68a68e37fdc7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -300,6 +300,7 @@ extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
 extern struct platform_driver rotator_driver;
+extern struct platform_driver scaler_driver;
 extern struct platform_driver gsc_driver;
 extern struct platform_driver mic_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c 
b/drivers/gpu/drm/exynos/exynos_drm_scal

[PATCH v5 5/8] drm/exynos: fimc: Convert driver to IPP v2 core API

2017-11-08 Thread Marek Szyprowski
This patch adapts Exynos DRM FIMC driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/Kconfig   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |7 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 3187 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.h |   23 -
 5 files changed, 1405 insertions(+), 1823 deletions(-)
 rewrite drivers/gpu/drm/exynos/exynos_drm_fimc.c (45%)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9b66a9838dca..73f06a3a8bec 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -99,7 +99,7 @@ config DRM_EXYNOS_IPP
 
 config DRM_EXYNOS_FIMC
bool "FIMC"
-   depends on BROKEN && MFD_SYSCON
+   select DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos FIMC for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 72344b74387d..3bd671a5620c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -219,6 +219,7 @@ struct exynos_drm_driver_info {
 #define DRM_COMPONENT_DRIVER   BIT(0)  /* supports component framework */
 #define DRM_VIRTUAL_DEVICE BIT(1)  /* create virtual platform device */
 #define DRM_DMA_DEVICE BIT(2)  /* can be used for dma allocations */
+#define DRM_FIMC_DEVICEBIT(3)  /* devices shared with V4L2 
subsystem */
 
 #define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? &drv : NULL)
 
@@ -258,6 +259,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = 
{
DRV_PTR(g2d_driver, CONFIG_DRM_EXYNOS_G2D),
}, {
DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
+   DRM_COMPONENT_DRIVER | DRM_FIMC_DEVICE,
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
DRM_COMPONENT_DRIVER
@@ -291,7 +293,10 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)
&info->driver->driver,
(void *)platform_bus_type.match))) {
put_device(p);
-   component_match_add(dev, &match, compare_dev, d);
+
+   if (!(info->flags & DRM_FIMC_DEVICE) ||
+   exynos_drm_check_fimc_device(d) == 0)
+   component_match_add(dev, &match, compare_dev, 
d);
p = d;
}
put_device(p);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b47f810d64d2..9dfe005805b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -275,6 +275,15 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
 }
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_FIMC
+int exynos_drm_check_fimc_device(struct device *dev);
+#else
+static inline int exynos_drm_check_fimc_device(struct device *dev)
+{
+   return 0;
+}
+#endif
+
 int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
*state,
 bool nonblock);
 int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
*state);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
dissimilarity index 45%
index 5b18b5c5fdf2..7e511840b0d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1,1798 +1,1389 @@
-/*
- * Copyright (C) 2012 Samsung Electronics Co.Ltd
- * Authors:
- * Eunchul Kim 
- * Jinyoung Jeon 
- * Sangmin Lee 
- *
- * 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 
-#include 
-#include 
-
-#include 
-#include 
-#include "regs-fimc.h"
-#include "exynos_drm_drv.h"
-#include "exynos_drm_ipp.h"
-#include "exynos_drm_fimc.h"
-
-/*
- * FIMC stands for Fully Interactive Mobile Camera and
- * supports image scaler/rotator and input/output DMA operations.
- * input DMA reads image data from the memory.
- * output DMA writes image data to memory.
- * FIMC supports image rotation and image effect functions.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > FIMC H/W > Memory.
- * Writeback operation : supports cloned screen with FIMD.
- * FIMD > FIMC H/W > Memory.
- * Output operation : supports direct display using local path.
- 

[PATCH v5 8/8] ARM64: dts: exynos: Add mem-2-mem Scaler devices

2017-11-08 Thread Marek Szyprowski
From: Andrzej Pietrasiewicz 

There are two Scaler devices in Exynos5433 SoCs. Add nodes for them and
their SYSMMU controllers.

Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Marek Szyprowski 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 7fe994b750da..97866114767f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -920,6 +920,28 @@
iommus = <&sysmmu_gscl2>;
};
 
+   scaler_0: scaler@1500 {
+   compatible = "samsung,exynos5433-scaler";
+   reg = <0x1500 0x1294>;
+   interrupts = <0 402 IRQ_TYPE_LEVEL_HIGH>;
+   clock-names = "pclk", "aclk", "aclk_xiu";
+   clocks = <&cmu_mscl CLK_PCLK_M2MSCALER0>,
+<&cmu_mscl CLK_ACLK_M2MSCALER0>,
+<&cmu_mscl CLK_ACLK_XIU_MSCLX>;
+   iommus = <&sysmmu_scaler_0>;
+   };
+
+   scaler_1: scaler@1501 {
+   compatible = "samsung,exynos5433-scaler";
+   reg = <0x1501 0x1294>;
+   interrupts = <0 403 IRQ_TYPE_LEVEL_HIGH>;
+   clock-names = "pclk", "aclk", "aclk_xiu";
+   clocks = <&cmu_mscl CLK_PCLK_M2MSCALER1>,
+<&cmu_mscl CLK_ACLK_M2MSCALER1>,
+<&cmu_mscl CLK_ACLK_XIU_MSCLX>;
+   iommus = <&sysmmu_scaler_1>;
+   };
+
jpeg: codec@1502 {
compatible = "samsung,exynos5433-jpeg";
reg = <0x1502 0x1>;
@@ -1014,6 +1036,26 @@
#iommu-cells = <0>;
};
 
+   sysmmu_scaler_0: sysmmu@0x1504 {
+   compatible = "samsung,exynos-sysmmu";
+   reg = <0x1504 0x1000>;
+   interrupts = ;
+   clock-names = "pclk", "aclk";
+   clocks = <&cmu_mscl CLK_PCLK_SMMU_M2MSCALER0>,
+<&cmu_mscl CLK_ACLK_SMMU_M2MSCALER0>;
+   #iommu-cells = <0>;
+   };
+
+   sysmmu_scaler_1: sysmmu@0x1505 {
+   compatible = "samsung,exynos-sysmmu";
+   reg = <0x1505 0x1000>;
+   interrupts = ;
+   clock-names = "pclk", "aclk";
+   clocks = <&cmu_mscl CLK_PCLK_SMMU_M2MSCALER1>,
+<&cmu_mscl CLK_ACLK_SMMU_M2MSCALER1>;
+   #iommu-cells = <0>;
+   };
+
sysmmu_jpeg: sysmmu@1506 {
compatible = "samsung,exynos-sysmmu";
reg = <0x1506 0x1000>;
-- 
2.14.2

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


Re: [PATCH] backlight: ili922x: remove redundant variable len

2017-11-08 Thread Lee Jones
On Sun, 05 Nov 2017, Colin King wrote:

> From: Colin Ian King 
> 
> The variable len is assigned but never read, therefore it is redundant
> and can be removed. Cleans up clang warning:
> 
> drivers/video/backlight/ili922x.c:276:2: warning: Value stored to 'len'
> is never read
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/video/backlight/ili922x.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Applied, thanks.

> diff --git a/drivers/video/backlight/ili922x.c 
> b/drivers/video/backlight/ili922x.c
> index a9e9cef..2b6c6aa 100644
> --- a/drivers/video/backlight/ili922x.c
> +++ b/drivers/video/backlight/ili922x.c
> @@ -251,7 +251,7 @@ static int ili922x_write(struct spi_device *spi, u8 reg, 
> u16 value)
>   struct spi_transfer xfer_regindex, xfer_regvalue;
>   unsigned char tbuf[CMD_BUFSIZE];
>   unsigned char rbuf[CMD_BUFSIZE];
> - int ret, len = 0;
> + int ret;
>  
>   memset(&xfer_regindex, 0, sizeof(struct spi_transfer));
>   memset(&xfer_regvalue, 0, sizeof(struct spi_transfer));
> @@ -273,7 +273,6 @@ static int ili922x_write(struct spi_device *spi, u8 reg, 
> u16 value)
>   ret = spi_sync(spi, &msg);
>  
>   spi_message_init(&msg);
> - len = 0;
>   tbuf[0] = set_tx_byte(START_BYTE(ili922x_id, START_RS_REG,
>START_RW_WRITE));
>   tbuf[1] = set_tx_byte((value & 0xFF00) >> 8);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Daniel Vetter
Two bits:
- check actual atomic state, the legacy stuff can only be looked at
  from within the atomic_commit_tail function, since it's only
  protected by ordering and not by any locks.

- Make sure we don't wreak the work an ongoing nonblocking commit is
  doing.

Cc: Manasi Navare 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
References: https://bugs.freedesktop.org/show_bug.cgi?id=99272
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d27c0145ac91..319c372dc26f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4319,6 +4319,8 @@ static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
+   struct drm_connector_state *conn_state =
+   intel_dp->attached_connector->base.state;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 link_status[DP_LINK_STATUS_SIZE];
 
@@ -4329,10 +4331,10 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
 
-   if (!intel_encoder->base.crtc)
+   if (!conn_state->crtc || !conn_state->crtc->state->active)
return;
 
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   if (!try_wait_for_completion(&conn_state->commit->hw_done))
return;
 
/*
-- 
2.15.0

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


[PATCH 1/2] drm/atomic-helper: always track connector commits, too

2017-11-08 Thread Daniel Vetter
It's useful for syncing async connector work like link retraining.

Cc: Manasi Navare 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f1b56a..ea781d55f2c1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1791,7 +1791,8 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,
if (new_conn_state->crtc)
continue;
 
-   commit = crtc_or_fake_commit(state, old_conn_state->crtc);
+   /* Always track connectors explicitly for e.g. link retraining. 
*/
+   commit = crtc_or_fake_commit(state, new_conn_state->crtc ?: 
old_conn_state->crtc);
if (!commit)
return -ENOMEM;
 
@@ -1805,10 +1806,7 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,

!try_wait_for_completion(&old_plane_state->commit->flip_done))
return -EBUSY;
 
-   /*
-* Unlike connectors, always track planes explicitly for
-* async pageflip support.
-*/
+   /* Always track planes explicitly for async pageflip support. */
commit = crtc_or_fake_commit(state, new_plane_state->crtc ?: 
old_plane_state->crtc);
if (!commit)
return -ENOMEM;
-- 
2.15.0

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


[PATCH v5 RESEND 5/8] drm/exynos: fimc: Convert driver to IPP v2 core API

2017-11-08 Thread Marek Szyprowski
This patch adapts Exynos DRM FIMC driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.

Signed-off-by: Marek Szyprowski 
---
This is a proper v5 version, by mistake I posted unfinished patch in the
"[PATCH v5 0/8] Exynos DRM: rewrite IPP subsystem and userspace API" patchset.
---
 drivers/gpu/drm/exynos/Kconfig   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |7 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 3170 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.h |   23 -
 5 files changed, 1388 insertions(+), 1823 deletions(-)
 rewrite drivers/gpu/drm/exynos/exynos_drm_fimc.c (47%)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9b66a9838dca..73f06a3a8bec 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -99,7 +99,7 @@ config DRM_EXYNOS_IPP
 
 config DRM_EXYNOS_FIMC
bool "FIMC"
-   depends on BROKEN && MFD_SYSCON
+   select DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos FIMC for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 72344b74387d..3bd671a5620c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -219,6 +219,7 @@ struct exynos_drm_driver_info {
 #define DRM_COMPONENT_DRIVER   BIT(0)  /* supports component framework */
 #define DRM_VIRTUAL_DEVICE BIT(1)  /* create virtual platform device */
 #define DRM_DMA_DEVICE BIT(2)  /* can be used for dma allocations */
+#define DRM_FIMC_DEVICEBIT(3)  /* devices shared with V4L2 
subsystem */
 
 #define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? &drv : NULL)
 
@@ -258,6 +259,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = 
{
DRV_PTR(g2d_driver, CONFIG_DRM_EXYNOS_G2D),
}, {
DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
+   DRM_COMPONENT_DRIVER | DRM_FIMC_DEVICE,
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
DRM_COMPONENT_DRIVER
@@ -291,7 +293,10 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)
&info->driver->driver,
(void *)platform_bus_type.match))) {
put_device(p);
-   component_match_add(dev, &match, compare_dev, d);
+
+   if (!(info->flags & DRM_FIMC_DEVICE) ||
+   exynos_drm_check_fimc_device(d) == 0)
+   component_match_add(dev, &match, compare_dev, 
d);
p = d;
}
put_device(p);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b47f810d64d2..9dfe005805b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -275,6 +275,15 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
 }
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_FIMC
+int exynos_drm_check_fimc_device(struct device *dev);
+#else
+static inline int exynos_drm_check_fimc_device(struct device *dev)
+{
+   return 0;
+}
+#endif
+
 int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
*state,
 bool nonblock);
 int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
*state);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
dissimilarity index 47%
index 5b18b5c5fdf2..fa961e8724c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1,1798 +1,1372 @@
-/*
- * Copyright (C) 2012 Samsung Electronics Co.Ltd
- * Authors:
- * Eunchul Kim 
- * Jinyoung Jeon 
- * Sangmin Lee 
- *
- * 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 
-#include 
-#include 
-
-#include 
-#include 
-#include "regs-fimc.h"
-#include "exynos_drm_drv.h"
-#include "exynos_drm_ipp.h"
-#include "exynos_drm_fimc.h"
-
-/*
- * FIMC stands for Fully Interactive Mobile Camera and
- * supports image scaler/rotator and input/output DMA operations.
- * input DMA reads image data from the memory.
- * output DMA writes image data to memory.
- * FIMC supports image rotation and image effect functions.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > FIMC H/W > Memory.
- * Write

Re: [PATCH 12/22] drm/sti: Use drm_fb_cma_fbdev_init/fini()

2017-11-08 Thread Benjamin Gaignard
2017-11-04 14:04 GMT+01:00 Noralf Trønnes :
> Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
> the fact that drm_device holds a pointer to the drm_fb_helper structure.
> This means that the driver doesn't have to keep track of that.
> Also use the drm_fb_helper functions directly.
>
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/sti/sti_drv.c | 25 +
>  drivers/gpu/drm/sti/sti_drv.h |  1 -
>  2 files changed, 5 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 9e9343101738..d61efef30a82 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -138,16 +139,9 @@ static int sti_atomic_check(struct drm_device *dev,
> return ret;
>  }
>
> -static void sti_output_poll_changed(struct drm_device *ddev)
> -{
> -   struct sti_private *private = ddev->dev_private;
> -
> -   drm_fbdev_cma_hotplug_event(private->fbdev);
> -}
> -
>  static const struct drm_mode_config_funcs sti_mode_config_funcs = {
> .fb_create = drm_gem_fb_create,
> -   .output_poll_changed = sti_output_poll_changed,
> +   .output_poll_changed = drm_fb_helper_output_poll_changed,
> .atomic_check = sti_atomic_check,
> .atomic_commit = drm_atomic_helper_commit,
>  };
> @@ -230,11 +224,7 @@ static void sti_cleanup(struct drm_device *ddev)
>  {
> struct sti_private *private = ddev->dev_private;
>
> -   if (private->fbdev) {
> -   drm_fbdev_cma_fini(private->fbdev);
> -   private->fbdev = NULL;
> -   }
> -
> +   drm_fb_cma_fbdev_fini(ddev);
> drm_kms_helper_poll_fini(ddev);
> component_unbind_all(ddev->dev, ddev);
> kfree(private);
> @@ -245,7 +235,6 @@ static int sti_bind(struct device *dev)
>  {
> struct drm_device *ddev;
> struct sti_private *private;
> -   struct drm_fbdev_cma *fbdev;
> int ret;
>
> ddev = drm_dev_alloc(&sti_driver, dev);
> @@ -268,13 +257,9 @@ static int sti_bind(struct device *dev)
>
> private = ddev->dev_private;
> if (ddev->mode_config.num_connector) {
> -   fbdev = drm_fbdev_cma_init(ddev, 32,
> -  ddev->mode_config.num_connector);
> -   if (IS_ERR(fbdev)) {
> +   ret = drm_fb_cma_fbdev_init(ddev, 32, 0);
> +   if (ret)
> DRM_DEBUG_DRIVER("Warning: fails to create fbdev\n");
> -   fbdev = NULL;
> -   }
> -   private->fbdev = fbdev;
> }

Like for stm driver I think that drm_kms_helper_poll_init() call
should be move after
this block of code.
struct sti_private *private could also be remove of the function.

When testing your patches I have a kernel panic in drm_fbdev_cma_create()
because fbdev_cma->fb_funcs is NULL so using/testing fbdev_cma->fb_funcs->dirty
make kernel crash.
Just adding a test on fbdev_cma->fb_funcs value fix the problem but I
wonder why I'm
the only to report this issue ?

With all these fix I have a fonctionnal frame buffer.

Benjamin
>
> return 0;
> diff --git a/drivers/gpu/drm/sti/sti_drv.h b/drivers/gpu/drm/sti/sti_drv.h
> index 6502ed2d3351..16c5c9110cb0 100644
> --- a/drivers/gpu/drm/sti/sti_drv.h
> +++ b/drivers/gpu/drm/sti/sti_drv.h
> @@ -24,7 +24,6 @@ struct sti_private {
> struct sti_compositor *compo;
> struct drm_property *plane_zorder_property;
> struct drm_device *drm_dev;
> -   struct drm_fbdev_cma *fbdev;
>  };
>
>  extern struct platform_driver sti_tvout_driver;
> --
> 2.14.2
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/cirrus drm/virtio: add create_handle support.

2017-11-08 Thread Daniel Vetter
On Tue, Nov 07, 2017 at 12:39:35PM -0800, Lepton Wu wrote:
> Add create_handle support to cirrus and virtio fb which are used
> in virtual machines. Without this, screenshot tool in chromium OS
> can't work.
> 
> Signed-off-by: Lepton Wu 

Please split per-driver and cc relevant driver maintainers on each
individually. Would also be sweet if you could somewhat move these over to
Noralf's shiny new gem helpers.

Thanks, Daniel

> ---
>  drivers/gpu/drm/cirrus/cirrus_main.c |  9 +
>  drivers/gpu/drm/virtio/virtgpu_display.c | 12 
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index b5f528543956..26df1e8cd490 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -13,6 +13,14 @@
>  
>  #include "cirrus_drv.h"
>  
> +static int cirrus_create_handle(struct drm_framebuffer *fb,
> + struct drm_file* file_priv,
> + unsigned int* handle)
> +{
> + struct cirrus_framebuffer *cirrus_fb = to_cirrus_framebuffer(fb);
> +
> + return drm_gem_handle_create(file_priv, cirrus_fb->obj, handle);
> +}
>  
>  static void cirrus_user_framebuffer_destroy(struct drm_framebuffer *fb)
>  {
> @@ -24,6 +32,7 @@ static void cirrus_user_framebuffer_destroy(struct 
> drm_framebuffer *fb)
>  }
>  
>  static const struct drm_framebuffer_funcs cirrus_fb_funcs = {
> + .create_handle = cirrus_create_handle,
>   .destroy = cirrus_user_framebuffer_destroy,
>  };
>  
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index b6d52055a11f..274b4206ca96 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -71,7 +71,19 @@ virtio_gpu_framebuffer_surface_dirty(struct 
> drm_framebuffer *fb,
>   return virtio_gpu_surface_dirty(virtio_gpu_fb, clips, num_clips);
>  }
>  
> +static int
> +virtio_gpu_framebuffer_create_handle(struct drm_framebuffer *fb,
> +  struct drm_file *file_priv,
> +  unsigned int *handle)
> +{
> + struct virtio_gpu_framebuffer *virtio_gpu_fb =
> + to_virtio_gpu_framebuffer(fb);
> +
> + return drm_gem_handle_create(file_priv, virtio_gpu_fb->obj, handle);
> +}
> +
>  static const struct drm_framebuffer_funcs virtio_gpu_fb_funcs = {
> + .create_handle = virtio_gpu_framebuffer_create_handle,
>   .destroy = virtio_gpu_user_framebuffer_destroy,
>   .dirty = virtio_gpu_framebuffer_surface_dirty,
>  };
> -- 
> 2.15.0.403.gc27cc4dac6-goog
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Daniel Vetter
Two bits:
- check actual atomic state, the legacy stuff can only be looked at
  from within the atomic_commit_tail function, since it's only
  protected by ordering and not by any locks.

- Make sure we don't wreak the work an ongoing nonblocking commit is
  doing.

v2: We need the crtc lock too, because a plane update might change it
without having to acquire the connection_mutex (Maarten). Use
Maarten's changes for this locking, while keeping the logic that uses
the connection->commit->hw_done signal for syncing with nonblocking
commits.

Cc: Manasi Navare 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 56 -
 1 file changed, 50 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d27c0145ac91..7cd7ab4fb431 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4319,6 +4319,8 @@ static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
+   struct drm_connector_state *conn_state =
+   intel_dp->attached_connector->base.state;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 link_status[DP_LINK_STATUS_SIZE];
 
@@ -4329,10 +4331,15 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
 
-   if (!intel_encoder->base.crtc)
+   if (!conn_state->crtc)
return;
 
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   WARN_ON(!drm_modeset_is_locked(&conn_state->crtc->mutex));
+
+   if (!conn_state->crtc->state->active)
+   return;
+
+   if (!try_wait_for_completion(&conn_state->commit->hw_done))
return;
 
/*
@@ -4368,7 +4375,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
-   struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
@@ -4408,9 +4414,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
 
-   drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
-   drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
/* Send a Hotplug Uevent to userspace to start modeset */
@@ -4860,8 +4865,19 @@ intel_dp_detect(struct drm_connector *connector,
  connector->base.id, connector->name);
 
/* If full detect is not performed yet, do a full detect */
-   if (!intel_dp->detect_done)
+   if (!intel_dp->detect_done) {
+   struct drm_crtc *crtc;
+   int ret;
+
+   crtc = connector->state->crtc;
+   if (crtc) {
+   ret = drm_modeset_lock(&crtc->mutex, ctx);
+   if (ret)
+   return ret;
+   }
+
status = intel_dp_long_pulse(intel_dp->attached_connector);
+   }
 
intel_dp->detect_done = false;
 
@@ -5146,10 +5162,38 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
 
if (!intel_dp->is_mst) {
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_connector *connector = 
&intel_dp->attached_connector->base;
+   struct drm_crtc *crtc;
+   int iret;
+
+   drm_modeset_acquire_init(&ctx, 0);
+retry:
+   iret = drm_modeset_lock(&dev->mode_config.connection_mutex, 
&ctx);
+   if (iret)
+   goto err;
+
+   crtc = connector->state->crtc;
+   if (crtc) {
+   iret = drm_modeset_lock(&crtc->mutex, &ctx);
+   if (iret)
+   goto err;
+   }
+
if (!intel_dp_short_pulse(intel_dp)) {
intel_dp->detect_done = false;
goto put_power;
}
+
+err:
+   if (iret == -EDEADLK) {
+   drm_modeset_backoff(&ctx);
+   goto retry;
+   }
+
+   drm_modeset_drop_locks(&ctx);
+   drm_modeset_acquire_fini(&ctx);
+   WARN(iret, "Acquiring modeset locks failed with %i\n", iret);
}
 
ret = IRQ_HANDLED;
-- 
2.15.0

__

[PULL] drm-misc-next-fixes

2017-11-08 Thread Daniel Vetter
Hi Dave,

drm-misc-next-fixes-2017-11-08:
4.15 merge window fixes, round 2:

randconfig fix from Arnd, plus the vblank WARN_ON fix from Ville.

Right away a new pull request because somehow Ville's fix was stuck for a
bit too long and everyone forgot :-( And I didn't notice because i915
isn't affected since we do have accurate vblank times. If some fool would
igt-CI some arm driver, I think that'd would be really great. Collabora
once did, but no idea where that is stuck now ...

Cheers, Daniel

The following changes since commit e073db5c5d7ad311efa8f4192a2047b006bbc5f3:

  drm/vc4: Fix wrong printk format in vc4_bo_stats_debugfs() (2017-11-03 
10:15:42 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2017-11-08

for you to fetch changes up to a111fbc4c44d2981f1a8fef64418685be5e30280:

  drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug 
(2017-11-07 21:07:02 +0200)


4.15 merge window fixes, round 2:

randconfig fix from Arnd, plus the vblank WARN_ON fix from Ville.


Arnd Bergmann (1):
  drm/rockchip: add CONFIG_OF dependency for lvds

Ville Syrjälä (1):
  drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug

 drivers/gpu/drm/drm_vblank.c | 4 ++--
 drivers/gpu/drm/rockchip/Kconfig | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Ville Syrjälä
On Wed, Nov 08, 2017 at 01:57:50PM +0100, Daniel Vetter wrote:
> Two bits:
> - check actual atomic state, the legacy stuff can only be looked at
>   from within the atomic_commit_tail function, since it's only
>   protected by ordering and not by any locks.
> 
> - Make sure we don't wreak the work an ongoing nonblocking commit is
>   doing.

I still think we need to move the retraining to the hotplug work.

> 
> v2: We need the crtc lock too, because a plane update might change it
> without having to acquire the connection_mutex (Maarten). Use
> Maarten's changes for this locking, while keeping the logic that uses
> the connection->commit->hw_done signal for syncing with nonblocking
> commits.
> 
> Cc: Manasi Navare 
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 56 
> -
>  1 file changed, 50 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d27c0145ac91..7cd7ab4fb431 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4319,6 +4319,8 @@ static void
>  intel_dp_check_link_status(struct intel_dp *intel_dp)
>  {
>   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
> + struct drm_connector_state *conn_state =
> + intel_dp->attached_connector->base.state;
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   u8 link_status[DP_LINK_STATUS_SIZE];
>  
> @@ -4329,10 +4331,15 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>   return;
>   }
>  
> - if (!intel_encoder->base.crtc)
> + if (!conn_state->crtc)
>   return;
>  
> - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> + WARN_ON(!drm_modeset_is_locked(&conn_state->crtc->mutex));
> +
> + if (!conn_state->crtc->state->active)
> + return;
> +
> + if (!try_wait_for_completion(&conn_state->commit->hw_done))
>   return;
>  
>   /*
> @@ -4368,7 +4375,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  static bool
>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>  {
> - struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
>   u8 sink_irq_vector = 0;
>   u8 old_sink_count = intel_dp->sink_count;
> @@ -4408,9 +4414,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>   DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
>   }
>  
> - drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>   intel_dp_check_link_status(intel_dp);
> - drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
>   if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
>   DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
>   /* Send a Hotplug Uevent to userspace to start modeset */
> @@ -4860,8 +4865,19 @@ intel_dp_detect(struct drm_connector *connector,
> connector->base.id, connector->name);
>  
>   /* If full detect is not performed yet, do a full detect */
> - if (!intel_dp->detect_done)
> + if (!intel_dp->detect_done) {
> + struct drm_crtc *crtc;
> + int ret;
> +
> + crtc = connector->state->crtc;
> + if (crtc) {
> + ret = drm_modeset_lock(&crtc->mutex, ctx);
> + if (ret)
> + return ret;
> + }
> +
>   status = intel_dp_long_pulse(intel_dp->attached_connector);
> + }
>  
>   intel_dp->detect_done = false;
>  
> @@ -5146,10 +5162,38 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>   }
>  
>   if (!intel_dp->is_mst) {
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_connector *connector = 
> &intel_dp->attached_connector->base;
> + struct drm_crtc *crtc;
> + int iret;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> +retry:
> + iret = drm_modeset_lock(&dev->mode_config.connection_mutex, 
> &ctx);
> + if (iret)
> + goto err;
> +
> + crtc = connector->state->crtc;
> + if (crtc) {
> + iret = drm_modeset_lock(&crtc->mutex, &ctx);
> + if (iret)
> + goto err;
> + }
> +
>   if (!intel_dp_short_pulse(intel_dp)) {
>   intel_dp->detect_done = false;
>   goto put_power;
>   }
> +
> +err:
> + if (iret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> +

[PATCH] drm: sti: remove useless fields from vtg structure

2017-11-08 Thread Benjamin Gaignard
Drivers are registered on platform bus so the private list
could be replace by a call to of_find_device_by_node().
Changing this also makes dev, np and link fields useless
in vtg structure.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig   |  1 +
 drivers/gpu/drm/sti/sti_vtg.c | 32 
 2 files changed, 9 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd7286..cca4b3c 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -8,5 +8,6 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
+   select OF
help
  Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
index 2dcba1d..5f75aea 100644
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -72,8 +73,6 @@
 #define AWG_DELAY_ED(-8)
 #define AWG_DELAY_SD(-7)
 
-static LIST_HEAD(vtg_lookup);
-
 /*
  * STI VTG register offset structure
  *
@@ -123,42 +122,31 @@ struct sti_vtg_sync_params {
 /**
  * STI VTG structure
  *
- * @dev: pointer to device driver
- * @np: device node
  * @regs: register mapping
  * @sync_params: synchronisation parameters used to generate timings
  * @irq: VTG irq
  * @irq_status: store the IRQ status value
  * @notifier_list: notifier callback
  * @crtc: the CRTC for vblank event
- * @link: List node to link the structure in lookup list
  */
 struct sti_vtg {
-   struct device *dev;
-   struct device_node *np;
void __iomem *regs;
struct sti_vtg_sync_params sync_params[VTG_MAX_SYNC_OUTPUT];
int irq;
u32 irq_status;
struct raw_notifier_head notifier_list;
struct drm_crtc *crtc;
-   struct list_head link;
 };
 
-static void vtg_register(struct sti_vtg *vtg)
-{
-   list_add_tail(&vtg->link, &vtg_lookup);
-}
-
 struct sti_vtg *of_vtg_find(struct device_node *np)
 {
-   struct sti_vtg *vtg;
+   struct platform_device *pdev;
 
-   list_for_each_entry(vtg, &vtg_lookup, link) {
-   if (vtg->np == np)
-   return vtg;
-   }
-   return NULL;
+   pdev = of_find_device_by_node(np);
+   if (!pdev)
+   return NULL;
+
+   return (struct sti_vtg *)platform_get_drvdata(pdev);
 }
 
 static void vtg_reset(struct sti_vtg *vtg)
@@ -397,9 +385,6 @@ static int vtg_probe(struct platform_device *pdev)
if (!vtg)
return -ENOMEM;
 
-   vtg->dev = dev;
-   vtg->np = pdev->dev.of_node;
-
/* Get Memory ressources */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -428,10 +413,9 @@ static int vtg_probe(struct platform_device *pdev)
return ret;
}
 
-   vtg_register(vtg);
platform_set_drvdata(pdev, vtg);
 
-   DRM_INFO("%s %s\n", __func__, dev_name(vtg->dev));
+   DRM_INFO("%s %s\n", __func__, dev_name(dev));
 
return 0;
 }
-- 
2.7.4

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


[PATCH] drm: sti: remove vtg_remove

2017-11-08 Thread Benjamin Gaignard
vtg_remove does nothing just remove it

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_vtg.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
index 5f75aea..3aa2fa6 100644
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -420,11 +420,6 @@ static int vtg_probe(struct platform_device *pdev)
return 0;
 }
 
-static int vtg_remove(struct platform_device *pdev)
-{
-   return 0;
-}
-
 static const struct of_device_id vtg_of_match[] = {
{ .compatible = "st,vtg", },
{ /* sentinel */ }
@@ -438,7 +433,6 @@ struct platform_driver sti_vtg_driver = {
.of_match_table = vtg_of_match,
},
.probe  = vtg_probe,
-   .remove = vtg_remove,
 };
 
 MODULE_AUTHOR("Benjamin Gaignard ");
-- 
2.7.4

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


Re: [PATCH] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Daniel Vetter
On Wed, Nov 08, 2017 at 03:04:58PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 08, 2017 at 01:57:50PM +0100, Daniel Vetter wrote:
> > Two bits:
> > - check actual atomic state, the legacy stuff can only be looked at
> >   from within the atomic_commit_tail function, since it's only
> >   protected by ordering and not by any locks.
> > 
> > - Make sure we don't wreak the work an ongoing nonblocking commit is
> >   doing.
> 
> I still think we need to move the retraining to the hotplug work.

Why? One of the patch series Maarten mentioned says there's a deadlock
with dp aux, but it seems to be all just fine when CI retrains.

And even if there is a deadlock, it's there already, so not sure why we
need to block this bugfix on a different bugfix. Which seems to be what
you're suggesting here (but it's a bit sparse).
-Daniel

> > v2: We need the crtc lock too, because a plane update might change it
> > without having to acquire the connection_mutex (Maarten). Use
> > Maarten's changes for this locking, while keeping the logic that uses
> > the connection->commit->hw_done signal for syncing with nonblocking
> > commits.
> > 
> > Cc: Manasi Navare 
> > Cc: Maarten Lankhorst 
> > Cc: Ville Syrjälä 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 56 
> > -
> >  1 file changed, 50 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index d27c0145ac91..7cd7ab4fb431 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4319,6 +4319,8 @@ static void
> >  intel_dp_check_link_status(struct intel_dp *intel_dp)
> >  {
> > struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
> > +   struct drm_connector_state *conn_state =
> > +   intel_dp->attached_connector->base.state;
> > struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > u8 link_status[DP_LINK_STATUS_SIZE];
> >  
> > @@ -4329,10 +4331,15 @@ intel_dp_check_link_status(struct intel_dp 
> > *intel_dp)
> > return;
> > }
> >  
> > -   if (!intel_encoder->base.crtc)
> > +   if (!conn_state->crtc)
> > return;
> >  
> > -   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > +   WARN_ON(!drm_modeset_is_locked(&conn_state->crtc->mutex));
> > +
> > +   if (!conn_state->crtc->state->active)
> > +   return;
> > +
> > +   if (!try_wait_for_completion(&conn_state->commit->hw_done))
> > return;
> >  
> > /*
> > @@ -4368,7 +4375,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> >  static bool
> >  intel_dp_short_pulse(struct intel_dp *intel_dp)
> >  {
> > -   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
> > u8 sink_irq_vector = 0;
> > u8 old_sink_count = intel_dp->sink_count;
> > @@ -4408,9 +4414,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> > DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
> > }
> >  
> > -   drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> > intel_dp_check_link_status(intel_dp);
> > -   drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > +
> > if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
> > DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
> > /* Send a Hotplug Uevent to userspace to start modeset */
> > @@ -4860,8 +4865,19 @@ intel_dp_detect(struct drm_connector *connector,
> >   connector->base.id, connector->name);
> >  
> > /* If full detect is not performed yet, do a full detect */
> > -   if (!intel_dp->detect_done)
> > +   if (!intel_dp->detect_done) {
> > +   struct drm_crtc *crtc;
> > +   int ret;
> > +
> > +   crtc = connector->state->crtc;
> > +   if (crtc) {
> > +   ret = drm_modeset_lock(&crtc->mutex, ctx);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> > status = intel_dp_long_pulse(intel_dp->attached_connector);
> > +   }
> >  
> > intel_dp->detect_done = false;
> >  
> > @@ -5146,10 +5162,38 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> > *intel_dig_port, bool long_hpd)
> > }
> >  
> > if (!intel_dp->is_mst) {
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   struct drm_connector *connector = 
> > &intel_dp->attached_connector->base;
> > +   struct drm_crtc *crtc;
> > +   int iret;
> > +
> > +   drm_modeset_acquire_init(&ctx, 0);
> > +retry:
> > +   iret = drm_modeset_lock(&dev->mode_config.connection_mutex, 
> > &ctx);
> > +   if (iret)
> > +   goto err;
> > +
> > +   crtc = co

Re: [PATCH] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Maarten Lankhorst
Op 08-11-17 om 14:04 schreef Ville Syrjälä:
> On Wed, Nov 08, 2017 at 01:57:50PM +0100, Daniel Vetter wrote:
>> Two bits:
>> - check actual atomic state, the legacy stuff can only be looked at
>>   from within the atomic_commit_tail function, since it's only
>>   protected by ordering and not by any locks.
>>
>> - Make sure we don't wreak the work an ongoing nonblocking commit is
>>   doing.
> I still think we need to move the retraining to the hotplug work.
But lets not block a fix for that. :)

Reviewed-by: Maarten Lankhorst 
>> v2: We need the crtc lock too, because a plane update might change it
>> without having to acquire the connection_mutex (Maarten). Use
>> Maarten's changes for this locking, while keeping the logic that uses
>> the connection->commit->hw_done signal for syncing with nonblocking
>> commits.
>>
>> Cc: Manasi Navare 
>> Cc: Maarten Lankhorst 
>> Cc: Ville Syrjälä 
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 56 
>> -
>>  1 file changed, 50 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index d27c0145ac91..7cd7ab4fb431 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -4319,6 +4319,8 @@ static void
>>  intel_dp_check_link_status(struct intel_dp *intel_dp)
>>  {
>>  struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
>> +struct drm_connector_state *conn_state =
>> +intel_dp->attached_connector->base.state;
>>  struct drm_device *dev = intel_dp_to_dev(intel_dp);
>>  u8 link_status[DP_LINK_STATUS_SIZE];
>>  
>> @@ -4329,10 +4331,15 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>>  return;
>>  }
>>  
>> -if (!intel_encoder->base.crtc)
>> +if (!conn_state->crtc)
>>  return;
>>  
>> -if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>> +WARN_ON(!drm_modeset_is_locked(&conn_state->crtc->mutex));
>> +
>> +if (!conn_state->crtc->state->active)
>> +return;
>> +
>> +if (!try_wait_for_completion(&conn_state->commit->hw_done))
>>  return;
>>  
>>  /*
>> @@ -4368,7 +4375,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>>  static bool
>>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>>  {
>> -struct drm_device *dev = intel_dp_to_dev(intel_dp);
>>  struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
>>  u8 sink_irq_vector = 0;
>>  u8 old_sink_count = intel_dp->sink_count;
>> @@ -4408,9 +4414,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>>  DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
>>  }
>>  
>> -drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>>  intel_dp_check_link_status(intel_dp);
>> -drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>>  if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
>>  DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
>>  /* Send a Hotplug Uevent to userspace to start modeset */
>> @@ -4860,8 +4865,19 @@ intel_dp_detect(struct drm_connector *connector,
>>connector->base.id, connector->name);
>>  
>>  /* If full detect is not performed yet, do a full detect */
>> -if (!intel_dp->detect_done)
>> +if (!intel_dp->detect_done) {
>> +struct drm_crtc *crtc;
>> +int ret;
>> +
>> +crtc = connector->state->crtc;
>> +if (crtc) {
>> +ret = drm_modeset_lock(&crtc->mutex, ctx);
>> +if (ret)
>> +return ret;
>> +}
>> +
>>  status = intel_dp_long_pulse(intel_dp->attached_connector);
>> +}
>>  
>>  intel_dp->detect_done = false;
>>  
>> @@ -5146,10 +5162,38 @@ intel_dp_hpd_pulse(struct intel_digital_port 
>> *intel_dig_port, bool long_hpd)
>>  }
>>  
>>  if (!intel_dp->is_mst) {
>> +struct drm_modeset_acquire_ctx ctx;
>> +struct drm_connector *connector = 
>> &intel_dp->attached_connector->base;
>> +struct drm_crtc *crtc;
>> +int iret;
>> +
>> +drm_modeset_acquire_init(&ctx, 0);
>> +retry:
>> +iret = drm_modeset_lock(&dev->mode_config.connection_mutex, 
>> &ctx);
>> +if (iret)
>> +goto err;
>> +
>> +crtc = connector->state->crtc;
>> +if (crtc) {
>> +iret = drm_modeset_lock(&crtc->mutex, &ctx);
>> +if (iret)
>> +goto err;
>> +}
>> +
>>  if (!intel_dp_short_pulse(intel_dp)) {
>>  intel_dp->detect_done = false;
>>  goto 

Re: [PATCH] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Ville Syrjälä
On Wed, Nov 08, 2017 at 02:11:46PM +0100, Daniel Vetter wrote:
> On Wed, Nov 08, 2017 at 03:04:58PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 08, 2017 at 01:57:50PM +0100, Daniel Vetter wrote:
> > > Two bits:
> > > - check actual atomic state, the legacy stuff can only be looked at
> > >   from within the atomic_commit_tail function, since it's only
> > >   protected by ordering and not by any locks.
> > > 
> > > - Make sure we don't wreak the work an ongoing nonblocking commit is
> > >   doing.
> > 
> > I still think we need to move the retraining to the hotplug work.
> 
> Why? One of the patch series Maarten mentioned says there's a deadlock
> with dp aux, but it seems to be all just fine when CI retrains.

I guess the deadlock is possible only with MST, maybe. Currently MST
has it's own copy of the retraining code without the locks.

At one point I started to rewrite the entire sink irq handling into a
much nicer shape, also unifying the approach between MST and SST. IIRC
I did still make the mistake of having some kind of higher level MST
vs. SST split, but I think the proper solution is to combine the two
almost entirely. I think we should even be using the ESI registers
with SST for DPCD 1.2+. Currently we use ESI for MST and non-ESI for
SST. Sadly I've not found the time to continue that work (same story
with the "shutdown displays prior to rebooting to keep Dell MST
monitors working" thing).

> 
> And even if there is a deadlock, it's there already, so not sure why we
> need to block this bugfix on a different bugfix. Which seems to be what
> you're suggesting here (but it's a bit sparse).

I guess what I'm really saying is that we shouldn't stop here.

> -Daniel
> 
> > > v2: We need the crtc lock too, because a plane update might change it
> > > without having to acquire the connection_mutex (Maarten). Use
> > > Maarten's changes for this locking, while keeping the logic that uses
> > > the connection->commit->hw_done signal for syncing with nonblocking
> > > commits.
> > > 
> > > Cc: Manasi Navare 
> > > Cc: Maarten Lankhorst 
> > > Cc: Ville Syrjälä 
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 56 
> > > -
> > >  1 file changed, 50 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index d27c0145ac91..7cd7ab4fb431 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4319,6 +4319,8 @@ static void
> > >  intel_dp_check_link_status(struct intel_dp *intel_dp)
> > >  {
> > >   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
> > > + struct drm_connector_state *conn_state =
> > > + intel_dp->attached_connector->base.state;
> > >   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > >   u8 link_status[DP_LINK_STATUS_SIZE];
> > >  
> > > @@ -4329,10 +4331,15 @@ intel_dp_check_link_status(struct intel_dp 
> > > *intel_dp)
> > >   return;
> > >   }
> > >  
> > > - if (!intel_encoder->base.crtc)
> > > + if (!conn_state->crtc)
> > >   return;
> > >  
> > > - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > > + WARN_ON(!drm_modeset_is_locked(&conn_state->crtc->mutex));
> > > +
> > > + if (!conn_state->crtc->state->active)
> > > + return;
> > > +
> > > + if (!try_wait_for_completion(&conn_state->commit->hw_done))
> > >   return;
> > >  
> > >   /*
> > > @@ -4368,7 +4375,6 @@ intel_dp_check_link_status(struct intel_dp 
> > > *intel_dp)
> > >  static bool
> > >  intel_dp_short_pulse(struct intel_dp *intel_dp)
> > >  {
> > > - struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > >   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
> > >   u8 sink_irq_vector = 0;
> > >   u8 old_sink_count = intel_dp->sink_count;
> > > @@ -4408,9 +4414,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> > >   DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
> > >   }
> > >  
> > > - drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> > >   intel_dp_check_link_status(intel_dp);
> > > - drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > > +
> > >   if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
> > >   DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
> > >   /* Send a Hotplug Uevent to userspace to start modeset */
> > > @@ -4860,8 +4865,19 @@ intel_dp_detect(struct drm_connector *connector,
> > > connector->base.id, connector->name);
> > >  
> > >   /* If full detect is not performed yet, do a full detect */
> > > - if (!intel_dp->detect_done)
> > > + if (!intel_dp->detect_done) {
> > > + struct drm_crtc *crtc;
> > > + int ret;
> > > +
> > > + crtc = connec

Re: [PATCH] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Daniel Vetter
On Wed, Nov 08, 2017 at 03:26:15PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 08, 2017 at 02:11:46PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 08, 2017 at 03:04:58PM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 08, 2017 at 01:57:50PM +0100, Daniel Vetter wrote:
> > > > Two bits:
> > > > - check actual atomic state, the legacy stuff can only be looked at
> > > >   from within the atomic_commit_tail function, since it's only
> > > >   protected by ordering and not by any locks.
> > > > 
> > > > - Make sure we don't wreak the work an ongoing nonblocking commit is
> > > >   doing.
> > > 
> > > I still think we need to move the retraining to the hotplug work.
> > 
> > Why? One of the patch series Maarten mentioned says there's a deadlock
> > with dp aux, but it seems to be all just fine when CI retrains.
> 
> I guess the deadlock is possible only with MST, maybe. Currently MST
> has it's own copy of the retraining code without the locks.
> 
> At one point I started to rewrite the entire sink irq handling into a
> much nicer shape, also unifying the approach between MST and SST. IIRC
> I did still make the mistake of having some kind of higher level MST
> vs. SST split, but I think the proper solution is to combine the two
> almost entirely. I think we should even be using the ESI registers
> with SST for DPCD 1.2+. Currently we use ESI for MST and non-ESI for
> SST. Sadly I've not found the time to continue that work (same story
> with the "shutdown displays prior to rebooting to keep Dell MST
> monitors working" thing).

Yeah, merging sst and mst more definitely sounds like a good idea. I've
also been toying with it since forever.

> > And even if there is a deadlock, it's there already, so not sure why we
> > need to block this bugfix on a different bugfix. Which seems to be what
> > you're suggesting here (but it's a bit sparse).
> 
> I guess what I'm really saying is that we shouldn't stop here.

Fully agreed.
-Daniel

> 
> > -Daniel
> > 
> > > > v2: We need the crtc lock too, because a plane update might change it
> > > > without having to acquire the connection_mutex (Maarten). Use
> > > > Maarten's changes for this locking, while keeping the logic that uses
> > > > the connection->commit->hw_done signal for syncing with nonblocking
> > > > commits.
> > > > 
> > > > Cc: Manasi Navare 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Ville Syrjälä 
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
> > > > Signed-off-by: Daniel Vetter 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 56 
> > > > -
> > > >  1 file changed, 50 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index d27c0145ac91..7cd7ab4fb431 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4319,6 +4319,8 @@ static void
> > > >  intel_dp_check_link_status(struct intel_dp *intel_dp)
> > > >  {
> > > > struct intel_encoder *intel_encoder = 
> > > > &dp_to_dig_port(intel_dp)->base;
> > > > +   struct drm_connector_state *conn_state =
> > > > +   intel_dp->attached_connector->base.state;
> > > > struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > > > u8 link_status[DP_LINK_STATUS_SIZE];
> > > >  
> > > > @@ -4329,10 +4331,15 @@ intel_dp_check_link_status(struct intel_dp 
> > > > *intel_dp)
> > > > return;
> > > > }
> > > >  
> > > > -   if (!intel_encoder->base.crtc)
> > > > +   if (!conn_state->crtc)
> > > > return;
> > > >  
> > > > -   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > > > +   WARN_ON(!drm_modeset_is_locked(&conn_state->crtc->mutex));
> > > > +
> > > > +   if (!conn_state->crtc->state->active)
> > > > +   return;
> > > > +
> > > > +   if (!try_wait_for_completion(&conn_state->commit->hw_done))
> > > > return;
> > > >  
> > > > /*
> > > > @@ -4368,7 +4375,6 @@ intel_dp_check_link_status(struct intel_dp 
> > > > *intel_dp)
> > > >  static bool
> > > >  intel_dp_short_pulse(struct intel_dp *intel_dp)
> > > >  {
> > > > -   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > > > struct intel_encoder *intel_encoder = 
> > > > &dp_to_dig_port(intel_dp)->base;
> > > > u8 sink_irq_vector = 0;
> > > > u8 old_sink_count = intel_dp->sink_count;
> > > > @@ -4408,9 +4414,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> > > > DRM_DEBUG_DRIVER("CP or sink specific irq 
> > > > unhandled\n");
> > > > }
> > > >  
> > > > -   drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> > > > intel_dp_check_link_status(intel_dp);
> > > > -   drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > > > +
> > > > if (inte

Re: [PATCH] drm: sti: remove vtg_remove

2017-11-08 Thread Benjamin Gaignard
2017-11-08 14:06 GMT+01:00 Benjamin Gaignard :
> vtg_remove does nothing just remove it
>
> Signed-off-by: Benjamin Gaignard 

Merge in drm-misc-next with Daniel's irc ack

> ---
>  drivers/gpu/drm/sti/sti_vtg.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
> index 5f75aea..3aa2fa6 100644
> --- a/drivers/gpu/drm/sti/sti_vtg.c
> +++ b/drivers/gpu/drm/sti/sti_vtg.c
> @@ -420,11 +420,6 @@ static int vtg_probe(struct platform_device *pdev)
> return 0;
>  }
>
> -static int vtg_remove(struct platform_device *pdev)
> -{
> -   return 0;
> -}
> -
>  static const struct of_device_id vtg_of_match[] = {
> { .compatible = "st,vtg", },
> { /* sentinel */ }
> @@ -438,7 +433,6 @@ struct platform_driver sti_vtg_driver = {
> .of_match_table = vtg_of_match,
> },
> .probe  = vtg_probe,
> -   .remove = vtg_remove,
>  };
>
>  MODULE_AUTHOR("Benjamin Gaignard ");
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: sti: remove useless fields from vtg structure

2017-11-08 Thread Benjamin Gaignard
2017-11-08 14:04 GMT+01:00 Benjamin Gaignard :
> Drivers are registered on platform bus so the private list
> could be replace by a call to of_find_device_by_node().
> Changing this also makes dev, np and link fields useless
> in vtg structure.
>
> Signed-off-by: Benjamin Gaignard 

Merge in drm-misc-next with Daniel's irc ack.


> ---
>  drivers/gpu/drm/sti/Kconfig   |  1 +
>  drivers/gpu/drm/sti/sti_vtg.c | 32 
>  2 files changed, 9 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index acd7286..cca4b3c 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -8,5 +8,6 @@ config DRM_STI
> select DRM_PANEL
> select FW_LOADER
> select SND_SOC_HDMI_CODEC if SND_SOC
> +   select OF
> help
>   Choose this option to enable DRM on STM stiH4xx chipset
> diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
> index 2dcba1d..5f75aea 100644
> --- a/drivers/gpu/drm/sti/sti_vtg.c
> +++ b/drivers/gpu/drm/sti/sti_vtg.c
> @@ -9,6 +9,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -72,8 +73,6 @@
>  #define AWG_DELAY_ED(-8)
>  #define AWG_DELAY_SD(-7)
>
> -static LIST_HEAD(vtg_lookup);
> -
>  /*
>   * STI VTG register offset structure
>   *
> @@ -123,42 +122,31 @@ struct sti_vtg_sync_params {
>  /**
>   * STI VTG structure
>   *
> - * @dev: pointer to device driver
> - * @np: device node
>   * @regs: register mapping
>   * @sync_params: synchronisation parameters used to generate timings
>   * @irq: VTG irq
>   * @irq_status: store the IRQ status value
>   * @notifier_list: notifier callback
>   * @crtc: the CRTC for vblank event
> - * @link: List node to link the structure in lookup list
>   */
>  struct sti_vtg {
> -   struct device *dev;
> -   struct device_node *np;
> void __iomem *regs;
> struct sti_vtg_sync_params sync_params[VTG_MAX_SYNC_OUTPUT];
> int irq;
> u32 irq_status;
> struct raw_notifier_head notifier_list;
> struct drm_crtc *crtc;
> -   struct list_head link;
>  };
>
> -static void vtg_register(struct sti_vtg *vtg)
> -{
> -   list_add_tail(&vtg->link, &vtg_lookup);
> -}
> -
>  struct sti_vtg *of_vtg_find(struct device_node *np)
>  {
> -   struct sti_vtg *vtg;
> +   struct platform_device *pdev;
>
> -   list_for_each_entry(vtg, &vtg_lookup, link) {
> -   if (vtg->np == np)
> -   return vtg;
> -   }
> -   return NULL;
> +   pdev = of_find_device_by_node(np);
> +   if (!pdev)
> +   return NULL;
> +
> +   return (struct sti_vtg *)platform_get_drvdata(pdev);
>  }
>
>  static void vtg_reset(struct sti_vtg *vtg)
> @@ -397,9 +385,6 @@ static int vtg_probe(struct platform_device *pdev)
> if (!vtg)
> return -ENOMEM;
>
> -   vtg->dev = dev;
> -   vtg->np = pdev->dev.of_node;
> -
> /* Get Memory ressources */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> @@ -428,10 +413,9 @@ static int vtg_probe(struct platform_device *pdev)
> return ret;
> }
>
> -   vtg_register(vtg);
> platform_set_drvdata(pdev, vtg);
>
> -   DRM_INFO("%s %s\n", __func__, dev_name(vtg->dev));
> +   DRM_INFO("%s %s\n", __func__, dev_name(dev));
>
> return 0;
>  }
> --
> 2.7.4
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92248

--- Comment #44 from Hector Velazquez 
 ---
This test continue failing on CFL QA

igt@kms_plane_scaling

This is my configuration:

==
Graphic stack
==
Component: drm
tag: libdrm-2.4.81-79-g61ff977
commit: 61ff9779e37179ed5106c0e2452e16500127fb9e

Component: cairo
tag: 1.15.6-63-g3322580
commit: 3322580f0488ff77f53d86c2b4d3cf59e6dca4c7

Component: intel-gpu-tools
tag: intel-gpu-tools-1.19-466-g1fc4de1
commit: 1fc4de1ca390adec9be8bd7cc0c36cab07465959

Component: piglit
tag: piglit-v1
commit: 65b4b197da9e4121155f2dca3fca913e677e7bf2
==
 Software
==
kernel version  : 4.14.0-rc7-drm-intel-qa-ww44-commit-2f945d9+
hostname: CFL-2
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
bios revision   : 95.4
bios release date   : 07/24/2017
ksc : 1.5
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
libdrm  : 2.4.87
cairo   : 1.15.9
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-470-gc8d1ea2
intel-gpu-tools (commit): c8d1ea2

==
 Firmware
==
dmc fw loaded : yes
dmc version   : 1.1
guc fw loaded : fetch SUCCESS, load SUCCESS
guc version wanted: wanted 9.14, found 9.14
guc version found : wanted 9.14, found 9.14

==
 kernel parameters
==
quiet drm.debug=0x1e pci=pcie_bus_safe intel_iommu=igfx_off auto panic=1
nmi_watchdog=panic i915.alpha_support=1 i915.enable_guc_loading=2
i915.enable_guc_submission=2 resume=/dev/sda3 fastboot

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


[PATCH 1/4] drm/ttm: move unlocking out of ttm_bo_cleanup_memtype_use

2017-11-08 Thread Christian König
Needed for the next patch and makes the code quite a bit easier to
understand.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c088703777e2..9905cf41cba6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -390,8 +390,6 @@ static void ttm_bo_cleanup_memtype_use(struct 
ttm_buffer_object *bo)
ttm_tt_destroy(bo->ttm);
bo->ttm = NULL;
ttm_bo_mem_put(bo, &bo->mem);
-
-   ww_mutex_unlock (&bo->resv->lock);
 }
 
 static int ttm_bo_individualize_resv(struct ttm_buffer_object *bo)
@@ -457,6 +455,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
reservation_object_unlock(&bo->ttm_resv);
 
ttm_bo_cleanup_memtype_use(bo);
+   reservation_object_unlock(bo->resv);
return;
}
 
@@ -559,6 +558,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
 
spin_unlock(&glob->lru_lock);
ttm_bo_cleanup_memtype_use(bo);
+   reservation_object_unlock(bo->resv);
 
return 0;
 }
-- 
2.11.0

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


[PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Christian König
Instead of having a pointless wrapper or call the underlying ww_mutex
function directly.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 13 +++--
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  8 
 include/drm/ttm/ttm_bo_driver.h| 14 +-
 3 files changed, 12 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9905cf41cba6..6f55310a9d09 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -471,7 +471,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
ttm_bo_add_to_lru(bo);
}
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
if (bo->resv != &bo->ttm_resv)
reservation_object_unlock(&bo->ttm_resv);
@@ -517,7 +517,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
 
if (ret && !no_wait_gpu) {
long lret;
-   ww_mutex_unlock(&bo->resv->lock);
+
+   reservation_object_unlock(bo->resv);
spin_unlock(&glob->lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true,
@@ -547,7 +548,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
}
 
if (ret || unlikely(list_empty(&bo->ddestroy))) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
spin_unlock(&glob->lru_lock);
return ret;
}
@@ -749,7 +750,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
 
if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
ret = -EBUSY;
continue;
}
@@ -1788,7 +1789,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
 * already swapped buffer.
 */
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
 }
@@ -1825,7 +1826,7 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
ret = __ttm_bo_reserve(bo, true, false, NULL);
if (unlikely(ret != 0))
goto out_unlock;
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
 
 out_unlock:
mutex_unlock(&bo->wu_mutex);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 5e1bcabffef5..373ced0b2fc2 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -38,7 +38,7 @@ static void ttm_eu_backoff_reservation_reverse(struct 
list_head *list,
list_for_each_entry_continue_reverse(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
 }
 
@@ -69,7 +69,7 @@ void ttm_eu_backoff_reservation(struct ww_acquire_ctx *ticket,
struct ttm_buffer_object *bo = entry->bo;
 
ttm_bo_add_to_lru(bo);
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
spin_unlock(&glob->lru_lock);
 
@@ -112,7 +112,7 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
 
ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), ticket);
if (!ret && unlikely(atomic_read(&bo->cpu_writers) > 0)) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
 
ret = -EBUSY;
 
@@ -203,7 +203,7 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx 
*ticket,
else
reservation_object_add_excl_fence(bo->resv, fence);
ttm_bo_add_to_lru(bo);
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
spin_unlock(&glob->lru_lock);
if (ticket)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 5f821a9b3a1f..389359a0006b 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -941,18 +941,6 @@ static inline int ttm_bo_reserve_slowpath(struct 
ttm_buffer_object *bo,
 }
 
 /**
- * __ttm_bo_unreserve
- * @bo: A pointer to a struct ttm_buffer_object.
- *
- * Unreserve a previous reservation of @bo where the buffer object is
- * already on lru lists.
- */
-static inline void __ttm_bo_unreserve(struct ttm_buffer_object *bo)
-{
-   ww_mutex_unlock(&bo->resv->lock);
-}
-
-/**
  * ttm_bo_unreserve
  *
  * @bo: A pointer to a struct ttm_bu

[PATCH 4/4] drm/ttm: optimize ttm_mem_evict_first

2017-11-08 Thread Christian König
Deleted BOs with the same reservation object can be reaped even if they
can't be reserved.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 35 +++
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d23592cfe42e..f486a484c70f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -735,20 +735,35 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
*bo,
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   uint32_t mem_type,
-   const struct ttm_place *place,
-   bool interruptible,
-   bool no_wait_gpu)
+  struct reservation_object *resv,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  bool interruptible,
+  bool no_wait_gpu)
 {
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+   bool locked;
unsigned i;
 
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
+   if (bo->resv == resv) {
+   if (list_empty(&bo->ddestroy))
+   continue;
+
+   if (place &&
+   !bdev->driver->eviction_valuable(bo, place))
+   continue;
+
+   ret = 0;
+   locked = false;
+   break;
+   }
+
ret = __ttm_bo_reserve(bo, false, true, NULL);
if (ret)
continue;
@@ -760,6 +775,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
continue;
}
 
+   locked = true;
break;
}
 
@@ -775,7 +791,8 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
kref_get(&bo->list_kref);
 
if (!list_empty(&bo->ddestroy)) {
-   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu,
+ locked);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}
@@ -786,7 +803,8 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
BUG_ON(ret != 0);
 
ret = ttm_bo_evict(bo, interruptible, no_wait_gpu);
-   ttm_bo_unreserve(bo);
+   if (locked)
+   ttm_bo_unreserve(bo);
 
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
@@ -850,7 +868,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type, place,
+   ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place,
  interruptible, no_wait_gpu);
if (unlikely(ret != 0))
return ret;
@@ -1353,7 +1371,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, 
false);
+   ret = ttm_mem_evict_first(bdev, NULL, mem_type, NULL,
+ false, false);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
-- 
2.11.0

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


[PATCH 3/4] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

2017-11-08 Thread Christian König
Needed for the next patch.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 52 
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6f55310a9d09..d23592cfe42e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -486,20 +486,21 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
 }
 
 /**
- * function ttm_bo_cleanup_refs_and_unlock
+ * function ttm_bo_cleanup_refs
  * If bo idle, remove from delayed- and lru lists, and unref.
  * If not idle, do nothing.
  *
  * Must be called with lru_lock and reservation held, this function
- * will drop both before returning.
+ * will drop the lru lock and optionally the reservation lock before returning.
  *
  * @interruptible Any sleeps should occur interruptibly.
  * @no_wait_gpu   Never wait for gpu. Return -EBUSY instead.
+ * @unlock_resv   Unlock the reservation lock as well.
  */
 
-static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
- bool interruptible,
- bool no_wait_gpu)
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+  bool interruptible, bool no_wait_gpu,
+  bool unlock_resv)
 {
struct ttm_bo_global *glob = bo->glob;
struct reservation_object *resv;
@@ -518,7 +519,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
if (ret && !no_wait_gpu) {
long lret;
 
-   reservation_object_unlock(bo->resv);
+   if (unlock_resv)
+   reservation_object_unlock(bo->resv);
spin_unlock(&glob->lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true,
@@ -531,19 +533,22 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return -EBUSY;
 
spin_lock(&glob->lru_lock);
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
-
-   /*
-* We raced, and lost, someone else holds the reservation now,
-* and is probably busy in ttm_bo_cleanup_memtype_use.
-*
-* Even if it's not the case, because we finished waiting any
-* delayed destruction would succeed, so just return success
-* here.
-*/
-   if (ret) {
-   spin_unlock(&glob->lru_lock);
-   return 0;
+   if (unlock_resv) {
+   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   /*
+* We raced, and lost, someone else holds the 
reservation now,
+* and is probably busy in ttm_bo_cleanup_memtype_use.
+*
+* Even if it's not the case, because we finished 
waiting any
+* delayed destruction would succeed, so just return 
success
+* here.
+*/
+   if (ret) {
+   spin_unlock(&glob->lru_lock);
+   return 0;
+   }
+   } else {
+   ret = 0;
}
}
 
@@ -600,8 +605,8 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
}
 
if (!ret)
-   ret = ttm_bo_cleanup_refs_and_unlock(entry, false,
-!remove_all);
+   ret = ttm_bo_cleanup_refs(entry, false, !remove_all,
+ true);
else
spin_unlock(&glob->lru_lock);
 
@@ -770,8 +775,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
kref_get(&bo->list_kref);
 
if (!list_empty(&bo->ddestroy)) {
-   ret = ttm_bo_cleanup_refs_and_unlock(bo, interruptible,
-no_wait_gpu);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}
@@ -1735,7 +1739,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
kref_get(&bo->list_kref);
 
if (!list_empty(&bo->ddestroy)) {
-   ret = ttm_bo_cleanup_refs_and_unlock(bo, false, false);
+   ret = ttm_bo_cleanup_refs(bo, false, false, true);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.or

Re: [PATCH 1/2] drm/atomic-helper: always track connector commits, too

2017-11-08 Thread Ville Syrjälä
On Wed, Nov 08, 2017 at 11:54:49AM +0100, Daniel Vetter wrote:
> It's useful for syncing async connector work like link retraining.
> 
> Cc: Manasi Navare 
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 71d712f1b56a..ea781d55f2c1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1791,7 +1791,8 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>   if (new_conn_state->crtc)
>   continue;

This guy says we will never have new_conn_state->crtc below.

>  
> - commit = crtc_or_fake_commit(state, old_conn_state->crtc);
> + /* Always track connectors explicitly for e.g. link retraining. 
> */
> + commit = crtc_or_fake_commit(state, new_conn_state->crtc ?: 
> old_conn_state->crtc);
>   if (!commit)
>   return -ENOMEM;
>  
> @@ -1805,10 +1806,7 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>   
> !try_wait_for_completion(&old_plane_state->commit->flip_done))
>   return -EBUSY;
>  
> - /*
> -  * Unlike connectors, always track planes explicitly for
> -  * async pageflip support.
> -  */
> + /* Always track planes explicitly for async pageflip support. */
>   commit = crtc_or_fake_commit(state, new_plane_state->crtc ?: 
> old_plane_state->crtc);
>   if (!commit)
>   return -ENOMEM;
> -- 
> 2.15.0

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 12/22] drm/sti: Use drm_fb_cma_fbdev_init/fini()

2017-11-08 Thread Noralf Trønnes


Den 08.11.2017 13.21, skrev Benjamin Gaignard:

2017-11-04 14:04 GMT+01:00 Noralf Trønnes :

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/sti/sti_drv.c | 25 +
  drivers/gpu/drm/sti/sti_drv.h |  1 -
  2 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 9e9343101738..d61efef30a82 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -138,16 +139,9 @@ static int sti_atomic_check(struct drm_device *dev,
 return ret;
  }

-static void sti_output_poll_changed(struct drm_device *ddev)
-{
-   struct sti_private *private = ddev->dev_private;
-
-   drm_fbdev_cma_hotplug_event(private->fbdev);
-}
-
  static const struct drm_mode_config_funcs sti_mode_config_funcs = {
 .fb_create = drm_gem_fb_create,
-   .output_poll_changed = sti_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 .atomic_check = sti_atomic_check,
 .atomic_commit = drm_atomic_helper_commit,
  };
@@ -230,11 +224,7 @@ static void sti_cleanup(struct drm_device *ddev)
  {
 struct sti_private *private = ddev->dev_private;

-   if (private->fbdev) {
-   drm_fbdev_cma_fini(private->fbdev);
-   private->fbdev = NULL;
-   }
-
+   drm_fb_cma_fbdev_fini(ddev);
 drm_kms_helper_poll_fini(ddev);
 component_unbind_all(ddev->dev, ddev);
 kfree(private);
@@ -245,7 +235,6 @@ static int sti_bind(struct device *dev)
  {
 struct drm_device *ddev;
 struct sti_private *private;
-   struct drm_fbdev_cma *fbdev;
 int ret;

 ddev = drm_dev_alloc(&sti_driver, dev);
@@ -268,13 +257,9 @@ static int sti_bind(struct device *dev)

 private = ddev->dev_private;
 if (ddev->mode_config.num_connector) {
-   fbdev = drm_fbdev_cma_init(ddev, 32,
-  ddev->mode_config.num_connector);
-   if (IS_ERR(fbdev)) {
+   ret = drm_fb_cma_fbdev_init(ddev, 32, 0);
+   if (ret)
 DRM_DEBUG_DRIVER("Warning: fails to create fbdev\n");
-   fbdev = NULL;
-   }
-   private->fbdev = fbdev;
 }

Like for stm driver I think that drm_kms_helper_poll_init() call
should be move after
this block of code.


I fail to see how this patchset affects output polling.
What kind of problem are you seeing?

I think we need to understand what's happening here because more
drivers call drm_kms_helper_poll_init() before fbdev init.

These are the various call sequences in the cma helper drivers:

arc, hdlcd, kirin, mxsfb, rcar-du, stm, zte:

drm_mode_config_reset()
drm_kms_helper_poll_init()
drm_fbdev_cma_init()
drm_dev_register()


atmel-hlcdc, imx, meson, pl111, sun4i, tilcdc, tve200:

drm_mode_config_reset()
drm_fbdev_cma_init()
drm_kms_helper_poll_init()
drm_dev_register()


sti:

drm_kms_helper_poll_init()
drm_dev_register()
drm_mode_config_reset()
drm_fbdev_cma_init()


vc4:

drm_dev_register()
drm_mode_config_reset()
drm_fbdev_cma_init()
drm_kms_helper_poll_init()


struct sti_private *private could also be remove of the function.


Will do.


When testing your patches I have a kernel panic in drm_fbdev_cma_create()
because fbdev_cma->fb_funcs is NULL so using/testing fbdev_cma->fb_funcs->dirty
make kernel crash.


Sorry about this, I was certain that I had tested this on the vc4 driver,
but it's clear that I haven't :/

Thanks for catching this!

Noralf.


Just adding a test on fbdev_cma->fb_funcs value fix the problem but I
wonder why I'm
the only to report this issue ?

With all these fix I have a fonctionnal frame buffer.

Benjamin

 return 0;
diff --git a/drivers/gpu/drm/sti/sti_drv.h b/drivers/gpu/drm/sti/sti_drv.h
index 6502ed2d3351..16c5c9110cb0 100644
--- a/drivers/gpu/drm/sti/sti_drv.h
+++ b/drivers/gpu/drm/sti/sti_drv.h
@@ -24,7 +24,6 @@ struct sti_private {
 struct sti_compositor *compo;
 struct drm_property *plane_zorder_property;
 struct drm_device *drm_dev;
-   struct drm_fbdev_cma *fbdev;
  };

  extern struct platform_driver sti_tvout_driver;
--
2.14.2






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


[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99553

Jan Vesely  changed:

   What|Removed |Added

 Depends on||103586


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=103586
[Bug 103586] OpenCL/Clover: AMD Turks: corrupt output buffer (depending on
dimension order?)
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 13/22] drm/stm: Use drm_fb_cma_fbdev_init/fini()

2017-11-08 Thread Noralf Trønnes


Den 06.11.2017 18.32, skrev Philippe CORNU:

Hi Noralf,

On 11/04/2017 02:04 PM, Noralf Trønnes wrote:

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Yannick Fertre 
Cc: Philippe Cornu 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Noralf Trønnes 

Many thanks for this nice cleanup.

I will have to push a small fix to move drm_kms_helper_poll_init() after
drm_fb_cma_fbdev_init() in order to remove a warning when booting (+ a
small cleanup as "ldev = ddev->dev_private;" is not used anymore before
drm_fb_cma_fbdev_init().


I can remove ldev in the next version.
Please take part in the conversation with Benjamin about polling in the 
sti patch.


Noralf.


Anyway, regarding your patchset for stm:

Acked-by: Philippe Cornu 
Tested-by: Philippe Cornu 

Thank you,
Philippe :-)


---
   drivers/gpu/drm/stm/drv.c  | 37 ++---
   drivers/gpu/drm/stm/ltdc.h |  1 -
   2 files changed, 6 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index c857663eafc2..9a66f5671d4f 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -15,6 +15,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -24,35 +25,19 @@
   #define STM_MAX_FB_WIDTH 2048
   #define STM_MAX_FB_HEIGHT2048 /* same as width to handle orientation */
   
-static void drv_output_poll_changed(struct drm_device *ddev)

-{
-   struct ltdc_device *ldev = ddev->dev_private;
-
-   drm_fbdev_cma_hotplug_event(ldev->fbdev);
-}
-
   static const struct drm_mode_config_funcs drv_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
-   .output_poll_changed = drv_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
   };
   
-static void drv_lastclose(struct drm_device *ddev)

-{
-   struct ltdc_device *ldev = ddev->dev_private;
-
-   DRM_DEBUG("%s\n", __func__);
-
-   drm_fbdev_cma_restore_mode(ldev->fbdev);
-}
-
   DEFINE_DRM_GEM_CMA_FOPS(drv_driver_fops);
   
   static struct drm_driver drv_driver = {

.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
   DRIVER_ATOMIC,
-   .lastclose = drv_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
.name = "stm",
.desc = "STMicroelectronics SoC DRM",
.date = "20170330",
@@ -79,7 +64,6 @@ static struct drm_driver drv_driver = {
   static int drv_load(struct drm_device *ddev)
   {
struct platform_device *pdev = to_platform_device(ddev->dev);
-   struct drm_fbdev_cma *fbdev;
struct ltdc_device *ldev;
int ret;
   
@@ -113,13 +97,9 @@ static int drv_load(struct drm_device *ddev)
   
   	if (ddev->mode_config.num_connector) {

ldev = ddev->dev_private;
-   fbdev = drm_fbdev_cma_init(ddev, 16,
-  ddev->mode_config.num_connector);
-   if (IS_ERR(fbdev)) {
+   ret = drm_fb_cma_fbdev_init(ddev, 16, 0);
+   if (ret)
DRM_DEBUG("Warning: fails to create fbdev\n");
-   fbdev = NULL;
-   }
-   ldev->fbdev = fbdev;
}
   
   	platform_set_drvdata(pdev, ddev);

@@ -132,14 +112,9 @@ static int drv_load(struct drm_device *ddev)
   
   static void drv_unload(struct drm_device *ddev)

   {
-   struct ltdc_device *ldev = ddev->dev_private;
-
DRM_DEBUG("%s\n", __func__);
   
-	if (ldev->fbdev) {

-   drm_fbdev_cma_fini(ldev->fbdev);
-   ldev->fbdev = NULL;
-   }
+   drm_fb_cma_fbdev_fini(ddev);
drm_kms_helper_poll_fini(ddev);
ltdc_unload(ddev);
drm_mode_config_cleanup(ddev);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index ae437557d715..27ac217406be 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -21,7 +21,6 @@ struct ltdc_caps {
   };
   
   struct ltdc_device {

-   struct drm_fbdev_cma *fbdev;
void __iomem *regs;
struct clk *pixel_clk;  /* lcd pixel clock */
struct mutex err_lock;  /* protecting error_status */



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


[PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

2017-11-08 Thread Ville Syrjala
From: Ville Syrjälä 

Apparently some sinks look at the YQ bits even when receiving RGB,
and they get somehow confused when they see a non-zero YQ value.
So we can't just blindly follow CEA-861-F and set YQ to match the
RGB range.

Unfortunately there is no good way to tell whether the sink
designer claims to have read CEA-861-F. The CEA extension block
revision number has generally been stuck at 3 since forever,
and even a very recently manufactured sink might be based on
an old design so the manufacturing date doesn't seem like
something we can use. In lieu of better information let's
follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.

The alternative would of course be to always set YQ=0. And if
we ever encounter a HDMI 2.0+ sink with this bug that's what
we'll probably have to do.

Cc: sta...@vger.kernel.org
Cc: Jani Nikula 
Cc: Eric Anholt 
Cc: Neil Kownacki 
Reported-by: Neil Kownacki 
Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to 
CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c| 12 ++--
 drivers/gpu/drm/i915/intel_hdmi.c |  3 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  3 ++-
 include/drm/drm_edid.h|  3 ++-
 4 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..8567890f47a7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4838,7 +4838,8 @@ void
 drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
   const struct drm_display_mode *mode,
   enum hdmi_quantization_range rgb_quant_range,
-  bool rgb_quant_range_selectable)
+  bool rgb_quant_range_selectable,
+  bool is_hdmi2_sink)
 {
/*
 * CEA-861:
@@ -4862,8 +4863,15 @@ drm_hdmi_avi_infoframe_quant_range(struct 
hdmi_avi_infoframe *frame,
 *  YQ-field to match the RGB Quantization Range being transmitted
 *  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
 *  set YQ=1) and the Sink shall ignore the YQ-field."
+*
+* Unfortunate certain sinks (eg. VIZ Model 67/E261VA) get confused
+* by non-zero YQ when receiving RGB. There doesn't seem to be any
+* good way to tell which version of CEA-861 the sink supports, so
+* we limit non-zero YQ to HDMI 2.0 sinks only as HDMI 2.0 is based
+* on on CEA-861-F.
 */
-   if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
+   if (!is_hdmi2_sink ||
+   rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
frame->ycc_quantization_range =
HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
else
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index fa1c793a21ef..2b23d3662eec 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -487,7 +487,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
   HDMI_QUANTIZATION_RANGE_FULL,
-  
intel_hdmi->rgb_quant_range_selectable);
+  
intel_hdmi->rgb_quant_range_selectable,
+  is_hdmi2_sink);
 
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, &frame);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9a9a6b4acccf..d645df0c6d15 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -423,7 +423,8 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder)
   vc4_encoder->limited_rgb_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
   HDMI_QUANTIZATION_RANGE_FULL,
-  vc4_encoder->rgb_range_selectable);
+  vc4_encoder->rgb_range_selectable,
+  false);
 
vc4_hdmi_write_infoframe(encoder, &frame);
 }
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 9e4e23524840..58ffb68efdc5 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -361,7 +361,8 @@ void
 drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
   const struct drm_display_mode *mode,
   e

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Tue, Nov 07, 2017 at 09:34:35PM +0530, Agrawal, Akshu wrote:
> On 11/7/2017 5:07 PM, Mark Brown wrote:

> > > > These two URLs are different, what was being reviewed here?  What is
> > > > Commit-Ready supposed to mean?

> Same patch is reviewed, once on 4.4 kernel (659699) and then on 4.12 kernel
> (672267).
> Commit-ready is to get it merged on tree after receiving a +2.

OK, that's not unreasonable but probably best to mention if the review
was in the context of a very old kernel, sometimes upstream changes can
invalidate the review.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Applied "ASoC: amd: Report accurate hw_ptr during dma" to the asoc tree

2017-11-08 Thread Mark Brown
The patch

   ASoC: amd: Report accurate hw_ptr during dma

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 61add8147942d23519b91f0edc30980d7c14482c Mon Sep 17 00:00:00 2001
From: Vijendar Mukunda 
Date: Fri, 3 Nov 2017 16:35:43 -0400
Subject: [PATCH] ASoC: amd: Report accurate hw_ptr during dma

Using hw register to read transmitted byte count and report
accordingly the hw pointer.

TEST=
modprobe snd-soc-acp-pcm.ko
modprobe snd-soc-acp-rt5645.ko
aplay 

Signed-off-by: Vijendar Mukunda 
Signed-off-by: Akshu Agrawal 
Tested-by: Akshu Agrawal 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/acp-pcm-dma.c | 71 -
 sound/soc/amd/acp.h | 10 +++
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 73b58ee00383..e19f281afeaa 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -817,39 +817,48 @@ static int acp_dma_hw_free(struct snd_pcm_substream 
*substream)
return snd_pcm_lib_free_pages(substream);
 }
 
+static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
+{
+   union acp_dma_count playback_dma_count;
+   union acp_dma_count capture_dma_count;
+   u64 bytescount = 0;
+
+   if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
+   mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
+   playback_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+   mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
+   bytescount = playback_dma_count.bytescount;
+   } else {
+   capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
+   mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
+   capture_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+   mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
+   bytescount = capture_dma_count.bytescount;
+   }
+   return bytescount;
+}
+
 static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream *substream)
 {
-   u16 dscr;
-   u32 mul, dma_config, period_bytes;
+   u32 buffersize;
u32 pos = 0;
+   u64 bytescount = 0;
 
struct snd_pcm_runtime *runtime = substream->runtime;
struct audio_substream_data *rtd = runtime->private_data;
 
-   period_bytes = frames_to_bytes(runtime, runtime->period_size);
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   dscr = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CUR_DSCR_13);
+   buffersize = frames_to_bytes(runtime, runtime->buffer_size);
+   bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
 
-   if (dscr == PLAYBACK_START_DMA_DESCR_CH13)
-   mul = 0;
-   else
-   mul = 1;
-   pos =  (mul * period_bytes);
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   if (bytescount > rtd->renderbytescount)
+   bytescount = bytescount - rtd->renderbytescount;
+   pos =  bytescount % buffersize;
} else {
-   dma_config = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CNTL_14);
-   if (dma_config != 0) {
-   dscr = acp_reg_read(rtd->acp_mmio,
-   mmACP_DMA_CUR_DSCR_14);
-   if (dscr == CAPTURE_START_DMA_DESCR_CH14)
-   mul = 1;
-   else
-   mul = 2;
-   pos = (mul * period_bytes);
-   }
-
-   if (pos >= (2 * period_bytes))
-   pos = 0;
-
+   if (bytescount > rtd->capturebytescount)
+   bytescount = bytescount - rtd->capturebytescount;
+   pos = bytescount % buffersize;
}
return bytes_to_frames(runtime, pos);
 }
@@ -904,6 +913,7 @@ static int acp_dma_trigger(struct snd_pcm_

[Bug 103625] Sporadic GPU HANG issue while Java is rendering via OpenGL

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103625

Bug ID: 103625
   Summary: Sporadic GPU HANG issue while Java is rendering via
OpenGL
   Product: Mesa
   Version: 17.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: l...@raritan.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135305
  --> https://bugs.freedesktop.org/attachment.cgi?id=135305&action=edit
/sys/class/drm/card0/error

GPU HANG: ecode 7:0:0x87d3bffa, in java [3688], reason: Hang on render ring,
action: reset

Java is rendering RFB content via OpenGL all day long and the OpenGL content
hangs at some point in time
Sometimes after 5 Minutes after bootup and application start, sometime after 7
days...

System: Shuttle Inc. DS81D
OS: CentOS 7.4.1708
CPU: Intel(R) Celeron(R) CPU G1840 @ 2.80GHz
Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor Integrated Graphics Controller (rev 06)

Kernel: 3.10.0-693.5.2.el7.x86_64
Used software:
libdrm-2.4.74-1.el7.x86_64
mesa-dri-drivers-17.0.1-6.20170307.el7.x86_64
mesa-private-llvm-3.9.1-3.el7.x86_64
xorg-x11-drv-intel-2.99.917-26.20160929.el7.x86_64
xorg-x11-server-Xorg-1.19.3-11.el7.x86_64

Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
DP1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 640mm
x 360mm
DP2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis)
640mm x 360mm

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


[Bug 103625] Sporadic GPU HANG issue while Java is rendering via OpenGL

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103625

--- Comment #1 from Lars Taubert  ---
Created attachment 135306
  --> https://bugs.freedesktop.org/attachment.cgi?id=135306&action=edit
dmesg output

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


[Bug 103625] Sporadic GPU HANG issue while Java is rendering via OpenGL

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103625

--- Comment #2 from Lars Taubert  ---
Created attachment 135307
  --> https://bugs.freedesktop.org/attachment.cgi?id=135307&action=edit
/var/log/Xorg.0.log

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


[Bug 103625] Sporadic GPU HANG issue while Java is rendering via OpenGL

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103625

--- Comment #3 from Lars Taubert  ---
Created attachment 135308
  --> https://bugs.freedesktop.org/attachment.cgi?id=135308&action=edit
/etc/X11/xorg.conf.d/01-intel-graphics.conf

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


[Bug 103625] Sporadic GPU HANG issue while Java is rendering via OpenGL

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103625

--- Comment #4 from Lars Taubert  ---
Created attachment 135309
  --> https://bugs.freedesktop.org/attachment.cgi?id=135309&action=edit
xrandr --verbose output

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


[Bug 103625] Sporadic GPU HANG issue while Java is rendering via OpenGL

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103625

--- Comment #5 from Lars Taubert  ---
Created attachment 135310
  --> https://bugs.freedesktop.org/attachment.cgi?id=135310&action=edit
detailed version of used drm, mesa & xorg software

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


Re: [PATCH 1/2] fbdev: pxa3xx: use ktime_get_ts64 for time stamps

2017-11-08 Thread Arnd Bergmann
On Tue, Nov 7, 2017 at 3:13 PM, Arnd Bergmann  wrote:
> do_gettimeofday() is deprecated because it is not y2038 safe, so I'm
> changing the calculation for the diagnostic output over to using
> 'timespec64'.
>
> We really only print time deltas here, so changing it to monotonic
> time makes this more robust, the correct accessor for this is
> ktime_get_ts64().
>
> Signed-off-by: Arnd Bergmann 

Please ignore this patch, my randconfig builder found a typo that
I had not noticed before.

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


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Michel Dänzer
On 08/11/17 03:59 PM, Christian König wrote:
> Instead of having a pointless wrapper or call the underlying ww_mutex
> function directly.

Not sure I can agree it's pointless, since it recently took me a while
to realize that unlocking bo->resv is essentially the same as
unreserving the BO.


Anyway, this breaks the qxl driver:

drivers/gpu/drm//qxl/qxl_release.c: In function 
‘qxl_release_fence_buffer_objects’:
drivers/gpu/drm//qxl/qxl_release.c:472:3: error: implicit declaration of 
function ‘__ttm_bo_unreserve’; did you mean ‘ttm_bo_unreserve’? 
[-Werror=implicit-function-declaration]
   __ttm_bo_unreserve(bo);
   ^~
   ttm_bo_unreserve


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


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Christian König

Am 08.11.2017 um 17:36 schrieb Michel Dänzer:

On 08/11/17 03:59 PM, Christian König wrote:

Instead of having a pointless wrapper or call the underlying ww_mutex
function directly.

Not sure I can agree it's pointless, since it recently took me a while
to realize that unlocking bo->resv is essentially the same as
unreserving the BO.


Ok in this case let's call this confusing. But yeah that 
__ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and 
ww_mutex_unlock(&bo->resv->lock) are essentially the same thing is 
exactly what I want to fix here.



Anyway, this breaks the qxl driver:

drivers/gpu/drm//qxl/qxl_release.c: In function 
‘qxl_release_fence_buffer_objects’:
drivers/gpu/drm//qxl/qxl_release.c:472:3: error: implicit declaration of 
function ‘__ttm_bo_unreserve’; did you mean ‘ttm_bo_unreserve’? 
[-Werror=implicit-function-declaration]
__ttm_bo_unreserve(bo);
^~
ttm_bo_unreserve


Thanks for pointing this out, going to respin.

Christian.

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


[PATCH v2 0/3] Fixes for AMD Stoney ACP audio

2017-11-08 Thread Alex Deucher
This patch set is just a couple fixes for the Audio CoProcessor (ACP)
on AMD Stoney platforms and a small general fix for the rt5645
codec driver.

The entire patch set can also be viewed here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=sound-for-next-stoney2

Thanks!

Alex

v2: - Add a fix for a 64 bit divide in hw_ptr patch
- rework rt5645 patch as per Mark's comments


Akshu Agrawal (2):
  ASoC: AMD: Make the driver name consistent across files
  ASoC: rt5645: Wait for 400msec before concluding on value of
RT5645_VENDOR_ID2

Guenter Roeck (1):
  FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 9 +
 sound/soc/codecs/rt5645.c   | 9 +
 3 files changed, 16 insertions(+), 6 deletions(-)

-- 
2.13.6

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


[PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
From: Guenter Roeck 

ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!

64-bit divides require special operations to avoid build errors on 32-bit
systems.

BUG=b:63121716
TEST="Build i386:allmodconfig"

Signed-off-by: Guenter Roeck 
Reviewed-on: https://chromium-review.googlesource.com/678919
Reviewed-by: Jason Clinton 
(cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
Reviewed-on: https://chromium-review.googlesource.com/681618
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/acp-pcm-dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 13d040a4d26f..ef7e98ad960c 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct 
snd_pcm_substream *substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (bytescount > rtd->renderbytescount)
bytescount = bytescount - rtd->renderbytescount;
-   pos =  bytescount % buffersize;
} else {
if (bytescount > rtd->capturebytescount)
bytescount = bytescount - rtd->capturebytescount;
-   pos = bytescount % buffersize;
}
+   pos = do_div(bytescount, buffersize);
return bytes_to_frames(runtime, pos);
 }
 
-- 
2.13.6

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


[PATCH 1/3] ASoC: AMD: Make the driver name consistent across files

2017-11-08 Thread Alex Deucher
From: Akshu Agrawal 

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci:00/:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

BUG=b:62103837
TEST=boot and check for device in lsmod

Signed-off-by: Akshu Agrawal 
Reviewed-on: https://chromium-review.googlesource.com/678278
Tested-by: Jason Clinton 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff6c73e..f07fd2e2870a 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e19f281afeaa..13d040a4d26f 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1189,7 +1191,7 @@ static struct platform_driver acp_dma_driver = {
.probe = acp_audio_probe,
.remove = acp_audio_remove,
.driver = {
-   .name = "acp_audio_dma",
+   .name = DRV_NAME,
.pm = &acp_pm_ops,
},
 };
@@ -1200,4 +1202,4 @@ MODULE_AUTHOR("vijendar.muku...@amd.com");
 MODULE_AUTHOR("maruthi.bayyavar...@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.13.6

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


[PATCH v2 2/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

2017-11-08 Thread Alex Deucher
From: Akshu Agrawal 

Minimum time required between power On of codec and read
of RT5645_VENDOR_ID2 is 400msec. We should wait that long
before reading the value.

TEST=Cold boot the device and check for sound device.

Signed-off-by: Akshu Agrawal 
Signed-off-by: Bard Liao 
Signed-off-by: Alex Deucher 
---

v2: rework the patch based on mailing list discussion.
Just wait before reading the register.

 sound/soc/codecs/rt5645.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 23cc2cb8393f..ce5d2c3c6976 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -55,6 +55,8 @@ MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
 
 #define RT5645_HWEQ_NUM 57
 
+#define TIME_TO_POWER_MS 400
+
 static const struct regmap_range_cfg rt5645_ranges[] = {
{
.name = "PR",
@@ -3786,6 +3788,13 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
}
regmap_read(regmap, RT5645_VENDOR_ID2, &val);
 
+   /*
+* Read after 400msec, as it is the interval required between
+* read and power On.
+*/
+   msleep(TIME_TO_POWER_MS);
+   regmap_read(regmap, RT5645_VENDOR_ID2, &val);
+
switch (val) {
case RT5645_DEVICE_ID:
rt5645->regmap = devm_regmap_init_i2c(i2c, &rt5645_regmap);
-- 
2.13.6

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


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Michel Dänzer
On 08/11/17 05:41 PM, Christian König wrote:
> Am 08.11.2017 um 17:36 schrieb Michel Dänzer:
>> On 08/11/17 03:59 PM, Christian König wrote:
>>> Instead of having a pointless wrapper or call the underlying ww_mutex
>>> function directly.
>> Not sure I can agree it's pointless, since it recently took me a while
>> to realize that unlocking bo->resv is essentially the same as
>> unreserving the BO.
> 
> Ok in this case let's call this confusing. But yeah that
> __ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and
> ww_mutex_unlock(&bo->resv->lock) are essentially the same thing is
> exactly what I want to fix here.

How about always using __ttm_bo_unreserve instead?


The first piglit run with this series applied hit the BUG_ON in
ttm_bo_add_to_lru, see the attached dmesg excerpt. The machine hung,
couldn't reboot cleanly. Haven't been able to reproduce it in three more
attempts though, so I'm not sure it's caused by this series, but I don't
remember seeing it before.


P.S. I just noticed I haven't had CONFIG_PROVE_LOCKING enabled in my
kernels for a while, I'll enable it again. Any other options that should
be enabled for testing?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
Nov  8 17:54:48 kaveri kernel: [ 1084.244694] [ cut here ]
Nov  8 17:54:48 kaveri kernel: [ 1084.244697] kernel BUG at drivers/gpu/drm//ttm/ttm_bo.c:172!
Nov  8 17:54:48 kaveri kernel: [ 1084.244703] invalid opcode:  [#1] SMP KASAN
Nov  8 17:54:48 kaveri kernel: [ 1084.244705] Modules linked in: lz4 lz4_compress cpufreq_powersave cpufreq_userspace cpufreq_conservative binfmt_misc nls_ascii nls_cp437 vfat fat edac_mce_amd amdgpu(O) amdkfd(O) radeon(O) kvm snd_hda_codec_realtek chash irqbypass snd_hda_codec_generic ttm(O) snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul drm_kms_helper(O) ghash_clmulni_intel efi_pstore snd_hda_intel pcbc snd_hda_codec drm(O) snd_hda_core snd_hwdep wmi_bmof snd_pcm snd_timer i2c_algo_bit fb_sys_fops snd aesni_intel syscopyarea ccp sysfillrect aes_x86_64 r8169 crypto_simd sp5100_tco ppdev glue_helper cryptd sg sysimgblt mfd_core mii soundcore rng_core pcspkr efivars i2c_piix4 parport_pc wmi parport i2c_designware_platform i2c_designware_core button acpi_cpufreq tcp_bbr sch_fq nct6775 hwmon_vid sunrpc efivarfs ip_tables x_tables
Nov  8 17:54:48 kaveri kernel: [ 1084.244743]  autofs4 ext4 crc16 mbcache jbd2 fscrypto dm_mod raid10 raid1 raid0 multipath linear md_mod sd_mod evdev hid_generic usbhid hid ahci xhci_pci libahci xhci_hcd libata crc32c_intel usbcore scsi_mod shpchp gpio_amdpt gpio_generic
Nov  8 17:54:48 kaveri kernel: [ 1084.244766] CPU: 13 PID: 4778 Comm: tex3d-maxsize Tainted: G   O4.14.0-rc3+ #32
Nov  8 17:54:48 kaveri kernel: [ 1084.244768] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 TOMAHAWK (MS-7A34), BIOS 1.80 09/13/2017
Nov  8 17:54:48 kaveri kernel: [ 1084.244770] task: 880233de6c80 task.stack: 880225ce
Nov  8 17:54:48 kaveri kernel: [ 1084.244779] RIP: 0010:ttm_bo_add_to_lru+0x4fe/0x640 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244780] RSP: 0018:880225ce6d60 EFLAGS: 00010206
Nov  8 17:54:48 kaveri kernel: [ 1084.244783] RAX: dc00 RBX: 88038de24cd8 RCX: 
Nov  8 17:54:48 kaveri kernel: [ 1084.244784] RDX: 110044b9cdb4 RSI:  RDI: 88038de24ce0
Nov  8 17:54:48 kaveri kernel: [ 1084.244786] RBP: 110044b9cdb0 R08: 07cbd06c R09: 
Nov  8 17:54:48 kaveri kernel: [ 1084.244788] R10: 93daac8e R11: 00057de4 R12: 110044b9cdb4
Nov  8 17:54:48 kaveri kernel: [ 1084.244791] R13: 880388033c88 R14: 88038de24d88 R15: 88038a452718
Nov  8 17:54:48 kaveri kernel: [ 1084.244794] FS:  7fa01e650300() GS:8803ae74() knlGS:
Nov  8 17:54:48 kaveri kernel: [ 1084.244797] CS:  0010 DS:  ES:  CR0: 80050033
Nov  8 17:54:48 kaveri kernel: [ 1084.244799] CR2: 7faecd0f06f0 CR3: 00038b7d3000 CR4: 003406e0
Nov  8 17:54:48 kaveri kernel: [ 1084.244801] Call Trace:
Nov  8 17:54:48 kaveri kernel: [ 1084.244823]  ? drm_mm_init+0x4d0/0x4d0 [drm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244832]  ? ttm_bo_device_init+0x620/0x620 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244837]  ? __kernel_text_address+0xe/0x30
Nov  8 17:54:48 kaveri kernel: [ 1084.244841]  ? bpf_prog_alloc+0x2d0/0x2d0
Nov  8 17:54:48 kaveri kernel: [ 1084.244844]  ? deref_stack_reg+0x1f0/0x1f0
Nov  8 17:54:48 kaveri kernel: [ 1084.244851]  ttm_mem_evict_first+0x473/0x5c0 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244857]  ? ttm_bo_evict+0xc70/0xc70 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244863]  ttm_bo_mem_space+0x89d/0xed0 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244869]  ? ttm_bo_mem_compat+0x6b/0x130 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244874]  ttm_bo_validate+0x301/0x530 [ttm]

Re: [PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 12:29 PM, Guenter Roeck  wrote:
> On Wed, Nov 8, 2017 at 9:24 AM, Alex Deucher  wrote:
>>
>> From: Guenter Roeck 
>>
>> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
>>
>> 64-bit divides require special operations to avoid build errors on 32-bit
>> systems.
>>
>> BUG=b:63121716
>> TEST="Build i386:allmodconfig"
>>
>
> Is this an upstream submission ? Fine with me, but it should not include any
> chromium specific tags, neither in the subject not in the description.

I'm not familiar with which are chromium specific (TEST, BUG, FIXUP,
FROMLIST I guess?). The info seems useful to have in the bug, but I
can respin if it's a big deal.

Alex

>
> Guenter
>
>>
>> Signed-off-by: Guenter Roeck 
>> Reviewed-on: https://chromium-review.googlesource.com/678919
>> Reviewed-by: Jason Clinton 
>> (cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
>> Reviewed-on: https://chromium-review.googlesource.com/681618
>> Signed-off-by: Alex Deucher 
>> ---
>>  sound/soc/amd/acp-pcm-dma.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
>> index 13d040a4d26f..ef7e98ad960c 100644
>> --- a/sound/soc/amd/acp-pcm-dma.c
>> +++ b/sound/soc/amd/acp-pcm-dma.c
>> @@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
>> snd_pcm_substream *substream)
>> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>> if (bytescount > rtd->renderbytescount)
>> bytescount = bytescount - rtd->renderbytescount;
>> -   pos =  bytescount % buffersize;
>> } else {
>> if (bytescount > rtd->capturebytescount)
>> bytescount = bytescount - rtd->capturebytescount;
>> -   pos = bytescount % buffersize;
>> }
>> +   pos = do_div(bytescount, buffersize);
>> return bytes_to_frames(runtime, pos);
>>  }
>>
>> --
>> 2.13.6
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 103519] wayland egl apps crash on start with mesa 17.2

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103519

--- Comment #6 from Emil Velikov  ---
Send Derek's patch to the list with some ack/rb tags. Modulo any objections
I'll push it in a day or two.

[1] https://patchwork.freedesktop.org/patch/187092/

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


Re: [PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 12:42 PM, Alex Deucher  wrote:
> On Wed, Nov 8, 2017 at 12:29 PM, Guenter Roeck  wrote:
>> On Wed, Nov 8, 2017 at 9:24 AM, Alex Deucher  wrote:
>>>
>>> From: Guenter Roeck 
>>>
>>> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
>>>
>>> 64-bit divides require special operations to avoid build errors on 32-bit
>>> systems.
>>>
>>> BUG=b:63121716
>>> TEST="Build i386:allmodconfig"
>>>
>>
>> Is this an upstream submission ? Fine with me, but it should not include any
>> chromium specific tags, neither in the subject not in the description.
>
> I'm not familiar with which are chromium specific (TEST, BUG, FIXUP,
> FROMLIST I guess?). The info seems useful to have in the bug, but I
> can respin if it's a big deal.

s/bug/commit message/

Alex

>
> Alex
>
>>
>> Guenter
>>
>>>
>>> Signed-off-by: Guenter Roeck 
>>> Reviewed-on: https://chromium-review.googlesource.com/678919
>>> Reviewed-by: Jason Clinton 
>>> (cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
>>> Reviewed-on: https://chromium-review.googlesource.com/681618
>>> Signed-off-by: Alex Deucher 
>>> ---
>>>  sound/soc/amd/acp-pcm-dma.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
>>> index 13d040a4d26f..ef7e98ad960c 100644
>>> --- a/sound/soc/amd/acp-pcm-dma.c
>>> +++ b/sound/soc/amd/acp-pcm-dma.c
>>> @@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
>>> snd_pcm_substream *substream)
>>> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>>> if (bytescount > rtd->renderbytescount)
>>> bytescount = bytescount - rtd->renderbytescount;
>>> -   pos =  bytescount % buffersize;
>>> } else {
>>> if (bytescount > rtd->capturebytescount)
>>> bytescount = bytescount - rtd->capturebytescount;
>>> -   pos = bytescount % buffersize;
>>> }
>>> +   pos = do_div(bytescount, buffersize);
>>> return bytes_to_frames(runtime, pos);
>>>  }
>>>
>>> --
>>> 2.13.6
>>>
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 66963] Rv6xx dpm problems

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #297 from Nicola Mori  ---
@Mihai I'm using dpm since years on my Mobility 3470 and I only experience
random freezes very rarely. The only thing that's really annoying for me is
this:

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

but it seems that it's not going to be fixed. Actually, all the remaining r6xx
dpm bugs will likely stay here forever, given the shifted focus of AMD
developer towards newer architecture and maybe the lack of hardware for
testing. Many dpm bug report threads end when the opener says he's using dpm,
with developers suddenly ceasing to reply. This sounds a lot like a "WONTFIX"
to me, and I perfectly understand the devs.

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


Re: [PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 12:45:16PM -0500, Alex Deucher wrote:
> On Wed, Nov 8, 2017 at 12:42 PM, Alex Deucher  wrote:

> > I'm not familiar with which are chromium specific (TEST, BUG, FIXUP,
> > FROMLIST I guess?). The info seems useful to have in the bug, but I
> > can respin if it's a big deal.

> s/bug/commit message/

All of those are Chrome specific.  If in doubt look at what other people
are using.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/i915: sync dp link status checks against atomic commmits

2017-11-08 Thread Manasi Navare
On Wed, Nov 08, 2017 at 02:28:23PM +0100, Daniel Vetter wrote:
> On Wed, Nov 08, 2017 at 03:26:15PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 08, 2017 at 02:11:46PM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 08, 2017 at 03:04:58PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Nov 08, 2017 at 01:57:50PM +0100, Daniel Vetter wrote:
> > > > > Two bits:
> > > > > - check actual atomic state, the legacy stuff can only be looked at
> > > > >   from within the atomic_commit_tail function, since it's only
> > > > >   protected by ordering and not by any locks.
> > > > > 
> > > > > - Make sure we don't wreak the work an ongoing nonblocking commit is
> > > > >   doing.
> > > > 
> > > > I still think we need to move the retraining to the hotplug work.
> > > 
> > > Why? One of the patch series Maarten mentioned says there's a deadlock
> > > with dp aux, but it seems to be all just fine when CI retrains.

This retraining here would be not because of the training failing in the commit 
but
when we get a short pulse right so when the link was already up and running?

> > 
> > I guess the deadlock is possible only with MST, maybe. Currently MST
> > has it's own copy of the retraining code without the locks.
> > 
> > At one point I started to rewrite the entire sink irq handling into a
> > much nicer shape, also unifying the approach between MST and SST. IIRC
> > I did still make the mistake of having some kind of higher level MST
> > vs. SST split, but I think the proper solution is to combine the two
> > almost entirely. I think we should even be using the ESI registers
> > with SST for DPCD 1.2+. Currently we use ESI for MST and non-ESI for
> > SST. Sadly I've not found the time to continue that work (same story
> > with the "shutdown displays prior to rebooting to keep Dell MST
> > monitors working" thing).
> 
> Yeah, merging sst and mst more definitely sounds like a good idea. I've
> also been toying with it since forever.
> 
> > > And even if there is a deadlock, it's there already, so not sure why we
> > > need to block this bugfix on a different bugfix. Which seems to be what
> > > you're suggesting here (but it's a bit sparse).
> > 
> > I guess what I'm really saying is that we shouldn't stop here.
> 
> Fully agreed.
> -Daniel
> 
> > 
> > > -Daniel
> > > 
> > > > > v2: We need the crtc lock too, because a plane update might change it
> > > > > without having to acquire the connection_mutex (Maarten). Use
> > > > > Maarten's changes for this locking, while keeping the logic that uses
> > > > > the connection->commit->hw_done signal for syncing with nonblocking
> > > > > commits.
> > > > > 
> > > > > Cc: Manasi Navare 
> > > > > Cc: Maarten Lankhorst 
> > > > > Cc: Ville Syrjälä 
> > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
> > > > > Signed-off-by: Daniel Vetter 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 56 
> > > > > -
> > > > >  1 file changed, 50 insertions(+), 6 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index d27c0145ac91..7cd7ab4fb431 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -4319,6 +4319,8 @@ static void
> > > > >  intel_dp_check_link_status(struct intel_dp *intel_dp)
> > > > >  {
> > > > >   struct intel_encoder *intel_encoder = 
> > > > > &dp_to_dig_port(intel_dp)->base;

I dont think we need intel_encoder, can we remove this?

Manasi

> > > > > + struct drm_connector_state *conn_state =
> > > > > + intel_dp->attached_connector->base.state;
> > > > >   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > > > >   u8 link_status[DP_LINK_STATUS_SIZE];
> > > > >  
> > > > > @@ -4329,10 +4331,15 @@ intel_dp_check_link_status(struct intel_dp 
> > > > > *intel_dp)
> > > > >   return;
> > > > >   }
> > > > >  
> > > > > - if (!intel_encoder->base.crtc)
> > > > > + if (!conn_state->crtc)
> > > > >   return;
> > > > >  
> > > > > - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > > > > + WARN_ON(!drm_modeset_is_locked(&conn_state->crtc->mutex));
> > > > > +
> > > > > + if (!conn_state->crtc->state->active)
> > > > > + return;
> > > > > +
> > > > > + if (!try_wait_for_completion(&conn_state->commit->hw_done))
> > > > >   return;
> > > > >  
> > > > >   /*
> > > > > @@ -4368,7 +4375,6 @@ intel_dp_check_link_status(struct intel_dp 
> > > > > *intel_dp)
> > > > >  static bool
> > > > >  intel_dp_short_pulse(struct intel_dp *intel_dp)
> > > > >  {
> > > > > - struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > > > >   struct intel_encoder *intel_encoder = 
> > > > > &dp_to_dig_port(intel_dp)->base;
> > > > >   u8 sink_irq_vector = 0;
> > > > >   u8 old_sink_count =

Re: [PATCH 1/3] ASoC: AMD: Make the driver name consistent across files

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 12:24:02PM -0500, Alex Deucher wrote:
> From: Akshu Agrawal 
> 
> This fixes the issue of driver not getting auto loaded with
> MODULE_ALIAS.

Please don't resubmit patches that have already been applied, you should
submit patches against current code in the tree you're expecting things
to be applied to.  If any updates are needed to a patch that's already
been applied you should submit incremental patches which make those
updates.  This avoids having to change published git commits which could
cause problems for people working against git.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 12:24:03PM -0500, Alex Deucher wrote:

>   regmap_read(regmap, RT5645_VENDOR_ID2, &val);
>  
> + /*
> +  * Read after 400msec, as it is the interval required between
> +  * read and power On.
> +  */
> + msleep(TIME_TO_POWER_MS);
> + regmap_read(regmap, RT5645_VENDOR_ID2, &val);
> +

This leaves the original read in there so we've both got the early read
(which might upset things potentially) and the delayed read.  Shouldn't
we just be adding a msleep() before the existing read?


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH 1/3] ASoC: AMD: Make the driver name consistent across files

2017-11-08 Thread Deucher, Alexander
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, November 08, 2017 1:09 PM
> To: Alex Deucher
> Cc: amd-...@lists.freedesktop.org; alsa-de...@alsa-project.org; dri-
> de...@lists.freedesktop.org; Mukunda, Vijendar; lgirdw...@gmail.com;
> ti...@suse.de; Agrawal, Akshu; Deucher, Alexander
> Subject: Re: [PATCH 1/3] ASoC: AMD: Make the driver name consistent
> across files
> 
> On Wed, Nov 08, 2017 at 12:24:02PM -0500, Alex Deucher wrote:
> > From: Akshu Agrawal 
> >
> > This fixes the issue of driver not getting auto loaded with
> > MODULE_ALIAS.
> 
> Please don't resubmit patches that have already been applied, you should
> submit patches against current code in the tree you're expecting things
> to be applied to.  If any updates are needed to a patch that's already
> been applied you should submit incremental patches which make those
> updates.  This avoids having to change published git commits which could
> cause problems for people working against git.

This didn't not appear to be in your tree yet and I never got any confirmation 
it being
applied.  Apologies.

Alex

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


Re: drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline

2017-11-08 Thread Eric Anholt
Lothar Waßmann  writes:

> Hi,
>
> drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
> dysfunctional due to:
> |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
> |Author: Eric Anholt 
> |Date:   Fri Jun 2 13:25:14 2017 -0700
> |
> |drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
>
> Also, there is no in-kernel user of this driver, so that it obviously
> doesn't get tested in any way. There is only one dts file (r8a7779-marzen.dts)
> that instantiates this driver, but it has an incomplete OF graph. The missing
> link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or
> r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in
> the kernel source.
>
> Should the driver be removed or moved to staging, until it is properly
> fixed?

I can't see any behavior change about the DT handling in that commit,
and I didn't intend for there to be any.  Could you help me understand
what went wrong?


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
From: Guenter Roeck 

ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!

64-bit divides require special operations to avoid build errors on 32-bit
systems.

fixes: 61add8147942 (ASoC: amd: Report accurate hw_ptr during dma)
Signed-off-by: Guenter Roeck 
Reviewed-on: https://chromium-review.googlesource.com/678919
Reviewed-by: Jason Clinton 
(cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
Reviewed-on: https://chromium-review.googlesource.com/681618
Signed-off-by: Alex Deucher 
---

v2: resend with the Chromium tags removed and the subject updated.

 sound/soc/amd/acp-pcm-dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 13d040a4d26f..ef7e98ad960c 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct 
snd_pcm_substream *substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (bytescount > rtd->renderbytescount)
bytescount = bytescount - rtd->renderbytescount;
-   pos =  bytescount % buffersize;
} else {
if (bytescount > rtd->capturebytescount)
bytescount = bytescount - rtd->capturebytescount;
-   pos = bytescount % buffersize;
}
+   pos = do_div(bytescount, buffersize);
return bytes_to_frames(runtime, pos);
 }
 
-- 
2.13.6

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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 01:18:41PM -0500, Alex Deucher wrote:
> From: Guenter Roeck 
> 
> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
> 
> 64-bit divides require special operations to avoid build errors on 32-bit
> systems.

Like I said in reply to your other mail please don't resubmit already
applied patches.  The current tip of my topic/amd branch appears to be
this very patch, if there's anything needs changing please send an
incremental patch.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Christian König

Am 08.11.2017 um 18:37 schrieb Michel Dänzer:

On 08/11/17 05:41 PM, Christian König wrote:

Am 08.11.2017 um 17:36 schrieb Michel Dänzer:

On 08/11/17 03:59 PM, Christian König wrote:

Instead of having a pointless wrapper or call the underlying ww_mutex
function directly.

Not sure I can agree it's pointless, since it recently took me a while
to realize that unlocking bo->resv is essentially the same as
unreserving the BO.

Ok in this case let's call this confusing. But yeah that
__ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and
ww_mutex_unlock(&bo->resv->lock) are essentially the same thing is
exactly what I want to fix here.

How about always using __ttm_bo_unreserve instead?


I actually want to get rid of __ttm_bo_reserve as well. Cause what is 
easier to understand:


__ttm_bo_reserve(bo, false, false, NULL) vs. 
reservation_object_lock(bo->resv);


__ttm_bo_reserve(bo, false, true, NULL) vs. 
reservation_object_trylock(bo->resv);


__ttm_bo_reserve(bo, true, false, NULL) vs. 
reservation_object_lock_interruptible(bo->resv);



The first piglit run with this series applied hit the BUG_ON in
ttm_bo_add_to_lru, see the attached dmesg excerpt. The machine hung,
couldn't reboot cleanly. Haven't been able to reproduce it in three more
attempts though, so I'm not sure it's caused by this series, but I don't
remember seeing it before.


It's most likely caused by this change, I will take another look tomorrow.


P.S. I just noticed I haven't had CONFIG_PROVE_LOCKING enabled in my
kernels for a while, I'll enable it again. Any other options that should
be enabled for testing?


kmemleak is quite nice to have available as well, but doesn't need to 
run automatically all the time.


Christian.

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


Re: [PATCH 1/3] ASoC: AMD: Make the driver name consistent across files

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 06:12:34PM +, Deucher, Alexander wrote:

> This didn't not appear to be in your tree yet and I never got any 
> confirmation it being
> applied.  Apologies.

Ah, sorry - my bad.  This was one that I tried to apply but which didn't
apply.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Applied "ASoC: amd: Make the driver name consistent across files" to the asoc tree

2017-11-08 Thread Mark Brown
The patch

   ASoC: amd: Make the driver name consistent across files

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From bdd2a858afd55cc11723df9dd2841241a4c49ce5 Mon Sep 17 00:00:00 2001
From: Akshu Agrawal 
Date: Wed, 8 Nov 2017 12:24:02 -0500
Subject: [PATCH] ASoC: amd: Make the driver name consistent across files

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci:00/:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

TEST=boot and check for device in lsmod

[Removed yet more ChromeOS crap from the changelog -- broonie]

Signed-off-by: Akshu Agrawal 
Tested-by: Jason Clinton 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff6c73e..f07fd2e2870a 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e19f281afeaa..13d040a4d26f 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1189,7 +1191,7 @@ static struct platform_driver acp_dma_driver = {
.probe = acp_audio_probe,
.remove = acp_audio_remove,
.driver = {
-   .name = "acp_audio_dma",
+   .name = DRV_NAME,
.pm = &acp_pm_ops,
},
 };
@@ -1200,4 +1202,4 @@ MODULE_AUTHOR("vijendar.muku...@amd.com");
 MODULE_AUTHOR("maruthi.bayyavar...@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.15.0

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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown  wrote:
> On Wed, Nov 08, 2017 at 01:18:41PM -0500, Alex Deucher wrote:
>> From: Guenter Roeck 
>>
>> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
>>
>> 64-bit divides require special operations to avoid build errors on 32-bit
>> systems.
>
> Like I said in reply to your other mail please don't resubmit already
> applied patches.  The current tip of my topic/amd branch appears to be
> this very patch, if there's anything needs changing please send an
> incremental patch.

I'm not seeing this one in your tree either.  This is just a resend of
Guenter's patch from an hour ago with the chromium stuff removed.
Maybe you already applied it in the interim?

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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 01:40:32PM -0500, Alex Deucher wrote:
> On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown  wrote:

> > Like I said in reply to your other mail please don't resubmit already
> > applied patches.  The current tip of my topic/amd branch appears to be
> > this very patch, if there's anything needs changing please send an
> > incremental patch.

> I'm not seeing this one in your tree either.  This is just a resend of
> Guenter's patch from an hour ago with the chromium stuff removed.
> Maybe you already applied it in the interim?

Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
which was applied at 16:07?


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH libdrm 1/6] headers: Sync vc4 header from drm-next.

2017-11-08 Thread Eric Anholt
This updates the header with the contents from drm-next d65d31388a23
("Merge tag 'drm-misc-next-fixes-2017-11-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next")

Signed-off-by: Eric Anholt 
---
 include/drm/vc4_drm.h | 47 ---
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/include/drm/vc4_drm.h b/include/drm/vc4_drm.h
index 6ac4c5c014cb..3415a4b71884 100644
--- a/include/drm/vc4_drm.h
+++ b/include/drm/vc4_drm.h
@@ -21,8 +21,8 @@
  * IN THE SOFTWARE.
  */
 
-#ifndef _UAPI_VC4_DRM_H_
-#define _UAPI_VC4_DRM_H_
+#ifndef _VC4_DRM_H_
+#define _VC4_DRM_H_
 
 #include "drm.h"
 
@@ -40,6 +40,8 @@ extern "C" {
 #define DRM_VC4_GET_PARAM 0x07
 #define DRM_VC4_SET_TILING0x08
 #define DRM_VC4_GET_TILING0x09
+#define DRM_VC4_LABEL_BO  0x0a
+#define DRM_VC4_GEM_MADVISE   0x0b
 
 #define DRM_IOCTL_VC4_SUBMIT_CL   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_SUBMIT_CL, struct drm_vc4_submit_cl)
 #define DRM_IOCTL_VC4_WAIT_SEQNO  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_WAIT_SEQNO, struct drm_vc4_wait_seqno)
@@ -51,6 +53,8 @@ extern "C" {
 #define DRM_IOCTL_VC4_GET_PARAM   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_PARAM, struct drm_vc4_get_param)
 #define DRM_IOCTL_VC4_SET_TILING  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_SET_TILING, struct drm_vc4_set_tiling)
 #define DRM_IOCTL_VC4_GET_TILING  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_TILING, struct drm_vc4_get_tiling)
+#define DRM_IOCTL_VC4_LABEL_BODRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_LABEL_BO, struct drm_vc4_label_bo)
+#define DRM_IOCTL_VC4_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GEM_MADVISE, struct drm_vc4_gem_madvise)
 
 struct drm_vc4_submit_rcl_surface {
__u32 hindex; /* Handle index, or ~0 if not present. */
@@ -153,6 +157,16 @@ struct drm_vc4_submit_cl {
__u32 pad:24;
 
 #define VC4_SUBMIT_CL_USE_CLEAR_COLOR  (1 << 0)
+/* By default, the kernel gets to choose the order that the tiles are
+ * rendered in.  If this is set, then the tiles will be rendered in a
+ * raster order, with the right-to-left vs left-to-right and
+ * top-to-bottom vs bottom-to-top dictated by
+ * VC4_SUBMIT_CL_RCL_ORDER_INCREASING_*.  This allows overlapping
+ * blits to be implemented using the 3D engine.
+ */
+#define VC4_SUBMIT_CL_FIXED_RCL_ORDER  (1 << 1)
+#define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X   (1 << 2)
+#define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y   (1 << 3)
__u32 flags;
 
/* Returned value of the seqno of this render job (for the
@@ -292,6 +306,8 @@ struct drm_vc4_get_hang_state {
 #define DRM_VC4_PARAM_SUPPORTS_BRANCHES3
 #define DRM_VC4_PARAM_SUPPORTS_ETC14
 #define DRM_VC4_PARAM_SUPPORTS_THREADED_FS 5
+#define DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER 6
+#define DRM_VC4_PARAM_SUPPORTS_MADVISE 7
 
 struct drm_vc4_get_param {
__u32 param;
@@ -311,8 +327,33 @@ struct drm_vc4_set_tiling {
__u64 modifier;
 };
 
+/**
+ * struct drm_vc4_label_bo - Attach a name to a BO for debug purposes.
+ */
+struct drm_vc4_label_bo {
+   __u32 handle;
+   __u32 len;
+   __u64 name;
+};
+
+/*
+ * States prefixed with '__' are internal states and cannot be passed to the
+ * DRM_IOCTL_VC4_GEM_MADVISE ioctl.
+ */
+#define VC4_MADV_WILLNEED  0
+#define VC4_MADV_DONTNEED  1
+#define __VC4_MADV_PURGED  2
+#define __VC4_MADV_NOTSUPP 3
+
+struct drm_vc4_gem_madvise {
+   __u32 handle;
+   __u32 madv;
+   __u32 retained;
+   __u32 pad;
+};
+
 #if defined(__cplusplus)
 }
 #endif
 
-#endif /* _UAPI_VC4_DRM_H_ */
+#endif /* _VC4_DRM_H_ */
-- 
2.15.0

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


[PATCH libdrm 6/6] headers: Drop outdated node about a delta in drm_mode.h.

2017-11-08 Thread Eric Anholt
Fixed in 9433b702fc16 ("headers: Sync drm{,_mode}.h with the kernel")

Signed-off-by: Eric Anholt 
---
 include/drm/README | 5 -
 1 file changed, 5 deletions(-)

diff --git a/include/drm/README b/include/drm/README
index 042cfb1786f2..5b518ddf8f03 100644
--- a/include/drm/README
+++ b/include/drm/README
@@ -91,11 +91,6 @@ Most UMS headers:
 Status: ?
 Promote to fixed size ints, which match the current (32bit) ones.
 
-
-drm_mode.h
- - Missing DPI encode/connector pair.
-Status: Trivial.
-
 i915_drm.h
  - Missing PARAMS - HAS_POOLED_EU, MIN_EU_IN_POOL 
CONTEXT_PARAM_NO_ERROR_CAPTURE
 Status: Trivial.
-- 
2.15.0

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


[PATCH libdrm 3/6] headers: Sync up some comment spelling and whitespace fixes from drm-next.

2017-11-08 Thread Eric Anholt
This pulls in pieces of drm-next d65d31388a23
("Merge tag 'drm-misc-next-fixes-2017-11-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next")

Signed-off-by: Eric Anholt 
---
 include/drm/mga_drm.h|  2 +-
 include/drm/qxl_drm.h|  2 +-
 include/drm/savage_drm.h | 10 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index f54e7a2e96a4..7035a664d503 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -111,7 +111,7 @@ extern "C" {
  */
 #define MGA_NR_SAREA_CLIPRECTS 8
 
-/* 2 heaps (1 for card, 1 for agp), each divided into upto 128
+/* 2 heaps (1 for card, 1 for agp), each divided into up to 128
  * regions, subject to a minimum region size of (1<<16) == 64k.
  *
  * Clients may subdivide regions internally, but when sharing between
diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h
index ccd841b173f0..a520123b7720 100644
--- a/include/drm/qxl_drm.h
+++ b/include/drm/qxl_drm.h
@@ -34,7 +34,7 @@ extern "C" {
 /* Please note that modifications to all structs defined here are
  * subject to backwards-compatibility constraints.
  *
- * Do not use pointers, use uint64_t instead for 32 bit / 64 bit user/kernel
+ * Do not use pointers, use __u64 instead for 32 bit / 64 bit user/kernel
  * compatibility Keep fields aligned to their size
  */
 
diff --git a/include/drm/savage_drm.h b/include/drm/savage_drm.h
index 26f387b78b15..1a91234e6751 100644
--- a/include/drm/savage_drm.h
+++ b/include/drm/savage_drm.h
@@ -35,7 +35,7 @@ extern "C" {
 #ifndef __SAVAGE_SAREA_DEFINES__
 #define __SAVAGE_SAREA_DEFINES__
 
-/* 2 heaps (1 for card, 1 for agp), each divided into upto 128
+/* 2 heaps (1 for card, 1 for agp), each divided into up to 128
  * regions, subject to a minimum region size of (1<<16) == 64k.
  *
  * Clients may subdivide regions internally, but when sharing between
@@ -69,10 +69,10 @@ typedef struct _drm_savage_sarea {
 #define DRM_SAVAGE_BCI_EVENT_EMIT  0x02
 #define DRM_SAVAGE_BCI_EVENT_WAIT  0x03
 
-#define DRM_IOCTL_SAVAGE_INIT  DRM_IOW( DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_INIT, drm_savage_init_t)
-#define DRM_IOCTL_SAVAGE_CMDBUFDRM_IOW( DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_CMDBUF, drm_savage_cmdbuf_t)
-#define DRM_IOCTL_SAVAGE_EVENT_EMITDRM_IOWR(DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_EVENT_EMIT, drm_savage_event_emit_t)
-#define DRM_IOCTL_SAVAGE_EVENT_WAITDRM_IOW( DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_EVENT_WAIT, drm_savage_event_wait_t)
+#define DRM_IOCTL_SAVAGE_BCI_INIT  DRM_IOW( DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_INIT, drm_savage_init_t)
+#define DRM_IOCTL_SAVAGE_BCI_CMDBUFDRM_IOW( DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_CMDBUF, drm_savage_cmdbuf_t)
+#define DRM_IOCTL_SAVAGE_BCI_EVENT_EMITDRM_IOWR(DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_EVENT_EMIT, drm_savage_event_emit_t)
+#define DRM_IOCTL_SAVAGE_BCI_EVENT_WAITDRM_IOW( DRM_COMMAND_BASE + 
DRM_SAVAGE_BCI_EVENT_WAIT, drm_savage_event_wait_t)
 
 #define SAVAGE_DMA_PCI 1
 #define SAVAGE_DMA_AGP 3
-- 
2.15.0

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


[PATCH libdrm 2/6] headers: Sync up some header guard changes from drm-next.

2017-11-08 Thread Eric Anholt
This pulls in pieces of drm-next d65d31388a23
("Merge tag 'drm-misc-next-fixes-2017-11-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next")

Signed-off-by: Eric Anholt 
---
 include/drm/README|  4 
 include/drm/mga_drm.h |  8 
 include/drm/nouveau_drm.h | 10 ++
 include/drm/qxl_drm.h |  8 
 include/drm/r128_drm.h| 10 ++
 include/drm/savage_drm.h  | 10 ++
 include/drm/sis_drm.h | 10 ++
 include/drm/tegra_drm.h   | 14 +++---
 include/drm/via_drm.h |  8 
 include/drm/vmwgfx_drm.h  |  9 +
 10 files changed, 84 insertions(+), 7 deletions(-)

diff --git a/include/drm/README b/include/drm/README
index 870b0b5b6a87..47d80929a8f1 100644
--- a/include/drm/README
+++ b/include/drm/README
@@ -86,10 +86,6 @@ Outdated or Broken Headers
 This section contains a list of headers and the respective "issues" they might
 have relative to their kernel equivalent.
 
-Nearly all headers:
- - Missing extern C notation.
-Status: Trivial.
-
 Most UMS headers:
  - Not using fixed size integers - compat ioctls are broken.
 Status: ?
diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index b630e8fad548..f54e7a2e96a4 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -37,6 +37,10 @@
 
 #include "drm.h"
 
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 /* WARNING: If you change any of these defines, make sure to change the
  * defines in the Xserver file (mga_sarea.h)
  */
@@ -416,4 +420,8 @@ typedef struct drm_mga_getparam {
void *value;
 } drm_mga_getparam_t;
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index e418f9f3899f..542a732bf065 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -27,6 +27,12 @@
 
 #define NOUVEAU_DRM_HEADER_PATCHLEVEL 16
 
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 struct drm_nouveau_channel_alloc {
uint32_t fb_ctxdma_handle;
uint32_t tt_ctxdma_handle;
@@ -207,4 +213,8 @@ struct drm_nouveau_sarea {
 #define DRM_NOUVEAU_GEM_CPU_FINI   0x43
 #define DRM_NOUVEAU_GEM_INFO   0x44
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif /* __NOUVEAU_DRM_H__ */
diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h
index 1e331a867b53..ccd841b173f0 100644
--- a/include/drm/qxl_drm.h
+++ b/include/drm/qxl_drm.h
@@ -27,6 +27,10 @@
 #include 
 #include "drm.h"
 
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 /* Please note that modifications to all structs defined here are
  * subject to backwards-compatibility constraints.
  *
@@ -149,4 +153,8 @@ struct drm_qxl_alloc_surf {
DRM_IOWR(DRM_COMMAND_BASE + DRM_QXL_ALLOC_SURF,\
struct drm_qxl_alloc_surf)
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif
diff --git a/include/drm/r128_drm.h b/include/drm/r128_drm.h
index ede78ff9d41f..bf431a02333d 100644
--- a/include/drm/r128_drm.h
+++ b/include/drm/r128_drm.h
@@ -33,6 +33,12 @@
 #ifndef __R128_DRM_H__
 #define __R128_DRM_H__
 
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 /* WARNING: If you change any of these defines, make sure to change the
  * defines in the X server file (r128_sarea.h)
  */
@@ -323,4 +329,8 @@ typedef struct drm_r128_getparam {
void *value;
 } drm_r128_getparam_t;
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif
diff --git a/include/drm/savage_drm.h b/include/drm/savage_drm.h
index f7a75eff007f..26f387b78b15 100644
--- a/include/drm/savage_drm.h
+++ b/include/drm/savage_drm.h
@@ -26,6 +26,12 @@
 #ifndef __SAVAGE_DRM_H__
 #define __SAVAGE_DRM_H__
 
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 #ifndef __SAVAGE_SAREA_DEFINES__
 #define __SAVAGE_SAREA_DEFINES__
 
@@ -207,4 +213,8 @@ union drm_savage_cmd_header {
} clear1;   /* SAVAGE_CMD_CLEAR data */
 };
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif
diff --git a/include/drm/sis_drm.h b/include/drm/sis_drm.h
index 30f7b3827466..8e51bb9a5cac 100644
--- a/include/drm/sis_drm.h
+++ b/include/drm/sis_drm.h
@@ -27,6 +27,12 @@
 #ifndef __SIS_DRM_H__
 #define __SIS_DRM_H__
 
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 /* SiS specific ioctls */
 #define NOT_USED_0_3
 #define DRM_SIS_FB_ALLOC   0x04
@@ -64,4 +70,8 @@ typedef struct {
unsigned int offset, size;
 } drm_sis_fb_t;
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif /* __SIS_DRM_H__ */
diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
index 7c0fe0ed511b..12f9bf848db1 100644
--- a/include/drm/tegra_drm.h
+++ b/include/drm/tegra_drm.h
@@ -20,10 +20,14 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#ifndef _UAPI_TEGRA_DRM_H_
-#define _UAPI_TEGRA_DRM_H_
+#ifndef _TEGRA_DRM_H_
+#define _TEGRA_DRM_H_
 
-#include 
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
 
 #define DRM_TEGRA_GEM_CREATE_TILED (1 << 0)
 #def

[PATCH libdrm 4/6] headers: Sync up mga_drm.h from drm-next.

2017-11-08 Thread Eric Anholt
The kernel started using the struct from drm.h instead of the typedef.

Signed-off-by: Eric Anholt 
---
 include/drm/README| 4 
 include/drm/mga_drm.h | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/include/drm/README b/include/drm/README
index 47d80929a8f1..6e12ca4d81f6 100644
--- a/include/drm/README
+++ b/include/drm/README
@@ -100,10 +100,6 @@ i915_drm.h
  - Missing PARAMS - HAS_POOLED_EU, MIN_EU_IN_POOL 
CONTEXT_PARAM_NO_ERROR_CAPTURE
 Status: Trivial.
 
-mga_drm.h
- - Typo fix, use struct over typedef.
-Status: Trivial.
-
 nouveau_drm.h
  - Missing macros NOUVEAU_GETPARAM*, NOUVEAU_DRM_HEADER_PATCHLEVEL, structs,
 enums, using stdint.h over the __u* types.
diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index 7035a664d503..793001114821 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -252,7 +252,7 @@ typedef struct _drm_mga_sarea {
 #define DRM_MGA_DMA_BOOTSTRAP  0x0c
 
 #define DRM_IOCTL_MGA_INIT DRM_IOW( DRM_COMMAND_BASE + DRM_MGA_INIT, 
drm_mga_init_t)
-#define DRM_IOCTL_MGA_FLUSHDRM_IOW( DRM_COMMAND_BASE + DRM_MGA_FLUSH, 
drm_lock_t)
+#define DRM_IOCTL_MGA_FLUSHDRM_IOW( DRM_COMMAND_BASE + DRM_MGA_FLUSH, 
struct drm_lock)
 #define DRM_IOCTL_MGA_RESETDRM_IO(  DRM_COMMAND_BASE + DRM_MGA_RESET)
 #define DRM_IOCTL_MGA_SWAP DRM_IO(  DRM_COMMAND_BASE + DRM_MGA_SWAP)
 #define DRM_IOCTL_MGA_CLEARDRM_IOW( DRM_COMMAND_BASE + DRM_MGA_CLEAR, 
drm_mga_clear_t)
-- 
2.15.0

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


[PATCH libdrm 0/6] drm-next header syncing

2017-11-08 Thread Eric Anholt
I wanted to update the vc4 header so that I could land some igt
testcases (though I'd much rather just be importing the header into
igt and ditching libdrm).  In the process, I cleaned up some other
header deltas to the kernel so that there's less diff for the next
person to look at.

I skipped the actual ABI changes for the other drivers, though.

Eric Anholt (6):
  headers: Sync vc4 header from drm-next.
  headers: Sync up some header guard changes from drm-next.
  headers: Sync up some comment spelling and whitespace fixes from
drm-next.
  headers: Sync up mga_drm.h from drm-next.
  headers: Sync up kernel changes to use kernel types instead of
stdint.h.
  headers: Drop outdated node about a delta in drm_mode.h.

 include/drm/README|  22 +---
 include/drm/mga_drm.h |  12 -
 include/drm/nouveau_drm.h |  94 +++---
 include/drm/qxl_drm.h |  82 +++--
 include/drm/r128_drm.h|  10 
 include/drm/radeon_drm.h  | 128 +++---
 include/drm/savage_drm.h  |  20 ++--
 include/drm/sis_drm.h |  10 
 include/drm/tegra_drm.h   |  14 +++--
 include/drm/vc4_drm.h |  47 +++--
 include/drm/via_drm.h |   8 +++
 include/drm/vmwgfx_drm.h  |   9 
 12 files changed, 280 insertions(+), 176 deletions(-)

-- 
2.15.0

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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 2:30 PM, Guenter Roeck  wrote:
> On Wed, Nov 8, 2017 at 11:18 AM, Deucher, Alexander
>  wrote:
>>
>> > -Original Message-
>> > From: Mark Brown [mailto:broo...@kernel.org]
>> > Sent: Wednesday, November 08, 2017 1:48 PM
>> > To: Alex Deucher
>> > Cc: amd-gfx list; alsa-de...@alsa-project.org; Maling list - DRI
>> > developers;
>> > Mukunda, Vijendar; Liam Girdwood; Takashi Iwai; Guenter Roeck; Deucher,
>> > Alexander
>> > Subject: Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma
>> >
>> > On Wed, Nov 08, 2017 at 01:40:32PM -0500, Alex Deucher wrote:
>> > > On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown 
>> > wrote:
>> >
>> > > > Like I said in reply to your other mail please don't resubmit
>> > > > already
>> > > > applied patches.  The current tip of my topic/amd branch appears to
>> > > > be
>> > > > this very patch, if there's anything needs changing please send an
>> > > > incremental patch.
>> >
>> > > I'm not seeing this one in your tree either.  This is just a resend of
>> > > Guenter's patch from an hour ago with the chromium stuff removed.
>> > > Maybe you already applied it in the interim?
>> >
>> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
>> > which was applied at 16:07?
>>
>> Yes, this is a fix for that patch.  It fixes a 64 bit division that wasn't
>> properly handled.
>>
>
> In that case, the subject should reflect the problem fixed, the description
> should describe the problem, and there should be a Fixes: tag pointing to
> the problematic patch.

I updated the patch subject and added a fixes tag when I resent it
after removing the chrome tags.  The subject could have been bit
better, but I wasn't sure how far to take it since it wasn't my patch
originally.

Alex

>
> Sorry, I was not aware that the problematic patch is already pending
> upstream, or I would have submitted a proper patch upstream myself.
>
> Guenter
>
>>
>> Alex
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH libdrm 5/6] headers: Sync up kernel changes to use kernel types instead of stdint.h.

2017-11-08 Thread Eric Anholt
This pulls in pieces of drm-next d65d31388a23 ("Merge tag
'drm-misc-next-fixes-2017-11-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next")

Signed-off-by: Eric Anholt 
---
 include/drm/README|   9 +---
 include/drm/nouveau_drm.h |  84 +++---
 include/drm/qxl_drm.h |  72 +-
 include/drm/radeon_drm.h  | 128 +++---
 4 files changed, 144 insertions(+), 149 deletions(-)

diff --git a/include/drm/README b/include/drm/README
index 6e12ca4d81f6..042cfb1786f2 100644
--- a/include/drm/README
+++ b/include/drm/README
@@ -102,19 +102,14 @@ Status: Trivial.
 
 nouveau_drm.h
  - Missing macros NOUVEAU_GETPARAM*, NOUVEAU_DRM_HEADER_PATCHLEVEL, structs,
-enums, using stdint.h over the __u* types.
+enums
 Status: ?
 
-qxl_drm.h
- - Using the stdint.h uint*_t over the respective __u* ones
-Status: Trivial.
-
 r128_drm.h
  - Broken compat ioctls.
 
 radeon_drm.h
- - Missing RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_*, broken UMS ioctls,
-using stdint types.
+ - Missing RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_*, broken UMS ioctls
  - Both kernel and libdrm: missing padding -
 drm_radeon_gem_{create,{g,s}et_tiling,set_domain} others ?
 Status: ?
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index 542a732bf065..cb077821c43f 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -111,34 +111,34 @@ struct drm_nouveau_setparam {
 #define NOUVEAU_GEM_TILE_NONCONTIG   0x0008
 
 struct drm_nouveau_gem_info {
-   uint32_t handle;
-   uint32_t domain;
-   uint64_t size;
-   uint64_t offset;
-   uint64_t map_handle;
-   uint32_t tile_mode;
-   uint32_t tile_flags;
+   __u32 handle;
+   __u32 domain;
+   __u64 size;
+   __u64 offset;
+   __u64 map_handle;
+   __u32 tile_mode;
+   __u32 tile_flags;
 };
 
 struct drm_nouveau_gem_new {
struct drm_nouveau_gem_info info;
-   uint32_t channel_hint;
-   uint32_t align;
+   __u32 channel_hint;
+   __u32 align;
 };
 
 #define NOUVEAU_GEM_MAX_BUFFERS 1024
 struct drm_nouveau_gem_pushbuf_bo_presumed {
-   uint32_t valid;
-   uint32_t domain;
-   uint64_t offset;
+   __u32 valid;
+   __u32 domain;
+   __u64 offset;
 };
 
 struct drm_nouveau_gem_pushbuf_bo {
-   uint64_t user_priv;
-   uint32_t handle;
-   uint32_t read_domains;
-   uint32_t write_domains;
-   uint32_t valid_domains;
+   __u64 user_priv;
+   __u32 handle;
+   __u32 read_domains;
+   __u32 write_domains;
+   __u32 valid_domains;
struct drm_nouveau_gem_pushbuf_bo_presumed presumed;
 };
 
@@ -147,47 +147,47 @@ struct drm_nouveau_gem_pushbuf_bo {
 #define NOUVEAU_GEM_RELOC_OR   (1 << 2)
 #define NOUVEAU_GEM_MAX_RELOCS 1024
 struct drm_nouveau_gem_pushbuf_reloc {
-   uint32_t reloc_bo_index;
-   uint32_t reloc_bo_offset;
-   uint32_t bo_index;
-   uint32_t flags;
-   uint32_t data;
-   uint32_t vor;
-   uint32_t tor;
+   __u32 reloc_bo_index;
+   __u32 reloc_bo_offset;
+   __u32 bo_index;
+   __u32 flags;
+   __u32 data;
+   __u32 vor;
+   __u32 tor;
 };
 
 #define NOUVEAU_GEM_MAX_PUSH 512
 struct drm_nouveau_gem_pushbuf_push {
-   uint32_t bo_index;
-   uint32_t pad;
-   uint64_t offset;
-   uint64_t length;
+   __u32 bo_index;
+   __u32 pad;
+   __u64 offset;
+   __u64 length;
 };
 
 struct drm_nouveau_gem_pushbuf {
-   uint32_t channel;
-   uint32_t nr_buffers;
-   uint64_t buffers;
-   uint32_t nr_relocs;
-   uint32_t nr_push;
-   uint64_t relocs;
-   uint64_t push;
-   uint32_t suffix0;
-   uint32_t suffix1;
-   uint64_t vram_available;
-   uint64_t gart_available;
+   __u32 channel;
+   __u32 nr_buffers;
+   __u64 buffers;
+   __u32 nr_relocs;
+   __u32 nr_push;
+   __u64 relocs;
+   __u64 push;
+   __u32 suffix0;
+   __u32 suffix1;
+   __u64 vram_available;
+   __u64 gart_available;
 };
 
 #define NOUVEAU_GEM_CPU_PREP_NOWAIT  0x0001
 #define NOUVEAU_GEM_CPU_PREP_NOBLOCK 0x0002
 #define NOUVEAU_GEM_CPU_PREP_WRITE   0x0004
 struct drm_nouveau_gem_cpu_prep {
-   uint32_t handle;
-   uint32_t flags;
+   __u32 handle;
+   __u32 flags;
 };
 
 struct drm_nouveau_gem_cpu_fini {
-   uint32_t handle;
+   __u32 handle;
 };
 
 enum nouveau_bus_type {
diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h
index a520123b7720..38a0dbdfdcbf 100644
--- a/include/drm/qxl_drm.h
+++ b/include/drm/qxl_drm.h
@@ -52,14 +52,14 @@ extern "C" {
 #define DRM_QXL_ALLOC_SURF  0x06
 
 struct drm_qxl_alloc {
-   uint32_t size;
-   uint32_t handle; /* 0 is an invalid handle */
+   __u32 size;
+   __u32 handle; /* 0 is an invalid 

Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 11:13:50AM -0800, Guenter Roeck wrote:
> On Wed, Nov 8, 2017 at 10:47 AM, Mark Brown  wrote:

> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
> > which was applied at 16:07?

> I suspect we may be getting hit by chromeos-isms again. In Chrome OS, we
> don't use Fixes: tags but "FIXUP: " in the subject
> (not that I like it, but it is what it is).

So it probably is the same patch that was just resent with a slightly
modified subject line?  That's what it looked like initially.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 103625] Sporadic GPU HANG issue while Java is rendering via OpenGL

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103625

Chris Wilson  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #6 from Chris Wilson  ---
commit 2c550183476dfa25641309ae9a28d30feed14379 (tag:
drm-intel-next-fixes-2014-
12-17)
Author: Chris Wilson 
Date:   Tue Dec 16 10:02:27 2014 +

drm/i915: Disable PSMI sleep messages on all rings around context switches

*** This bug has been marked as a duplicate of bug 80660 ***

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


[Bug 101382] [r300] Electronic super joy crash on startup(regression)

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101382

--- Comment #7 from cosiek...@o2.pl ---
17.2.4-1 crash

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


[Bug 101382] [r300] Electronic super joy crash on startup(regression)

2017-11-08 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101382

cosiek...@o2.pl changed:

   What|Removed |Added

   Severity|normal  |major
Version|17.1|17.2
   Priority|medium  |high

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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 2:49 PM, Mark Brown  wrote:
> On Wed, Nov 08, 2017 at 11:13:50AM -0800, Guenter Roeck wrote:
>> On Wed, Nov 8, 2017 at 10:47 AM, Mark Brown  wrote:
>
>> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
>> > which was applied at 16:07?
>
>> I suspect we may be getting hit by chromeos-isms again. In Chrome OS, we
>> don't use Fixes: tags but "FIXUP: " in the subject
>> (not that I like it, but it is what it is).
>
> So it probably is the same patch that was just resent with a slightly
> modified subject line?  That's what it looked like initially.

The original patch which was applied to your tree already:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-next&id=61add8147942d23519b91f0edc30980d7c14482c
That patch as a 64 bit divide in it which was fixed by this patch from Guenter:
https://lists.freedesktop.org/archives/dri-devel/2017-November/157063.html
which contained a bunch of Chrome tags.  I removed the tags and
updated the subject and added a fixes line and resent it as this patch
(subject of this thread):
https://lists.freedesktop.org/archives/dri-devel/2017-November/157076.html
Please apply.  Sorry for the confusion.

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


Re: [PATCH 1/2] drm/atomic-helper: always track connector commits, too

2017-11-08 Thread Manasi Navare
On Wed, Nov 08, 2017 at 05:21:04PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 08, 2017 at 11:54:49AM +0100, Daniel Vetter wrote:
> > It's useful for syncing async connector work like link retraining.
> > 
> > Cc: Manasi Navare 
> > Cc: Maarten Lankhorst 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 71d712f1b56a..ea781d55f2c1 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1791,7 +1791,8 @@ int drm_atomic_helper_setup_commit(struct 
> > drm_atomic_state *state,
> > if (new_conn_state->crtc)
> > continue;
> 
> This guy says we will never have new_conn_state->crtc below.
> 
> >  
> > -   commit = crtc_or_fake_commit(state, old_conn_state->crtc);
> > +   /* Always track connectors explicitly for e.g. link retraining. 
> > */
> > +   commit = crtc_or_fake_commit(state, new_conn_state->crtc ?: 
> > old_conn_state->crtc);

Yes exactly, I had the same thought. Control will never reach here if 
new_conn_state->crtc is true.
If we want to track it explicitly for link retraining pending modeset retry 
work then shouldnt we
remove the remove the if (new_conn_state->crtc) continue part?

Manasi

> > if (!commit)
> > return -ENOMEM;
> >  
> > @@ -1805,10 +1806,7 @@ int drm_atomic_helper_setup_commit(struct 
> > drm_atomic_state *state,
> > 
> > !try_wait_for_completion(&old_plane_state->commit->flip_done))
> > return -EBUSY;
> >  
> > -   /*
> > -* Unlike connectors, always track planes explicitly for
> > -* async pageflip support.
> > -*/
> > +   /* Always track planes explicitly for async pageflip support. */
> > commit = crtc_or_fake_commit(state, new_plane_state->crtc ?: 
> > old_plane_state->crtc);
> > if (!commit)
> > return -ENOMEM;
> > -- 
> > 2.15.0
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

2017-11-08 Thread Eric Anholt
Ville Syrjala  writes:

> From: Ville Syrjälä 
>
> Apparently some sinks look at the YQ bits even when receiving RGB,
> and they get somehow confused when they see a non-zero YQ value.
> So we can't just blindly follow CEA-861-F and set YQ to match the
> RGB range.
>
> Unfortunately there is no good way to tell whether the sink
> designer claims to have read CEA-861-F. The CEA extension block
> revision number has generally been stuck at 3 since forever,
> and even a very recently manufactured sink might be based on
> an old design so the manufacturing date doesn't seem like
> something we can use. In lieu of better information let's
> follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
>
> The alternative would of course be to always set YQ=0. And if
> we ever encounter a HDMI 2.0+ sink with this bug that's what
> we'll probably have to do.

Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
source?

That said, as far as vc4, this patch is

Acked-by: Eric Anholt 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >