Re: [PATCH v2 2/5] drm/vkms: map/unmap buffers in [prepare/cleanup]_fb hooks

[Sean Paul]

On Sat, Jul 14, 2018 at 03:20:21PM +0300, Haneen Mohammed wrote:
> This patch map/unmap GEM backing memory to kernel address space
> in prepare/cleanup_fb respectively and cache the virtual address
> for later use.
> 
> Signed-off-by: Haneen Mohammed 
> ---
> Changes in v2:
> - use vkms_gem_vunmap
> 
>  drivers/gpu/drm/vkms/vkms_plane.c | 36 ++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 9f75b1e2c1c4..877483984897 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -7,8 +7,9 @@
>   */
>  
>  #include "vkms_drv.h"
> -#include 

nit: This seems unrelated to the patch

>  #include 
> +#include 
> +#include 
>  
>  static const struct drm_plane_funcs vkms_plane_funcs = {
>   .update_plane   = drm_atomic_helper_update_plane,
> @@ -24,8 +25,41 @@ static void vkms_primary_plane_update(struct drm_plane 
> *plane,
>  {
>  }
>  
> +static int vkms_prepare_fb(struct drm_plane *plane,
> +struct drm_plane_state *state)
> +{
> + struct drm_gem_object *gem_obj;
> + struct vkms_gem_object *vkms_obj;
> +
> + if (!state->fb)
> + return 0;
> +
> + gem_obj = drm_gem_fb_get_obj(state->fb, 0);
> + vkms_obj = drm_gem_to_vkms_gem(gem_obj);
> + vkms_obj->vaddr = vkms_gem_vmap(gem_obj);
> +
> + if (!vkms_obj->vaddr)

- vkms_gem_vmap() returns ERR_PTR(), not NULL. So IS_ERR_OR_NULL would be
  more appropriate
- You shouldn't be assigning the return of vkms_gem_vmap() to vkms_obj->vaddr
  since vkms_gem_vmap() already does this internally (with proper locks and
  checks)

So you should probably change vkms_gem_vmap() to return int and accept a
vkms_obj upon which it'll populate vaddr for you.

Sean

> + DRM_ERROR("vmap failed\n");
> +
> + return drm_gem_fb_prepare_fb(plane, state);
> +}
> +
> +static void vkms_cleanup_fb(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct drm_gem_object *gem_obj;
> +
> + if (!old_state->fb)
> + return;
> +
> + gem_obj = drm_gem_fb_get_obj(old_state->fb, 0);
> + vkms_gem_vunmap(gem_obj);
> +}
> +
>  static const struct drm_plane_helper_funcs vkms_primary_helper_funcs = {
>   .atomic_update  = vkms_primary_plane_update,
> + .prepare_fb = vkms_prepare_fb,
> + .cleanup_fb = vkms_cleanup_fb,
>  };
>  
>  struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev)
> -- 
> 2.17.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 10/11] media: vsp1: Support Interlaced display pipelines

[Kieran Bingham]

Hi Laurent,

Some questions here too :)

On 24/05/18 13:51, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:
>> Calculate the top and bottom fields for the interlaced frames and
>> utilise the extended display list command feature to implement the
>> auto-field operations. This allows the DU to update the VSP2 registers
>> dynamically based upon the currently processing field.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>> v3:
>>  - Pass DL through partition calls to allow autocmd's to be retrieved
>>  - Document interlaced field in struct vsp1_du_atomic_config
>>
>> v2:
>>  - fix erroneous BIT value which enabled interlaced
>>  - fix field handling at frame_end interrupt
>> ---
>>  drivers/media/platform/vsp1/vsp1_dl.c   | 10 -
>>  drivers/media/platform/vsp1/vsp1_drm.c  | 11 -
>>  drivers/media/platform/vsp1/vsp1_regs.h |  1 +-
>>  drivers/media/platform/vsp1/vsp1_rpf.c  | 71 --
>>  drivers/media/platform/vsp1/vsp1_rwpf.h |  1 +-
>>  include/media/vsp1.h|  2 +-
>>  6 files changed, 93 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index d33ae5f125bd..bbe9f3006f71
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
>> @@ -906,6 +906,8 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool
>> internal) */
>>  unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
>>  {
>> +struct vsp1_device *vsp1 = dlm->vsp1;
>> +u32 status = vsp1_read(vsp1, VI6_STATUS);
>>  unsigned int flags = 0;
>>
>>  spin_lock(>lock);
>> @@ -931,6 +933,14 @@ unsigned int vsp1_dlm_irq_frame_end(struct
>> vsp1_dl_manager *dlm) goto done;
>>
>>  /*
>> + * Progressive streams report only TOP fields. If we have a BOTTOM
>> + * field, we are interlaced, and expect the frame to complete on the
>> + * next frame end interrupt.
>> + */
>> +if (status & VI6_STATUS_FLD_STD(dlm->index))
>> +goto done;
>> +
>> +/*
>>   * The device starts processing the queued display list right after the
>>   * frame end interrupt. The display list thus becomes active.
>>   */
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
>> b/drivers/media/platform/vsp1/vsp1_drm.c index 2c3db8b8adce..cc29c9d96bb7
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
>> @@ -811,6 +811,17 @@ int vsp1_du_atomic_update(struct device *dev, unsigned
>> int pipe_index, return -EINVAL;
>>  }
>>
>> +if (!(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) && cfg->interlaced) {
> 
> Nitpicking, writing the condition as
> 
>   if (cfg->interlaced && !(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)))

Done.

> 
> would match the comment better. You can also drop the parentheses around the 
> vsp1_feature() call.
> 
>> +/*
>> + * Interlaced support requires extended display lists to
>> + * provide the auto-fld feature with the DU.
>> + */
>> +dev_dbg(vsp1->dev, "Interlaced unsupported on this output\n");
> 
> Could we catch this in the DU driver to fail atomic test ?

Ugh - I thought moving the configuration to vsp1_du_setup_lif() would
give us this, but that return value is not checked in the DU.

How can we interogate the VSP1 to ask it if it supports interlaced from
rcar_du_vsp_plane_atomic_check()?


Some dummy call to vsp1_du_setup_lif() to check the return value ? Or
should we implement a hook to call through to perform checks in the VSP1
DRM API?




> 
>> +return -EINVAL;
>> +}
>> +
>> +rpf->interlaced = cfg->interlaced;
>> +
>>  rpf->fmtinfo = fmtinfo;
>>  rpf->format.num_planes = fmtinfo->planes;
>>  rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
>> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h
>> b/drivers/media/platform/vsp1/vsp1_regs.h index d054767570c1..a2ac65cc5155
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
>> @@ -28,6 +28,7 @@
>>  #define VI6_SRESET_SRTS(n)  (1 << (n))
>>
>>  #define VI6_STATUS  0x0038
>> +#define VI6_STATUS_FLD_STD(n)   (1 << ((n) + 28))
>>  #define VI6_STATUS_SYS_ACT(n)   (1 << ((n) + 8))
>>
>>  #define VI6_WPF_IRQ_ENB(n)  (0x0048 + (n) * 12)
>> diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c
>> b/drivers/media/platform/vsp1/vsp1_rpf.c index 8fae7c485642..511b2e127820
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_rpf.c
>> +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
>> @@ -20,6 +20,20 @@
>>  #define RPF_MAX_WIDTH   8190
>>  #define RPF_MAX_HEIGHT  8190
>>
>> +/* Pre extended display list command data structure */
>> +struct vsp1_extcmd_auto_fld_body {
>> +u32 top_y0;
>> 

[PATCH] drm/connector: Fix typo in drm_connector_list_iter_next()

[Lyude Paul]

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_connector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9b9ba5d5ec0c..2e0312e4645a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -577,7 +577,7 @@ __drm_connector_put_safe(struct drm_connector *conn)
 
 /**
  * drm_connector_list_iter_next - return next connector
- * @iter: connectr_list iterator
+ * @iter: connector_list iterator
  *
  * Returns the next connector for @iter, or NULL when the list walk has
  * completed.
-- 
2.17.1

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

Re: [PATCH] drm/connector: Fix typo in drm_connector_list_iter_next()

[Rodrigo Vivi]

On Mon, Jul 16, 2018 at 12:16:45PM -0400, Lyude Paul wrote:
> Signed-off-by: Lyude Paul 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/drm_connector.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 9b9ba5d5ec0c..2e0312e4645a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -577,7 +577,7 @@ __drm_connector_put_safe(struct drm_connector *conn)
>  
>  /**
>   * drm_connector_list_iter_next - return next connector
> - * @iter: connectr_list iterator
> + * @iter: connector_list iterator
>   *
>   * Returns the next connector for @iter, or NULL when the list walk has
>   * completed.
> -- 
> 2.17.1
> 
> ___
> 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

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

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

Does this patch help?  Just a hack for testing to see if the scratch registers
are stale or corrupt.

-- 
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 v2] drm/connector: Fix typo in drm_connector_list_iter_next()

[Lyude Paul]

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
---
Will push in just a moment, updating patchwork

 drivers/gpu/drm/drm_connector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9b9ba5d5ec0c..2e0312e4645a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -577,7 +577,7 @@ __drm_connector_put_safe(struct drm_connector *conn)
 
 /**
  * drm_connector_list_iter_next - return next connector
- * @iter: connectr_list iterator
+ * @iter: connector_list iterator
  *
  * Returns the next connector for @iter, or NULL when the list walk has
  * completed.
-- 
2.17.1

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

Re: [PATCH v2 4/5] drm/vkms: subclass CRTC state

[Sean Paul]

On Sat, Jul 14, 2018 at 03:22:36PM +0300, Haneen Mohammed wrote:
> Subclass CRTC state struct to enable storing driver's private
> state. This patch only adds the base drm_crtc_state struct and
> the atomic functions that handle it.
> 
> Signed-off-by: Haneen Mohammed 
> Reviewed-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 53 ++--
>  drivers/gpu/drm/vkms/vkms_drv.h  | 11 +++
>  2 files changed, 61 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 875fca662ac0..26babb85ca77 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -64,13 +64,60 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, 
> unsigned int pipe,
>   return true;
>  }
>  
> +static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
> +{
> + struct vkms_crtc_state *vkms_state = NULL;
> +
> + if (crtc->state) {
> + vkms_state = to_vkms_crtc_state(crtc->state);
> + __drm_atomic_helper_crtc_destroy_state(crtc->state);
> + kfree(vkms_state);
> + crtc->state = NULL;
> + }
> +
> + vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> + if (!vkms_state)
> + return;
> +
> + crtc->state = _state->base;
> + crtc->state->crtc = crtc;
> +}
> +
> +static struct drm_crtc_state *
> +vkms_atomic_crtc_duplicate_state(struct drm_crtc *crtc)
> +{
> + struct vkms_crtc_state *vkms_state;
> +
> + if (WARN_ON(!crtc->state))
> + return NULL;
> +
> + vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> + if (!vkms_state)
> + return NULL;
> +
> + __drm_atomic_helper_crtc_duplicate_state(crtc, _state->base);
> +
> + return _state->base;
> +}
> +
> +static void vkms_atomic_crtc_destroy_state(struct drm_crtc *crtc,
> +struct drm_crtc_state *state)
> +{
> + struct vkms_crtc_state *vkms_state;
> +
> + vkms_state = to_vkms_crtc_state(state);
> +
> + __drm_atomic_helper_crtc_destroy_state(state);
> + kfree(vkms_state);
> +}
> +
>  static const struct drm_crtc_funcs vkms_crtc_funcs = {
>   .set_config = drm_atomic_helper_set_config,
>   .destroy= drm_crtc_cleanup,
>   .page_flip  = drm_atomic_helper_page_flip,
> - .reset  = drm_atomic_helper_crtc_reset,
> - .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> - .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
> + .reset  = vkms_atomic_crtc_reset,
> + .atomic_duplicate_state = vkms_atomic_crtc_duplicate_state,
> + .atomic_destroy_state   = vkms_atomic_crtc_destroy_state,
>   .enable_vblank  = vkms_enable_vblank,
>   .disable_vblank = vkms_disable_vblank,
>  };
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 855e1ea8bc35..bf811d0ec349 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -20,6 +20,14 @@ static const u32 vkms_formats[] = {
>   DRM_FORMAT_XRGB,
>  };
>  
> +/**
> + * vkms_crtc_state - Driver specific CRTC state
> + * @base: base CRTC state
> + */
> +struct vkms_crtc_state {
> + struct drm_crtc_state base;
> +};
> +
>  struct vkms_output {
>   struct drm_crtc crtc;
>   struct drm_encoder encoder;
> @@ -52,6 +60,9 @@ struct vkms_gem_object {
>  #define drm_gem_to_vkms_gem(target)\
>   container_of(target, struct vkms_gem_object, gem)
>  
> +#define to_vkms_crtc_state(target)\
> + container_of(target, struct vkms_crtc_state, base)
> +
>  /* CRTC */
>  int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
>  struct drm_plane *primary, struct drm_plane *cursor);
> -- 
> 2.17.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [Freedreno] [PATCH 02/13] drm: drm_printer: Add printer for devcoredump

[Berg, Johannes]

> > Hm, why not add seq_file support to dev_coredump? Neither git blame
> > nor google sched any light on why seq_file wasn't picked over the
> > custom read interface ...
> >
> > Adding Johannes and Greg about this.
> 
> Main reason was that this is used for devcoredump which has its own similar
> but not quite seq_file compatible callback. If there is synergy to be had 
> there
> that would be great because reinventing the wheel isn't fun.

Adding or changing it to seq_file is fine with me, I don't think we really need 
the devm_coredump() much these days since we have the vmalloc one.

(apologies for the footer and all - I'm on vacation and in a hurry)

johannes
-- 

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

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

Re: [PATCH v2 5/5] drm/vkms: Implement CRC debugfs API

[Sean Paul]

On Sat, Jul 14, 2018 at 03:23:32PM +0300, Haneen Mohammed wrote:
> Implement the set_crc_source() callback.
> Compute CRC using crc32 on the visible part of the framebuffer.
> Use ordered workqueue to compute and add CRC at the end of a vblank.
> 
> Use appropriate synchronization methods since the crc computation must
> be atomic wrt the generated vblank event for a given atomic update,
> 
> Signed-off-by: Haneen Mohammed 

Hey Haneen,
Thanks for revising this patch set. Things are looking good across the series,
just a few more comments :-)

> ---
> Changes in v2:
> - Include this patch in this patchset.
> 
>  drivers/gpu/drm/vkms/Makefile |  2 +-
>  drivers/gpu/drm/vkms/vkms_crtc.c  | 60 ++-
>  drivers/gpu/drm/vkms/vkms_drv.c   |  1 +
>  drivers/gpu/drm/vkms/vkms_drv.h   | 21 +++
>  drivers/gpu/drm/vkms/vkms_plane.c | 10 ++
>  5 files changed, 85 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 986297da51bf..37966914f70b 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -1,3 +1,3 @@
> -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
> +vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o 
> vkms_crc.o
>  
>  obj-$(CONFIG_DRM_VKMS) += vkms.o
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 26babb85ca77..f3a674db33b8 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -10,18 +10,36 @@
>  #include 
>  #include 
>  
> -static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> +static void _vblank_handle(struct vkms_output *output)
>  {
> - struct vkms_output *output = container_of(timer, struct vkms_output,
> -   vblank_hrtimer);
>   struct drm_crtc *crtc = >crtc;
> - int ret_overrun;
> + struct vkms_crtc_state *state = to_vkms_crtc_state(crtc->state);
>   bool ret;
>  
> + int crc_enabled = 0;
> +
> + spin_lock(>lock);
> + crc_enabled = output->crc_enabled;

Aside from the implicit bool -> int cast, I don't think you need this local var,
just use output->crc_enabled directly below.

>   ret = drm_crtc_handle_vblank(crtc);
>   if (!ret)
>   DRM_ERROR("vkms failure on handling vblank");

This would be more useful with the error code printed.

>  
> + if (state && crc_enabled) {
> + state->n_frame = drm_crtc_accurate_vblank_count(crtc);
> + queue_work(output->crc_workq, >crc_work);
> + }
> +
> + spin_unlock(>lock);
> +}
> +
> +static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> +{
> + struct vkms_output *output = container_of(timer, struct vkms_output,
> +   vblank_hrtimer);
> + int ret_overrun;
> +
> + _vblank_handle(output);
> +
>   ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> output->period_ns);
>  
> @@ -97,6 +115,8 @@ vkms_atomic_crtc_duplicate_state(struct drm_crtc *crtc)
>  
>   __drm_atomic_helper_crtc_duplicate_state(crtc, _state->base);
>  
> + INIT_WORK(_state->crc_work, vkms_crc_work_handle);
> +
>   return _state->base;
>  }
>  
> @@ -104,11 +124,18 @@ static void vkms_atomic_crtc_destroy_state(struct 
> drm_crtc *crtc,
>  struct drm_crtc_state *state)
>  {
>   struct vkms_crtc_state *vkms_state;
> + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
>  
>   vkms_state = to_vkms_crtc_state(state);
>  
>   __drm_atomic_helper_crtc_destroy_state(state);
> - kfree(vkms_state);
> +
> + if (vkms_state) {
> + flush_workqueue(vkms_out->crc_workq);

I'm a little worried about this bit. Since the workqueue is per-output, is it
possible you'll be waiting for more frames to complete than you need to be?

> + drm_framebuffer_put(_state->data.fb);
> + memset(_state->data, 0, sizeof(struct vkms_crc_data));
> + kfree(vkms_state);
> + }
>  }
>  
>  static const struct drm_crtc_funcs vkms_crtc_funcs = {
> @@ -120,6 +147,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
>   .atomic_destroy_state   = vkms_atomic_crtc_destroy_state,
>   .enable_vblank  = vkms_enable_vblank,
>   .disable_vblank = vkms_disable_vblank,
> + .set_crc_source = vkms_set_crc_source,
>  };
>  
>  static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
> @@ -134,26 +162,37 @@ static void vkms_crtc_atomic_disable(struct drm_crtc 
> *crtc,
>   drm_crtc_vblank_off(crtc);
>  }
>  
> +static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
> +struct drm_crtc_state *old_crtc_state)
> +{
> + struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
> +
> + 

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

--- Comment #48 from Alex Deucher  ---
(In reply to Thomas Martitz from comment #47)
> So pci_raw_set_power_state() does a pci_read_config_word() and that returns
> a valid word. Yet, the device appears to be not in powerd up state later on.
> How's that possible, and why does it work on Windows?
> 
> Can I inspect Windows behavior in some way to get insight?
> 
> Since Windows works I'm sure there must be a SW fix (or at least a
> workaround) available. Perhaps just wait for a bit?

In HG laptops, the d3cold control is handled by the OS rather than the driver
(e.g., the driver doesn't call into APCI to handle d3cold, the pci core does). 
The driver just has to support the necessary callbacks to the OS to enter/leave
this state when idle.  Each OS interacts slightly differently with ACPI so if
the OEM never validated Linux it's likely there is some slight differences in
the sequencing that is causing a problem.  You might try playing with the ACPI
interfaces directly on Linux.  There are user mode tools to interact with ACPI.
 Blacklist the amdgpu driver and try calling the _PR3 method for the device to
power it down/up and then see if the device comes back properly.

-- 
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 v4 08/11] media: vsp1: Add support for extended display list headers

[Kieran Bingham]

Hi Laurent,

On 24/05/18 12:44, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 3 May 2018 16:36:19 EEST Kieran Bingham wrote:
>> Extended display list headers allow pre and post command lists to be
>> executed by the VSP pipeline. This provides the base support for
>> features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for
>> supporting continuous camera preview pipelines.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>>
>> v2:
>>  - remove __packed attributes
>> ---
>>  drivers/media/platform/vsp1/vsp1.h  |  1 +-
>>  drivers/media/platform/vsp1/vsp1_dl.c   | 83 +-
>>  drivers/media/platform/vsp1/vsp1_dl.h   | 29 -
>>  drivers/media/platform/vsp1/vsp1_drv.c  |  7 +-
>>  drivers/media/platform/vsp1/vsp1_regs.h |  5 +-
>>  5 files changed, 116 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1.h
>> b/drivers/media/platform/vsp1/vsp1.h index f0d21cc8e9ab..56c62122a81a
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1.h
>> +++ b/drivers/media/platform/vsp1/vsp1.h
>> @@ -53,6 +53,7 @@ struct vsp1_uif;
>>  #define VSP1_HAS_HGO(1 << 7)
>>  #define VSP1_HAS_HGT(1 << 8)
>>  #define VSP1_HAS_BRS(1 << 9)
>> +#define VSP1_HAS_EXT_DL (1 << 10)
>>
>>  struct vsp1_device_info {
>>  u32 version;
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index 56514cd51c51..b64d32535edc
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
>> @@ -22,6 +22,9 @@
>>  #define VSP1_DLH_INT_ENABLE (1 << 1)
>>  #define VSP1_DLH_AUTO_START (1 << 0)
>>
>> +#define VSP1_DLH_EXT_PRE_CMD_EXEC   (1 << 9)
>> +#define VSP1_DLH_EXT_POST_CMD_EXEC  (1 << 8)
>> +
>>  struct vsp1_dl_header_list {
>>  u32 num_bytes;
>>  u32 addr;
>> @@ -34,11 +37,34 @@ struct vsp1_dl_header {
>>  u32 flags;
>>  };
>>
>> +struct vsp1_dl_ext_header {
>> +u32 reserved0;  /* alignment padding */
>> +
>> +u16 pre_ext_cmd_qty;
> 
> Should this be called pre_ext_dl_num_cmd to match the datasheet ?

Yes, renamed.

> 
>> +u16 flags;
> 
> Aren't the flags supposed to come before the pre_ext_dl_num_cmd field ?

These are out-of-order to account for the fact that they are 16bit values.

I felt that keeping them described in the struct was cleaner than shifts
and masks - but clearly this stands out, due to the byte-ordering.

Would you prefer I re-write this as 32 bit accesses (or even 64bit),
with shifts? Or is a comment sufficient here ?


If we rewrite to be 32 bit accesses, would you be happy with the
following naming:

u32 reserved0;
u32 pre_ext_dl_num_cmd; /* Also stores command flags. */
u32 pre_ext_dl_plist;
u32 post_ext_dl_num_cmd;
u32 post_ext_dl_plist;

(Technically the flags are for the whole header, not the just the
pre_ext, which is why I wanted it separated)


Actually - now I write that - the 'number of commands' is sort of a flag
or a parameter? so maybe the following is just as appropriate?:

u32 reserved0;
u32 pre_ext_dl_flags;
u32 pre_ext_dl_plist;
u32 post_ext_dl_flags;
u32 post_ext_dl_plist;

Or they could be named 'options', or parameters?

Any comments before I hack that in?

The annoying part is that the 'flags' aren't part of the pre_ext cmds,
they declare whether the pre or post cmd should be executed (or both I
presume, we are yet to see post-cmd usage)


> 
>> +u32 pre_ext_cmd_plist;
> 
> And pre_ext_dl_plist ?
> 
>> +
>> +u32 post_ext_cmd_qty;
>> +u32 post_ext_cmd_plist;
> 
> Similar comments for these variables.

Renamed.


>> +};
>> +
>> +struct vsp1_dl_header_extended {
>> +struct vsp1_dl_header header;
>> +struct vsp1_dl_ext_header ext;
>> +};
>> +
>>  struct vsp1_dl_entry {
>>  u32 addr;
>>  u32 data;
>>  };
>>
>> +struct vsp1_dl_ext_cmd_header {
> 
> Isn't this referred to in the datasheet as a body entry, not a header ? How 
> about naming it vsp1_dl_ext_cmd_entry ? Or just vsp1_dl_ext_cmd (in which 
> case 
> the other structure that goes by the same name would need to be renamed) ?

I think I was getting too creative. The reality is this part is really a
'header' describing the data in the body, but yes - it should be named
to match a "Pre Extended Display List Body"

  s/vsp1_dl_ext_cmd_header/vsp1_pre_ext_dl_body/

This will then leave "struct vsp1_dl_ext_cmd" which represents the
object instance within the VSP1 driver only.


> 
>> +u32 cmd;

This should really have been opcode then too :)

>> +u32 flags;
>> +u32 data;
>> +u32 reserved;
> 
> The datasheet documents this as two 64-bit fields, shouldn't we handle the 
> structure the same way ?


I was trying to separate out the fields for clarity.

In this instance (unlike the 16bit handling above), the byte ordering of
a 64 bit value works in 

Re: [PATCH v4 11/11] drm: rcar-du: Support interlaced video output through vsp1

[Kieran Bingham]

Hi Laurent,


On 24/05/18 12:50, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:
>> Use the newly exposed VSP1 interface to enable interlaced frame support
>> through the VSP1 lif pipelines.
> 
> s/lif/LIF/

Fixed.


>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +
>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 3 +++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index d71d709fe3d9..206532959ec9
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> @@ -289,6 +289,7 @@ static void rcar_du_crtc_set_display_timing(struct
>> rcar_du_crtc *rcrtc) /* Signal polarities */
>>  value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
>>| ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
>> +  | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
> 
> How will this affect Gen2 ?.

The bit is documented identically for Gen2. Potentially / Probably it
'might' reverse the fields... I'm not certain yet. I don't have access
to a Gen2 platform to test.

I'll see if this change can be dropped, but I think it is playing a role
in ensuring that the field detection occurs in VSP1 through the
VI6_STATUS_FLD_STD() field. (see vsp1_dlm_irq_frame_end())


> Could you document what this change does in the 
> commit message ?

This sets the position in the buffer of the ODDF. With this set, the ODD
field is located in the second half (BOTTOM) of the same frame of the
interlace display.

Otherwise, it's in the first half (TOP)

I faced some issues as to the ordering when testing, so I suspect this
might actually be related to that. (re VI6_STATUS_FLD_STD in
vsp1_dlm_irq_frame_end()).

As you mention - this may have a negative effect on the Gen2
implementation - so it needs considering with that.


/me to investigate further.



> 
>>| DSMR_DIPM_DISP | DSMR_CSPM;
>>
>>  rcar_du_crtc_write(rcrtc, DSMR, value);
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index af7822a66dee..c7b37232ee91
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -186,6 +186,9 @@ static void rcar_du_vsp_plane_setup(struct
>> rcar_du_vsp_plane *plane) };
>>  unsigned int i;
>>
>> +cfg.interlaced = !!(plane->plane.state->crtc->mode.flags
>> +& DRM_MODE_FLAG_INTERLACE);
>> +
>>  cfg.src.left = state->state.src.x1 >> 16;
>>  cfg.src.top = state->state.src.y1 >> 16;
>>  cfg.src.width = drm_rect_width(>state.src) >> 16;

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Split audio component to a generic type

[Takashi Iwai]

On Mon, 16 Jul 2018 19:22:17 +0200,
Rodrigo Vivi wrote:
> 
> > --- /dev/null
> > +++ b/include/drm/drm_audio_component.h
> > @@ -0,0 +1,115 @@
> > +/*
> > + * Copyright © 2014 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> 
> I think it is better to start new files with SPDX identifiers

Yeah, it's a more sensible option.  Will rewrite in v2.

> > +
> > +#ifndef _DRM_AUDIO_COMPONENT_H_
> > +#define _DRM_AUDIO_COMPONENT_H_
> > +
> > +/**
> > + * struct drm_audio_component_ops - Ops implemented by DRM driver, called 
> > by hda driver
> > + */
> > +struct drm_audio_component_ops {
> > +   /**
> > +* @owner: i915 module
> 
> drm now?

Right.  Will be fixed in v2, too.


Thanks!

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

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 16, 2018 at 11:25 AM, Takashi Iwai  wrote:
> On Mon, 16 Jul 2018 17:10:43 +0200,
> Harry Wentland wrote:
>>
>>
>>
>> On 2018-07-15 10:36 AM, Alex Deucher wrote:
>> > On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai  wrote:
>> >> On Sat, 14 Jul 2018 14:03:26 +0200,
>> >> jimqu wrote:
>> >>>
>> >>>
>> >>>
>> >>> 在 2018/7/13 23:07, Takashi Iwai 写道:
>>  On Wed, 11 Jul 2018 13:12:01 +0200,
>>  Takashi Iwai wrote:
>> > And the forced runtime PM is still an issue, and this would need the
>> > other notification mechanism than the HD-audio unsolicited event as
>> > AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.
>>  Since we had a nice "hack week" in this week at SUSE, I spent some
>>  time to write some patches for the support of the direct hotplug
>>  notification / ELD query between HD-audio and radeon/amdgpu.  It
>>  re-utilizes the audio component framework for i915 but in a slightly
>>  more flexible way.
>> 
>>  The patches are found in topic/hda-acomp branch of my sound.git tree:
>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>> 
>>  The following commits are relevant:
>> drm/i915: Split audio component to a generic type
>> ALSA: hda/i915: Allow delayed i915 audio component binding
>> ALSA: hda/i915: Associate audio component with devres
>> ALSA: hda: Make audio component support more generic
>> ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
>> ALSA: hda/hdmi: Use single mutex unlock in error paths
>> drm/radeon: Add audio component support
>> drm/amdgpu: Add audio component support
>> 
>>  The branch should be cleanly pullable onto the latest 4.18-rc.
>> 
>>  I couldn't test amdgpu but the test with a radeon driver on an old
>>  laptop seemed working through a very quick test.
>> 
>>  Please give it a try.
>> >>>
>> >>> That is really wonderful work. I will check it on our AMD
>> >>> platform.
>> >>
>> >> Thanks, it'll be great if you can check whether the current code works
>> >> or not.  I'd love to push the stuff for 4.19.  Hopefully I'll start
>> >> submitting the preparation patches in the next week.
>> >>
>> >> Basically this also opens the door of the similar capability for
>> >> nouveau, and I guess it's also trivial enough.
>> >>
>> >>> BTW, For display, AMD has moved to use DC to support new
>> >>> asics. so there also need a patch for amdgpu in DC code.
>> >>
>> >> Could you give a more hint?  I'll try adapt the code if such a change
>> >> is already in upstream tree.
>> >
>> > The new code is in drivers/gpu/drm/amd/display.
>> >
>>
>> In particular, I imagine all you need should be in display/amdgpu_dm, 
>> although there's chance you might have to touch display/dc/dce/dce_audio.c 
>> if you have to do anything with the unsolicited event.
>
> Thanks, I'm currently struggling to read down the whole complex DC
> code tree, and it's a very helpful hint.
>
> How is the audio enable/disable call associated with the pipe index?
> IOW, if I add a hook to call a notifier callback to pass the pipe
> index that is enabled/disabled, how can it be deduced?
>
> Similarly, when DC driver gets the query about the ELD on the given
> pipe, where can I convert it to which object?
>
> DC is quite another beast, so I still haven't figured out the
> structures yet...
>
>
>> I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since 
>> the code in display/dc is shared with other OSes and internal test 
>> frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but 
>> if GPL is fine in amd/amdgpu it's probably fine there as well.
>
> Oh I just didn't know that amdgpu code was with MIT.  Indeed the
> driver module is provided via "GPL and additional rights".
>
> I'm fine to change the license to follow other code bits there.  What
> exactly SPDX tag should be put there?

Preferably:
SPDX-License-Identifier: MIT
or I suppose dual licensing (MIT or GPL 2.0) is ok too.

Alex

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Split audio component to a generic type

[Rodrigo Vivi]

On Mon, Jul 16, 2018 at 03:48:13PM +0200, Takashi Iwai wrote:
> For allowing other drivers to use the DRM audio component, rename the
> i915_audio_component_* with drm_audio_component_*, and split the
> generic part into drm_audio_component.h.  The i915 specific stuff
> remains in struct i915_audio_component, which contains
> drm_audio_component as the base.
> 
> This is a preliminary change for further development, and no
> functional changes by this patch itself, merely code-split and
> renames.

+1 on the idea

> 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/intel_audio.c |  22 +++---
>  include/drm/drm_audio_component.h  | 115 +
>  include/drm/i915_component.h   |  85 ++---
>  include/sound/hda_i915.h   |   6 +-
>  include/sound/hdaudio.h|   6 +-
>  sound/hda/hdac_i915.c  |  40 +-
>  sound/pci/hda/patch_hdmi.c |   8 +-
>  sound/soc/codecs/hdac_hdmi.c   |   2 +-
>  8 files changed, 164 insertions(+), 120 deletions(-)
>  create mode 100644 include/drm/drm_audio_component.h
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 3ea566f99450..7dd5605d94ae 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -639,11 +639,12 @@ void intel_audio_codec_enable(struct intel_encoder 
> *encoder,
>   dev_priv->av_enc_map[pipe] = encoder;
>   mutex_unlock(_priv->av_mutex);
>  
> - if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
> + if (acomp && acomp->base.audio_ops &&
> + acomp->base.audio_ops->pin_eld_notify) {
>   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
>   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
>   pipe = -1;
> - acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> + 
> acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
>(int) port, (int) pipe);
>   }
>  
> @@ -681,11 +682,12 @@ void intel_audio_codec_disable(struct intel_encoder 
> *encoder,
>   dev_priv->av_enc_map[pipe] = NULL;
>   mutex_unlock(_priv->av_mutex);
>  
> - if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
> + if (acomp && acomp->base.audio_ops &&
> + acomp->base.audio_ops->pin_eld_notify) {
>   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
>   if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
>   pipe = -1;
> - acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> + 
> acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
>(int) port, (int) pipe);
>   }
>  
> @@ -880,7 +882,7 @@ static int i915_audio_component_get_eld(struct device 
> *kdev, int port,
>   return ret;
>  }
>  
> -static const struct i915_audio_component_ops i915_audio_component_ops = {
> +static const struct drm_audio_component_ops i915_audio_component_ops = {
>   .owner  = THIS_MODULE,
>   .get_power  = i915_audio_component_get_power,
>   .put_power  = i915_audio_component_put_power,
> @@ -897,12 +899,12 @@ static int i915_audio_component_bind(struct device 
> *i915_kdev,
>   struct drm_i915_private *dev_priv = kdev_to_i915(i915_kdev);
>   int i;
>  
> - if (WARN_ON(acomp->ops || acomp->dev))
> + if (WARN_ON(acomp->base.ops || acomp->base.dev))
>   return -EEXIST;
>  
>   drm_modeset_lock_all(_priv->drm);
> - acomp->ops = _audio_component_ops;
> - acomp->dev = i915_kdev;
> + acomp->base.ops = _audio_component_ops;
> + acomp->base.dev = i915_kdev;
>   BUILD_BUG_ON(MAX_PORTS != I915_MAX_PORTS);
>   for (i = 0; i < ARRAY_SIZE(acomp->aud_sample_rate); i++)
>   acomp->aud_sample_rate[i] = 0;
> @@ -919,8 +921,8 @@ static void i915_audio_component_unbind(struct device 
> *i915_kdev,
>   struct drm_i915_private *dev_priv = kdev_to_i915(i915_kdev);
>  
>   drm_modeset_lock_all(_priv->drm);
> - acomp->ops = NULL;
> - acomp->dev = NULL;
> + acomp->base.ops = NULL;
> + acomp->base.dev = NULL;
>   dev_priv->audio_component = NULL;
>   drm_modeset_unlock_all(_priv->drm);
>  }
> diff --git a/include/drm/drm_audio_component.h 
> b/include/drm/drm_audio_component.h
> new file mode 100644
> index ..f310b28404e8
> --- /dev/null
> +++ b/include/drm/drm_audio_component.h
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to 

Re: [PATCH v2 3/5] drm/vkms: Add atomic_helper_check_plane_state

[Sean Paul]

On Sat, Jul 14, 2018 at 03:21:13PM +0300, Haneen Mohammed wrote:
> Call atomic_helper_check_plane_state to clip plane coordinates.
> 
> Signed-off-by: Haneen Mohammed 

Reviewed-by: Sean Paul 

> ---
> Changes in v2:
> - check for plane_state->visible since we can't handle a disabled
>   primary plane yet.
> 
>  drivers/gpu/drm/vkms/vkms_plane.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 877483984897..aaf7c35faed6 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -7,6 +7,7 @@
>   */
>  
>  #include "vkms_drv.h"
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -25,6 +26,33 @@ static void vkms_primary_plane_update(struct drm_plane 
> *plane,
>  {
>  }
>  
> +static int vkms_plane_atomic_check(struct drm_plane *plane,
> +struct drm_plane_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> + int ret;
> +
> + if (!state->fb | !state->crtc)
> + return 0;
> +
> + crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> +   DRM_PLANE_HELPER_NO_SCALING,
> +   DRM_PLANE_HELPER_NO_SCALING,
> +   false, true);
> + if (ret != 0)
> + return ret;
> +
> + /* for now primary plane must be visible and full screen */
> + if (!state->visible)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
>  static int vkms_prepare_fb(struct drm_plane *plane,
>  struct drm_plane_state *state)
>  {
> @@ -58,6 +86,7 @@ static void vkms_cleanup_fb(struct drm_plane *plane,
>  
>  static const struct drm_plane_helper_funcs vkms_primary_helper_funcs = {
>   .atomic_update  = vkms_primary_plane_update,
> + .atomic_check   = vkms_plane_atomic_check,
>   .prepare_fb = vkms_prepare_fb,
>   .cleanup_fb = vkms_cleanup_fb,
>  };
> -- 
> 2.17.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] ALSA: hda: Make audio component support more generic

[Takashi Iwai]

On Mon, 16 Jul 2018 15:48:15 +0200,
Takashi Iwai wrote:
> 
> +static int hdac_component_master_bind(struct device *dev)
> +{
> + struct drm_audio_component *acomp = hdac_get_acomp(dev);
> + int ret;
> +
> + ret = component_bind_all(dev, acomp);
> + if (ret < 0)
> + return ret;
> +
> + if (WARN_ON(!(acomp->dev && acomp->ops))) {
> + ret = -EINVAL;
> + goto out_unbind;
> + }
> +
> + /* pin the module to avoid dynamic unbinding, but only if given */
> + if (!try_module_get(acomp->ops->owner)) {
> + ret = -ENODEV;
> + goto out_unbind;
> + }
> +
> + if (acomp->audio_ops->master_bind) {

Here misses the NULL check of acomp->audio_ops, which is caught by the
intel CI.  I overlooked it since the upcoming patch will set audio_ops
initially for i915 as well.  Will fix it in v2.


thanks,

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

Re: [PATCH 10/12] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings

[Rob Herring]

On Tue, Jul 03, 2018 at 11:02:21AM +0100, Damian Kos wrote:
> Document the bindings used for the Cadence MHDP DPI/DP bridge.
> 
> Signed-off-by: Damian Kos 
> ---
>  .../bindings/display/bridge/cdns,mhdp.txt  |   39 
> 
>  1 files changed, 39 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt 
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
> new file mode 100644
> index 000..d872e26
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
> @@ -0,0 +1,39 @@
> +Cadence MHDP bridge
> +==
> +
> +The Cadence MHDP bridge is a DPI to DP bridge.
> +
> +Required properties:
> + - compatible: should be "cdns,mhdp",

Not very specific. Only 1 version of this block?

> + - reg: physical base address and length of the controller's registers,
> + - clocks: DP bridge clock, it's used by the IP to know how to translate
> +a number of clock cycles into a time (which is used to comply
> +with DP standard timings and delays),
> + - clock-names: must be "clk",

Not a useful name. With only 1 clock, you can just drop this.

> +
> +Required subnodes:
> + - ports: Ports as described in Documentation/devictree/bindings/graph.txt
> +   Currently contains a single input port at address 0 representing the DPI
> +   input.

Currently? You should have a port connecting to a connector node.

> +   Port 0 should be connected to a DPI encoder output.
> +
> +Example:
> +
> + mhdp: mhdp@0xf0fb00 {

dp-bridge@f0fb00

> + compatible = "cdns,mhdp";
> + reg = <0xf0 0xfb00 0x0 0x100>;
> + clocks = <_clock>;
> + clock-names = "clk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mhdp0_dpi_input: endpoint {
> + remote-endpoint = <_dpi_output>;
> + };
> + };
> + };
> + };
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: simple: Support simple VGA panels

[Rob Herring]

On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij  wrote:
>
> The need to support some straight-forward VGA panels that are
> not adhering to any standard like DPI arise in the ARM RTSM VE
> Real-Time Systems Model Virtual Executive. This emulator (which
> is not QEMU) does not model any bridge or panel other than
> displaying whatever the user defines that they have.
>
> Currently a fake "DPI panel" is used for this with the old
> FBDEV driver, but this is wrong as it is not conforming to any
> MIPI DPI standards. However the resolution chosen there is
> standard VGA, and we can cover this with the simple panel
> by simply adding the most common VGA resolutions as a kind
> of "simple panel".
>
> In difference from other cases where "simple panel" might be
> hiding something more complex (such as a panel driver or bridge)
> this case is actually applicable, since we are running inside
> a simulation with no real hardware on the output.
>
> Cc: devicet...@vger.kernel.org
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Liviu Dudau 
> Cc: Robin Murphy 
> Signed-off-by: Linus Walleij 
> ---
>  .../display/panel/video-graphics-array.txt| 21 ++
>  drivers/gpu/drm/panel/panel-simple.c  | 66 +++
>  2 files changed, 87 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/video-graphics-array.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt 
> b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt
> new file mode 100644
> index ..193d24ebe052
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt
> @@ -0,0 +1,21 @@
> +Video Graphics Array

VGA is more a controller interface than a panel...

> +
> +This binding is for simple panels using the standardized VGA resolutions
> +defined by de facto standards beginning with the IBM PS/2 in 1987.
> +
> +Required properties:
> +- compatible: should be "video-graphics-array"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> +
> +Example:
> +
> +panel {
> +   compatible = "video-graphics-array";
> +   port {
> +   vga_panel_in: endpoint {
> +   remote-endpoint = <>;
> +   };
> +   };
> +};
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index cbf1ab404ee7..db4db5a3f75e 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2069,6 +2069,69 @@ static const struct panel_desc winstar_wf35ltiacd = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>  };
>
> +static const struct drm_display_mode video_graphics_array_modes[] = {
> +   {
> +   /*
> +* This is the most standardized "vanilla" VGA mode there is:
> +* 640x480 @ 60 Hz

Don't we have standard VESA timings already defined as well as timings
that can be calculated based on resolution and refresh rate (called
CVT IIRC). Why duplicate here?

Why don't you just define a 'vga-connector' node and IIRC, you can
just force the standard modes from userspace with DRM. Maybe you need
some flag to force a connection in the emulator and perhaps some fake
EDID data to set a default mode. There's also some other cases of
"transparent" bridges which don't have any driver.

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

Re: [PATCH] drm/msm/display: negative x/y in cursor move

[kbuild test robot]

Hi Carsten,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on robclark/msm-next]
[also build test WARNING on v4.18-rc5 next-20180716]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Carsten-Behling/drm-msm-display-negative-x-y-in-cursor-move/20180717-031351
base:   git://people.freedesktop.org/~robclark/linux msm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from include/drm/drm_mm.h:49:0,
from include/drm/drmP.h:73,
from include/drm/drm_modeset_helper.h:26,
from include/drm/drm_crtc_helper.h:44,
from drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:22:
   drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c: In function 
'mdp5_crtc_restore_cursor':
>> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:831:6: warning: format '%s' 
>> expects argument of type 'char *', but argument 3 has type 'uint32_t {aka 
>> unsigned int}' [-Wformat=]
 DBG("%s: x=%d, y=%d roi_w=%d roi_h=%d src_x=%d src_y=%d",
 ^
   include/drm/drm_print.h:285:25: note: in definition of macro 
'DRM_DEBUG_DRIVER'
 drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
^~~
>> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:831:2: note: in expansion of macro 
>> 'DBG'
 DBG("%s: x=%d, y=%d roi_w=%d roi_h=%d src_x=%d src_y=%d",
 ^~~
   drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:831:8: note: format string is 
defined here
 DBG("%s: x=%d, y=%d roi_w=%d roi_h=%d src_x=%d src_y=%d",
  ~^
  %d
   In file included from include/drm/drm_mm.h:49:0,
from include/drm/drmP.h:73,
from include/drm/drm_modeset_helper.h:26,
from include/drm/drm_crtc_helper.h:44,
from drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:22:
>> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:831:6: warning: format '%d' 
>> expects a matching 'int' argument [-Wformat=]
 DBG("%s: x=%d, y=%d roi_w=%d roi_h=%d src_x=%d src_y=%d",
 ^
   include/drm/drm_print.h:285:25: note: in definition of macro 
'DRM_DEBUG_DRIVER'
 drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
^~~
>> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:831:2: note: in expansion of macro 
>> 'DBG'
 DBG("%s: x=%d, y=%d roi_w=%d roi_h=%d src_x=%d src_y=%d",
 ^~~
   drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:831:56: note: format string is 
defined here
 DBG("%s: x=%d, y=%d roi_w=%d roi_h=%d src_x=%d src_y=%d",
  ~^

vim +831 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c

   789  
   790  static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
   791  {
   792  struct mdp5_crtc_state *mdp5_cstate = 
to_mdp5_crtc_state(crtc->state);
   793  struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
   794  struct mdp5_kms *mdp5_kms = get_kms(crtc);
   795  const enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
   796  uint32_t blendcfg, stride;
   797  uint32_t x, y, src_x, src_y, width, height;
   798  uint32_t roi_w, roi_h;
   799  int lm;
   800  
   801  assert_spin_locked(_crtc->cursor.lock);
   802  
   803  lm = mdp5_cstate->pipeline.mixer->lm;
   804  
   805  x = mdp5_crtc->cursor.x;
   806  y = mdp5_crtc->cursor.y;
   807  width = mdp5_crtc->cursor.width;
   808  height = mdp5_crtc->cursor.height;
   809  
   810  stride = width * drm_format_plane_cpp(DRM_FORMAT_ARGB, 0);
   811  
   812  get_roi(crtc, _w, _h);
   813  
   814  /* If cusror buffer overlaps due to rotation on the
   815   * upper or left screen border the pixel offset inside
   816   * the cursor buffer of the ROI is the positive overlap
   817   * distance.
   818   */
   819  if (mdp5_crtc->cursor.x < 0) {
   820  src_x = abs(mdp5_crtc->cursor.x);
   821  x = 0;
   822  } else {
   823  src_x = 0;
   824  }
   825  if (mdp5_crtc->cursor.y < 0) {
   826  src_y = abs(mdp5_crtc->cursor.y);
   827  y = 0;
   828  } else {
   829  src_y = 0;
   830  }
 > 831  DBG("%s: x=%d, y=%d roi_w=%d r

Re: Bug in virtio gpu connector destroy

[Dave Airlie]

Cc'ing some others

On Mon., 16 Jul. 2018, 23:33 Damir Shaikhutdinov, <
damir.shaikhutdi...@opensynergy.com> wrote:

> Hi Dave!
>
> I'm debugging virtio gpu unloading path in kernel 4.14, and found some bug
> that presents even in 4.18.
>
> In file drivers/gpu/drm/virtio/virtgpu_display.c:
>
> static void virtio_gpu_conn_destroy 
> (struct
>  drm_connector 
>  *connector){
>   struct virtio_gpu_output 
>  
> *virtio_gpu_output 
>  =
>   drm_connector_to_virtio_gpu_output 
> (connector);
>
>   drm_connector_unregister 
> (connector);
>   drm_connector_cleanup 
> (connector);
>   kfree 
> (virtio_gpu_output 
> ); // 
> <--- here is the bug}
>
>
>
> https://elixir.bootlin.com/linux/v4.18-rc5/source/drivers/gpu/drm/virtio/virtgpu_display.c#L264
>
> This virtio_gpu_output pointer in this function points to a memory NOT
> allocated by k*alloc, but to an element of
> outputs array in struct virtio device.
>
> You can find the actual code that initialize connector few lines lower:
>
>   struct virtio_gpu_output 
>  *output 
>  = vgdev->outputs 
>  + index;
>   struct drm_connector 
>  *connector = 
>  ->conn 
> ;
>
> 
> drm_connector_init 
> (dev, 
> connector, _gpu_connector_funcs 
> ,
>  DRM_MODE_CONNECTOR_VIRTUAL 
> );
>
> So, connector points to a field "conn" inside struct "virtio_gpu_output", 
> which is an element of array
> vgdev->outputs, and not something that was allocated separately.
>
> Kfree-ing it is an error.
>
>
> Can you confirm that bug?
>
>
> With best regards,
>
> Damir Shaikhutdinov
> Senior Software Engineer
>
> OpenSynergy GmbH
> Rotherstr. 20, 10245 Berlin
>
> Phone: +49 30 60 98 54 0.
> Fax:  +49 30 60 98 54 0 -99
> EMail:   damir.shaikhutdi...@opensynergy.com
> www.opensynergy.com
>
> Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
> Geschäftsführung: Stefaan Sonck Thiebaut, Rolf Morich
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Andrew Morton]

On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko  wrote:

> From: Michal Hocko 
> 
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend on any sleepable locks.
> 
> Currently we simply back off and mark an oom victim with blockable mmu
> notifiers as done after a short sleep. That can result in selecting a
> new oom victim prematurely because the previous one still hasn't torn
> its memory down yet.
> 
> We can do much better though. Even if mmu notifiers use sleepable locks
> there is no reason to automatically assume those locks are held.
> Moreover majority of notifiers only care about a portion of the address
> space and there is absolutely zero reason to fail when we are unmapping an
> unrelated range. Many notifiers do really block and wait for HW which is
> harder to handle and we have to bail out though.
> 
> This patch handles the low hanging fruid. 
> __mmu_notifier_invalidate_range_start
> gets a blockable flag and callbacks are not allowed to sleep if the
> flag is set to false. This is achieved by using trylock instead of the
> sleepable lock for most callbacks and continue as long as we do not
> block down the call chain.

I assume device driver developers are wondering "what does this mean
for me".  As I understand it, the only time they will see
blockable==false is when their driver is being called in response to an
out-of-memory condition, yes?  So it is a very rare thing.

Any suggestions regarding how the driver developers can test this code
path?  I don't think we presently have a way to fake an oom-killing
event?  Perhaps we should add such a thing, given the problems we're
having with that feature.

> I think we can improve that even further because there is a common
> pattern to do a range lookup first and then do something about that.
> The first part can be done without a sleeping lock in most cases AFAICS.
> 
> The oom_reaper end then simply retries if there is at least one notifier
> which couldn't make any progress in !blockable mode. A retry loop is
> already implemented to wait for the mmap_sem and this is basically the
> same thing.
> 
> ...
>
> +static inline int mmu_notifier_invalidate_range_start_nonblock(struct 
> mm_struct *mm,
> +   unsigned long start, unsigned long end)
> +{
> + int ret = 0;
> + if (mm_has_notifiers(mm))
> + ret = __mmu_notifier_invalidate_range_start(mm, start, end, 
> false);
> +
> + return ret;
>  }

nit,

{
if (mm_has_notifiers(mm))
return __mmu_notifier_invalidate_range_start(mm, start, end, 
false);
return 0;
}

would suffice.


> 
> ...
>
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3074,7 +3074,7 @@ void exit_mmap(struct mm_struct *mm)
>* reliably test it.
>*/
>   mutex_lock(_lock);
> - __oom_reap_task_mm(mm);
> + (void)__oom_reap_task_mm(mm);
>   mutex_unlock(_lock);

What does this do?

>   set_bit(MMF_OOM_SKIP, >flags);
> 
> ...
>

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

[PATCH] backlight: pwm_bl: Fix uninitialized variable

[Daniel Thompson]

Currently, if the DT does not define num-interpolated-steps then
num_steps is undefined and the interpolation code will deploy randomly.
Fix this.

Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
brightness-levels")
Reported-by: Marcel Ziswiler 
Signed-off-by: Daniel Thompson 
Signed-off-by: Marcel Ziswiler 
Tested-by: Marcel Ziswiler 
---
 drivers/video/backlight/pwm_bl.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 9ee4c1b735b2..e3c22b79fbcd 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -299,15 +299,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
 * interpolation between each of the values of brightness levels
 * and creates a new pre-computed table.
 */
-   of_property_read_u32(node, "num-interpolated-steps",
-_steps);
-
-   /*
-* Make sure that there is at least two entries in the
-* brightness-levels table, otherwise we can't interpolate
-* between two points.
-*/
-   if (num_steps) {
+   if ((of_property_read_u32(node, "num-interpolated-steps",
+ _steps) == 0) && num_steps) {
+   /*
+* Make sure that there is at least two entries in the
+* brightness-levels table, otherwise we can't
+* interpolate
+* between two points.
+*/
if (data->max_brightness < 2) {
dev_err(dev, "can't interpolate\n");
return -EINVAL;
--
2.17.1

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Split audio component to a generic type

[Takashi Iwai]

On Mon, 16 Jul 2018 19:50:48 +0200,
Takashi Iwai wrote:
> 
> On Mon, 16 Jul 2018 19:22:17 +0200,
> Rodrigo Vivi wrote:
> > 
> > > --- /dev/null
> > > +++ b/include/drm/drm_audio_component.h
> > > @@ -0,0 +1,115 @@
> > > +/*
> > > + * Copyright © 2014 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a
> > > + * copy of this software and associated documentation files (the 
> > > "Software"),
> > > + * to deal in the Software without restriction, including without 
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the 
> > > next
> > > + * paragraph) shall be included in all copies or substantial portions of 
> > > the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > > OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > > DEALINGS
> > > + * IN THE SOFTWARE.
> > > + */
> > 
> > I think it is better to start new files with SPDX identifiers
> 
> Yeah, it's a more sensible option.  Will rewrite in v2.

So, now I changed to

  // SPDX-License-Identifier: MIT

as the original i915_component.h seems containing that license.
Let me know if it should be changed to anything else.


thanks,

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

[PATCH 3/6] drm/i915: Move out non-modeset calls from modeset init and cleanup

[José Roberto de Souza]

i915_load_modeset_init() and intel_modeset_cleanup() was initializing
and cleaning up things that is not modeset only.
This will make easy initialize drive without display part.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.c  | 56 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 16 +++-
 3 files changed, 42 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 99792039176f..402ed9b4f29e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -665,25 +665,15 @@ static int i915_load_modeset_init(struct drm_device *dev)
/* must happen before intel_power_domains_init_hw() on VLV/CHV */
intel_update_rawclk(dev_priv);
 
-   intel_power_domains_init_hw(dev_priv, false);
-
intel_csr_ucode_init(dev_priv);
 
-   ret = intel_irq_install(dev_priv);
-   if (ret)
-   goto cleanup_csr;
-
intel_setup_gmbus(dev_priv);
 
/* Important: The output setup functions called by modeset_init need
 * working irqs for e.g. gmbus and dp aux transfers. */
ret = intel_modeset_init(dev);
if (ret)
-   goto cleanup_irq;
-
-   ret = i915_gem_init(dev_priv);
-   if (ret)
-   goto cleanup_modeset;
+   goto cleanup_gmbus;
 
intel_setup_overlay(dev_priv);
 
@@ -692,23 +682,17 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
ret = intel_fbdev_init(dev);
if (ret)
-   goto cleanup_gem;
+   goto cleanup_modeset;
 
/* Only enable hotplug handling once the fbdev is fully set up. */
intel_hpd_init(dev_priv);
 
return 0;
 
-cleanup_gem:
-   if (i915_gem_suspend(dev_priv))
-   DRM_ERROR("failed to idle hardware; continuing to unload!\n");
-   i915_gem_fini(dev_priv);
 cleanup_modeset:
intel_modeset_cleanup(dev);
-cleanup_irq:
-   drm_irq_uninstall(dev);
+cleanup_gmbus:
intel_teardown_gmbus(dev_priv);
-cleanup_csr:
intel_csr_ucode_fini(dev_priv);
intel_power_domains_fini(dev_priv);
vga_switcheroo_unregister_client(pdev);
@@ -1395,9 +1379,22 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
goto out_cleanup_hw;
}
 
+   ret = intel_irq_install(dev_priv);
+   if (ret)
+   goto out_cleanup_hw;
+
+   /* i915_gem_init() call chain will call
+* intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ);
+*/
+   intel_power_domains_init_hw(dev_priv, false);
+
+   ret = i915_gem_init(dev_priv);
+   if (ret)
+   goto cleanup_irq;
+
ret = i915_load_modeset_init(_priv->drm);
if (ret < 0)
-   goto out_cleanup_hw;
+   goto cleanup_gem;
 
i915_driver_register(dev_priv);
 
@@ -1411,6 +1408,12 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
return 0;
 
+cleanup_gem:
+   if (i915_gem_suspend(dev_priv))
+   DRM_ERROR("failed to idle hardware; continuing to unload!\n");
+   i915_gem_fini(dev_priv);
+cleanup_irq:
+   drm_irq_uninstall(_priv->drm);
 out_cleanup_hw:
i915_driver_cleanup_hw(dev_priv);
 out_cleanup_mmio:
@@ -1445,8 +1448,21 @@ void i915_driver_unload(struct drm_device *dev)
 
intel_gvt_cleanup(dev_priv);
 
+   intel_modeset_cleanup_prepare(dev);
+
+   intel_disable_gt_powersave(dev_priv);
+
+   /*
+* Interrupts and polling as the first thing to avoid creating havoc.
+* Too much stuff here (turning of connectors, ...) would
+* experience fancy races otherwise.
+*/
+   intel_irq_uninstall(dev_priv);
+
intel_modeset_cleanup(dev);
 
+   intel_cleanup_gt_powersave(dev_priv);
+
intel_bios_cleanup(dev_priv);
 
vga_switcheroo_unregister_client(pdev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4fb937399440..51eb48f6b57a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3419,6 +3419,7 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
 /* modesetting */
 extern void intel_modeset_init_hw(struct drm_device *dev);
 extern int intel_modeset_init(struct drm_device *dev);
+extern void intel_modeset_cleanup_prepare(struct drm_device *dev);
 extern void intel_modeset_cleanup(struct drm_device *dev);
 extern int intel_connector_register(struct drm_connector *);
 extern void intel_connector_unregister(struct drm_connector *);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bbf63741ae80..136fb8d51967 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15905,7 +15905,7 @@ static void intel_hpd_poll_fini(struct drm_device 

[PATCH 2/6] drm/i915: Set PCH as NOP if display is disabled

[José Roberto de Souza]

num_pipes is set to 0 if disable_display is set inside
intel_device_info_runtime_init() but when that happen PCH will
already be set in intel_detect_pch().

i915_driver_load()
i915_driver_init_early()
...
intel_detect_pch()
...
...
i915_driver_init_hw()
intel_device_info_runtime_init()

Cc: Jani Nikula 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3834bd758a2e..99792039176f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -287,7 +287,8 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 * Use PCH_NOP (PCH but no South Display) for PCH platforms without
 * display.
 */
-   if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
+   if (pch && ((INTEL_INFO(dev_priv)->num_pipes == 0) ||
+   i915_modparams.disable_display)) {
DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
dev_priv->pch_type = PCH_NOP;
dev_priv->pch_id = 0;
-- 
2.18.0

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

[PATCH 6/6] drm/i915: Remove redundante checks for num_pipes == 0

[José Roberto de Souza]

This 'if's will always be false because of previous changes.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.c  | 12 +++-
 drivers/gpu/drm/i915/intel_audio.c   |  3 ---
 drivers/gpu/drm/i915/intel_display.c |  3 ---
 drivers/gpu/drm/i915/intel_i2c.c |  3 ---
 4 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e109815cfa51..bad7ad0bd5ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -643,12 +643,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (i915_inject_load_failure())
return -ENODEV;
 
-   if (INTEL_INFO(dev_priv)->num_pipes == 0) {
-   ret = drm_vblank_init(_priv->drm,
- INTEL_INFO(dev_priv)->num_pipes);
-   if (ret)
-   goto out;
-   }
+   ret = drm_vblank_init(_priv->drm, INTEL_INFO(dev_priv)->num_pipes);
+   if (ret)
+   goto out;
 
intel_bios_init(dev_priv);
 
@@ -684,9 +681,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
intel_setup_overlay(dev_priv);
 
-   if (INTEL_INFO(dev_priv)->num_pipes == 0)
-   return 0;
-
ret = intel_fbdev_init(dev);
if (ret)
goto cleanup_modeset;
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index bb94172ffc07..f02cb211d3e7 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -960,9 +960,6 @@ void i915_audio_component_init(struct drm_i915_private 
*dev_priv)
 {
int ret;
 
-   if (INTEL_INFO(dev_priv)->num_pipes == 0)
-   return;
-
ret = component_add(dev_priv->drm.dev, _audio_component_bind_ops);
if (ret < 0) {
DRM_ERROR("failed to add audio component (%d)\n", ret);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 136fb8d51967..b572151c52fa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15137,9 +15137,6 @@ int intel_modeset_init(struct drm_device *dev)
 
intel_init_pm(dev_priv);
 
-   if (INTEL_INFO(dev_priv)->num_pipes == 0)
-   return 0;
-
/*
 * There may be no VBT; and if the BIOS enabled SSC we can
 * just keep using it to avoid unnecessary flicker.  Whereas if the
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index bef32b7c248e..2f941c5b2e8c 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -819,9 +819,6 @@ int intel_setup_gmbus(struct drm_i915_private *dev_priv)
unsigned int pin;
int ret;
 
-   if (INTEL_INFO(dev_priv)->num_pipes == 0)
-   return 0;
-
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->gpio_mmio_base = VLV_DISPLAY_BASE;
else if (!HAS_GMCH_DISPLAY(dev_priv))
-- 
2.18.0

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

[PATCH 1/6] drm: Let userspace check if driver supports modeset

[José Roberto de Souza]

GPU accelerators usually don't have display block or the display
driver part can be disable when building driver(for servers it save
some resources) so it is important let userspace check this
capability too.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/drm_ioctl.c | 3 +++
 include/uapi/drm/drm.h  | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ea10e9a26aad..3a8438ae9b51 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -244,6 +244,9 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
case DRM_CAP_SYNCOBJ:
req->value = drm_core_check_feature(dev, DRIVER_SYNCOBJ);
return 0;
+   case DRM_CAP_MODESET:
+   req->value = drm_core_check_feature(dev, DRIVER_MODESET);
+   return 0;
}
 
/* Other caps only work with KMS drivers */
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 300f336633f2..85fae6ddbf48 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -649,6 +649,7 @@ struct drm_gem_open {
 #define DRM_CAP_PAGE_FLIP_TARGET   0x11
 #define DRM_CAP_CRTC_IN_VBLANK_EVENT   0x12
 #define DRM_CAP_SYNCOBJ0x13
+#define DRM_CAP_MODESET0x14
 
 /** DRM_IOCTL_GET_CAP ioctl argument type */
 struct drm_get_cap {
-- 
2.18.0

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

[PATCH 5/6] drm/i915: Do not call modeset related functions when display is disabled

[José Roberto de Souza]

No need to run i915_load_modeset_init() when num_pipes == 0 also
kms depends on things initialized in i915_load_modeset_init() so not
initializing it too. fbdev and audio have guards against
num_pipes == 0 but lets move it to the if block to make it explicit
to readers.

Also as planes, CRTCs, encoders and connectors are not being added
it is necessary to unset the MODESET driver feature otherwise it
will crash when registering driver in drm, also disabling ATOMIC as
do not make sense have ATOMIC and do not have MODESET.

There is more modeset/display calls that still needs to be removed,
this is a initial work.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.c | 69 -
 1 file changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aacb467fe3ea..e109815cfa51 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1248,23 +1248,26 @@ static void i915_driver_register(struct 
drm_i915_private *dev_priv)
if (IS_GEN5(dev_priv))
intel_gpu_ips_init(dev_priv);
 
-   intel_audio_init(dev_priv);
+   if (INTEL_INFO(dev_priv)->num_pipes) {
+   intel_audio_init(dev_priv);
 
-   /*
-* Some ports require correctly set-up hpd registers for detection to
-* work properly (leading to ghost connected connector status), e.g. VGA
-* on gm45.  Hence we can only set up the initial fbdev config after hpd
-* irqs are fully enabled. We do it last so that the async config
-* cannot run before the connectors are registered.
-*/
-   intel_fbdev_initial_config_async(dev);
+   /*
+* Some ports require correctly set-up hpd registers for
+* detection to work properly (leading to ghost connected
+* connector status), e.g. VGA on gm45.  Hence we can only set
+* up the initial fbdev config after hpd irqs are fully enabled.
+* We do it last so that the async config cannot run before the
+* connectors are registered.
+*/
+   intel_fbdev_initial_config_async(dev);
 
-   /*
-* We need to coordinate the hotplugs with the asynchronous fbdev
-* configuration, for which we use the fbdev->async_cookie.
-*/
-   if (INTEL_INFO(dev_priv)->num_pipes)
+   /*
+* We need to coordinate the hotplugs with the asynchronous
+* fbdev configuration, for which we use the
+* fbdev->async_cookie.
+*/
drm_kms_helper_poll_init(dev);
+   }
 }
 
 /**
@@ -1273,15 +1276,17 @@ static void i915_driver_register(struct 
drm_i915_private *dev_priv)
  */
 static void i915_driver_unregister(struct drm_i915_private *dev_priv)
 {
-   intel_fbdev_unregister(dev_priv);
-   intel_audio_deinit(dev_priv);
+   if (INTEL_INFO(dev_priv)->num_pipes) {
+   intel_fbdev_unregister(dev_priv);
+   intel_audio_deinit(dev_priv);
 
-   /*
-* After flushing the fbdev (incl. a late async config which will
-* have delayed queuing of a hotplug event), then flush the hotplug
-* events.
-*/
-   drm_kms_helper_poll_fini(_priv->drm);
+   /*
+* After flushing the fbdev (incl. a late async config which
+* will have delayed queuing of a hotplug event), then flush the
+* hotplug events.
+*/
+   drm_kms_helper_poll_fini(_priv->drm);
+   }
 
intel_gpu_ips_teardown();
acpi_video_unregister();
@@ -1333,6 +1338,9 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
driver.driver_features &= ~DRIVER_ATOMIC;
 
+   if (i915_modparams.disable_display)
+   driver.driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC);
+
ret = -ENOMEM;
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (dev_priv)
@@ -1387,9 +1395,11 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret)
goto cleanup_irq;
 
-   ret = i915_load_modeset_init(_priv->drm);
-   if (ret < 0)
-   goto cleanup_gem;
+   if (INTEL_INFO(dev_priv)->num_pipes) {
+   ret = i915_load_modeset_init(_priv->drm);
+   if (ret < 0)
+   goto cleanup_gem;
+   }
 
i915_driver_register(dev_priv);
 
@@ -1439,11 +1449,13 @@ void i915_driver_unload(struct drm_device *dev)
 
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
-   drm_atomic_helper_shutdown(dev);
+   if (INTEL_INFO(dev_priv)->num_pipes)
+   drm_atomic_helper_shutdown(dev);
 

[PATCH 4/6] drm/i915: Move drm_vblank_init() to i915_load_modeset_init()

[José Roberto de Souza]

i915_load_modeset_init() is a more suitable place than
i915_driver_load() as vblank is part of modeset API.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 402ed9b4f29e..aacb467fe3ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -643,6 +643,13 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (i915_inject_load_failure())
return -ENODEV;
 
+   if (INTEL_INFO(dev_priv)->num_pipes == 0) {
+   ret = drm_vblank_init(_priv->drm,
+ INTEL_INFO(dev_priv)->num_pipes);
+   if (ret)
+   goto out;
+   }
+
intel_bios_init(dev_priv);
 
/* If we have > 1 VGA cards, then we need to arbitrate access
@@ -1367,18 +1374,6 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_mmio;
 
-   /*
-* TODO: move the vblank init and parts of modeset init steps into one
-* of the i915_driver_init_/i915_driver_register functions according
-* to the role/effect of the given init step.
-*/
-   if (INTEL_INFO(dev_priv)->num_pipes) {
-   ret = drm_vblank_init(_priv->drm,
- INTEL_INFO(dev_priv)->num_pipes);
-   if (ret)
-   goto out_cleanup_hw;
-   }
-
ret = intel_irq_install(dev_priv);
if (ret)
goto out_cleanup_hw;
-- 
2.18.0

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

[PATCH RESEND] drm/meson: Make DMT timings parameters and pixel clock generic

[Neil Armstrong]

Remove the modes timings tables for DMT modes and calculate the HW
paremeters from the modes timings.

Switch the DMT modes pixel clock calculation out of the static frequency
list to a generic calculation from a range of possible PLL dividers.

This patch is an intermediate step towards usage of the Common Clock
Framwework for PLL setup, by reworking the code to have common
sel_pll() function called by the CEA (HDMI) freq setup and the generic
DMT frequencies setup, we should be able to simply call clk_set_rate()
on the PLL clock handle in a near future.

The CEA (HDMI) and CVBS modes needs very specific clock paths that CCF will
never be able to determine by itself, so there is still some work to do for
a full handoff to CCF handling the clocks.

This setup permits setting non-CEA modes like :
- 1600x900-60Hz
- 1280x1024-75Hz
- 1280x1024-60Hz
- 1440x900-60Hz
- 1366x768-60Hz
- 1280x800-60Hz
- 1152x864-75Hz
- 1024x768-75Hz
- 1024x768-70Hz
- 1024x768-60Hz
- 832x624-75Hz
- 800x600-75Hz
- 800x600-72Hz
- 800x600-60Hz
- 640x480-75Hz
- 640x480-73Hz
- 640x480-67Hz

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c |  22 +-
 drivers/gpu/drm/meson/meson_vclk.c| 672 +++---
 drivers/gpu/drm/meson/meson_vclk.h|   4 +
 drivers/gpu/drm/meson/meson_venc.c| 377 +++
 drivers/gpu/drm/meson/meson_venc.h|   3 +-
 5 files changed, 358 insertions(+), 720 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index c9ad456..df7247c 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -329,6 +329,12 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi *dw_hdmi,
 
vclk_freq = mode->clock;
 
+   if (!vic) {
+   meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, vclk_freq,
+vclk_freq, vclk_freq, false);
+   return;
+   }
+
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
vclk_freq *= 2;
 
@@ -542,10 +548,12 @@ static enum drm_mode_status
 dw_hdmi_mode_valid(struct drm_connector *connector,
   const struct drm_display_mode *mode)
 {
+   struct meson_drm *priv = connector->dev->dev_private;
unsigned int vclk_freq;
unsigned int venc_freq;
unsigned int hdmi_freq;
int vic = drm_match_cea_mode(mode);
+   enum drm_mode_status status;
 
DRM_DEBUG_DRIVER("Modeline %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 
0x%x\n",
mode->base.id, mode->name, mode->vrefresh, mode->clock,
@@ -556,8 +564,11 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
 
/* Check against non-VIC supported modes */
if (!vic) {
-   if (!meson_venc_hdmi_supported_mode(mode))
-   return MODE_BAD;
+   status = meson_venc_hdmi_supported_mode(mode);
+   if (status != MODE_OK)
+   return status;
+
+   return meson_vclk_dmt_supported_freq(priv, mode->clock);
/* Check against supported VIC modes */
} else if (!meson_venc_hdmi_supported_vic(vic))
return MODE_BAD;
@@ -583,16 +594,11 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
dev_dbg(connector->dev->dev, "%s: vclk:%d venc=%d hdmi=%d\n", __func__,
vclk_freq, venc_freq, hdmi_freq);
 
-   /* Finally filter by configurable vclk frequencies */
+   /* Finally filter by configurable vclk frequencies for VIC modes */
switch (vclk_freq) {
-   case 25175:
-   case 4:
case 54000:
-   case 65000:
case 74250:
-   case 108000:
case 148500:
-   case 162000:
case 297000:
case 594000:
return MODE_OK;
diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index f051122..0b17788 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -320,32 +320,23 @@ static void meson_venci_cvbs_clock_config(struct 
meson_drm *priv)
CTS_VDAC_EN, CTS_VDAC_EN);
 }
 
-
+enum {
 /* PLL O1 O2 O3 VP DV EN TX */
 /* 4320 /4 /4 /1 /5 /1  => /2 /2 */
-#define MESON_VCLK_HDMI_ENCI_54000 1
+   MESON_VCLK_HDMI_ENCI_54000 = 1,
 /* 4320 /4 /4 /1 /5 /1  => /1 /2 */
-#define MESON_VCLK_HDMI_DDR_54000  2
+   MESON_VCLK_HDMI_DDR_54000,
 /* 2970 /4 /1 /1 /5 /1  => /1 /2 */
-#define MESON_VCLK_HDMI_DDR_148500 3
-/* 4028 /4 /4 /1 /5 /2  => /1 /1 */
-#define MESON_VCLK_HDMI_25175  4
-/* 3200 /4 /2 /1 /5 /2  => /1 /1 */
-#define MESON_VCLK_HDMI_4  5
-/* 5200 /4 /2 /1 /5 /2  => /1 /1 */
-#define MESON_VCLK_HDMI_65000  6
+   MESON_VCLK_HDMI_DDR_148500,
 /* 2970 /2 /2 /2 /5 /1  => /1 /1 */
-#define MESON_VCLK_HDMI_74250  7
-/* 4320 /4 /1 /1 /5 /2  => /1 /1 */
-#define MESON_VCLK_HDMI_108000 8
+   

Re: [PATCH 1/3 v4] ARM: dts: Modernize the Vexpress PL111 integration

[Linus Walleij]

On Tue, Jul 10, 2018 at 11:46 AM Sudeep Holla  wrote:
> On 09/07/18 08:52, Linus Walleij wrote:

> Still get below warnings, not sure if I need to upgrade my DTC ?
>
> vexpress-v2f-1xv7-ca53x2.dtb: Warning (graph_child_address):
> /smb@800/motherboard/iofpga@3,/i2c@16/dvi-transmitter@39/ports:
> graph node has single child node 'port@0', #address-cells/#size-cells
> are not necessary
> rtsm_ve-aemv8a.dtb: Warning (graph_child_address):
> /smb@800/motherboard/iofpga@3,/i2c@16/dvi-transmitter@39/ports:
> graph node has single child node 'port@0', #address-cells/#size-cells
> are not necessary

Yeah I looked at it as you said I decided to drop the amendments and I'm
just ever more confused.

> > - Fixed up the CA53 DTS: use the right chip select base
> >   at 0x1800.
>
> I really hate this as it make maintenance difficult, but I don't have
> good alternative, so I am fine as it is for now :)

Yeah :/

I wish I could fix this but the changes are already daunting and scary
as they are without going in and trying to fix how the CMA DMA
allocator does its job as well (I admit I am scared of that code).

> > - Fixed up the Real-Time Systems Models Virtual Executive
> >   RTSMv8 AEM VE:
> >   - Added the I2C interface (whether implemented in the
> > emulator or not)
>
> It doesn't work. This change is breaking the working CLCD on the models.
> I just tested and CLCD driver returns

Yeah not surprised... with QEMU I had to go in and add the I2C
bridge as it was not modeled.

I think the solution is to add a "simple" panel without bridge
for this as it is properly modeling what the hardware in the
RTSM looks like. Looking into it.

> >   - Fixed the chip select of the memory node to the right
> > memory base 0x1800.
>
> See, this keeps happening.

Yeah, I looked them over again and again, it gets wrong because
I put a human to do a machine's job... The chipselect setting is
in a non-obvious place in one file and the base that corresponds
to in a different file and it gets a bit confused.

I hope I have them all right now.

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

Re: [PATCH 1/3 v4] ARM: dts: Modernize the Vexpress PL111 integration

[Linus Walleij]

On Fri, Jul 13, 2018 at 1:44 PM Robin Murphy  wrote:
> On 13/07/18 10:50, Sudeep Holla wrote:
> >> It doesn't work. This change is breaking the working CLCD on the models.
> >> I just tested and CLCD driver returns
> >>
> >
> > It even fails to initialize CLCD on my TC2.
> >
> > clcd-pl11x 1c1f.clcd: PL111 designer 41 rev1 at 0x1c1f
> > clcd-pl11x: probe of 1c1f.clcd failed with error -2
>
> FWIW the same happens on PB-A8; looks like converting to OF graph
> bindings falls foul of the "panel-dpi" check in clcdfb_of_get_mode().

That is from the old FB drivers, the defconfig changes in patch 2,3
need to be applied in lockstep with this patch. Then it "should work"
(alas I only tested PB-A8 on QEMU, which I modified to hopefully
properly model the DVI bridge).

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

[V2 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[Jim Qu]

On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio codec
for HDMP/DP output. For some dGPU which is no output,
audio codec usually is disabled.

In currect HDA audio driver, it will set all codec as
VGA_SWITCHEROO_DIS, the audio which is binded to UMA
will be suspended if user use debugfs to control power

In HDA driver side, it is difficult to know which GPU
the audio has bound to. So set the bound gpu pci dev
to vgaswitchreoo, the correct audio id will be set in
vgaswitchreoo enable function.

Signed-off-by: Jim Qu 
---
 drivers/gpu/vga/vga_switcheroo.c | 39 +--
 include/linux/vga_switcheroo.h   |  8 
 sound/pci/hda/hda_intel.c| 10 +-
 3 files changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index fc4adf3..2b9ae42 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -103,6 +103,7 @@
  * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
  * interface is a no-op so as not to interfere with runtime pm
  * @list: client list
+ * @vga_dev: pci device, indicate which GPU is bound to current audio client
  *
  * Registered client. A client can be either a GPU or an audio device on a GPU.
  * For audio clients, the @fb_info and @active members are bogus.
@@ -116,6 +117,7 @@ struct vga_switcheroo_client {
bool active;
bool driver_power_control;
struct list_head list;
+   struct pci_dev *vga_dev;
 };
 
 /*
@@ -161,9 +163,8 @@ struct vgasr_priv {
 };
 
 #define ID_BIT_AUDIO   0x100
-#define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
-#define client_is_vga(c)   ((c)->id == VGA_SWITCHEROO_UNKNOWN_ID || \
-!client_is_audio(c))
+#define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
+#define client_is_vga(c)   (!client_is_audio(c))
 #define client_id(c)   ((c)->id & ~ID_BIT_AUDIO)
 
 static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
@@ -192,14 +193,28 @@ static void vga_switcheroo_enable(void)
vgasr_priv.handler->init();
 
list_for_each_entry(client, _priv.clients, list) {
-   if (client->id != VGA_SWITCHEROO_UNKNOWN_ID)
+   if (!client_is_vga(client) || client_id(client) !=
+   VGA_SWITCHEROO_UNKNOWN_ID)
continue;
+
ret = vgasr_priv.handler->get_client_id(client->pdev);
if (ret < 0)
return;
-
client->id = ret;
}
+
+   list_for_each_entry(client, _priv.clients, list) {
+   if (!client_is_audio(client) || client_id(client) !=
+   VGA_SWITCHEROO_UNKNOWN_ID)
+   continue;
+
+   ret = vgasr_priv.handler->get_client_id(client->vga_dev);
+   if (ret < 0)
+   return;
+
+   client->id = ret | ID_BIT_AUDIO;
+   }
+
vga_switcheroo_debugfs_init(_priv);
vgasr_priv.active = true;
 }
@@ -272,7 +287,9 @@ EXPORT_SYMBOL(vga_switcheroo_handler_flags);
 
 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
-  enum vga_switcheroo_client_id id, bool active,
+  enum vga_switcheroo_client_id id,
+  struct pci_dev *vga_dev,
+  bool active,
   bool driver_power_control)
 {
struct vga_switcheroo_client *client;
@@ -287,6 +304,7 @@ static int register_client(struct pci_dev *pdev,
client->id = id;
client->active = active;
client->driver_power_control = driver_power_control;
+   client->vga_dev = vga_dev;
 
mutex_lock(_mutex);
list_add_tail(>list, _priv.clients);
@@ -319,7 +337,7 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
   bool driver_power_control)
 {
-   return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID,
+   return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID, NULL,
   pdev == vga_default_device(),
   driver_power_control);
 }
@@ -329,7 +347,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  * vga_switcheroo_register_audio_client - register audio client
  * @pdev: client pci device
  * @ops: client callbacks
- * @id: client identifier
+ * @vga_dev:  pci device which is bound to current audio client
  *
  * Register audio client (audio device on a GPU). The client is assumed
  * to use runtime PM. Beforehand, vga_switcheroo_client_probe_defer()
@@ -339,9 +357,10 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  */
 int 

[V2 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to replace PCI_CLASS_DISPLAY_VGA

[Jim Qu]

Except PCI_CLASS_DISPLAY_VGA, some PCI class is sometimes
PCI_CLASS_DISPLAY_3D or PCI_CLASS_DISPLAY_OTHER.

Signed-off-by: Jim Qu 
---
 sound/pci/hda/hda_intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1ae1850..14733ff 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1429,7 +1429,7 @@ static struct pci_dev *get_bound_vga(struct pci_dev *pci)
p = pci_get_domain_bus_and_slot(pci_domain_nr(pci->bus),
pci->bus->number, 0);
if (p) {
-   if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA)
+   if ((p->class >> 16) == PCI_BASE_CLASS_DISPLAY)
return p;
pci_dev_put(p);
}
-- 
2.7.4

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

[PATCH] drm/vgem: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 0e5620f76ee0..ec6af8b920da 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -504,7 +504,7 @@ static int __init vgem_init(void)
 static void __exit vgem_exit(void)
 {
drm_dev_unregister(_device->drm);
-   drm_dev_unref(_device->drm);
+   drm_dev_put(_device->drm);
 }
 
 module_init(vgem_init);
-- 
2.18.0

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

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Leon Romanovsky]

On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote:
> > > On Wed 27-06-18 09:44:21, Michal Hocko wrote:
> > > > This is the v2 of RFC based on the feedback I've received so far. The
> > > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
> > > > because I have no idea how.
> > > >
> > > > Any further feedback is highly appreciated of course.
> > >
> > > Any other feedback before I post this as non-RFC?
> >
> > From mlx5 perspective, who is primary user of umem_odp.c your change looks 
> > ok.
>
> Can I assume your Acked-by?
>
> Thanks for your review!

For mlx and umem_odp pieces,
Acked-by: Leon Romanovsky 

Thanks


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

nouveau-next - misc fixes/cleanups for 4.19

[Ben Skeggs]

The following changes since commit b861686b18538eaaf3530255eb37b4133146fbe2:

  Merge tag 'vmwgfx-next-4.19-3' of
git://people.freedesktop.org/~thomash/linux into drm-next (2018-07-10
11:13:39 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-4.19

for you to fetch changes up to b59fb482b52269977ee5de205308e5b236a03917:

  drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping (2018-07-16
18:06:36 +1000)


Ben Skeggs (5):
  drm/nouveau/gr/gv100: handle multiple SM-per-TPC for shader exceptions
  drm/nouveau/fault/gv100: fix fault buffer initialisation
  drm/nouveau/core: ERR_PTR vs NULL bug in nvkm_engine_info()
  drm/nouveau/disp/nv50-gp10x: fix coverity warning
  drm/nouveau/kms/nv50-: remove duplicate assignment

Dan Carpenter (1):
  drm/nouveau/hwmon: potential uninitialized variables

Jérôme Glisse (1):
  drm/nouveau/mmu/gp10b: remove ghost file

Karol Herbst (2):
  drm/nouveau/bios/vpstate: There are some fermi vbios with no
boost or tdp entry
  drm/nouveau/debugfs: Wake up GPU before doing any reclocking

Kees Cook (1):
  drm/nouveau/secboot/acr: Remove VLA usage

Lyude Paul (1):
  drm/nouveau: Fix runtime PM leak in drm_open()

Mario Kleiner (1):
  drm/nouveau/kms/nv50-: Allow vblank_disable_immediate

Nick Desaulniers (1):
  drm/nouveau/nvif: remove const attribute from nvif_mclass

Nicolas Chauvet (1):
  drm/nouveau/secboot/tegra: Enable gp20b/gp10b firmware tag when relevant

Thierry Reding (2):
  ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
  drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

Thomas Zimmermann (3):
  drm/nouveau: Replace drm_framebuffer_{un/reference} with put,
get functions
  drm/nouveau: Replace drm_gem_object_unreference_unlocked with put function
  drm/nouveau: Replace drm_dev_unref with drm_dev_put

kbuild test robot (1):
  drm/nouveau/kms/nv50-: fix drm-get-put.cocci warnings

 arch/arm/mm/dma-mapping.c  | 12 +--
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c|  5 -
 drivers/gpu/drm/nouveau/dispnv50/wndw.c|  1 -
 drivers/gpu/drm/nouveau/include/nvif/object.h  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_abi16.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c  |  4 
 drivers/gpu/drm/nouveau/nouveau_display.c  |  8 +++
 drivers/gpu/drm/nouveau/nouveau_drm.c  |  6 --
 drivers/gpu/drm/nouveau/nouveau_fbcon.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c  | 14 ++--
 drivers/gpu/drm/nouveau/nouveau_hwmon.c| 12 +--
 drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
 drivers/gpu/drm/nouveau/nvkm/core/engine.c |  3 ++-
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 +++
 .../gpu/drm/nouveau/nvkm/engine/disp/changf119.c   |  2 +-
 .../gpu/drm/nouveau/nvkm/engine/disp/channv50.c|  4 ++--
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gv100.c | 21 --
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/vpstate.c | 10 +++--
 drivers/gpu/drm/nouveau/nvkm/subdev/fault/base.c   | 10 +++--
 drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c  | 21 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fault/priv.h   |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gp10b. |  0
 .../gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c | 25 +++---
 .../gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c | 16 +-
 .../gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c|  2 ++
 .../gpu/drm/nouveau/nvkm/subdev/secboot/gp10b.c|  2 ++
 27 files changed, 140 insertions(+), 62 deletions(-)
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gp10b.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] Immutable branch between MFD and DRM/i915, Media and Platform due for the v4.19 merge window

[Neil Armstrong]

Hi Dave, Rodrigo.

On 13/07/2018 09:46, Lee Jones wrote:
> Enjoy!
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-i915-media-platform-v4.19
> 
> for you to fetch changes up to cd70de2d356ee692477276bd5d6bc88c71a48733:
> 
>   media: platform: Add ChromeOS EC CEC driver (2018-07-13 08:44:46 +0100)
> 
> 
> Immutable branch between MFD and DRM/i915, Media and Platform due for the 
> v4.19 merge window


This PR is here to solve a complex interdependency over this patchset,
Hans agreed all the media patches go to the MFD tree and Rodrigo acked the i915
patch so it could be applied to another tree,
but who is suposed to take this PR to the DRM tree ?

Neil

> 
> 
> Neil Armstrong (6):
>   media: cec-notifier: Get notifier by device and connector name
>   drm/i915: hdmi: add CEC notifier to intel_hdmi
>   mfd: cros-ec: Increase maximum mkbp event size
>   mfd: cros-ec: Introduce CEC commands and events definitions.
>   mfd: cros_ec_dev: Add CEC sub-device registration
>   media: platform: Add ChromeOS EC CEC driver
> 
>  drivers/gpu/drm/i915/Kconfig |   1 +
>  drivers/gpu/drm/i915/intel_display.h |  24 ++
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_hdmi.c|  13 +
>  drivers/media/cec/cec-notifier.c |  11 +-
>  drivers/media/platform/Kconfig   |  11 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/cros-ec-cec/Makefile  |   1 +
>  drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 
> +++
>  drivers/mfd/cros_ec_dev.c|  16 ++
>  drivers/platform/chrome/cros_ec_proto.c  |  40 ++-
>  include/linux/mfd/cros_ec.h  |   2 +-
>  include/linux/mfd/cros_ec_commands.h |  97 +++
>  include/media/cec-notifier.h |  27 +-
>  14 files changed, 578 insertions(+), 16 deletions(-)
>  create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
>  create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> 

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

Re: [PATCH v13 3/3] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[spanda]

On 2018-06-29 17:31, Andrzej Hajda wrote:

On 27.06.2018 11:57, Sandeep Panda wrote:

Document the bindings used for the sn65dsi86 DSI to eDP bridge.

Changes in v1:
 - Rephrase the dt-binding descriptions to be more inline with 
existing

   bindings (Andrzej Hajda).
 - Add missing dt-binding that are parsed by corresponding driver
   (Andrzej Hajda).

Changes in v2:
 - Remove edp panel specific dt-binding entries. Only keep bridge
   specific entries (Sean Paul).
 - Remove custom-modes dt entry since its usage is removed from driver 
also (Sean Paul).
 - Remove is-pluggable dt entry since this will not be needed anymore 
(Sean Paul).


Changes in v3:
 - Remove irq-gpio dt entry and instead populate is an interrupt
   property (Rob Herring).

Changes in v4:
 - Add link to bridge chip datasheet (Stephen Boyd)
 - Add vpll and vcc regulator supply bindings (Stephen Boyd)
 - Add ref clk optional dt binding (Stephen Boyd)
 - Add gpio-controller optional dt binding (Stephen Boyd)

Changes in v5:
 - Use clock property to specify the input refclk (Stephen Boyd).
 - Update gpio cell and pwm cell numbers (Stephen Boyd).

Changes in v6:
 - Add property to mention the lane mapping scheme and polarity 
inversion

   (Stephen Boyd).

Changes in v7:
 - Detail description of lane mapping scheme dt property (Andrzej
   Hajda/ Rob Herring).
 - Removed HDP gpio binding, since the bridge uses IRQ signal to
   determine HPD, and IRQ property is already documented in binding.

Changes in v8:
 - Removed unnecessary explanation of lane mapping and polarity dt
   property, since these are already explained in 
media/video-interface

   dt binidng (Rob Herring).

Changes in v9:
 - Avoid putting re-definition of lane mapping and polarity dt binding
   (Rob Herring).

Changes in v10:
 - Use interrupts-extended property instead of interrupts to specify
   interrupt line (Andrzej Hajda).
 - Move data-lanes and lane-polarity property example to proper place 
(Andrzej Hajda).


Changes in v11:
 - Add a property for suspend gpio function of GPIO1 pin on bridge 
chip

   (Stephen Boyd).

Signed-off-by: Sandeep Panda 
---
 .../bindings/display/bridge/ti,sn65dsi86.txt   | 89 
++

 1 file changed, 89 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt


diff --git 
a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt

new file mode 100644
index ..6787f5f2c7cd
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt

@@ -0,0 +1,89 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specification for bridge_en pin 
(active high)

+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vpll-supply: A 1.8V supply that powers up the displayport PLL.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+- vcc-supply: A 1.2V supply that powers up the digital core.
+
+Optional properties:
+- interrupts-extended: Specifier for the SN65DSI86 interrupt line.
+
+- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID 
probing


One more thing, I have overlooked: why do you need this property? eDP
panels passes its EDID via DP-AUX channel, do you have some strange
panel?


OK i will remove this property in next patchset.


 I have looked for the panel you want to add in this patchset -

"Innolux TV123WAM" and found nothing, there is TV123WAM made by BOE (it
is the same panel??) and it reports EDID via DP-AUX, no I2C lines for 
DDC.


Regards
Andrzej


+
+- gpio-controller: Marks the device has a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the pin number 
and

+   the second cell is used to specify flags.
+   See ../../gpio/gpio.txt for more information.
+- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description 
of

+   the cell formats.
+
+- clock-names: should be "refclk"
+- clocks: Specification for input reference clock. The reference
+ clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
+
+- data-lanes: See ../../media/video-interface.txt
+- lane-polarities: See ../../media/video-interface.txt
+
+- suspend-gpios: OF device-tree specification for GPIO1 pin on bridge 
(active low)

+
+Required nodes:
+This device has two video ports. Their connections are modelled using 
the
+OF graph bindings specified in 
Documentation/devicetree/bindings/graph.txt.

+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+   compatible = "ti,sn65dsi86";
+   

[PATCH] drm/virtio: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c 
b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
index 7df8d0c9026a..094b876f6da6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
@@ -85,6 +85,6 @@ int drm_virtio_init(struct drm_driver *driver, struct 
virtio_device *vdev)
return 0;
 
 err_free:
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
return ret;
 }
-- 
2.18.0

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

nouveau-fixes 4.18

[Ben Skeggs]

The following changes since commit 1264f8325e9b8c004f36f1ae7bacd2a46a7ed771:

  drm/nouveau/kms/nv50-: cursors always use core channel vram ctxdma
(2018-06-19 10:38:26 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-4.18

for you to fetch changes up to eb493fbc150f4a28151ae1ee84f24395989f3600:

  drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs
(2018-07-16 17:59:59 +1000)


Ben Skeggs (1):
  drm/nouveau/kms/nv50-: ensure window updates are submitted when
flushing mst disables

Dan Carpenter (1):
  drm/nouveau/gem: off by one bugs in nouveau_gem_pushbuf_reloc_apply()

Lyude Paul (5):
  drm/nouveau: Use drm_connector_list_iter_* for iterating connectors
  drm/nouveau: Avoid looping through fake MST connectors
  drm/nouveau/drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()
  drm/nouveau: Remove bogus crtc check in pmops_runtime_idle
  drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs

 drivers/gpu/drm/nouveau/dispnv04/disp.c |  3 ++
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 53 +++--
 drivers/gpu/drm/nouveau/nouveau_backlight.c |  6 ++--
 drivers/gpu/drm/nouveau/nouveau_connector.c |  9 +++--
 drivers/gpu/drm/nouveau/nouveau_connector.h | 36 +---
 drivers/gpu/drm/nouveau/nouveau_display.c   | 10 --
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 18 --
 drivers/gpu/drm/nouveau/nouveau_gem.c   |  4 +--
 8 files changed, 90 insertions(+), 49 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: mali-dp: Call drm_crtc_vblank_reset on device init

[Alexandru Gheorghe]

Currently, if userspace calls drm_wait_vblank before the crtc is
activated the crtc vblank_enable hook is called, which in case of
malidp driver triggers some warninngs. This happens because on
device init we don't inform the drm core about the vblank state
by calling drm_crtc_vblank_on/off/reset which together with
drm_vblank_get have some magic that prevents calling drm_vblank_enable
when crtc is off.

Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/arm/malidp_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4169a72..641d743 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -755,6 +755,7 @@ static int malidp_bind(struct device *dev)
drm->irq_enabled = true;
 
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
+   drm_crtc_vblank_reset(>crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
goto vblank_fail;
-- 
2.7.4

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

[Bug 107153] 4.18-rc3 crash on hdmi (0010:dm_update_crtcs_state+0x41e/0x4a0)

[bugzilla-daemon]

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

--- Comment #11 from Patrik Kullman  ---
No updates in rc5 looking at "git log v4.18-rc4..v4.18-rc5
drivers/gpu/drm/amd/", but I'll try it out anyway once it's available at
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18-rc5/

-- 
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 2/3 v5] ARM: defconfig: Update the vexpress defconfig

[Linus Walleij]

Update the Versatile Express defconfig to match the
Kconfig changes in the kernel.

Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Signed-off-by: Linus Walleij 
---
ChangeLog v4->v5:
- Resending.
ChangeLog v3->v4:
- Resending.
ChangeLog v1->v3:
- Rebased
---
 arch/arm/configs/vexpress_defconfig | 12 
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/configs/vexpress_defconfig 
b/arch/arm/configs/vexpress_defconfig
index edae1c58fe80..226fe4bfb487 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -21,20 +21,17 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_ARCH_VEXPRESS=y
 CONFIG_ARCH_VEXPRESS_DCSCB=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
-# CONFIG_SWP_EMULATE is not set
 CONFIG_SMP=y
 CONFIG_HAVE_ARM_ARCH_TIMER=y
 CONFIG_MCPM=y
 CONFIG_VMSPLIT_2G=y
 CONFIG_NR_CPUS=8
 CONFIG_ARM_PSCI=y
-CONFIG_AEABI=y
 CONFIG_CMA=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="console=ttyAMA0"
 CONFIG_CPU_IDLE=y
-CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
@@ -61,7 +58,6 @@ CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_MTD_PLATRAM=y
 CONFIG_MTD_UBI=y
-CONFIG_PROC_DEVICETREE=y
 CONFIG_VIRTIO_BLK=y
 # CONFIG_SCSI_PROC_FS is not set
 CONFIG_BLK_DEV_SD=y
@@ -85,7 +81,6 @@ CONFIG_HW_RANDOM_VIRTIO=y
 CONFIG_I2C=y
 CONFIG_I2C_VERSATILE=y
 CONFIG_SENSORS_VEXPRESS=y
-CONFIG_REGULATOR=y
 CONFIG_REGULATOR_VEXPRESS=y
 CONFIG_FB=y
 CONFIG_FB_ARMCLCD=y
@@ -95,8 +90,6 @@ CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_VGA16 is not set
 CONFIG_SOUND=y
 CONFIG_SND=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
 # CONFIG_SND_DRIVERS is not set
 CONFIG_SND_ARMAACI=y
 CONFIG_HID_DRAGONRISE=y
@@ -133,9 +126,6 @@ CONFIG_VIRTIO_MMIO=y
 CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-# CONFIG_EXT3_FS_XATTR is not set
-CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
 CONFIG_JFFS2_FS=y
@@ -149,11 +139,9 @@ CONFIG_9P_FS=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_DEBUG_INFO=y
-CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_KERNEL=y
 CONFIG_DETECT_HUNG_TASK=y
 # CONFIG_SCHED_DEBUG is not set
 CONFIG_DEBUG_USER=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
 # CONFIG_CRYPTO_HW is not set
-- 
2.17.0

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

[PATCH 3/3 v5] ARM: defconfig: Enable the PL111 DRM driver on vexpress

[Linus Walleij]

This updates the Versatile defconfig to use the new P111 DRM
driver that is merged in the DRM subsystem.

We deactivate the old CLCD driver and activate the Pl111 DRM
driver and the SiI9022 HDMI bridge.

We activate DMA memory allocation using CMA so that the special
graphics memory for the on-board CLCD can be used.

Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Signed-off-by: Linus Walleij 
---
ChangeLog v4->v5:
- Resending.
ChangeLog v3->v4:
- Resending.
ChangeLog v1->v3:
- Rebased
---
 arch/arm/configs/vexpress_defconfig | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/configs/vexpress_defconfig 
b/arch/arm/configs/vexpress_defconfig
index 226fe4bfb487..392ed3b3613c 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -48,6 +48,7 @@ CONFIG_NET_9P=y
 CONFIG_NET_9P_VIRTIO=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
+CONFIG_DMA_CMA=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y
@@ -78,13 +79,16 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
 CONFIG_VIRTIO_CONSOLE=y
 CONFIG_HW_RANDOM=y
 CONFIG_HW_RANDOM_VIRTIO=y
-CONFIG_I2C=y
 CONFIG_I2C_VERSATILE=y
 CONFIG_SENSORS_VEXPRESS=y
 CONFIG_REGULATOR_VEXPRESS=y
-CONFIG_FB=y
-CONFIG_FB_ARMCLCD=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_DRM=y
+CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_SII902X=y
+CONFIG_DRM_PL111=y
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_VGA16 is not set
-- 
2.17.0

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

[PATCH 1/3 v5] ARM: dts: Modernize the Vexpress PL111 integration

[Linus Walleij]

The Versatile Express was submitted with the actual display
bridges unconnected (but defined in the device tree) and
mock "panels" encoded in the device tree node of the PL111
controller.

This doesn't even remotely describe the actual Versatile
Express hardware. Exploit the SiI9022 bridge by connecting
the PL111 pads to it, making it use EDID or fallback values
to drive the monitor.

The  also has to use the reserved memory through the
CMA pool rather than by open coding a memory region and
remapping it explicitly in the driver. To achieve this,
a reserved-memory node must exist in the root of the
device tree, so we need to pull that out of the
motherboard .dtsi include files, and push it into each
top-level device tree instead.

We do the same manouver for all the Versatile Express
boards, taking into account the different location of the
video RAM depending on which chip select is used on
each platform.

This plays nicely with the new PL111 DRM driver and
follows the standard ways of assigning bridges and
memory pools for graphics.

Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Liviu Dudau 
Cc: Mali DP Maintainers 
Cc: Robin Murphy 
Signed-off-by: Linus Walleij 
---
ChangeLog v4->v5:
- Fix up the RTSMv8 AEM VE by using the new simple VGA
  panel I invented in the DRI simple panel.
- NOTE: This patch depends at runtime on the DRM simple
  panel patch "drm/panel: simple: Support simple VGA panels"
ChangeLog v3->v4:
- Fix the ARM and ARM64 shared vexpress-v2m-rc1.dtsi
  file address-cells etc so that the ports do not give
  DTC warnings anymore.
- Fixed up the CA53 DTS: use the right chip select base
  at 0x1800.
- Fixed up the Real-Time Systems Models Virtual Executive
  RTSMv8 AEM VE:
  - Added the I2C interface (whether implemented in the
emulator or not)
  - Fixed the chip select of the memory node to the right
memory base 0x1800.
- Add right address-cells and size-cells to the
  vexpress-v2m.dtsi dvi port as well.
- Create two endpoints for the motherboard and the
  core tile in the vexpress-v2m.dtsi. This is just used
  by the CA9 VExpress. Tested on both QEMU and the
  actual hardware with the DRM driver. This removes the
  last warnings from the DTC.
ChangeLog v2->v3:
- Add some reg = <0>; to the ports to make the DTC happy.
- Add reserved memory node to
  arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
  as well.
ChangeLog v1->v2:
- Fix up the memory address for the -rs1 tiles to 0x1800
- Drop a bunch of extraneous reg props from the DVI adapter
---
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi   | 49 +--
 arch/arm/boot/dts/vexpress-v2m.dtsi   | 63 +--
 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts   | 14 +
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 14 +
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts   | 14 +
 arch/arm/boot/dts/vexpress-v2p-ca9.dts| 43 ++---
 arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 27 
 .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 ++-
 .../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 14 +
 9 files changed, 154 insertions(+), 121 deletions(-)

diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi 
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 4488c8fe213a..a9569d15de41 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -43,11 +43,6 @@
bank-width = <4>;
};
 
-   v2m_video_ram: vram@2, {
-   compatible = "arm,vexpress-vram";
-   reg = <2 0x 0x0080>;
-   };
-
ethernet@2,0200 {
compatible = "smsc,lan9118", "smsc,lan9115";
reg = <2 0x0200 0x1>;
@@ -223,13 +218,24 @@
v2m_i2c_dvi: i2c@16 {
compatible = "arm,versatile-i2c";
reg = <0x16 0x1000>;
-
#address-cells = <1>;
#size-cells = <0>;
 
dvi-transmitter@39 {
compatible = "sil,sii9022-tpi", 
"sil,sii9022";
reg = <0x39>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dvi_bridge_in: 
endpoint {
+   
remote-endpoint = <_pads>;
+  

[Bug 107229] Metro 2033 Redux hangs

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
(In reply to Alexander Tsoy from comment #0)
> 
> linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=y = OK
> linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=n + mesa-8.0.x / mesa-8.1.x =
> hang

Did you swap CONFIG_TRANSPARENT_HUGEPAGE=y/n here? I.e.
CONFIG_TRANSPARENT_HUGEPAGE=y is bad, CONFIG_TRANSPARENT_HUGEPAGE=n is good?

If not, how exactly did you bisect with CONFIG_TRANSPARENT_HUGEPAGE=y ?

-- 
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 v3] drm: mali-dp: Set encoder possible_clones

[Alexandru Gheorghe]

Set possible_clones field to report that the writeback connector and
the one driving the display could be enabled at the same time.

Signed-off-by: Alexandru Gheorghe 

Changes since v2:
  - Use proper style for multi-line comments.
---
 drivers/gpu/drm/arm/malidp_drv.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 5b72605..4169a72 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -616,6 +616,7 @@ static int malidp_bind(struct device *dev)
struct malidp_hw_device *hwdev;
struct platform_device *pdev = to_platform_device(dev);
struct of_device_id const *dev_id;
+   struct drm_encoder *encoder;
/* number of lines for the R, G and B output */
u8 output_width[MAX_OUTPUT_CHANNELS];
int ret = 0, i;
@@ -737,6 +738,16 @@ static int malidp_bind(struct device *dev)
goto bind_fail;
}
 
+   /*
+* We expect to have a maximum of two encoders one for the actual
+* display and a virtual one for the writeback connector
+*/
+   WARN_ON(drm->mode_config.num_encoder > 2);
+   list_for_each_entry(encoder, >mode_config.encoder_list, head) {
+   encoder->possible_clones =
+   (1 << drm->mode_config.num_encoder) -  1;
+   }
+
ret = malidp_irq_init(pdev);
if (ret < 0)
goto irq_init_fail;
-- 
2.7.4

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

[Bug 107229] Metro 2033 Redux hangs

[bugzilla-daemon]

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

--- Comment #6 from Alexander Tsoy  ---
(In reply to Alexander Tsoy from comment #5)
> To clarify a bit: first bad commit in bisect is actually the first good
> commit that fixed hangs in Metro.
But only when transparent huge pages are enabled of course.

-- 
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 107229] Metro 2033 Redux hangs

[bugzilla-daemon]

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

--- Comment #5 from Alexander Tsoy  ---
To clarify a bit: first bad commit in bisect is actually the first good commit
that fixed hangs in Metro.

-- 
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 RESEND] drm/meson: Make DMT timings parameters and pixel clock generic

[Neil Armstrong]

On 16/07/2018 10:36, Jerome Brunet wrote:
> On Mon, 2018-07-16 at 09:40 +0200, Neil Armstrong wrote:
>> Remove the modes timings tables for DMT modes and calculate the HW
>> paremeters from the modes timings.
>>
>> Switch the DMT modes pixel clock calculation out of the static frequency
>> list to a generic calculation from a range of possible PLL dividers.
>>
>> This patch is an intermediate step towards usage of the Common Clock
>> Framwework for PLL setup, by reworking the code to have common
>> sel_pll() function called by the CEA (HDMI) freq setup and the generic
>> DMT frequencies setup, we should be able to simply call clk_set_rate()
>> on the PLL clock handle in a near future.
>>
>> The CEA (HDMI) and CVBS modes needs very specific clock paths that CCF will
>> never be able to determine by itself, so there is still some work to do for
>> a full handoff to CCF handling the clocks.
> 
> Patch seems to be a good step forward making the display compatible with CCF
> indeed. While full automatic handling through CCF might not possible, it would
> be good if, someday,  we could handle the SoC quirks in CCF, removing the need
> check is the SoC is gxbb, gxl or gxm while setting the clocks.
> 
> If the display driver needs a detailed control over the clock setup, maybe we
> could solve the problem by exporting the intermediate clock elements in CCF
> (such as muxes, ODs, etc...) and let the display driver claim them all ?
> 
> Anyway, the situation is improving so:
> Acked-by: Jerome Brunet 
> 
>>
>> This setup permits setting non-CEA modes like :
>> - 1600x900-60Hz
>> - 1280x1024-75Hz
>> - 1280x1024-60Hz
>> - 1440x900-60Hz
>> - 1366x768-60Hz
>> - 1280x800-60Hz
>> - 1152x864-75Hz
>> - 1024x768-75Hz
>> - 1024x768-70Hz
>> - 1024x768-60Hz
>> - 832x624-75Hz
>> - 800x600-75Hz
>> - 800x600-72Hz
>> - 800x600-60Hz
>> - 640x480-75Hz
>> - 640x480-73Hz
>> - 640x480-67Hz
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/meson/meson_dw_hdmi.c |  22 +-
>>  drivers/gpu/drm/meson/meson_vclk.c| 672 
>> +++---
>>  drivers/gpu/drm/meson/meson_vclk.h|   4 +
>>  drivers/gpu/drm/meson/meson_venc.c| 377 +++
>>  drivers/gpu/drm/meson/meson_venc.h|   3 +-
>>  5 files changed, 358 insertions(+), 720 deletions(-)
>>
[...]


Applied to drm-misc-next with some trivial checkpatch fixes.

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

[Bug 200499] amdgpu: kfd: kgd2kfd_probe failed, Ryzen 2400G

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Patches adding Raven Ridge support are currently being reviewed:
https://patchwork.freedesktop.org/series/46440/

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

Re: [PATCH] drm/vgem: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

Hi

> There are other gpu/drm drivers where drm_dev_unref is used.
> Do we need to replace drm_dev_unref with drm_dev_put  in
> other places as well ?

Yes. This is some overall clean-up work that I do as a side project. I
already have patches for all drivers, but I found that sending them
one-by-one gives a much better chance of getting them applied.

Best regards
Thomas

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755;  https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)



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

[PATCH] drm/panel: simple: Support simple VGA panels

[Linus Walleij]

The need to support some straight-forward VGA panels that are
not adhering to any standard like DPI arise in the ARM RTSM VE
Real-Time Systems Model Virtual Executive. This emulator (which
is not QEMU) does not model any bridge or panel other than
displaying whatever the user defines that they have.

Currently a fake "DPI panel" is used for this with the old
FBDEV driver, but this is wrong as it is not conforming to any
MIPI DPI standards. However the resolution chosen there is
standard VGA, and we can cover this with the simple panel
by simply adding the most common VGA resolutions as a kind
of "simple panel".

In difference from other cases where "simple panel" might be
hiding something more complex (such as a panel driver or bridge)
this case is actually applicable, since we are running inside
a simulation with no real hardware on the output.

Cc: devicet...@vger.kernel.org
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Liviu Dudau 
Cc: Robin Murphy 
Signed-off-by: Linus Walleij 
---
 .../display/panel/video-graphics-array.txt| 21 ++
 drivers/gpu/drm/panel/panel-simple.c  | 66 +++
 2 files changed, 87 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt 
b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt
new file mode 100644
index ..193d24ebe052
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt
@@ -0,0 +1,21 @@
+Video Graphics Array
+
+This binding is for simple panels using the standardized VGA resolutions
+defined by de facto standards beginning with the IBM PS/2 in 1987.
+
+Required properties:
+- compatible: should be "video-graphics-array"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Example:
+
+panel {
+   compatible = "video-graphics-array";
+   port {
+   vga_panel_in: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+};
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..db4db5a3f75e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2069,6 +2069,69 @@ static const struct panel_desc winstar_wf35ltiacd = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct drm_display_mode video_graphics_array_modes[] = {
+   {
+   /*
+* This is the most standardized "vanilla" VGA mode there is:
+* 640x480 @ 60 Hz
+*/
+   .clock = 27175,
+   .hdisplay = 640,
+   .hsync_start = 640 + 16,
+   .hsync_end = 640 + 16 + 96,
+   .htotal = 640 + 16 + 96 + 48,
+   .vdisplay = 480,
+   .vsync_start = 480 + 10,
+   .vsync_end = 480 + 10 + 2,
+   .vtotal = 480 + 10 + 2 + 33,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+   },
+   {
+   /* SVGA 800x600 @60 Hz */
+   .clock = 4,
+   .hdisplay = 800,
+   .hsync_start = 800 + 40,
+   .hsync_end = 800 + 40 + 128,
+   .htotal = 800 + 40 + 128 + 88,
+   .vdisplay = 600,
+   .vsync_start = 600 + 1,
+   .vsync_end = 600 + 1 + 4,
+   .vtotal = 600 + 1 + 4 + 23,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+   },
+   {
+   /* XGA 1024x768 @60 Hz */
+   .clock = 65000,
+   .hdisplay = 1024,
+   .hsync_start = 1024 + 24,
+   .hsync_end = 1024 + 24 + 136,
+   .htotal = 1024 + 24 + 136 + 160,
+   .vdisplay = 768,
+   .vsync_start = 768 + 3,
+   .vsync_end = 768 + 3 + 6,
+   .vtotal = 768 + 3 + 6 + 29,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+   },
+};
+
+static const struct panel_desc video_graphics_array = {
+   .modes = video_graphics_array_modes,
+   .num_modes = ARRAY_SIZE(video_graphics_array_modes),
+   .bpc = 8,
+   /*
+* Some typical 4:3 aspect ratio VGA monitor surely has these dimensions
+* of 40x30 mm.
+*/
+   .size = {
+   .width = 400,
+   .height = 300,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am-480272h3tmqw-t01h",
@@ -2286,6 +2349,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "winstar,wf35ltiacd",
   

[Bug 107229] Metro 2033 Redux hangs

[bugzilla-daemon]

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

--- Comment #4 from Alexander Tsoy  ---
(In reply to Michel Dänzer from comment #3)
> (In reply to Alexander Tsoy from comment #0)
> > 
> > linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=y = OK
> > linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=n + mesa-8.0.x / mesa-8.1.x =
> > hang
> 
> Did you swap CONFIG_TRANSPARENT_HUGEPAGE=y/n here? I.e.
> CONFIG_TRANSPARENT_HUGEPAGE=y is bad, CONFIG_TRANSPARENT_HUGEPAGE=n is good?

Yes, after getting a clue that this bug could be related to transparent huge
pages, I tried to disable CONFIG_TRANSPARENT_HUGEPAGE in 4.17.6 kernel. This
results in the same hang I had with 4.14.x kernels.

Note that transparent huge pages must be disabled at build time. cmdline option
" transparent_hugepage=never" doesn't change anything.

-- 
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 200517] New: Vega 8/Radeon 535 hybrid graphics - amdgpu crash on modesetting

[bugzilla-daemon]

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

Bug ID: 200517
   Summary: Vega 8/Radeon 535 hybrid graphics - amdgpu crash on
modesetting
   Product: Drivers
   Version: 2.5
Kernel Version: 4.18.0rc5
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: bakarichar...@gmail.com
Regression: No

Created attachment 277363
  --> https://bugzilla.kernel.org/attachment.cgi?id=277363=edit
dmesg

Notebook: Acer A315-41G-*

4.* kernels start only using these parameters:
amdgpu.runpm=0 radeon.modeset=0 or compiled without VGA switcheroo.

lspci and dmesg attached

Even with these parameters significant heating occurs however this can be fixed
by running "sudo echo OFF > /sys/kernel/debug/vgaswitcheroo/switch" command.

It would be the best if both of them worked correctly like on win10.

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

[PATCH 1/5] drm/nouveau: Prevent RPM callback recursion in suspend/resume paths

[Lyude Paul]

In order to fix all of the spots that need to have runtime PM get/puts()
added, we need to ensure that it's possible for us to call
pm_runtime_get/put() in any context, regardless of how deep, since
almost all of the spots that are currently missing refs can potentially
get called in the runtime suspend/resume path. Otherwise, we'll try to
resume the GPU as we're trying to resume the GPU (and vice-versa) and
cause the kernel to deadlock.

With this, it should be safe to call the pm runtime functions in any
context in nouveau with one condition: any point in the driver that
calls pm_runtime_get*() cannot hold any locks owned by nouveau that
would be acquired anywhere inside nouveau_pmops_runtime_resume().
This includes modesetting locks, i2c bus locks, etc.

Signed-off-by: Lyude Paul 
Cc: Karol Herbst 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c7ec86d6c3c9..e851ef7b6373 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -835,6 +835,8 @@ nouveau_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
 
+   dev->power.disable_depth++;
+
drm_kms_helper_poll_disable(drm_dev);
nouveau_switcheroo_optimus_dsm();
ret = nouveau_do_suspend(drm_dev, true);
@@ -843,6 +845,8 @@ nouveau_pmops_runtime_suspend(struct device *dev)
pci_ignore_hotplug(pdev);
pci_set_power_state(pdev, PCI_D3cold);
drm_dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF;
+
+   dev->power.disable_depth--;
return ret;
 }
 
@@ -859,11 +863,13 @@ nouveau_pmops_runtime_resume(struct device *dev)
return -EBUSY;
}
 
+   dev->power.disable_depth++;
+
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
ret = pci_enable_device(pdev);
if (ret)
-   return ret;
+   goto out;
pci_set_master(pdev);
 
ret = nouveau_do_resume(drm_dev, true);
@@ -875,6 +881,8 @@ nouveau_pmops_runtime_resume(struct device *dev)
/* Monitors may have been connected / disconnected during suspend */
schedule_work(_drm(drm_dev)->hpd_work);
 
+out:
+   dev->power.disable_depth--;
return ret;
 }
 
-- 
2.17.1

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

[PATCH 2/5] drm/nouveau: Grab RPM ref while probing outputs

[Lyude Paul]

When DP MST hubs get confused, they can occasionally stop responding for
a good bit of time up until the point where the DRM driver manages to
do the right DPCD accesses to get it to start responding again. In a
worst case scenario however, this process can take upwards of 10+
seconds.

Currently we use the default output_poll_changed handler
drm_fb_helper_output_poll_changed() to handle output polling, which
doesn't happen to grab any power references on the device when polling.
If we're unlucky enough to have a hub (such as Lenovo's infamous laptop
docks for the P5x/P7x series) that's easily startled and confused, this
can lead to a pretty nasty deadlock situation that looks like this:

- Hotplug event from hub happens, we enter
  drm_fb_helper_output_poll_changed() and start communicating with the
  hub
- While we're in drm_fb_helper_output_poll_changed() and attempting to
  communicate with the hub, we end up confusing it and cause it to stop
  responding for at least 10 seconds
- After 5 seconds of being in drm_fb_helper_output_poll_changed(), the
  pm core attempts to put the GPU into autosuspend, which ends up
  calling drm_kms_helper_poll_disable()
- While the runtime PM core is waiting in drm_kms_helper_poll_disable()
  for the output poll to finish, we end up finally detecting an MST
  display
- We notice the new display and tries to enable it, which triggers
  an atomic commit which triggers a call to pm_runtime_get_sync()
- the output poll thread deadlocks the pm core waiting for the pm core
  to finish the autosuspend request while the pm core waits for the
  output poll thread to finish

Sample:
[  246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds.
[  246.673398]   Not tainted 4.18.0-rc5Lyude-Test+ #2
[  246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  246.676527] kworker/4:0 D037  2 0x8000
[  246.677580] Workqueue: events output_poll_execute [drm_kms_helper]
[  246.678704] Call Trace:
[  246.679753]  __schedule+0x322/0xaf0
[  246.680916]  schedule+0x33/0x90
[  246.681924]  schedule_preempt_disabled+0x15/0x20
[  246.683023]  __mutex_lock+0x569/0x9a0
[  246.684035]  ? kobject_uevent_env+0x117/0x7b0
[  246.685132]  ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
[  246.686179]  mutex_lock_nested+0x1b/0x20
[  246.687278]  ? mutex_lock_nested+0x1b/0x20
[  246.688307]  drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
[  246.689420]  drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper]
[  246.690462]  drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper]
[  246.691570]  output_poll_execute+0x198/0x1c0 [drm_kms_helper]
[  246.692611]  process_one_work+0x231/0x620
[  246.693725]  worker_thread+0x214/0x3a0
[  246.694756]  kthread+0x12b/0x150
[  246.695856]  ? wq_pool_ids_show+0x140/0x140
[  246.696888]  ? kthread_create_worker_on_cpu+0x70/0x70
[  246.697998]  ret_from_fork+0x3a/0x50
[  246.699034] INFO: task kworker/0:1:60 blocked for more than 120 seconds.
[  246.700153]   Not tainted 4.18.0-rc5Lyude-Test+ #2
[  246.701182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  246.702278] kworker/0:1 D060  2 0x8000
[  246.703293] Workqueue: pm pm_runtime_work
[  246.704393] Call Trace:
[  246.705403]  __schedule+0x322/0xaf0
[  246.706439]  ? wait_for_completion+0x104/0x190
[  246.707393]  schedule+0x33/0x90
[  246.708375]  schedule_timeout+0x3a5/0x590
[  246.709289]  ? mark_held_locks+0x58/0x80
[  246.710208]  ? _raw_spin_unlock_irq+0x2c/0x40
[  246.711222]  ? wait_for_completion+0x104/0x190
[  246.712134]  ? trace_hardirqs_on_caller+0xf4/0x190
[  246.713094]  ? wait_for_completion+0x104/0x190
[  246.713964]  wait_for_completion+0x12c/0x190
[  246.714895]  ? wake_up_q+0x80/0x80
[  246.715727]  ? get_work_pool+0x90/0x90
[  246.716649]  flush_work+0x1c9/0x280
[  246.717483]  ? flush_workqueue_prep_pwqs+0x1b0/0x1b0
[  246.718442]  __cancel_work_timer+0x146/0x1d0
[  246.719247]  cancel_delayed_work_sync+0x13/0x20
[  246.720043]  drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper]
[  246.721123]  nouveau_pmops_runtime_suspend+0x3d/0xb0 [nouveau]
[  246.721897]  pci_pm_runtime_suspend+0x6b/0x190
[  246.722825]  ? pci_has_legacy_pm_support+0x70/0x70
[  246.723737]  __rpm_callback+0x7a/0x1d0
[  246.724721]  ? pci_has_legacy_pm_support+0x70/0x70
[  246.725607]  rpm_callback+0x24/0x80
[  246.726553]  ? pci_has_legacy_pm_support+0x70/0x70
[  246.727376]  rpm_suspend+0x142/0x6b0
[  246.728185]  pm_runtime_work+0x97/0xc0
[  246.728938]  process_one_work+0x231/0x620
[  246.729796]  worker_thread+0x44/0x3a0
[  246.730614]  kthread+0x12b/0x150
[  246.731395]  ? wq_pool_ids_show+0x140/0x140
[  246.732202]  ? kthread_create_worker_on_cpu+0x70/0x70
[  246.732878]  ret_from_fork+0x3a/0x50
[  246.733768] INFO: task kworker/4:2:422 blocked for more than 120 seconds.
[  246.734587]   Not tainted 4.18.0-rc5Lyude-Test+ #2
[  246.735393] "echo 0 

[PATCH 4/5] drm/nouveau: Grab RPM ref when i2c bus is in use

[Lyude Paul]

The i2c bus can be both accessed by DRM itself, along with any of it's
devnodes (/sys/class/i2c). So, we need to make sure that all codepaths
using the i2c bus keep the GPU resumed.

Signed-off-by: Lyude Paul 
Cc: Karol Herbst 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c
index 807a2b67bd64..1de48c990b80 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c
@@ -119,18 +119,28 @@ nvkm_i2c_bus_release(struct nvkm_i2c_bus *bus)
BUS_TRACE(bus, "release");
nvkm_i2c_pad_release(pad);
mutex_unlock(>mutex);
+   pm_runtime_put_autosuspend(pad->i2c->subdev.device->dev);
 }
 
 int
 nvkm_i2c_bus_acquire(struct nvkm_i2c_bus *bus)
 {
struct nvkm_i2c_pad *pad = bus->pad;
+   struct device *dev = pad->i2c->subdev.device->dev;
int ret;
+
BUS_TRACE(bus, "acquire");
+
+   ret = pm_runtime_get_sync(dev);
+   if (ret < 0 && ret != -EACCES)
+   return ret;
+
mutex_lock(>mutex);
ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_I2C);
-   if (ret)
+   if (ret) {
mutex_unlock(>mutex);
+   pm_runtime_put_autosuspend(dev);
+   }
return ret;
 }
 
-- 
2.17.1

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

[PATCH 3/5] drm/nouveau: Add missing RPM get/put() when probing connectors

[Lyude Paul]

While the GPU is guaranteed to be on when a hotplug has been received,
the same assertion does not hold true if a connector probe has been
started by userspace without having had received a sysfs event. So
ensure that any connector probing keeps the GPU alive for the duration
of the probe.

Signed-off-by: Lyude Paul 
Cc: Karol Herbst 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c | 21 +++--
 drivers/gpu/drm/nouveau/nouveau_connector.h |  3 +++
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index ea2a886854fe..0f283ca75189 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -858,7 +858,7 @@ static const struct drm_connector_funcs
 nv50_mstc = {
.reset = nouveau_conn_reset,
.detect = nv50_mstc_detect,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = nouveau_connector_probe_single_connector_modes,
.destroy = nv50_mstc_destroy,
.atomic_duplicate_state = nouveau_conn_atomic_duplicate_state,
.atomic_destroy_state = nouveau_conn_atomic_destroy_state,
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 2a45b4c2ceb0..feb142fb7a8a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -770,6 +770,23 @@ nouveau_connector_force(struct drm_connector *connector)
nouveau_connector_set_encoder(connector, nv_encoder);
 }
 
+int
+nouveau_connector_probe_single_connector_modes(struct drm_connector *connector,
+  uint32_t maxX, uint32_t maxY)
+{
+   struct device *dev = connector->dev->dev;
+   int ret;
+
+   ret = pm_runtime_get_sync(dev);
+   if (WARN_ON(ret < 0 && ret != -EACCES))
+   return 0;
+
+   ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
+
+   pm_runtime_put_autosuspend(dev);
+   return ret;
+}
+
 static int
 nouveau_connector_set_property(struct drm_connector *connector,
   struct drm_property *property, uint64_t value)
@@ -1088,7 +1105,7 @@ nouveau_connector_funcs = {
.reset = nouveau_conn_reset,
.detect = nouveau_connector_detect,
.force = nouveau_connector_force,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = nouveau_connector_probe_single_connector_modes,
.set_property = nouveau_connector_set_property,
.destroy = nouveau_connector_destroy,
.atomic_duplicate_state = nouveau_conn_atomic_duplicate_state,
@@ -1103,7 +1120,7 @@ nouveau_connector_funcs_lvds = {
.reset = nouveau_conn_reset,
.detect = nouveau_connector_detect_lvds,
.force = nouveau_connector_force,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = nouveau_connector_probe_single_connector_modes,
.set_property = nouveau_connector_set_property,
.destroy = nouveau_connector_destroy,
.atomic_duplicate_state = nouveau_conn_atomic_duplicate_state,
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index 2d9d35a146a4..e9ffc6eebda2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -106,6 +106,9 @@ nouveau_crtc_connector_get(struct nouveau_crtc *nv_crtc)
 
 struct drm_connector *
 nouveau_connector_create(struct drm_device *, const struct dcb_output *);
+int
+nouveau_connector_probe_single_connector_modes(struct drm_connector *,
+  uint32_t, uint32_t);
 
 extern int nouveau_tv_disable;
 extern int nouveau_ignorelid;
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH v6 09/35] drm/i915: Initialize HDCP2.2 and its MEI interface

[kbuild test robot]

Hi Ramalingam,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.18-rc4 next-20180713]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180714-204349
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce: make htmldocs
:: branch date: 5 hours ago
:: commit date: 5 hours ago

All warnings (new ones prefixed by >>):

   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg.signal' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg.chain_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.filtered' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.retry_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.retry_count' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.lost_packets' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_tdls_pkt_time' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.msdu_retries' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.msdu_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_ack' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_ack_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.ack_signal_filled' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'tx_stats.packets' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'tx_stats.bytes' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'tx_stats.last_rate' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'tx_stats.msdu' not described in 'sta_info'
   kernel/sched/fair.c:3731: warning: Function parameter or member 'flags' not 
described in 'attach_entity_load_avg'
   include/linux/dma-buf.h:307: warning: Function parameter or member 
'cb_excl.cb' not described in 'dma_buf'
   include/linux/dma-buf.h:307: warning: Function parameter or member 
'cb_excl.poll' not described in 'dma_buf'
   include/linux/dma-buf.h:307: warning: Function parameter or member 
'cb_excl.active' not described in 'dma_buf'
  

[Bug 200517] Vega 8/Radeon 535 hybrid graphics - amdgpu crash on modesetting

[bugzilla-daemon]

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

--- Comment #1 from bakarichar...@gmail.com ---
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15d0
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 15d1
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models
00h-0fh) PCIe Dummy Host Bridge
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15d3
00:01.6 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15d3
00:01.7 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15d3
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models
00h-0fh) PCIe Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15db
00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 15dc
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15e8
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15e9
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ea
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15eb
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ec
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ed
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ee
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15ef
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT
[Radeon R7 M260/M265 / M340/M360 / M440/M445] (rev d1)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI
Express Card Reader (rev 01)
02:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
PCI Express Gigabit Ethernet Controller (rev 12)
03:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network
Adapter (rev 31)
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega
[Radeon Vega 8 Mobile] (rev c4)
04:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 15de
04:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 15df
04:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15e0
04:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15e1
04:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Device 15e3
05:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller
[AHCI mode] (rev 61)

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

[PATCH 5/5] drm/nouveau: Grab RPM ref when aux bus is in use

[Lyude Paul]

DP AUX busses can both be accessed by DRM, and through any of the
userspace dev nodes in /dev/drm_dp_auxN. We need to make sure the GPU
stays on in all of these codepaths.

Signed-off-by: Lyude Paul 
Cc: Karol Herbst 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
index 4c1f547da463..6276b113065c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
@@ -98,18 +98,28 @@ nvkm_i2c_aux_release(struct nvkm_i2c_aux *aux)
AUX_TRACE(aux, "release");
nvkm_i2c_pad_release(pad);
mutex_unlock(>mutex);
+   pm_runtime_put_autosuspend(pad->i2c->subdev.device->dev);
 }
 
 int
 nvkm_i2c_aux_acquire(struct nvkm_i2c_aux *aux)
 {
struct nvkm_i2c_pad *pad = aux->pad;
+   struct device *dev = pad->i2c->subdev.device->dev;
int ret;
+
AUX_TRACE(aux, "acquire");
+
+   ret = pm_runtime_get_sync(dev);
+   if (ret < 0 && ret != -EACCES)
+   return ret;
+
mutex_lock(>mutex);
ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_AUX);
-   if (ret)
+   if (ret) {
mutex_unlock(>mutex);
+   pm_runtime_put_autosuspend(dev);
+   }
return ret;
 }
 
-- 
2.17.1

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

[PATCH 0/5] drm/nouveau: Fix a lot of nasty RPM bugs and deadlocks

[Lyude Paul]

This fixes quite a number of runtime PM bugs I found that have been
causing some pretty nasty issues such as:
 - Deadlocking on boot
 - Connector probing potentially not working while the GPU is in runtime
   suspend
 - i2c char dev not working while the GPU is in runtime suspend
 - aux char dev not working while the GPU is in runtime suspend

There's definitely more parts of nouveau that need to be fixed to use
runtime power management correctly, such as the hwmon portions, but this
series just handles the more important fixes that should get into stable
for the time being.

Cc: Karol Herbst 
Cc: sta...@vger.kernel.org

Lyude Paul (5):
  drm/nouveau: Prevent RPM callback recursion in suspend/resume paths
  drm/nouveau: Grab RPM ref while probing outputs
  drm/nouveau: Add missing RPM get/put() when probing connectors
  drm/nouveau: Grab RPM ref when i2c bus is in use
  drm/nouveau: Grab RPM ref when aux bus is in use

 drivers/gpu/drm/nouveau/dispnv50/disp.c   | 12 +--
 drivers/gpu/drm/nouveau/nouveau_connector.c   | 21 +--
 drivers/gpu/drm/nouveau/nouveau_connector.h   |  3 +++
 drivers/gpu/drm/nouveau/nouveau_drm.c | 10 -
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 12 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 12 ++-
 6 files changed, 63 insertions(+), 7 deletions(-)

-- 
2.17.1

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

[radeon-alex:amd-staging-drm-next 5/6] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:465:44: sparse: incorrect type in argument 1 (different address spaces)

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   d0987b4ee380e9d814052071c939b38a74a34ab1
commit: 4771bffd00cf57702e4bea3a1b08fe9a9ea78abd [5/6] drm/amdgpu/pp/smu7: 
cache smu firmware toc
reproduce:
# apt-get install sparse
git checkout 4771bffd00cf57702e4bea3a1b08fe9a9ea78abd
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
:: branch date: 22 hours ago
:: commit date: 22 hours ago

   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:65:25: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:65:25: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:65:25: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:65:25: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:65:25: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:65:25: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:74:26: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:74:26: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:74:26: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:74:26: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:74:26: sparse: 
cast to restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:74:26: sparse: 
cast to restricted __be32
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:465:44: sparse: 
>> incorrect type in argument 1 (different address spaces) @@expected void 
>> volatile [noderef] *addr @@got sn:2>*addr @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:465:44:
expected void volatile [noderef] *addr
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:465:44:got 
void *kaddr

git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout 4771bffd00cf57702e4bea3a1b08fe9a9ea78abd
vim +465 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c

1ff55f46 Rex Zhu   2016-08-19  377  
d3f8c0ab Rex Zhu   2017-09-20  378  int smu7_request_smu_load_fw(struct 
pp_hwmgr *hwmgr)
1ff55f46 Rex Zhu   2016-08-19  379  {
b3b03052 Rex Zhu   2017-09-26  380  struct smu7_smumgr *smu_data = 
(struct smu7_smumgr *)(hwmgr->smu_backend);
1ff55f46 Rex Zhu   2016-08-19  381  uint32_t fw_to_load;
4771bffd Alex Deucher  2018-07-12  382  int r = 0;
1ff55f46 Rex Zhu   2016-08-19  383  
b3b03052 Rex Zhu   2017-09-26  384  if (!hwmgr->reload_fw) {
634a24d8 Huang Rui 2016-12-26  385  pr_info("skip 
reloading...\n");
1ff55f46 Rex Zhu   2016-08-19  386  return 0;
1ff55f46 Rex Zhu   2016-08-19  387  }
1ff55f46 Rex Zhu   2016-08-19  388  
1ff55f46 Rex Zhu   2016-08-19  389  if (smu_data->soft_regs_start)
d3f8c0ab Rex Zhu   2017-09-20  390  
cgs_write_ind_register(hwmgr->device, CGS_IND_REG__SMC,
d3f8c0ab Rex Zhu   2017-09-20  391  
smu_data->soft_regs_start + smum_get_offsetof(hwmgr,
1ff55f46 Rex Zhu   2016-08-19  392  
SMU_SoftRegisters, UcodeLoadStatus),
1ff55f46 Rex Zhu   2016-08-19  393  
0x0);
1ff55f46 Rex Zhu   2016-08-19  394  
d3f8c0ab Rex Zhu   2017-09-20  395  if (hwmgr->chip_id > 
CHIP_TOPAZ) { /* add support for Topaz */
8bb575a2 Rex Zhu   2018-03-22  396  if (hwmgr->not_vf) {
d3f8c0ab Rex Zhu   2017-09-20  397  
smu7_send_msg_to_smc_with_parameter(hwmgr,
e224e4f1 Xiangliang Yu 2016-12-02  398  
PPSMC_MSG_SMU_DRAM_ADDR_HI,
bb03c9c4 Rex Zhu   2018-03-06  399  
upper_32_bits(smu_data->smu_buffer.mc_addr));
d3f8c0ab Rex Zhu   2017-09-20  400  
smu7_send_msg_to_smc_with_parameter(hwmgr,
e224e4f1 Xiangliang Yu 2016-12-02  401  
PPSMC_MSG_SMU_DRAM_ADDR_LO,
bb03c9c4 Rex Zhu   2018-03-06  402  
lower_32_bits(smu_data->smu_buffer.mc_addr));
e224e4f1 Xiangliang Yu 2016-12-02  403  }
1ff55f46 Rex Zhu   2016-08-19  404  fw_to_load = 
UCODE_ID_RLC_G_MASK
1ff55f46 Rex Zhu   2016-08-19  405 + 
UCODE_ID_SDMA0_MASK
1ff55f46 Rex Zhu   2016-08-19  406 + 
UCODE_ID_SDMA1_MASK

[PATCH] drm/nouveau: Fix bogus indenting in nouveau_hwmon.c

[Lyude Paul]

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 44178b4c3599..d556f24c6c48 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -655,7 +655,7 @@ nouveau_read_string(struct device *dev, enum 
hwmon_sensor_types type, u32 attr,
 
 static int
 nouveau_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
-   int channel, long *val)
+int channel, long *val)
 {
switch (type) {
case hwmon_chip:
@@ -677,7 +677,7 @@ nouveau_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
 
 static int
 nouveau_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
-   int channel, long val)
+ int channel, long val)
 {
switch (type) {
case hwmon_temp:
-- 
2.17.1

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

Re: [PATCH v2 19/21] dt-bindings: msm/disp: Add bindings for Snapdragon 845 DPU

[Rob Herring]

On Thu, Jul 12, 2018 at 05:08:37PM -0400, Sean Paul wrote:
> From: Jeykumar Sankaran 
> 
> Adds bindings for Snapdragon 845 display processing unit
> 
> Changes in v2:
>  - Use SoC specific compatibles for mdss and dpu
>  - Use assigned-clocks to set initial clock frequency
> 
> Signed-off-by: Jeykumar Sankaran 
> Signed-off-by: Rajesh Yadav 
> Signed-off-by: Sean Paul 
> ---
>  .../devicetree/bindings/display/msm/dpu.txt   | 136 ++
>  1 file changed, 136 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
> b/Documentation/devicetree/bindings/display/msm/dpu.txt
> new file mode 100644
> index ..a998028896ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
> @@ -0,0 +1,136 @@
> +Qualcomm Technologies, Inc. DPU KMS
> +
> +Description:
> +
> +Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates
> +sub-blocks like DPU display controller, DSI and DP interfaces etc.
> +The DPU display controller is found in SDM845 SoC.
> +
> +MDSS:
> +Required properties:
> +- compatible: "qcom,sdm845-mdss"
> +- reg: physical base address and length of contoller's registers.
> +- reg-names: register region names. The following region is required:
> +  * "mdss_phys"

phys as in physical address? If so, that's always the case. *-names is 
pointless when there is only one anyways.

> +- power-domains: a power domain consumer specifier according to
> +  Documentation/devicetree/bindings/power/power_domain.txt
> +- clocks: list of phandles for clock device nodes needed by the device.
> +- clock-names: device clock names, must be in same order as clocks property.
> +  The following clocks are required:
> +  * "iface"
> +  * "bus"
> +  * "core"
> +- interrupts: interrupt signal from MDSS.
> +- interrupt-controller: identifies the node as an interrupt controller.
> +- #interrupt-cells: specifies the number of cells needed to encode an 
> interrupt
> +  source, should be 1.
> +- iommus: phandle of iommu device node.
> +- #address-cells: number of address cells for the MDSS children. Should be 1.
> +- #size-cells: Should be 1.
> +- ranges: parent bus address space is the same as the child bus address 
> space.
> +
> +Optional properties:
> +- assigned-clocks: list of phandles for clock device nodes needing rate

It's a list of clock specifiers (phandle and id), not device nodes.

> +assignment
> +- assigned-clock-rates: list of clock frequencies sorted in the same order as
> +  the assigned-clocks property.
> +
> +MDP:
> +Required properties:
> +- compatible: "qcom,sdm845-dpu"
> +- reg: physical base address and length of controller's registers.
> +- reg-names : register region names. The following region is required:
> +  * "mdp_phys"
> +  * "vbif_phys"

Same comment on "_phys" here.

> +- clocks: list of phandles for clock device nodes needed by the device.
> +- clock-names: device clock names, must be in same order as clocks property.
> +  The following clocks are required.
> +  * "bus"
> +  * "iface"
> +  * "core"
> +  * "vsync"
> +- interrupt-parent: phandle to MDSS block.

Actually, you don't need this if a parent node contains 
"interrupt-controller" property.

> +- interrupts: interrupt line from DPU to MDSS.
> +- ports: contains the list of output ports from DPU device. These ports 
> connect
> +  to interfaces that are external to the DPU hardware, such as DSI, DP etc.
> +
> +  Each output port contains an endpoint that describes how it is connected 
> to an
> +  external interface. These are described by the standard properties 
> documented
> +  here:
> + Documentation/devicetree/bindings/graph.txt
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> + Port 0 -> DPU_INTF1 (DSI1)
> + Port 1 -> DPU_INTF2 (DSI2)
> +
> +Optional properties:
> +- assigned-clocks: list of phandles for clock device nodes needing rate
> +assignment
> +- assigned-clock-rates: list of clock frequencies sorted in the same order as
> +  the assigned-clocks property.
> +
> +Example:
> +
> + mdss: mdss@ae0 {
> + compatible = "qcom,sdm845-mdss";
> + reg = <0xae0 0x1000>;
> + reg-names = "mdss_phys";
> +
> + power-domains = <_dispcc 0>;
> +
> + clocks = < GCC_DISP_AHB_CLK>, < GCC_DISP_AXI_CLK>,
> +  <_dispcc DISP_CC_MDSS_MDP_CLK>;
> + clock-names = "iface", "bus", "core";
> +
> + assigned-clocks = <_dispcc DISP_CC_MDSS_MDP_CLK>;
> + assigned-clock-rates = <3>;
> +
> + interrupts = ;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + iommus = <_iommu 0>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;

It's preferred to put actual values in and limit the range 

Re: [PATCH v2 1/5] drm/vkms: Add functions to map/unmap GEM backing storage

[Sean Paul]

On Sat, Jul 14, 2018 at 03:18:55PM +0300, Haneen Mohammed wrote:
> This patch add the necessary functions to map/unmap GEM
> backing memory to the kernel's virtual address space.
> 
> Signed-off-by: Haneen Mohammed 
> ---
> Changes in v2:
> - add vkms_gem_vunmap
> - use vmap_count to guard against multiple prepare_fb calls on the same
>   fb
> 
>  drivers/gpu/drm/vkms/vkms_drv.h |  9 
>  drivers/gpu/drm/vkms/vkms_gem.c | 73 -
>  2 files changed, 81 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 07be29f2dc44..855e1ea8bc35 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -39,6 +39,8 @@ struct vkms_gem_object {
>   struct drm_gem_object gem;
>   struct mutex pages_lock; /* Page lock used in page fault handler */
>   struct page **pages;
> + unsigned int vmap_count;
> + void *vaddr;
>  };
>  
>  #define drm_crtc_to_vkms_output(target) \
> @@ -47,6 +49,9 @@ struct vkms_gem_object {
>  #define drm_device_to_vkms_device(target) \
>   container_of(target, struct vkms_device, drm)
>  
> +#define drm_gem_to_vkms_gem(target)\
> + container_of(target, struct vkms_gem_object, gem)
> +
>  /* CRTC */
>  int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
>  struct drm_plane *primary, struct drm_plane *cursor);
> @@ -75,4 +80,8 @@ int vkms_dumb_map(struct drm_file *file, struct drm_device 
> *dev,
>  
>  void vkms_gem_free_object(struct drm_gem_object *obj);
>  
> +void *vkms_gem_vmap(struct drm_gem_object *obj);
> +
> +void vkms_gem_vunmap(struct drm_gem_object *obj);
> +
>  #endif /* _VKMS_DRV_H_ */
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index c7e38368602b..3f574e761b0f 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -37,7 +37,9 @@ void vkms_gem_free_object(struct drm_gem_object *obj)
>   struct vkms_gem_object *gem = container_of(obj, struct vkms_gem_object,
>  gem);
>  
> - kvfree(gem->pages);
> + WARN_ON(gem->pages);
> + WARN_ON(gem->vaddr);
> +
>   mutex_destroy(>pages_lock);
>   drm_gem_object_release(obj);
>   kfree(gem);
> @@ -177,3 +179,72 @@ int vkms_dumb_map(struct drm_file *file, struct 
> drm_device *dev,
>  
>   return ret;
>  }
> +
> +static struct page **_get_pages(struct vkms_gem_object *vkms_obj)
> +{
> + struct drm_gem_object *gem_obj = _obj->gem;
> +
> + if (!vkms_obj->pages) {
> + struct page **pages = drm_gem_get_pages(gem_obj);
> +
> + if (IS_ERR(pages))
> + return pages;
> +
> + if (cmpxchg(_obj->pages, NULL, pages))
> + drm_gem_put_pages(gem_obj, pages, false, true);
> + }
> +
> + return vkms_obj->pages;
> +}
> +
> +void vkms_gem_vunmap(struct drm_gem_object *obj)
> +{
> + struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(obj);
> +
> + mutex_lock(_obj->pages_lock);
> + WARN_ON(vkms_obj->vmap_count < 1);
> + vkms_obj->vmap_count--;
> +
> + if (vkms_obj->vmap_count == 0) {
> + vunmap(vkms_obj->vaddr);
> + vkms_obj->vaddr = NULL;
> + drm_gem_put_pages(obj, vkms_obj->pages, false, true);
> + vkms_obj->pages = NULL;
> + }
> +
> + mutex_unlock(_obj->pages_lock);
> +}
> +
> +void *vkms_gem_vmap(struct drm_gem_object *obj)
> +{
> + struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(obj);
> +

nit: extra line

> + int ret = 0;
> +
> + mutex_lock(_obj->pages_lock);
> + vkms_obj->vmap_count++;

If you increment this below the conditional block, you don't need to decrement
it in fail.

> +
> + if (!vkms_obj->vaddr) {
> + unsigned int n_pages = obj->size >> PAGE_SHIFT;
> + struct page **pages = _get_pages(vkms_obj);
> +
> + if (IS_ERR(pages)) {
> + ret = PTR_ERR(pages);
> + goto fail;
> + }
> +
> + vkms_obj->vaddr = vmap(pages, n_pages, VM_MAP, PAGE_KERNEL);
> + if (!vkms_obj->vaddr) {

Do you need to cleanup from _get_pages() here?

> + ret = -ENOMEM;
> + goto fail;
> + }
> + }
> +
> + mutex_unlock(_obj->pages_lock);
> + return vkms_obj->vaddr;
> +
> +fail:
> + vkms_obj->vmap_count--;
> + mutex_unlock(_obj->pages_lock);
> + return ERR_PTR(ret);
> +}
> -- 
> 2.17.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107012] [PATCH] Radeon SI driver not architecture safe, crashes on ppc64[el]

[bugzilla-daemon]

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

--- Comment #7 from Timothy Pearson  ---
(In reply to Michel Dänzer from comment #6)
> Please send patches like this directly to the mesa-dev mailing list for
> review.

Patch has been sent.  I don't monitor mesa-dev, so please address any concerns
directly to the Email address the patch came from.

Thanks!

-- 
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 v2 2/3] drm: mali-dp: Report writeback connector as connected

[Liviu Dudau]

On Fri, Jul 13, 2018 at 04:10:59PM +0100, Alexandru Gheorghe wrote:
> Older version of this patch series reported writeback as disconnected
> to avoid confusing userspace not aware of writeback connectors.
> However, the version that got merged uses a special cap
> (DRM_CLIENT_CAP_WRITEBACK_CONNECTORS) for this purpose.
> 
> This helps us avoid some special handling of writeback connector
> in drm_helper_probe_single_connector_modes, see [1].
> 
> https://lists.freedesktop.org/archives/dri-devel/2018-July/183144.html
> 
> Signed-off-by: Alexandru Gheorghe 

Acked-by: Liviu Dudau 

> ---
>  drivers/gpu/drm/arm/malidp_mw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index cfd718e..ba6ae66 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -73,7 +73,7 @@ static void malidp_mw_connector_reset(struct drm_connector 
> *connector)
>  static enum drm_connector_status
>  malidp_mw_connector_detect(struct drm_connector *connector, bool force)
>  {
> - return connector_status_disconnected;
> + return connector_status_connected;
>  }
>  
>  static void malidp_mw_connector_destroy(struct drm_connector *connector)
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm: writeback: Fix doc that says connector should be disconnected

[Liviu Dudau]

On Fri, Jul 13, 2018 at 04:10:58PM +0100, Alexandru Gheorghe wrote:
> During iteration process one of the proposed mechanism for not
> breaking existing userspace was to report writeback connectors as
> disconnected, however the final version used
> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS for that purpose.
> 
> Signed-off-by: Alexandru Gheorghe 

Acked-by: Liviu Dudau 

> ---
>  drivers/gpu/drm/drm_writeback.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index 8273950..e7b6e5e 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -23,8 +23,8 @@
>   * from a CRTC to a memory buffer. They are used and act similarly to other
>   * types of connectors, with some important differences:
>   *  - Writeback connectors don't provide a way to output visually to the 
> user.
> - *  - Writeback connectors should always report as "disconnected" (so that
> - *clients which don't understand them will ignore them).
> + *  - Writeback connectors are visible to userspace only when the client sets
> + *DRM_CLIENT_CAP_WRITEBACK_CONNECTORS.
>   *  - Writeback connectors don't have EDID.
>   *
>   * A framebuffer may only be attached to a writeback connector when the
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC v3 0/8] Add Plane Color Properties

[Shankar, Uma]

>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Thursday, July 12, 2018 10:02 PM
>To: Shankar, Uma 
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville
>; n...@arm.com; Lankhorst, Maarten
>
>Subject: Re: [RFC v3 0/8] Add Plane Color Properties
>
>Hi Uma,
>
>On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>> >Behalf Of Alexandru-Cosmin Gheorghe
>> >Sent: Monday, June 11, 2018 3:47 PM
>> >To: Shankar, Uma 
>> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>> >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala,
>> >Ville ; n...@arm.com; Lankhorst, Maarten
>> >
>> >Subject: Re: [RFC v3 0/8] Add Plane Color Properties
>> >
>> >Hi Uma,
>> >
>> >Any progress on userspace for this?
>> >I was thinking on working on using this in drm_hwcomposer.
>> >
>>
>> Hi Alex,
>> Not much work has been done till now on user space side. You can go
>> ahead and try to enable it in drm_hwcomposer.
>>
>> Regards,
>> Uma Shankar
>>
>
>I opened a Merge request in drm_hwcomposer, if you have time please have a
>look and let me know what you think.
>[1] https://gitlab.freedesktop.org/drm-hwcomposer/drm-
>hwcomposer/merge_requests/25
>

Hi Alex,
The changes are inline to what these properties are intended for and looks ok 
to me.
However, it would be good if some compositor experts also review the same from 
design perspective.

Also we need RB for kernel patches. I hope with the current drm hwcomposer 
changes, we should be good
to get them merge.

Regards,
Uma Shankar

>> >Thank you,
>> >Alex Gheorghe
>> >
>> >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote:
>> >> This patch series adds properties for plane color features. It adds
>> >> properties for degamma used to linearize data, CSC used for gamut
>> >> conversion, and gamma used to again non-linearize data as per panel
>> >> supported color space. These can be utilize by user space to
>> >> convert planes from one format to another, one color space to another etc.
>> >>
>> >> Usersapce can take smart blending decisions and utilize these
>> >> hardware supported plane color features to get accurate color
>> >> profile. The same can help in consistent color quality from source
>> >> to panel taking advantage of advanced color features in hardware.
>> >>
>> >> These patches just add the property interfaces and enable helper
>> >> functions.
>> >>
>> >> This series adds Intel Gen9 specific plane gamma feature. We can
>> >> build up and add other platform/hardware specific implementation on
>> >> top of this series
>> >>
>> >> Note: This is just to get a design feedback whether these
>> >> interfaces look ok. Based on community feedback on interfaces, we
>> >> will implement IGT tests to validate plane color features. This is 
>> >> un-tested
>currently.
>> >> Also, userspace implementation to use these properties is currently
>> >> not available.
>> >>
>> >> v2: Dropped legacy gamma table for plane as suggested by Maarten.
>> >> Added Gen9/BDW plane gamma feature and rebase on tot.
>> >>
>> >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit
>> >> precision entries, pointed to by Brian, Starkey for HDR usecases.
>> >> Addressed Sean,Paul comments and moved plane color properties to
>> >> drm_plane instead of mode_config. Added property documentation as
>> >suggested by Daniel, Vetter.
>> >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov.
>> >>
>> >> Uma Shankar (8):
>> >>   drm: Add Enhanced Gamma LUT precision structure
>> >>   drm: Add Plane Degamma properties
>> >>   drm: Add Plane CTM property
>> >>   drm: Add Plane Gamma properties
>> >>   drm: Define helper function for plane color enabling
>> >>   drm/i915: Enable plane color features
>> >>   drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
>> >>   drm/i915: Load plane color luts from atomic flip
>> >>
>> >>  Documentation/gpu/drm-kms.rst |  18 
>> >>  drivers/gpu/drm/drm_atomic.c  |  30 +++
>> >>  drivers/gpu/drm/drm_atomic_helper.c   |  12 +++
>> >>  drivers/gpu/drm/drm_plane.c   | 131
>> >++
>> >>  drivers/gpu/drm/i915/i915_drv.h   |   5 ++
>> >>  drivers/gpu/drm/i915/i915_pci.c   |   5 +-
>> >>  drivers/gpu/drm/i915/i915_reg.h   |  24 ++
>> >>  drivers/gpu/drm/i915/intel_atomic_plane.c |   4 +
>> >>  drivers/gpu/drm/i915/intel_color.c|  80 ++
>> >>  drivers/gpu/drm/i915/intel_device_info.h  |   5 ++
>> >>  drivers/gpu/drm/i915/intel_display.c  |   4 +
>> >>  drivers/gpu/drm/i915/intel_drv.h  |  10 +++
>> >>  drivers/gpu/drm/i915/intel_sprite.c   |   4 +
>> >>  include/drm/drm_color_mgmt.h  |   5 ++
>> >>  

Re: [V2 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[Takashi Iwai]

On Mon, 16 Jul 2018 08:06:35 +0200,
Jim Qu wrote:
> 
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
> 
> In currect HDA audio driver, it will set all codec as
> VGA_SWITCHEROO_DIS, the audio which is binded to UMA
> will be suspended if user use debugfs to control power
> 
> In HDA driver side, it is difficult to know which GPU
> the audio has bound to. So set the bound gpu pci dev
> to vgaswitchreoo, the correct audio id will be set in
> vgaswitchreoo enable function.
> 
> Signed-off-by: Jim Qu 

Looks good to me.  Lukas, let me know if it's OK for you.

I guess this can go through sound.git tree together with another
change.  In that case, please give ACK from DRM guys.

Or anyone wants this through another tree inevitably, let me know.  In
that case, fell free to take my reviewed-by tag:
  Reviewed-by: Takashi Iwai 


thanks,

Takashi


> ---
>  drivers/gpu/vga/vga_switcheroo.c | 39 +--
>  include/linux/vga_switcheroo.h   |  8 
>  sound/pci/hda/hda_intel.c| 10 +-
>  3 files changed, 38 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index fc4adf3..2b9ae42 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -103,6 +103,7 @@
>   *   runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
>   *   interface is a no-op so as not to interfere with runtime pm
>   * @list: client list
> + * @vga_dev: pci device, indicate which GPU is bound to current audio client
>   *
>   * Registered client. A client can be either a GPU or an audio device on a 
> GPU.
>   * For audio clients, the @fb_info and @active members are bogus.
> @@ -116,6 +117,7 @@ struct vga_switcheroo_client {
>   bool active;
>   bool driver_power_control;
>   struct list_head list;
> + struct pci_dev *vga_dev;
>  };
>  
>  /*
> @@ -161,9 +163,8 @@ struct vgasr_priv {
>  };
>  
>  #define ID_BIT_AUDIO 0x100
> -#define client_is_audio(c)   ((c)->id & ID_BIT_AUDIO)
> -#define client_is_vga(c) ((c)->id == VGA_SWITCHEROO_UNKNOWN_ID || \
> -  !client_is_audio(c))
> +#define client_is_audio(c)   ((c)->id & ID_BIT_AUDIO)
> +#define client_is_vga(c) (!client_is_audio(c))
>  #define client_id(c) ((c)->id & ~ID_BIT_AUDIO)
>  
>  static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
> @@ -192,14 +193,28 @@ static void vga_switcheroo_enable(void)
>   vgasr_priv.handler->init();
>  
>   list_for_each_entry(client, _priv.clients, list) {
> - if (client->id != VGA_SWITCHEROO_UNKNOWN_ID)
> + if (!client_is_vga(client) || client_id(client) !=
> + VGA_SWITCHEROO_UNKNOWN_ID)
>   continue;
> +
>   ret = vgasr_priv.handler->get_client_id(client->pdev);
>   if (ret < 0)
>   return;
> -
>   client->id = ret;
>   }
> +
> + list_for_each_entry(client, _priv.clients, list) {
> + if (!client_is_audio(client) || client_id(client) !=
> + VGA_SWITCHEROO_UNKNOWN_ID)
> + continue;
> +
> + ret = vgasr_priv.handler->get_client_id(client->vga_dev);
> + if (ret < 0)
> + return;
> +
> + client->id = ret | ID_BIT_AUDIO;
> + }
> +
>   vga_switcheroo_debugfs_init(_priv);
>   vgasr_priv.active = true;
>  }
> @@ -272,7 +287,9 @@ EXPORT_SYMBOL(vga_switcheroo_handler_flags);
>  
>  static int register_client(struct pci_dev *pdev,
>  const struct vga_switcheroo_client_ops *ops,
> -enum vga_switcheroo_client_id id, bool active,
> +enum vga_switcheroo_client_id id,
> +struct pci_dev *vga_dev,
> +bool active,
>  bool driver_power_control)
>  {
>   struct vga_switcheroo_client *client;
> @@ -287,6 +304,7 @@ static int register_client(struct pci_dev *pdev,
>   client->id = id;
>   client->active = active;
>   client->driver_power_control = driver_power_control;
> + client->vga_dev = vga_dev;
>  
>   mutex_lock(_mutex);
>   list_add_tail(>list, _priv.clients);
> @@ -319,7 +337,7 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
>  const struct vga_switcheroo_client_ops *ops,
>  bool driver_power_control)
>  {
> - return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID,
> + return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID, NULL,
>  pdev == vga_default_device(),
>  driver_power_control);
> 

Re: [PATCH] drm: mali-dp: Call drm_crtc_vblank_reset on device init

[Liviu Dudau]

On Mon, Jul 16, 2018 at 11:07:07AM +0100, Alexandru Gheorghe wrote:
> Currently, if userspace calls drm_wait_vblank before the crtc is
> activated the crtc vblank_enable hook is called, which in case of
> malidp driver triggers some warninngs. This happens because on
> device init we don't inform the drm core about the vblank state
> by calling drm_crtc_vblank_on/off/reset which together with
> drm_vblank_get have some magic that prevents calling drm_vblank_enable
> when crtc is off.
> 
> Signed-off-by: Alexandru Gheorghe 

Acked-by: Liviu Dudau 

> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 4169a72..641d743 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -755,6 +755,7 @@ static int malidp_bind(struct device *dev)
>   drm->irq_enabled = true;
>  
>   ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> + drm_crtc_vblank_reset(>crtc);
>   if (ret < 0) {
>   DRM_ERROR("failed to initialise vblank\n");
>   goto vblank_fail;
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm: mali-dp: Set encoder possible_clones

[Liviu Dudau]

On Mon, Jul 16, 2018 at 10:56:13AM +0100, Alexandru Gheorghe wrote:
> Set possible_clones field to report that the writeback connector and
> the one driving the display could be enabled at the same time.
> 
> Signed-off-by: Alexandru Gheorghe 

Acked-by: Liviu Dudau 

> 
> Changes since v2:
>   - Use proper style for multi-line comments.
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 5b72605..4169a72 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -616,6 +616,7 @@ static int malidp_bind(struct device *dev)
>   struct malidp_hw_device *hwdev;
>   struct platform_device *pdev = to_platform_device(dev);
>   struct of_device_id const *dev_id;
> + struct drm_encoder *encoder;
>   /* number of lines for the R, G and B output */
>   u8 output_width[MAX_OUTPUT_CHANNELS];
>   int ret = 0, i;
> @@ -737,6 +738,16 @@ static int malidp_bind(struct device *dev)
>   goto bind_fail;
>   }
>  
> + /*
> +  * We expect to have a maximum of two encoders one for the actual
> +  * display and a virtual one for the writeback connector
> +  */
> + WARN_ON(drm->mode_config.num_encoder > 2);
> + list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> + encoder->possible_clones =
> + (1 << drm->mode_config.num_encoder) -  1;
> + }
> +
>   ret = malidp_irq_init(pdev);
>   if (ret < 0)
>   goto irq_init_fail;
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: off by one in vkms_gem_fault()

[Rodrigo Siqueira]

Hi Dan,

Thanks for your patch. I checked and tested it, everything is fine.

On 07/14, Dan Carpenter wrote:
> The > should be >= so that we don't read one page beyond the end of the
> obj->pages[] array.
> 
> Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index c7e38368602b..2cca8c2f260f 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -55,7 +55,7 @@ int vkms_gem_fault(struct vm_fault *vmf)
>   page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
>   num_pages = DIV_ROUND_UP(obj->gem.size, PAGE_SIZE);
>  
> - if (page_offset > num_pages)
> + if (page_offset >= num_pages)
>   return VM_FAULT_SIGBUS;
>  
>   ret = -ENOENT;

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

Re: drm/msm/mdp5: negative x/y in cursor move

[Rob Clark]

On Tue, Jul 10, 2018 at 1:18 PM, Carsten Behling
 wrote:
> I found the solution:
>
> ROI has to be recalculated for negative x/y indicating using the lower/right
> corner of the cursor buffer. Further, MDP5_LM_CURSOR_XY_SRC_Y and
> MDP5_LM_CURSOR_XY_SRC_X mus be calculated for the hotspot:

oh, sorry, I had not seen your earlier msg.. but if you haven't found
it already, mdp5 (and rest of SoC) register docs are in the HRD:

http://linaro.co/96b-qc-hrd

(often somewhat, umm, terse, but can be helpful)

If you could send this as a proper git patch, that would be appreciated.  Thx

BR,
-R

>
> Index: kernel-source/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> ===
> --- kernel-source.orig/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> +++ kernel-source/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> @@ -65,7 +65,7 @@ struct mdp5_crtc {
>   struct drm_gem_object *scanout_bo;
>   uint64_t iova;
>   uint32_t width, height;
> - uint32_t x, y;
> + int x, y;
>   } cursor;
>  };
>  #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
> @@ -756,10 +756,16 @@ static void get_roi(struct drm_crtc *crt
>   * (xres-x) will be new cursor width when x > (xres - cursor.width)
>   * (yres-y) will be new cursor height when y > (yres - cursor.height)
>   */
> - *roi_w = min(mdp5_crtc->cursor.width, xres -
> - mdp5_crtc->cursor.x);
> - *roi_h = min(mdp5_crtc->cursor.height, yres -
> - mdp5_crtc->cursor.y);
> + if (mdp5_crtc->cursor.x >= 0)
> + *roi_w = min(mdp5_crtc->cursor.width, xres -
> + mdp5_crtc->cursor.x);
> + else
> + *roi_w = mdp5_crtc->cursor.width - abs(mdp5_crtc->cursor.x);
> + if (mdp5_crtc->cursor.y >= 0)
> + *roi_h = min(mdp5_crtc->cursor.height, yres -
> + mdp5_crtc->cursor.y);
> + else
> + *roi_h = mdp5_crtc->cursor.height - abs(mdp5_crtc->cursor.y);
>  }
>
>  static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
> @@ -769,7 +775,7 @@ static void mdp5_crtc_restore_cursor(str
>   struct mdp5_kms *mdp5_kms = get_kms(crtc);
>   const enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
>   uint32_t blendcfg, stride;
> - uint32_t x, y, width, height;
> + uint32_t x, y, src_x, src_y, width, height;
>   uint32_t roi_w, roi_h;
>   int lm;
>
> @@ -786,6 +792,20 @@ static void mdp5_crtc_restore_cursor(str
>
>   get_roi(crtc, _w, _h);
>
> +if (mdp5_crtc->cursor.x < 0) {
> +src_x = abs(mdp5_crtc->cursor.x);
> +x = 0;
> + } else
> +src_x = 0;
> +
> +if (mdp5_crtc->cursor.y < 0) {
> +src_y = abs(mdp5_crtc->cursor.y);
> +y = 0;
> +} else
> +src_y = 0;
> +
> + //printk("x=%d, y=%d roi_w=%d roi_h=%d src_x=%d src_y=%d\n", x, y, roi_w,
> roi_h, src_x, src_y);
> +
>   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
>   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
>   MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
> @@ -798,6 +818,9 @@ static void mdp5_crtc_restore_cursor(str
>   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_START_XY(lm),
>   MDP5_LM_CURSOR_START_XY_Y_START(y) |
>   MDP5_LM_CURSOR_START_XY_X_START(x));
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_XY(lm),
> + MDP5_LM_CURSOR_XY_SRC_Y(src_y) |
> + MDP5_LM_CURSOR_XY_SRC_X(src_x));
>   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_BASE_ADDR(lm),
>   mdp5_crtc->cursor.iova);
>
> @@ -903,6 +926,8 @@ static int mdp5_crtc_cursor_move(struct
>   uint32_t roi_w;
>   uint32_t roi_h;
>   unsigned long flags;
> + int border_x = mdp5_crtc->cursor.width * (-1);
> + int border_y = mdp5_crtc->cursor.height * (-1);
>
>   if (!mdp5_crtc->lm_cursor_enabled) {
>   dev_warn(dev->dev,
> @@ -918,8 +943,8 @@ static int mdp5_crtc_cursor_move(struct
>   if (unlikely(!crtc->state->enable))
>   return 0;
>
> - mdp5_crtc->cursor.x = x = max(x, 0);
> - mdp5_crtc->cursor.y = y = max(y, 0);
> + mdp5_crtc->cursor.x = x = max(x, border_x);
> + mdp5_crtc->cursor.y = y = max(y, border_y);
>
>   get_roi(crtc, _w, _h);
>
> Best regards
> -Carsten
>
> 2018-07-10 12:11 GMT+02:00 Carsten Behling :
>>
>> Hi,
>>
>> modesetting X11 driver may provide negative x/y cordinates in
>> mdp5_crtc_cursor_move(...) call when rotation is enabled.
>>
>> Because of
>>
>> static int mdp5_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
>> {
>> ...
>> mdp5_crtc->cursor.x = x = max(x, 0);
>> mdp5_crtc->cursor.y = y = max(y, 0);
>> ...
>> }
>>
>> x/y is calmped to 0/0 in those cases resulting that the cursor does not
>> move anymore beyond mdp5_crtc->cursor.width, mdp5_crtc->cursor.height.
>>
>> For e.g rotation of 180 degree that means that the upper left cursor point
>> stays never reaches the region (0/0) to
>> (mdp5_crtc->cursor.width/mdp5_crtc->cursor.height).
>>
>> I already asked the X men if this should be fixed in modesetting driver or
>> in the kernel CRT
>> functions:
>>
>> https://www.spinics.net/lists/xorg/msg58969.html
>>
>> They told me to fix this 

Re: [V2 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to replace PCI_CLASS_DISPLAY_VGA

[Takashi Iwai]

On Mon, 16 Jul 2018 08:06:34 +0200,
Jim Qu wrote:
> 
> Except PCI_CLASS_DISPLAY_VGA, some PCI class is sometimes
> PCI_CLASS_DISPLAY_3D or PCI_CLASS_DISPLAY_OTHER.
> 
> Signed-off-by: Jim Qu 

Applied this one now, as it's basically an individual fix.


thanks,

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

[PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Michal Hocko]

From: Michal Hocko 

There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks.

Currently we simply back off and mark an oom victim with blockable mmu
notifiers as done after a short sleep. That can result in selecting a
new oom victim prematurely because the previous one still hasn't torn
its memory down yet.

We can do much better though. Even if mmu notifiers use sleepable locks
there is no reason to automatically assume those locks are held.
Moreover majority of notifiers only care about a portion of the address
space and there is absolutely zero reason to fail when we are unmapping an
unrelated range. Many notifiers do really block and wait for HW which is
harder to handle and we have to bail out though.

This patch handles the low hanging fruid. __mmu_notifier_invalidate_range_start
gets a blockable flag and callbacks are not allowed to sleep if the
flag is set to false. This is achieved by using trylock instead of the
sleepable lock for most callbacks and continue as long as we do not
block down the call chain.

I think we can improve that even further because there is a common
pattern to do a range lookup first and then do something about that.
The first part can be done without a sleeping lock in most cases AFAICS.

The oom_reaper end then simply retries if there is at least one notifier
which couldn't make any progress in !blockable mode. A retry loop is
already implemented to wait for the mmap_sem and this is basically the
same thing.

Changes since rfc v1
- gpu notifiers can sleep while waiting for HW (evict_process_queues_cpsch
  on a lock and amdgpu_mn_invalidate_node on unbound timeout) make sure
  we bail out when we have an intersecting range for starter
- note that a notifier failed to the log for easier debugging
- back off early in ib_umem_notifier_invalidate_range_start if the
  callback is called
- mn_invl_range_start waits for completion down the unmap_grant_pages
  path so we have to back off early on overlapping ranges

Cc: "David (ChunMing) Zhou" 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Alex Deucher 
Cc: David Airlie 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Doug Ledford 
Cc: Jason Gunthorpe 
Cc: Mike Marciniszyn 
Cc: Dennis Dalessandro 
Cc: Sudeep Dutt 
Cc: Ashutosh Dixit 
Cc: Dimitri Sivanich 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: "Jérôme Glisse" 
Cc: Andrea Arcangeli 
Cc: Felix Kuehling 
Cc: k...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: linux...@kvack.org
Acked-by: Christian König  # AMD notifiers
Acked-by: Leon Romanovsky  # mlx and umem_odp
Reported-by: David Rientjes 
Signed-off-by: Michal Hocko 
---

Hi,
there were no major objections when I sent this as an RFC the last time
[1]. I was hoping for more feedback in the drivers land because I am
touching the code I have no way to test. On the other hand the pattern
is quite simple and consistent over all users so there shouldn't be
any large surprises hopefully.

Any further review would be highly appreciate of course. But is this
something to put into the mm tree now?

[1] http://lkml.kernel.org/r/20180627074421.gf32...@dhcp22.suse.cz


 arch/x86/kvm/x86.c  |  7 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  | 43 +++-
 drivers/gpu/drm/i915/i915_gem_userptr.c | 13 ++--
 drivers/gpu/drm/radeon/radeon_mn.c  | 22 +++--
 drivers/infiniband/core/umem_odp.c  | 33 +++
 drivers/infiniband/hw/hfi1/mmu_rb.c | 11 ---
 drivers/infiniband/hw/mlx5/odp.c|  2 +-
 drivers/misc/mic/scif/scif_dma.c|  7 ++--
 drivers/misc/sgi-gru/grutlbpurge.c  |  7 ++--
 drivers/xen/gntdev.c| 44 -
 include/linux/kvm_host.h|  4 +--
 include/linux/mmu_notifier.h| 35 +++-
 include/linux/oom.h |  2 +-
 include/rdma/ib_umem_odp.h  |  3 +-
 mm/hmm.c|  7 ++--
 mm/mmap.c   |  2 +-
 mm/mmu_notifier.c   | 19 ---
 mm/oom_kill.c   | 29 
 virt/kvm/kvm_main.c | 15 ++---
 19 files changed, 225 insertions(+), 80 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6bcecc325e7e..ac08f5d711be 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7203,8 +7203,9 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu)
kvm_x86_ops->load_eoi_exitmap(vcpu, eoi_exit_bitmap);
 }
 
-void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
-   unsigned long start, unsigned long end)
+int 

Re: [PATCH 04/21] drm: add msm compressed format modifiers

[Rob Clark]

On Mon, Jul 9, 2018 at 1:31 PM, Sean Paul  wrote:
> From: Jeykumar Sankaran 
>
> Qualcomm Snapdragon chipsets uses compressed format
> to optimize BW across multiple IP's. This change adds
> needed modifier support in drm for a simple 4x4 tile
> based compressed variants of base formats.
>
> Signed-off-by: Jeykumar Sankaran 
> Signed-off-by: Sean Paul 
> ---
>  include/uapi/drm/drm_fourcc.h | 45 +++
>  1 file changed, 45 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..9a97405a3d2a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -298,6 +298,38 @@ extern "C" {
>   */
>  #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE  fourcc_mod_code(SAMSUNG, 1)
>
> +/*
> + * Qualcomm Compressed Format
> + *
> + * Refers to a compressed variant of the base format that is compressed.
> + * Implementation may be platform and base-format specific.
> + */
> +#define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)

hmm, somehow (I guess rebasing gone wrong?) we end up with
DRM_FORMAT_MOD_QCOM_COMPRESSED.. I'll drop the 2nd hunk

BR,
-R

> +
> +/*
> + * QTI DX Format
> + *
> + * Refers to a DX variant of the base format.
> + * Implementation may be platform and base-format specific.
> + */
> +#define DRM_FORMAT_MOD_QCOM_DX fourcc_mod_code(QCOM, 0x2)
> +
> +/*
> + * QTI Tight Format
> + *
> + * Refers to a tightly packed variant of the base format.
> + * Implementation may be platform and base-format specific.
> + */
> +#define DRM_FORMAT_MOD_QCOM_TIGHT  fourcc_mod_code(QCOM, 0x4)
> +
> +/*
> + * QTI Tile Format
> + *
> + * Refers to a tile variant of the base format.
> + * Implementation may be platform and base-format specific.
> + */
> +#define DRM_FORMAT_MOD_QCOM_TILE   fourcc_mod_code(QCOM, 0x8)
> +
>  /* Vivante framebuffer modifiers */
>
>  /*
> @@ -405,6 +437,19 @@ extern "C" {
>   */
>  #define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
>
> +/*
> + * MSM compressed format
> + *
> + * Refers to the compressed variant of a base format.
> + * Implementation may be platform and base-format specific.
> + *
> + * Each macrotile consists of m x n (mostly 4 x 4) tiles.
> + * Pixel data pitch/stride is aligned with macrotile width.
> + * Pixel data height is aligned with macrotile height.
> + * Entire pixel data buffer is aligned with 4k(bytes).
> + */
> +#define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/selftests: Remove redundant code

[Chris Wilson]

Quoting Gustavo A. R. Silva (2018-07-16 13:39:33)
> err is assigned to -EIO, but this value is never actually
> used and *err* is updated later on.
> 
> Remove such reduntant code.

The mistake is that err is lost, possible masking the test failure.
Looks like the unwind needs to be refactored?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[Lukas Wunner]

On Sat, Jul 14, 2018 at 02:15:24PM +0800, jimqu wrote:
> ??? 2018/7/13 17:27, Lukas Wunner ??:
> >On Fri, Jul 13, 2018 at 04:06:02PM +0800, Jim Qu wrote:
> >>On modern laptop, there are more and more platforms
> >>have two GPUs, and each of them maybe have audio codec
> >>for HDMP/DP output. For some dGPU which is no output,
> >>audio codec usually is disabled.
> >>
> >>In currect HDA audio driver, it will set all codec as
> >>VGA_SWITCHEROO_DIS, the audio which is binded to UMA
> >>will be suspended if user use debugfs to contorl power
> >>
> >>In HDA driver side, it is difficult to know which GPU
> >>the audio has binded to. So set the bound gpu pci dev
> >>to vgaswitchroo, the correct audio id will be set in
> >>vgaswitchreoo enable function.
> >>
> >>Signed-off-by: Jim Qu 
> >The approach you've taken in this patch won't work if the HDA controller
> >is bound to a driver after both GPUs have already been bound to a driver
> >and the handler has already been registered.
> >
> >That's because vga_switcheroo_enable() is run when two GPUs have registered
> >as clients and the handler has also registered.  If the HDA controller is
> >probed afterwards, its ID will be stuck at VGA_SWITCHEROO_UNKNOWN_ID.
> 
> In genernic speaking, there are two cases , a. audio client is the third
> client. b. audio client is not the third client.
> 
> if audio is third client. vga_switcheroo_ready() is true,
> vga_switcheroo_enable() can be called in audio client register fuction.
> if audio is not the third client, vga_switcheroo_enable() will be called in
> the second GFX client register.
> In vga_switcheroo_enable() , the first list loop will set two GPU clients'
> id, and the second list loop will select audio client, set id by its bound
> gpu pci dev.

No, if audio is the third client, vga_switcheroo_ready() is *not* true
because vgasr_priv.active is true.  This is set to true once the two
GPUs and the handler have registered.  If the audio device registers
afterwards, vga_switcheroo_enable() will already have been called.
It's never called twice because it sets vgasr_priv.active = true.

As a result, the audio device is stuck at VGA_SWITCHEROO_UNKNOWN_ID.

Thanks,

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

Re: [PATCH 20/21] drm/msm: Add SDM845 DPU support

[Rob Clark]

On Tue, Jul 10, 2018 at 11:45 AM, Sean Paul  wrote:
> The patch was rejected for being too big. Please refer to
> https://gitlab.freedesktop.org/seanpaul/dpu-staging/commit/b4215cf040d1978287bd1403832ffc610659652b
>

heh, and also seems to be too big for gmail to reply to..

That said, +30k is a nice improvement over the +110k where this
started.  But a few comments..

+static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
+{
+   struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+   struct drm_device *dev = dpu_kms->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   unsigned int i;
+
+   for (i = 0; i < priv->num_crtcs; i++)
+   dpu_crtc_cancel_pending_flip(priv->crtcs[i], file);
+}

So, not totally a fan of bringing back preclose() from the dead, esp.
since it is only supposed to be used by legacy drivers.  Since all
this does is fire off pending events, I think it could be dropped
entirely... drm_events_release() should unlink unsent events from the
drm_file, and if that isn't working properly, that seems like a bug
that should be fixed in drm core.

+static int _dpu_core_irq_enable(struct dpu_kms *dpu_kms, int irq_idx)
+{
+   unsigned long irq_flags;
+   int ret = 0, enable_count;
+
+   if (!dpu_kms || !dpu_kms->hw_intr ||
+   !dpu_kms->irq_obj.enable_counts ||
+   !dpu_kms->irq_obj.irq_counts) {
+   DPU_ERROR("invalid params\n");
+   return -EINVAL;
+   }
+
+   if (irq_idx < 0 || irq_idx >= dpu_kms->hw_intr->irq_idx_tbl_size) {
+   DPU_ERROR("invalid IRQ index: [%d]\n", irq_idx);
+   return -EINVAL;
+   }
...
+int dpu_core_irq_enable(struct dpu_kms *dpu_kms, int *irq_idxs, u32 irq_count)
+{
+   int i, ret = 0, counts;
+
+   if (!dpu_kms || !irq_idxs || !irq_count) {
+   DPU_ERROR("invalid params\n");
+   return -EINVAL;
+   }
...


there is a *whole* lot of multiple levels of null checks like this for
things that are only ever called internally (ie. not something that
can be triggered by parameters passed from userspace).. which is
really unnecessary.

(maybe something that someone who knows coccinelle better than I,
could automate cleaning up?)


+/**
+ * dpu_core_irq_disable_nolock - disable core interrupt given by the index
+ *   without lock
+ * @dpu_kms:   Pointer to dpu kms context
+ * @irq_idx:   interrupt index
+ */
+int dpu_core_irq_disable_nolock(struct dpu_kms *dpu_kms, int irq_idx)
+{

appears to be unused?  dpu_core_irq_read_nolock() also seems unused,
and maybe some others.



diff --git a/include/uapi/media/msm_media_info.h
b/include/uapi/media/msm_media_info.h
new file mode 100644
index ..4f12e5c534c8
--- /dev/null
+++ b/include/uapi/media/msm_media_info.h
@@ -0,0 +1,1376 @@
+#ifndef __MEDIA_INFO_H__
+#define __MEDIA_INFO_H__
+
...


Not quite sure where this belongs, but (at least for now)
include/uapi/media seems very wrong.

Maybe just move into drm/msm for now?  We can always move it back to
include/uapi later (but the other direction isn't so cool)


--

Anyways, if I notice anything else to complain about, I'll send more
replies.  Overall it looks much better than where we started, and I'm
open to the idea of pulling it in to msm-next soon.  I think moving
msm_media_info.h out of uapi, and probably nuking preclose, should
happen first.


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

[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!

[bugzilla-daemon]

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

--- Comment #35 from Andrey Grodzovsky  ---
(In reply to dwagner from comment #30)
> (In reply to Andrey Grodzovsky from comment #29)
> > > (If that is a Mesa issue, no more than user processes / X11 should have
> > > crashed - but not the kernel amdgpu driver... right?)
> > 
> > Not exactly, MESA could create a bad request (faulty GPU address) which
> > would lead to this. It can even be triggered on purpose using a debug flag
> > from MESA.
> 
> My understanding is that all parts of MESA run as user processes, outside of
> the kernel space. If such code is allowed to pass parameters into kernel
> functions that make the kernel crash, that would be a veritable security
> hole which attackers could exploit to stage at least denial-of-service
> attacks, if not worse.

There is no impact on the kernlel, please note that this is a GPU page fault,
not CPU page fault so the kernel keeps working normal, doesn't hang and
workable. You might get black screen out of this and have to reboot the graphic
card or maybe the entire system to recover but I don't see any system security
and stability compromise here.

-- 
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: [alsa-devel] [V2 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[Lukas Wunner]

On Mon, Jul 16, 2018 at 03:52:45PM +0800, Hui Wang wrote:
> On 2018???07???16??? 14:06, Jim Qu wrote:
> >On modern laptop, there are more and more platforms
> >have two GPUs, and each of them maybe have audio codec
> >for HDMP/DP output. For some dGPU which is no output,
> >audio codec usually is disabled.
> >
> >In currect HDA audio driver, it will set all codec as
> >VGA_SWITCHEROO_DIS, the audio which is binded to UMA
> >will be suspended if user use debugfs to control power
> >
> >In HDA driver side, it is difficult to know which GPU
> >the audio has bound to. So set the bound gpu pci dev
> >to vgaswitchreoo, the correct audio id will be set in
> >vgaswitchreoo enable function.
> >
> >Signed-off-by: Jim Qu 
> 
> Is it possible to send this patch to  as well, then
> we will know that it is safe to backport this patch to the linux kernels
> with different version.

For which hardware do you want it in stable kernels?

This patch pertains to manual power control, which is only used on the
MacBook Pro by default.  And there are no MacBook Pros with AMD APUs.
On all other hardware, users have to specify "amdgpu.runpm=0" on the
command line to see any benefit from this patch.  Also, manual power
control will likely be removed once we get runtime PM working with
muxed systems (such as the MacBook Pro).

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

Re: [PATCH 05/21] drm/msm/dsi: adjust dsi timing for dual dsi mode

[Archit Taneja]

On Monday 09 July 2018 11:01 PM, Sean Paul wrote:

From: Chandan Uddaraju 

For dual dsi mode, the horizontal timing needs
to be divided by half since both the dsi controllers
will be driving this panel. Adjust the pixel clock and
DSI timing accordingly.


Reviewed-by: Archit Taneja 



Changes in V2:
--Removed Change-Id from the commit text tags.

Changes in V3:
--Instead of adjusting the DRM mode structure, divide
   the clocks and horizontal timings in DSI host just
   before configuring the values.

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/dsi/dsi.h |  6 ++-
  drivers/gpu/drm/msm/dsi/dsi_host.c| 55 +--
  drivers/gpu/drm/msm/dsi/dsi_manager.c |  7 ++--
  3 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a47acd..01c38f67d699 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -162,7 +162,8 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host 
*host,
  int msm_dsi_host_enable(struct mipi_dsi_host *host);
  int msm_dsi_host_disable(struct mipi_dsi_host *host);
  int msm_dsi_host_power_on(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_shared_timings *phy_shared_timings);
+   struct msm_dsi_phy_shared_timings *phy_shared_timings,
+   bool is_dual_dsi);
  int msm_dsi_host_power_off(struct mipi_dsi_host *host);
  int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
struct drm_display_mode *mode);
@@ -175,7 +176,8 @@ int msm_dsi_host_set_src_pll(struct mipi_dsi_host *host,
struct msm_dsi_pll *src_pll);
  void msm_dsi_host_reset_phy(struct mipi_dsi_host *host);
  void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_clk_request *clk_req);
+   struct msm_dsi_phy_clk_request *clk_req,
+   bool is_dual_dsi);
  void msm_dsi_host_destroy(struct mipi_dsi_host *host);
  int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 2f1a2780658a..671039b7b75b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -118,6 +118,7 @@ struct msm_dsi_host {
struct clk *byte_intf_clk;
  
  	u32 byte_clk_rate;

+   u32 pixel_clk_rate;
u32 esc_clk_rate;
  
  	/* DSI v2 specific clocks */

@@ -511,7 +512,7 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -592,7 +593,7 @@ static int dsi_link_clk_enable_v2(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -662,7 +663,7 @@ static void dsi_link_clk_disable(struct msm_dsi_host 
*msm_host)
}
  }
  
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)

+static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host, bool is_dual_dsi)
  {
struct drm_display_mode *mode = msm_host->mode;
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -676,14 +677,28 @@ static int dsi_calc_clk_rate(struct msm_dsi_host 
*msm_host)
}
  
  	pclk_rate = mode->clock * 1000;

+
+   /*
+* For dual DSI mode, the current DRM mode has
+* the complete width of the panel. Since, the complete
+* panel is driven by two DSI controllers, the
+* the clock rates have to be split between
+* the two dsi controllers. Adjust the byte and
+* pixel clock rates for each dsi host accordingly.
+*/
+   if (is_dual_dsi)
+   pclk_rate /= 2;
+
if (lanes > 0) {
msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
} else {
pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
}
+   msm_host->pixel_clk_rate = pclk_rate;
  
-	DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate);

+   DBG("pclk=%d, bclk=%d", msm_host->pixel_clk_rate,
+   msm_host->byte_clk_rate);
  
  	msm_host->esc_clk_rate = clk_get_rate(msm_host->esc_clk);
  
@@ -885,7 +900,7 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool enable,

Re: [PATCH 00/10] Improve crc-core driver interface

[Kumar, Mahesh]

Hi,

thanks for the review.


On 7/12/2018 4:38 PM, Laurent Pinchart wrote:

Hi Mahesh,

Thank you for the patches.

When resubmitting patch series, could you please add a version number to the
[PATCH] prefix ? Otherwise it gets difficult to figure out which version is
the latest. This can be done automatically with the -v argument to git-format-
patch.
sure :), added patch prefix (now v4) and re-floated the series after 
addressing review comments in patches 03/10, 08/10 & 10/10.


-Mahesh


On Thursday, 12 July 2018 11:36:25 EEST Mahesh Kumar wrote:

This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
  - Now control node will print all the available sources if
implemented by driver along with current source.
  - Setting of sorce will fail if provided source is not supported
  - cleanup of crtc_crc_open function first allocate memory before
enabling CRC generation
  - Don't block open() call instead wait in crc read call.

Following IGT will fail due to crc-core <-> driver interface change
igt@kms_pipe_crc_basic@bad-source 
ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X
ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X-frame-sequence
In nonblocking crc tests we'll get lesser crc's due to skipping crc

AMD/Rockchip/rcar code path is not validated and need inputs

Cc: dri-devel@lists.freedesktop.org

Mahesh Kumar (10):
   drm: crc: Introduce verify_crc_source callback
   drm: crc: Introduce get_crc_sources callback
   drm/rockchip/crc: Implement verify_crc_source callback
   drm/amdgpu_dm/crc: Implement verify_crc_source callback
   drm/rcar-du/crc: Implement verify_crc_source callback
   drm/i915/crc: implement verify_crc_source callback
   drm/i915/crc: implement get_crc_sources callback
   drm/crc: Cleanup crtc_crc_open function
   Revert "drm: crc: Wait for a frame before returning from open()"
   drm/rcar-du/crc: Implement get_crc_sources callback

  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |   1 +
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |   7 +-
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  |  20 +++-
  drivers/gpu/drm/drm_debugfs_crc.c  |  92 +---
  drivers/gpu/drm/i915/intel_display.c   |   2 +
  drivers/gpu/drm/i915/intel_drv.h   |   9 +-
  drivers/gpu/drm/i915/intel_pipe_crc.c  | 119 +-
  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  82 +++---
  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |   2 +
  drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   2 +
  drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  67 
  drivers/gpu/drm/rcar-du/rcar_du_kms.h  |   1 +
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  26 -
  include/drm/drm_crtc.h |  40 ++-
  14 files changed, 396 insertions(+), 74 deletions(-)


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

[Bug 107153] 4.18-rc3 crash on hdmi (0010:dm_update_crtcs_state+0x41e/0x4a0)

[bugzilla-daemon]

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

--- Comment #12 from Peter  ---
I'm running 4.18-rc4 on Slackware and I seem to have the same problem. My
system boots fine, but if I run startx with HDMI connected the system freezes
with a black screen and I get the bug in my kernel log.

I can start KDE and then connect HDMI and that seems to work fine. I even get
HDMI audio. If I close KDE, I then get the black screen and bug.

My system is a Ryzen 2700x, ASUS Prime x470-Pro motherboard, Radeon RX 470
video card. I have a monitor connected with DisplayPort and an AV receiver
connected with HDMI for sound. There is a TV connected to the receiver's
output, which is usually switched off.

Interestingly, I'm also using an Onkyo AV receiver. Mine's a TX-NR515AE. If I
unplug the receiver, unplug my monitor from DisplayPort and connect the monitor
with HDMI, my system starts KDE fine and HDMI audio plays from the monitor's
speakers.

I spent some time crashing and rebooting my system to find the combination that
didn't work. Turning everything off between attempts and starting with
everything turned off:

Leave AV receiver off. Turn on computer. Start KDE. Bug.

Turn on AV receiver. Turn on computer. Start KDE. Bug.

Turn on AV receiver. Turn on TV. Turn on computer. Start KDE. No bug. Monitor
and TV both work as expected. HDMI audio works.

Turn on AV receiver. Turn on TV. Turn *off* TV. Turn on computer. Start KDE. No
bug. Monitor works as expected. HDMI audio works.

I have a hunch that the AV receiver gets HDMI data from the TV. If the TV
hasn't been on, the receiver feeds odd data to the PC and hits this bug. I
don't know how to troubleshoot this further.

I also get two warnings in my kernel log on boot before starting KDE that
disappear if I unplug the AV receiver. I don't know if they're relevant.


Bug:

[   37.762733] kernel BUG at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4829!
[   37.762742] invalid opcode:  [#1] SMP NOPTI
[   37.762746] CPU: 7 PID: 1477 Comm: Xorg Tainted: GW
4.18.0-rc4 #1
[   37.762747] Hardware name: System manufacturer System Product Name/PRIME
X470-PRO, BIOS 4011 04/19/2018
[   37.762804] RIP: 0010:dm_update_crtcs_state+0x458/0x4d0 [amdgpu]
[   37.762805] Code: ff ff 48 85 db 0f 84 d9 fd ff ff 48 c7 44 24 18 00 00 00
00 48 c7 44 24 08 00 00 00 00 48 c7 04 24 00 00 00 00 e9 91 fe ff ff <0f> 0b 48
83 c4 30 b8 ea ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 
[   37.762828] RSP: 0018:b04c0083baa0 EFLAGS: 00010246
[   37.762831] RAX: 925fca3ea401 RBX:  RCX:
02f7
[   37.762832] RDX: 02f6 RSI: 925fdede4160 RDI:
925fde806e80
[   37.762834] RBP: 925fca3a1880 R08: 00024160 R09:
c095be2e
[   37.762836] R10: df2c9028fa00 R11: f080 R12:
0001
[   37.762837] R13: 925fca3ea000 R14: 925fca3ecc00 R15:
925fc8965000
[   37.762839] FS:  7fbb6af6fd40() GS:925fdedc()
knlGS:
[   37.762841] CS:  0010 DS:  ES:  CR0: 80050033
[   37.762842] CR2: 7ffc9f29bfa8 CR3: 0003fa86a000 CR4:
003406e0
[   37.762844] Call Trace:
[   37.762901]  amdgpu_dm_atomic_check+0x1bc/0x3a0 [amdgpu]
[   37.762919]  drm_atomic_check_only+0x360/0x510 [drm]
[   37.762935]  drm_atomic_commit+0x13/0x50 [drm]
[   37.762944]  drm_atomic_helper_set_config+0x75/0x80 [drm_kms_helper]
[   37.762959]  __drm_mode_set_config_internal+0x67/0x120 [drm]
[   37.762974]  drm_mode_setcrtc+0x412/0x610 [drm]
[   37.762988]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[   37.763001]  drm_ioctl_kernel+0xa1/0xf0 [drm]
[   37.763014]  drm_ioctl+0x1fc/0x390 [drm]
[   37.763028]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[   37.763066]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[   37.763071]  do_vfs_ioctl+0xa4/0x620
[   37.763075]  ? __x64_sys_futex+0x143/0x180
[   37.763078]  ksys_ioctl+0x60/0x90
[   37.763080]  __x64_sys_ioctl+0x16/0x20
[   37.763084]  do_syscall_64+0x55/0x100
[   37.763088]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   37.763091] RIP: 0033:0x7fbb68da2297
[   37.763092] Code: b3 66 90 48 8b 05 f1 1b 2d 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d c1 1b 2d 00 f7 d8 64 89 01 48 
[   37.763114] RSP: 002b:7fffe459de58 EFLAGS: 3246 ORIG_RAX:
0010
[   37.763116] RAX: ffda RBX: 7fffe459de90 RCX:
7fbb68da2297
[   37.763117] RDX: 7fffe459de90 RSI: c06864a2 RDI:
0016
[   37.763119] RBP: 7fffe459de90 R08:  R09:
028314f0
[   37.763120] R10: 7fffe459df50 R11: 3246 R12:
c06864a2
[   37.763122] R13: 0016 R14:  R15:
028314f0
[   37.763124] Modules linked in: ipv6 cfg80211 8021q garp mrp stp llc
nls_iso8859_1 nls_cp437 vfat fat fuse joydev hid_generic usbhid hid amdkfd
amd_iommu_v2 snd_hda_codec_realtek 

Re: [PATCH 07/21] drm/msm/dsi: initialize postdiv_lock before use for 10nm pll

[Archit Taneja]

On Monday 09 July 2018 11:01 PM, Sean Paul wrote:

From: Rajesh Yadav 

postdiv_lock spinlock was used before initialization
for 10nm pll. It causes following spin_bug:
"BUG: spinlock bad magic on CPU#0".
Initialize spinlock before its usage.


Reviewed-by: Archit Taneja 



Signed-off-by: Rajesh Yadav 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index c4c37a7df637..4c03f0b7343e 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -798,6 +798,8 @@ struct msm_dsi_pll *msm_dsi_pll_10nm_init(struct 
platform_device *pdev, int id)
return ERR_PTR(-ENOMEM);
}
  
+	spin_lock_init(_10nm->postdiv_lock);

+
pll = _10nm->base;
pll->min_rate = 10UL;
pll->max_rate = 35UL;


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

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

--- Comment #47 from Thomas Martitz  ---
So pci_raw_set_power_state() does a pci_read_config_word() and that returns a
valid word. Yet, the device appears to be not in powerd up state later on.
How's that possible, and why does it work on Windows?

Can I inspect Windows behavior in some way to get insight?

Since Windows works I'm sure there must be a SW fix (or at least a workaround)
available. Perhaps just wait for a bit?

-- 
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: [Freedreno] [PATCH 09/21] drm/msm/mdp5: subclass msm_mdss for mdp5

[Archit Taneja]

On Monday 09 July 2018 11:01 PM, Sean Paul wrote:

From: Rajesh Yadav 

SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.

Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.

Add mdss helper interface (msm_mdss_funcs) to msm_mdss
base for mdp5/dpu mdss specific implementation calls.

This change subclasses msm_mdss for mdp5, dpu specific
changes will be done separately.


Reviewed-by: Archit Taneja 



Changes in v3:
- none

Changes in v2:
- fixed indentation for irq_domain_add_linear call (Sean Paul)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
[seanpaul rebased on msm-next and resolved conflicts]
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154 --
  drivers/gpu/drm/msm/msm_drv.c |  22 +++-
  drivers/gpu/drm/msm/msm_kms.h |  17 ++-
  3 files changed, 109 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
index f2a0db7a8a03..1cc4e57f0226 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
@@ -20,12 +20,10 @@
  #include "msm_drv.h"
  #include "mdp5_kms.h"
  
-/*

- * If needed, this can become more specific: something like struct mdp5_mdss,
- * which contains a 'struct msm_mdss base' member.
- */
-struct msm_mdss {
-   struct drm_device *dev;
+#define to_mdp5_mdss(x) container_of(x, struct mdp5_mdss, base)
+
+struct mdp5_mdss {
+   struct msm_mdss base;
  
  	void __iomem *mmio, *vbif;
  
@@ -41,22 +39,22 @@ struct msm_mdss {

} irqcontroller;
  };
  
-static inline void mdss_write(struct msm_mdss *mdss, u32 reg, u32 data)

+static inline void mdss_write(struct mdp5_mdss *mdp5_mdss, u32 reg, u32 data)
  {
-   msm_writel(data, mdss->mmio + reg);
+   msm_writel(data, mdp5_mdss->mmio + reg);
  }
  
-static inline u32 mdss_read(struct msm_mdss *mdss, u32 reg)

+static inline u32 mdss_read(struct mdp5_mdss *mdp5_mdss, u32 reg)
  {
-   return msm_readl(mdss->mmio + reg);
+   return msm_readl(mdp5_mdss->mmio + reg);
  }
  
  static irqreturn_t mdss_irq(int irq, void *arg)

  {
-   struct msm_mdss *mdss = arg;
+   struct mdp5_mdss *mdp5_mdss = arg;
u32 intr;
  
-	intr = mdss_read(mdss, REG_MDSS_HW_INTR_STATUS);

+   intr = mdss_read(mdp5_mdss, REG_MDSS_HW_INTR_STATUS);
  
  	VERB("intr=%08x", intr);
  
@@ -64,7 +62,7 @@ static irqreturn_t mdss_irq(int irq, void *arg)

irq_hw_number_t hwirq = fls(intr) - 1;
  
  		generic_handle_irq(irq_find_mapping(

-   mdss->irqcontroller.domain, hwirq));
+   mdp5_mdss->irqcontroller.domain, hwirq));
intr &= ~(1 << hwirq);
}
  
@@ -84,19 +82,19 @@ static irqreturn_t mdss_irq(int irq, void *arg)
  
  static void mdss_hw_mask_irq(struct irq_data *irqd)

  {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
  
  	smp_mb__before_atomic();

-   clear_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   clear_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
  }
  
  static void mdss_hw_unmask_irq(struct irq_data *irqd)

  {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
  
  	smp_mb__before_atomic();

-   set_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   set_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
  }
  
@@ -109,13 +107,13 @@ static struct irq_chip mdss_hw_irq_chip = {

  static int mdss_hw_irqdomain_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hwirq)
  {
-   struct msm_mdss *mdss = d->host_data;
+   struct mdp5_mdss *mdp5_mdss = d->host_data;
  
  	if (!(VALID_IRQS & (1 << hwirq)))

return -EPERM;
  
  	irq_set_chip_and_handler(irq, _hw_irq_chip, handle_level_irq);

-   irq_set_chip_data(irq, mdss);
+   irq_set_chip_data(irq, mdp5_mdss);
  
  	return 0;

  }
@@ -126,90 +124,99 @@ static const struct irq_domain_ops mdss_hw_irqdomain_ops 
= {
  };
  
  
-static int mdss_irq_domain_init(struct msm_mdss *mdss)

+static int mdss_irq_domain_init(struct mdp5_mdss *mdp5_mdss)
  {
-   struct device *dev = mdss->dev->dev;
+   struct device *dev = mdp5_mdss->base.dev->dev;
struct irq_domain *d;
  
  	d = irq_domain_add_linear(dev->of_node, 32, _hw_irqdomain_ops,

- mdss);
+ mdp5_mdss);
if (!d) {
dev_err(dev, "mdss irq domain add failed\n");
return -ENXIO;
}
  
-	

Re: [PATCH] drm: re-enable error handling

[Sean Paul]

On Sat, Jul 14, 2018 at 02:32:12PM +0200, Nicholas Mc Guire wrote:
> drm_legacy_ctxbitmap_next() returns idr_alloc() which can return
> -ENOMEM, -EINVAL or -ENOSPC none of which are -1 . but the call sites 
> of drm_legacy_ctxbitmap_next() seem to be assuming that the error case
> would be -1 (original return of drm_ctxbitmap_next() prior to 2.6.23
> was actually -1). Thus reenable error handling by checking for < 0.
> 
> Signed-off-by: Nicholas Mc Guire 

Thanks for your patch, I've applied it to drm-misc-fixes.

Sean

> Fixes: 62968144e673 ("drm: convert drm context code to use Linux idr")
> ---
> 
> Problem located with experimental coccinelle script
> 
> The noted Fixes tag is one of the commits that removed the -1 return
> value in 2.6.23 in drm_ctxbitmap_next() but thats not the only change
> that must have taken place to invalidate the error check.
> 
> Patch was compile tested with: x86_64_defconfig
> 
> Patch is against 4.18-rc4 (localversion-next is next-20180713)
> 
>  drivers/gpu/drm/drm_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
> index 3c4000f..f973d28 100644
> --- a/drivers/gpu/drm/drm_context.c
> +++ b/drivers/gpu/drm/drm_context.c
> @@ -372,7 +372,7 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
>   ctx->handle = drm_legacy_ctxbitmap_next(dev);
>   }
>   DRM_DEBUG("%d\n", ctx->handle);
> - if (ctx->handle == -1) {
> + if (ctx->handle < 0) {
>   DRM_DEBUG("Not enough free contexts.\n");
>   /* Should this return -EBUSY instead? */
>   return -ENOMEM;
> -- 
> 2.1.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] efifb: BGRT: Do not copy the boot graphics for non native resolutions

[Hans de Goede]

On x86 some firmwares use a low non native resolution for the display when
they have shown some text messages. While keeping the bgrt filled with info
for the native resolution. If the bgrt image intended for the native
resolution still fits, it will be displayed very close to the right edge of
the display looking quite bad.

This commits adds a (heuristics based) checks for this and makes efifb
not show the boot graphics when this is the case.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/efifb.c | 43 +
 1 file changed, 43 insertions(+)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index fa01eecc0a55..52bf39f93888 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -111,6 +111,46 @@ static void efifb_copy_bmp(u8 *src, u32 *dst, int width, 
struct screen_info *si)
}
 }
 
+#ifdef CONFIG_X86
+/*
+ * On x86 some firmwares use a low non native resolution for the display when
+ * they have shown some text messages. While keeping the bgrt filled with info
+ * for the native resolution. If the bgrt image intended for the native
+ * resolution still fits, it will be displayed very close to the right edge of
+ * the display looking quite bad. This function checks for this.
+ */
+static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)
+{
+   static const int default_resolutions[][2] = {
+   {  800,  600 },
+   { 1024,  768 },
+   { 1280, 1024 },
+   };
+   u32 i, right_margin;
+
+   for (i = 0; i < ARRAY_SIZE(default_resolutions); i++) {
+   if (default_resolutions[i][0] == si->lfb_width &&
+   default_resolutions[i][1] == si->lfb_height)
+   break;
+   }
+   /* If not a default resolution used for textmode, this should be fine */
+   if (i >= ARRAY_SIZE(default_resolutions))
+   return true;
+
+   /* If the right margin is 5 times smaller then the left one, reject */
+   right_margin = si->lfb_width - (bgrt_tab.image_offset_x + bmp_width);
+   if (right_margin < (bgrt_tab.image_offset_x / 5))
+   return false;
+
+   return true;
+}
+#else
+static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)
+{
+   return true;
+}
+#endif
+
 static void efifb_show_boot_graphics(struct fb_info *info)
 {
u32 bmp_width, bmp_height, bmp_pitch, screen_pitch, dst_x, y, src_y;
@@ -169,6 +209,9 @@ static void efifb_show_boot_graphics(struct fb_info *info)
(bgrt_tab.image_offset_y + bmp_height) > si->lfb_height)
goto error;
 
+   if (!efifb_bgrt_sanity_check(si, bmp_width))
+   goto error;
+
pr_info("efifb: showing boot graphics\n");
 
for (y = 0; y < si->lfb_height; y++, dst += si->lfb_linelength) {
-- 
2.17.1

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

[PATCH] video: fbdev: tridentfb: remove deadcode on unreachable case statement

[Colin King]

From: Colin Ian King 

The value of tmp being used in the switch statement has the range of
just 0..3 hence the case 4 statement can never be reached and is
deadcode and can be removed.

Detected by CoverityScan, CID#744384 ("Logically dead code")

Signed-off-by: Colin Ian King 
---
 drivers/video/fbdev/tridentfb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index 284706184b1b..f4b745590600 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -777,9 +777,6 @@ static int get_nativex(struct tridentfb_par *par)
case 3:
x = 800; y = 600;
break;
-   case 4:
-   x = 1400; y = 1050;
-   break;
case 1:
default:
x = 640;  y = 480;
-- 
2.17.1

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

[PATCH 3/3] ALSA: hda: Make audio component support more generic

[Takashi Iwai]

This is the final step for more generic support of DRM audio
component.  The generic audio component code is now moved to its own
file, and the symbols are renamed from snd_hac_i915_* to
snd_hdac_acomp_*, respectively.  The generic code is enabled via the
new kconfig, CONFIG_SND_HDA_COMPONENT, while CONFIG_SND_HDA_I915 is
kept as the super-class.

Along with the split, three new callbacks are added to audio_ops:
pin2port is for providing the conversion between the pin number and
the widget id, and master_bind/master_unbin are called at binding /
unbinding the master component, respectively.  All these are optional,
but used in i915 implementation and also other later implementations.

A note about the new snd_hdac_acomp_init() function: there is a slight
difference between this and the old snd_hdac_i915_init().  The latter
(still) synchronizes with the master component binding, i.e. it
assures that the relevant DRM component gets bound when it returns, or
gives a negative error.  Meanwhile the new function doesn't
synchronize but just leaves as is.  It's the responsibility by the
caller's side to synchronize, or the caller may accept the
asynchronous binding on the fly.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/Kconfig  |   1 +
 include/drm/drm_audio_component.h |  23 ++
 include/sound/hda_component.h |  61 ++
 include/sound/hda_i915.h  |  39 +---
 sound/hda/Kconfig |   7 +-
 sound/hda/Makefile|   1 +
 sound/hda/hdac_component.c| 332 +
 sound/hda/hdac_i915.c | 343 ++
 sound/pci/hda/patch_hdmi.c|  50 +++--
 sound/soc/codecs/hdac_hdmi.c  |   8 +-
 10 files changed, 483 insertions(+), 382 deletions(-)
 create mode 100644 include/sound/hda_component.h
 create mode 100644 sound/hda/hdac_component.c

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd95889f4b7..5c607f2c707b 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
select SYNC_FILE
select IOSF_MBI
select CRC32
+   select SND_HDA_I915 if SND_HDA_CORE
help
  Choose this option if you have a system that has "Intel Graphics
  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/include/drm/drm_audio_component.h 
b/include/drm/drm_audio_component.h
index f310b28404e8..746a5afc3970 100644
--- a/include/drm/drm_audio_component.h
+++ b/include/drm/drm_audio_component.h
@@ -24,6 +24,8 @@
 #ifndef _DRM_AUDIO_COMPONENT_H_
 #define _DRM_AUDIO_COMPONENT_H_
 
+struct drm_audio_component;
+
 /**
  * struct drm_audio_component_ops - Ops implemented by DRM driver, called by 
hda driver
  */
@@ -92,6 +94,27 @@ struct drm_audio_component_audio_ops {
 * mode).
 */
void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
+   /**
+* @pin2port: Check and convert from pin node to port number
+*
+* Called by HDA driver to check and convert from the pin widget node
+* number to a port number in the graphics side.
+*/
+   int (*pin2port)(void *audio_ptr, int pin);
+   /**
+* @master_bind: (Optional) component master bind callback
+*
+* Called at binding master component, for HDA codec-specific
+* handling of dynamic binding.
+*/
+   int (*master_bind)(struct device *dev, struct drm_audio_component *);
+   /**
+* @master_unbind: (Optional) component master unbind callback
+*
+* Called at unbinding master component, for HDA codec-specific
+* handling of dynamic unbinding.
+*/
+   void (*master_unbind)(struct device *dev, struct drm_audio_component *);
 };
 
 /**
diff --git a/include/sound/hda_component.h b/include/sound/hda_component.h
new file mode 100644
index ..78626cde7081
--- /dev/null
+++ b/include/sound/hda_component.h
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+// HD-Audio helpers to sync with DRM driver
+
+#ifndef __SOUND_HDA_COMPONENT_H
+#define __SOUND_HDA_COMPONENT_H
+
+#include 
+
+#ifdef CONFIG_SND_HDA_COMPONENT
+int snd_hdac_set_codec_wakeup(struct hdac_bus *bus, bool enable);
+int snd_hdac_display_power(struct hdac_bus *bus, bool enable);
+int snd_hdac_sync_audio_rate(struct hdac_device *codec, hda_nid_t nid,
+int dev_id, int rate);
+int snd_hdac_acomp_get_eld(struct hdac_device *codec, hda_nid_t nid, int 
dev_id,
+  bool *audio_enabled, char *buffer, int max_bytes);
+int snd_hdac_acomp_init(struct hdac_bus *bus,
+   const struct drm_audio_component_audio_ops *aops,
+   int (*match_master)(struct device *, void *),
+   size_t extra_size);
+int snd_hdac_acomp_exit(struct hdac_bus *bus);
+int snd_hdac_acomp_register_notifier(struct hdac_bus *bus,
+   

[PATCH 0/3] Make the audio component binding more generic

[Takashi Iwai]

Hi,

this is a preliminiary patch set to convert the existing i915 /
HD-audio component binding to be applicable to other drivers like
radeon / amdgpu.  This patchset itself doesn't change the
functionality but only renames and split to a new drm_audio_component
stuff from i915_audio_component.

The actual usage of the new API will follow once after this one gets
reviewed / accepted.  The whole patches (including this patchset) are
found in topic/hda-acomp branch of sound.git tree.

BTW, since the whole stuff is about the audio binding, I suppose these
will go through sound git tree.  Let me know if anyone has concerns.


Thanks!

Takashi

===

Takashi Iwai (3):
  drm/i915: Split audio component to a generic type
  ALSA: hda/i915: Associate audio component with devres
  ALSA: hda: Make audio component support more generic

 drivers/gpu/drm/i915/Kconfig   |   1 +
 drivers/gpu/drm/i915/intel_audio.c |  22 +-
 include/drm/drm_audio_component.h  | 138 
 include/drm/i915_component.h   |  85 +---
 include/sound/hda_component.h  |  61 ++
 include/sound/hda_i915.h   |  37 +---
 include/sound/hdaudio.h|   6 +-
 sound/hda/Kconfig  |   7 +-
 sound/hda/Makefile |   1 +
 sound/hda/hdac_component.c | 332 
 sound/hda/hdac_i915.c  | 335 ++---
 sound/pci/hda/patch_hdmi.c |  57 +++--
 sound/soc/codecs/hdac_hdmi.c   |  10 +-
 13 files changed, 624 insertions(+), 468 deletions(-)
 create mode 100644 include/drm/drm_audio_component.h
 create mode 100644 include/sound/hda_component.h
 create mode 100644 sound/hda/hdac_component.c

-- 
2.18.0

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

[PATCH 2/3] ALSA: hda/i915: Associate audio component with devres

[Takashi Iwai]

The HD-audio i915 binding code contains a single pointer, hdac_acomp,
for allowing the access to audio component from the master bind/unbind
callbacks.  This was needed because the callbacks pass only the device
pointer and we can't guarantee the object type assigned to the drvdata
(which is free for each controller driver implementation).
And this implementation will be a problem if we support multiple
components for different DRM drivers, not only i915.

As a solution, allocate the audio component object via devres and
associate it with the given device, so that the component callbacks
can refer to it via devres_find().

The removal of the object is still done half-manually via
devres_destroy() to make the code consistent (although it may work
without the explicit call).

Also, the snd_hda_i915_register_notifier() had the reference to
hdac_acomp as well.  In this patch, the corresponding code is removed
by passing hdac_bus object to the function, too.

Signed-off-by: Takashi Iwai 
---
 include/sound/hda_i915.h |  6 --
 sound/hda/hdac_i915.c| 34 +-
 sound/pci/hda/patch_hdmi.c   |  5 +++--
 sound/soc/codecs/hdac_hdmi.c |  2 +-
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/include/sound/hda_i915.h b/include/sound/hda_i915.h
index f69ea84e7b65..648263791559 100644
--- a/include/sound/hda_i915.h
+++ b/include/sound/hda_i915.h
@@ -17,7 +17,8 @@ int snd_hdac_acomp_get_eld(struct hdac_device *codec, 
hda_nid_t nid, int dev_id,
   bool *audio_enabled, char *buffer, int max_bytes);
 int snd_hdac_i915_init(struct hdac_bus *bus);
 int snd_hdac_i915_exit(struct hdac_bus *bus);
-int snd_hdac_i915_register_notifier(const struct drm_audio_component_audio_ops 
*);
+int snd_hdac_i915_register_notifier(struct hdac_bus *bus,
+   const struct drm_audio_component_audio_ops 
*ops);
 #else
 static inline int snd_hdac_set_codec_wakeup(struct hdac_bus *bus, bool enable)
 {
@@ -49,7 +50,8 @@ static inline int snd_hdac_i915_exit(struct hdac_bus *bus)
 {
return 0;
 }
-static inline int snd_hdac_i915_register_notifier(const struct 
drm_audio_component_audio_ops *ops)
+static inline int snd_hdac_i915_register_notifier(struct hdac_bus *bus,
+ const struct 
drm_audio_component_audio_ops *ops)
 {
return -ENODEV;
 }
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index 1a88c1aaf9bb..861b77bbc7df 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -22,7 +22,14 @@
 #include 
 #include 
 
-static struct drm_audio_component *hdac_acomp;
+static void hdac_acomp_release(struct device *dev, void *res)
+{
+}
+
+static struct drm_audio_component *hdac_get_acomp(struct device *dev)
+{
+   return devres_find(dev, hdac_acomp_release, NULL, NULL);
+}
 
 /**
  * snd_hdac_set_codec_wakeup - Enable / disable HDMI/DP codec wakeup
@@ -262,7 +269,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_acomp_get_eld);
 
 static int hdac_component_master_bind(struct device *dev)
 {
-   struct drm_audio_component *acomp = hdac_acomp;
+   struct drm_audio_component *acomp = hdac_get_acomp(dev);
int ret;
 
ret = component_bind_all(dev, acomp);
@@ -294,7 +301,7 @@ static int hdac_component_master_bind(struct device *dev)
 
 static void hdac_component_master_unbind(struct device *dev)
 {
-   struct drm_audio_component *acomp = hdac_acomp;
+   struct drm_audio_component *acomp = hdac_get_acomp(dev);
 
module_put(acomp->ops->owner);
component_unbind_all(dev, acomp);
@@ -314,6 +321,7 @@ static int hdac_component_master_match(struct device *dev, 
void *data)
 
 /**
  * snd_hdac_i915_register_notifier - Register i915 audio component ops
+ * @bus: HDA core bus
  * @aops: i915 audio component ops
  *
  * This function is supposed to be used only by a HD-audio controller
@@ -323,12 +331,13 @@ static int hdac_component_master_match(struct device 
*dev, void *data)
  *
  * Returns zero for success or a negative error code.
  */
-int snd_hdac_i915_register_notifier(const struct drm_audio_component_audio_ops 
*aops)
+int snd_hdac_i915_register_notifier(struct hdac_bus *bus,
+   const struct drm_audio_component_audio_ops 
*aops)
 {
-   if (!hdac_acomp)
+   if (!bus->audio_component)
return -ENODEV;
 
-   hdac_acomp->audio_ops = aops;
+   bus->audio_component->audio_ops = aops;
return 0;
 }
 EXPORT_SYMBOL_GPL(snd_hdac_i915_register_notifier);
@@ -365,18 +374,19 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
struct drm_audio_component *acomp;
int ret;
 
-   if (WARN_ON(hdac_acomp))
+   if (WARN_ON(hdac_get_acomp(dev)))
return -EBUSY;
 
if (!i915_gfx_present())
return -ENODEV;
 
-   i915_acomp = kzalloc(sizeof(*i915_acomp), GFP_KERNEL);
+   i915_acomp = devres_alloc(hdac_acomp_release, 

[PATCH 1/3] drm/i915: Split audio component to a generic type

[Takashi Iwai]

For allowing other drivers to use the DRM audio component, rename the
i915_audio_component_* with drm_audio_component_*, and split the
generic part into drm_audio_component.h.  The i915 specific stuff
remains in struct i915_audio_component, which contains
drm_audio_component as the base.

This is a preliminary change for further development, and no
functional changes by this patch itself, merely code-split and
renames.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/intel_audio.c |  22 +++---
 include/drm/drm_audio_component.h  | 115 +
 include/drm/i915_component.h   |  85 ++---
 include/sound/hda_i915.h   |   6 +-
 include/sound/hdaudio.h|   6 +-
 sound/hda/hdac_i915.c  |  40 +-
 sound/pci/hda/patch_hdmi.c |   8 +-
 sound/soc/codecs/hdac_hdmi.c   |   2 +-
 8 files changed, 164 insertions(+), 120 deletions(-)
 create mode 100644 include/drm/drm_audio_component.h

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 3ea566f99450..7dd5605d94ae 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -639,11 +639,12 @@ void intel_audio_codec_enable(struct intel_encoder 
*encoder,
dev_priv->av_enc_map[pipe] = encoder;
mutex_unlock(_priv->av_mutex);
 
-   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+   if (acomp && acomp->base.audio_ops &&
+   acomp->base.audio_ops->pin_eld_notify) {
/* audio drivers expect pipe = -1 to indicate Non-MST cases */
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
pipe = -1;
-   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
+   
acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
 (int) port, (int) pipe);
}
 
@@ -681,11 +682,12 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
dev_priv->av_enc_map[pipe] = NULL;
mutex_unlock(_priv->av_mutex);
 
-   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+   if (acomp && acomp->base.audio_ops &&
+   acomp->base.audio_ops->pin_eld_notify) {
/* audio drivers expect pipe = -1 to indicate Non-MST cases */
if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
pipe = -1;
-   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
+   
acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
 (int) port, (int) pipe);
}
 
@@ -880,7 +882,7 @@ static int i915_audio_component_get_eld(struct device 
*kdev, int port,
return ret;
 }
 
-static const struct i915_audio_component_ops i915_audio_component_ops = {
+static const struct drm_audio_component_ops i915_audio_component_ops = {
.owner  = THIS_MODULE,
.get_power  = i915_audio_component_get_power,
.put_power  = i915_audio_component_put_power,
@@ -897,12 +899,12 @@ static int i915_audio_component_bind(struct device 
*i915_kdev,
struct drm_i915_private *dev_priv = kdev_to_i915(i915_kdev);
int i;
 
-   if (WARN_ON(acomp->ops || acomp->dev))
+   if (WARN_ON(acomp->base.ops || acomp->base.dev))
return -EEXIST;
 
drm_modeset_lock_all(_priv->drm);
-   acomp->ops = _audio_component_ops;
-   acomp->dev = i915_kdev;
+   acomp->base.ops = _audio_component_ops;
+   acomp->base.dev = i915_kdev;
BUILD_BUG_ON(MAX_PORTS != I915_MAX_PORTS);
for (i = 0; i < ARRAY_SIZE(acomp->aud_sample_rate); i++)
acomp->aud_sample_rate[i] = 0;
@@ -919,8 +921,8 @@ static void i915_audio_component_unbind(struct device 
*i915_kdev,
struct drm_i915_private *dev_priv = kdev_to_i915(i915_kdev);
 
drm_modeset_lock_all(_priv->drm);
-   acomp->ops = NULL;
-   acomp->dev = NULL;
+   acomp->base.ops = NULL;
+   acomp->base.dev = NULL;
dev_priv->audio_component = NULL;
drm_modeset_unlock_all(_priv->drm);
 }
diff --git a/include/drm/drm_audio_component.h 
b/include/drm/drm_audio_component.h
new file mode 100644
index ..f310b28404e8
--- /dev/null
+++ b/include/drm/drm_audio_component.h
@@ -0,0 +1,115 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * 

[Bug 107065] "BUG: unable to handle kernel paging request at 0000000000002000" in amdgpu_vm_cpu_set_ptes at amdgpu_vm.c:921

[bugzilla-daemon]

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

--- Comment #26 from Andrey Grodzovsky  ---
(In reply to dwagner from comment #25)
> Created attachment 140634 [details]
> dmesg before and after S3 sleep with commit "updating plane ..." reverted

Reverting the patch makes the TTM eviction failure + following driver resume
failure go away. So that one issue. Another issue Is that you still experience
page table updates realated fault during S3. I can't reproduce that issue. 

I am currently looking into how this patch broke S3, this is more burning issue
as other people experience it to. Later i will try to give you some debug
printk patch to sort out your page fault issue.

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