[PATCHv2 00/31] drm/omap: patches for v4.6 part 1

[Laurent Pinchart]

Hi Tomi,

Thank you for the patches.

On Friday 26 February 2016 11:35:48 Tomi Valkeinen wrote:
> Hi,
> 
> Here's a collection of patches for omapdrm. Some of them have been sent for
> review at some point, most of them haven't.
> 
> There are two bigger features in the series: dmabuf import support and HDMI
> interlace output support. Otherwise they are smaller improvements, fixes and
> cleanups.
> 
> Changes to v1 of the series:
> 
> - Dropped the following patches, which need a bit more work:
>   * HACK: drm/omap: fix memory barrier bug in DMM driver
>   * drm/omap: partial workaround for DRA7 DMM errata i878
> 
> - Cosmetic fixes addressing the review comments

For patches 17-19, 21-27 and 29,

Acked-by: Laurent Pinchart 

> Jyri Sarha (1):
>   drm/omap: drm_atomic_get_plane_state() may return ERR_PTR
> 
> Laurent Pinchart (3):
>   drm/omap: gem: Clean up GEM objects memory flags
>   drm/omap: gem: Refactor GEM object allocation
>   drm/omap: gem: Implement dma_buf import
> 
> Manisha Agrawal (3):
>   drm/omap: tpd12s015: remove platform data support
>   drm/omap: tpd12s015: gpio descriptor API
>   drm/omap: tpd12s015: CT_CP_HPD as optional gpio
> 
> Rob Clark (1):
>   drm/omap: EBUSY status handling in omap_gem_fault()
> 
> Tomi Valkeinen (23):
>   drm/omap: HDMI: change enable/disable to avoid sync-losts
>   HACK: drm/omap: always use blocking DMM fill
>   drm/omap: add dmm_read() and dmm_write() wrappers
>   drm/omap: add define for DISPC_IRQ_WBUNCOMPLETEERROR
>   drm/omap: use dma_mapping_error in omap_gem_attach_pages
>   drm/omap: use dma_mapping_error in omap_gem_dma_sync
>   drm/omap: print an error if display enable fails
>   drm/omap: remove support for ext mem & sync
>   drm/omap: increase vblank wait timeout
>   drm/omap: DISPC: support double-pixel mode
>   drm/omap: support double-pixel
>   drm/omap: HDMI: support double-pixel pixel clock
>   drm/omap: HDMI: Fix HSW value
>   drm/omap: HDMI: fix WP timings for ilace
>   drm/omap: DISPC: Fix field order for HDMI
>   drm/omap: HDMI5: Fix FC HSW value
>   drm/omap: HDMI5: clean up timings copy
>   drm/omap: HDMI5: Add interlace support
>   drm/omap: HDMI5: allow interlace
>   drm/omap: verify that display x-res is divisible by 8
>   drm/omap: verify that fb plane pitches are the same
>   drm/omap: fix crtc->plane property delegation
>   drm/omap: check if rotation is supported before commit
> 
>  .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   | 118 ++--
>  drivers/gpu/drm/omapdrm/dss/dispc.c|  20 ++
>  drivers/gpu/drm/omapdrm/dss/dpi.c  |   3 +
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c|  23 +-
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c|  27 +-
>  drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  42 ++-
>  drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  32 +-
>  drivers/gpu/drm/omapdrm/omap_connector.c   |   4 +
>  drivers/gpu/drm/omapdrm/omap_crtc.c|  69 +++--
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |  54 +++-
>  drivers/gpu/drm/omapdrm/omap_drv.h |   3 +
>  drivers/gpu/drm/omapdrm/omap_encoder.c |   6 +-
>  drivers/gpu/drm/omapdrm/omap_fb.c  |  16 +
>  drivers/gpu/drm/omapdrm/omap_gem.c | 328 ++
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  53 +++-
>  drivers/gpu/drm/omapdrm/omap_plane.c   |   6 +
>  include/video/omap-panel-data.h|  15 -
>  include/video/omapdss.h|   3 +
>  18 files changed, 502 insertions(+), 320 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCHv2 20/31] drm/omap: HDMI: Fix HSW value

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Friday 26 February 2016 11:36:08 Tomi Valkeinen wrote:
> On OMAP4 and OMAP5 ES1.0 the HDMI_WP_VIDEO_TIMING_H:HSW field is
> set directly to the HSW value. On later SoCs the field needs to be
> programmed with the value of HSW-1.
> 
> Currently the driver always programs the field with the HSW value. Most
> videomodes seem to work fine with that, but at least low resolution
> interlaced modes don't work at all.
> 
> This patch fixes the HSW for OMAP5 ES2.0+ SoCs.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c index 7c544bc56fb5..48ffb39663c8
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
> @@ -165,12 +165,24 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data
> *wp, {
>   u32 timing_h = 0;
>   u32 timing_v = 0;
> + bool hsw_minus_one = true;
> 
>   DSSDBG("Enter hdmi_wp_video_config_timing\n");
> 
> + /*
> +  * On OMAP4 and OMAP5 ES1 the HSW field is programmed as is. On OMAP5
> +  * ES2+ (including DRA7/AM5 SoCs) HSW field is programmed to hsw-1.
> +  * However, we don't support OMAP5 ES1 at all, so we can just check for
> +  * OMAP4 here.
> +  */
> + if (omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES1 ||
> + omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES2 ||
> + omapdss_get_version() == OMAPDSS_VER_OMAP4)
> + hsw_minus_one = false;
> +
>   timing_h |= FLD_VAL(timings->hbp, 31, 20);
>   timing_h |= FLD_VAL(timings->hfp, 19, 8);
> - timing_h |= FLD_VAL(timings->hsw, 7, 0);
> + timing_h |= FLD_VAL(timings->hsw - (hsw_minus_one ? 1 : 0), 7, 0);

If you named the variable hsw_offset, make it an unsigned int, initialized it 
to 1 and set it to 0 instead of false, you could write this as

timing_h |= FLD_VAL(timings->hsw - hsw_offset, 7, 0);

>   hdmi_write_reg(wp->base, HDMI_WP_VIDEO_TIMING_H, timing_h);
> 
>   timing_v |= FLD_VAL(timings->vbp, 31, 20);

-- 
Regards,

Laurent Pinchart

[PATCHv2 11/31] drm/omap: print an error if display enable fails

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.
On Friday 26 February 2016 11:35:59 Tomi Valkeinen wrote:
> If the panel's enable fails, omap_encoder silently ignores the failure.
> omapdrm should really handle the failure, but unfortunately the whole
> encoder enable codepath is expected to always succeed.
> 
> So for now, catch the enable failure and print an error.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

You might want to add a line break to keep the dev_err within the 80 
characters per column limit.

> ---
>  drivers/gpu/drm/omapdrm/omap_encoder.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
> b/drivers/gpu/drm/omapdrm/omap_encoder.c index 61714e9670ae..ae347cc19f01
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
> @@ -139,11 +139,15 @@ static void omap_encoder_enable(struct drm_encoder
> *encoder) struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
>   struct omap_dss_device *dssdev = omap_encoder->dssdev;
>   struct omap_dss_driver *dssdrv = dssdev->driver;
> + int r;
> 
>   omap_encoder_update(encoder, omap_crtc_channel(encoder->crtc),
>   omap_crtc_timings(encoder->crtc));
> 
> - dssdrv->enable(dssdev);
> + r = dssdrv->enable(dssdev);
> + if (r)
> + dev_err(encoder->dev->dev, "Failed to enable display '%s': 
> %d\n",
> + dssdev->name, r);
>  }
> 
>  static int omap_encoder_atomic_check(struct drm_encoder *encoder,

-- 
Regards,

Laurent Pinchart

[PATCHv2 10/31] drm/omap: use dma_mapping_error in omap_gem_dma_sync

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Friday 26 February 2016 11:35:58 Tomi Valkeinen wrote:
> omap_gem_dma_sync() calls dma_map_page() but does not check the possible
> error with dma_mapping_error(). If DMA-API debugging is enabled, the
> debug layer will give a warning if dma_mapping_error() has not been
> used.
> 
> This patch adds proper error handling to omap_gem_dma_sync().
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_gem.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c index cb541d6b3c2b..21989d3518f2
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -776,9 +776,20 @@ void omap_gem_dma_sync(struct drm_gem_object *obj,
> 
>   for (i = 0; i < npages; i++) {
>   if (!omap_obj->addrs[i]) {
> - omap_obj->addrs[i] = dma_map_page(dev->dev, 
> pages[i], 0,
> + dma_addr_t addr;
> +
> + addr = dma_map_page(dev->dev, pages[i], 0,
>   PAGE_SIZE, DMA_BIDIRECTIONAL);
> +
> + if (dma_mapping_error(dev->dev, addr)) {
> + dev_warn(dev->dev,
> + "%s: failed to map page\n",
> + __func__);
> + break;
> + }
> +
>   dirty = true;
> + omap_obj->addrs[i] = addr;
>   }
>   }

-- 
Regards,

Laurent Pinchart

[PATCHv2 01/31] drm/omap: HDMI: change enable/disable to avoid sync-losts

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Friday 26 February 2016 11:35:49 Tomi Valkeinen wrote:
> We occasionally see DISPC sync-lost errors when enabling and disabling
> HDMI. Sometimes we get only a few, which get handled (ignored) by the
> driver, but sometimes there's a flood of the errors which doesn't seem
> to stop.
> 
> The HW team has root caused this to the order in which HDMI and DISPC
> are enabled/disabled. Currently we enable HDMI first, and then DISPC,
> and vice versa when disabling. HW team's suggestion is to do it the
> other way around.
> 
> This patch changes the order, but this has two side effects as the pixel
> clock is produced by HDMI, and the clock is not running when we
> enable/disable DISPC:
> 
> * When enabling DISPC first, we don't get vertical sync events
> * When disabling DISPC last, we don't get FRAMEDONE event
> 
> At the moment we use both of those to verify that DISPC has been
> enabled/disabled properly. Thus this patch also needs to change the
> omapdrm and omapdss which handle the DISPC side.
> 
> Signed-off-by: Tomi Valkeinen 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c | 16 
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c | 16 
>  drivers/gpu/drm/omapdrm/omap_crtc.c |  5 +
>  3 files changed, 21 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index 7103c659a534..b09ce9ee82fa
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -214,22 +214,22 @@ static int hdmi_power_on_full(struct omap_dss_device
> *dssdev) /* tv size */
>   dss_mgr_set_timings(mgr, p);
> 
> - r = hdmi_wp_video_start();
> - if (r)
> - goto err_vid_enable;
> -
>   r = dss_mgr_enable(mgr);
>   if (r)
>   goto err_mgr_enable;
> 
> + r = hdmi_wp_video_start();
> + if (r)
> + goto err_vid_enable;
> +
>   hdmi_wp_set_irqenable(wp,
>   HDMI_IRQ_LINK_CONNECT | HDMI_IRQ_LINK_DISCONNECT);
> 
>   return 0;
> 
> -err_mgr_enable:
> - hdmi_wp_video_stop();
>  err_vid_enable:
> + dss_mgr_disable(mgr);
> +err_mgr_enable:
>   hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);
>  err_phy_pwr:
>  err_phy_cfg:
> @@ -246,10 +246,10 @@ static void hdmi_power_off_full(struct omap_dss_device
> *dssdev)
> 
>   hdmi_wp_clear_irqenable(, 0x);
> 
> - dss_mgr_disable(mgr);
> -
>   hdmi_wp_video_stop();
> 
> + dss_mgr_disable(mgr);
> +
>   hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);
> 
>   dss_pll_disable();
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi5.c index a955a2c4c061..4485a1c37bd8
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> @@ -231,22 +231,22 @@ static int hdmi_power_on_full(struct omap_dss_device
> *dssdev) /* tv size */
>   dss_mgr_set_timings(mgr, p);
> 
> - r = hdmi_wp_video_start();
> - if (r)
> - goto err_vid_enable;
> -
>   r = dss_mgr_enable(mgr);
>   if (r)
>   goto err_mgr_enable;
> 
> + r = hdmi_wp_video_start();
> + if (r)
> + goto err_vid_enable;
> +
>   hdmi_wp_set_irqenable(,
>   HDMI_IRQ_LINK_CONNECT | HDMI_IRQ_LINK_DISCONNECT);
> 
>   return 0;
> 
> -err_mgr_enable:
> - hdmi_wp_video_stop();
>  err_vid_enable:
> + dss_mgr_disable(mgr);
> +err_mgr_enable:
>   hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);
>  err_phy_pwr:
>  err_phy_cfg:
> @@ -263,10 +263,10 @@ static void hdmi_power_off_full(struct omap_dss_device
> *dssdev)
> 
>   hdmi_wp_clear_irqenable(, 0x);
> 
> - dss_mgr_disable(mgr);
> -
>   hdmi_wp_video_stop();
> 
> + dss_mgr_disable(mgr);
> +
>   hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);
> 
>   dss_pll_disable();
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c index 2ed0754ed19e..7dd3d44a93e5
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -138,6 +138,11 @@ static void omap_crtc_set_enabled(struct drm_crtc
> *crtc, bool enable) u32 framedone_irq, vsync_irq;
>   int ret;
> 
> + if (omap_crtc->mgr->output->output_type == OMAP_DISPLAY_TYPE_HDMI) {
> + dispc_mgr_enable(channel, enable);
> + return;
> + }
> +
>   if (dispc_mgr_is_enabled(channel) == enable)
>   return;

-- 
Regards,

Laurent Pinchart

[PATCHv2 09/31] drm/omap: use dma_mapping_error in omap_gem_attach_pages

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Friday 26 February 2016 11:35:57 Tomi Valkeinen wrote:
> omap_gem_attach_pages() calls dma_map_page() but does not check the
> possible error with dma_mapping_error(). If DMA-API debugging is
> enabled, the debug layer will give a warning if dma_mapping_error() has
> not been used.
> 
> This patch adds proper error handling to omap_gem_attach_pages().
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c index 8495a1a4b617..cb541d6b3c2b
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -264,6 +264,19 @@ static int omap_gem_attach_pages(struct drm_gem_object
> *obj) for (i = 0; i < npages; i++) {
>   addrs[i] = dma_map_page(dev->dev, pages[i],
>   0, PAGE_SIZE, DMA_BIDIRECTIONAL);
> +
> + if (dma_mapping_error(dev->dev, addrs[i])) {
> + dev_warn(dev->dev,
> + "%s: failed to map page\n", __func__);
> +
> + for (i = i - 1; i >= 0; --i) {
> + dma_unmap_page(dev->dev, addrs[i],
> + PAGE_SIZE, DMA_BIDIRECTIONAL);
> + }
> +
> + ret = -ENOMEM;
> + goto free_addrs;
> + }
>   }
>   } else {
>   addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
> @@ -278,6 +291,8 @@ static int omap_gem_attach_pages(struct drm_gem_object
> *obj)
> 
>   return 0;
> 
> +free_addrs:
> + kfree(addrs);
>  free_pages:
>   drm_gem_put_pages(obj, pages, true, false);

-- 
Regards,

Laurent Pinchart

[PATCHv2 02/31] HACK: drm/omap: always use blocking DMM fill

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Friday 26 February 2016 11:35:50 Tomi Valkeinen wrote:
> The current driver uses non-blocking DMM fill when releasing memory.
> This gives us a small performance increase as we don't have to wait for
> the fill operation to finish.
> 
> However, the driver does not have any error handling for non-blocking
> fill. In case of an error, the fill operation may silently fail, leading
> to leaking DMM engines, which may eventually lead to deadlock if we run
> out of DMM engines.
> 
> This patch makes the DMM driver always use blocking fills, so that we
> can catch the errors. A more complex option would be to allow
> non-blocking fills, and implement proper error handling, but that is
> left for the future.
> 
> This patch is a HACK, as the proper fix is to either decide to always
> use sync fills and remove all the async related code, or fix the async
> code.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index dfebdc4aa0f2..67edf839dce3
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -309,6 +309,21 @@ static int fill(struct tcm_area *area, struct page
> **pages, struct tcm_area slice, area_s;
>   struct dmm_txn *txn;
> 
> + /*
> +  * FIXME
> +  *
> +  * Asynchronous fill does not work reliably, as the driver does not
> +  * handle errors in the async code paths. The fill operation may
> +  * silently fail, leading to leaking DMM engines, which may eventually
> +  * lead to deadlock if we run out of DMM engines.
> +  *
> +  * For now, always set 'wait' so that we only use sync fills. Async
> +  * fills should be fixed, or alternatively we could decide to only
> +  * support sync fills and so the whole async code path could be removed.
> +  */
> +
> + wait = true;
> +
>   txn = dmm_txn_init(omap_dmm, area->tcm);
>   if (IS_ERR_OR_NULL(txn))
>   return -ENOMEM;

-- 
Regards,

Laurent Pinchart

[Bug 93144] [radeonsi] Alien: Isolation feature request

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

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

--- Comment #21 from Luzipher  ---
(In reply to Marek Olšák from comment #20)
> Why is this bug called "feature request"?

I guess the feature requested is compute shaders ;-) Or GL 4.3 of course, if
you prefer.

To clarify: the game wants GL 4.3 and the game devs said it'd require compute
shaders - yet it runs on radeonsi (GL 4.1), but with heavy psychedelic
flickering (see attachements).

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

drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc.

[Dan Carpenter]

Hello Mario Kleiner,

The patch e1d09dc0ccc6: "drm/amdgpu: Don't hang in
amdgpu_flip_work_func on disabled crtc." from Feb 19, 2016, leads to
the following static checker warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:127 amdgpu_flip_work_func() warn: 
should this be 'repcnt == -1'
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() error: 
double unlock 'spin_lock:>dev->event_lock'
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() error: 
double unlock 'irqsave:flags'


drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
64  static void amdgpu_flip_work_func(struct work_struct *__work)
65  {
66  struct amdgpu_flip_work *work =
67  container_of(__work, struct amdgpu_flip_work, 
flip_work);
68  struct amdgpu_device *adev = work->adev;
69  struct amdgpu_crtc *amdgpuCrtc = 
adev->mode_info.crtcs[work->crtc_id];
70  
71  struct drm_crtc *crtc = >base;
72  unsigned long flags;
73  unsigned i, repcnt = 4;
74  int vpos, hpos, stat, min_udelay = 0;
75  struct drm_vblank_crtc *vblank = 
>dev->vblank[work->crtc_id];
76  
77  if (amdgpu_flip_handle_fence(work, >excl))
78  return;
79  
80  for (i = 0; i < work->shared_count; ++i)
81  if (amdgpu_flip_handle_fence(work, >shared[i]))
82  return;
83  
84  /* We borrow the event spin lock for protecting flip_status */
85  spin_lock_irqsave(>dev->event_lock, flags);
86  
87  /* If this happens to execute within the "virtually extended" 
vblank
88   * interval before the start of the real vblank interval then 
it needs
89   * to delay programming the mmio flip until the real vblank is 
entered.
90   * This prevents completing a flip too early due to the way we 
fudge
91   * our vblank counter and vblank timestamps in order to work 
around the
92   * problem that the hw fires vblank interrupts before actual 
start of
93   * vblank (when line buffer refilling is done for a frame). It
94   * complements the fudging logic in 
amdgpu_get_crtc_scanoutpos() for
95   * timestamping and amdgpu_get_vblank_counter_kms() for vblank 
counts.
96   *
97   * In practice this won't execute very often unless on very fast
98   * machines because the time window for this to happen is very 
small.
99   */
   100  while (amdgpuCrtc->enabled && repcnt--) {
  
Exists the loop with spin_lock held and repcnt == -1.


   101  /* GET_DISTANCE_TO_VBLANKSTART returns distance to real 
vblank
   102   * start in hpos, and to the "fudged earlier" vblank 
start in
   103   * vpos.
   104   */
   105  stat = amdgpu_get_crtc_scanoutpos(adev->ddev, 
work->crtc_id,
   106
GET_DISTANCE_TO_VBLANKSTART,
   107, , NULL, 
NULL,
   108>hwmode);
   109  
   110  if ((stat & (DRM_SCANOUTPOS_VALID | 
DRM_SCANOUTPOS_ACCURATE)) !=
   111  (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE) ||
   112  !(vpos >= 0 && hpos <= 0))
   113  break;
   114  
   115  /* Sleep at least until estimated real start of hw 
vblank */
   116  spin_unlock_irqrestore(>dev->event_lock, flags);
   117  min_udelay = (-hpos + 1) * max(vblank->linedur_ns / 
1000, 5);
   118  if (min_udelay > vblank->framedur_ns / 2000) {
   119  /* Don't wait ridiculously long - something is 
wrong */
   120  repcnt = 0;

Exit with spin_lock released and repcnt == 0.

   121  break;
   122  }
   123  usleep_range(min_udelay, 2 * min_udelay);
   124  spin_lock_irqsave(>dev->event_lock, flags);
   125  };
   126  
   127  if (!repcnt)
 ^^
Assumes exit with zero.

   128  DRM_DEBUG_DRIVER("Delay problem on crtc %d: min_udelay 
%d, "
   129   "framedur %d, linedur %d, stat %d, 
vpos %d, "
   130   "hpos %d\n", work->crtc_id, min_udelay,
   131   vblank->framedur_ns / 1000,
   132   vblank->linedur_ns / 1000, stat, vpos, 
hpos);
   133  
   134  /* set the flip status */
   135  amdgpuCrtc->pflip_status = AMDGPU_FLIP_SUBMITTED;
   136  

[Bug 93826] 144Hz graphic glitches and bad refresh rate

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

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

--- Comment #19 from Alex Deucher  ---
(In reply to Damien from comment #18)
> Alex thank you for your return.
> 
> Since my monitor works from scratch with a 7950 or fury but not with three
> 290X tested, is that it is possible to retrieve the values that work ?

The same algorithm is used on all of those parts.  The only reason there would
be different dividers selected would be if the pll limits in the vbios or the
reference clock were different.  However, looking at various vbioses for those
different asics indicate that the vbios limits are the same for all of them.  I
doubt they would be different on your boards.  As such. that combination of
dividers seems to be disagreeable to your monitor on that specific hw.  The
underlying hw implementation of the pll varies a bit from asic to asic, so the
pll selection probably needs to be tweaked a bit for that hw to be stable at
that combination as per comment 17.

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

[Bug 93826] 144Hz graphic glitches and bad refresh rate

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

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

--- Comment #18 from Damien  ---
Alex thank you for your return.

Since my monitor works from scratch with a 7950 or fury but not with three 290X
tested, is that it is possible to retrieve the values that work ?

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

[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

[Ville Syrjälä]

On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote:
> Interlaced video can have different scan order:
> Top Field First or Bottom Field First
> 
> In case of video with interlaced content, this information should be
> propagated from the userland to the DRM kernel driver that will process the
> deinterlacing starting with the top or the bottom field first.
> That's why we introduce this new flag definition DRM_MODE_FB_BFF (Bottom Field
> First) that should be used jointly with the already existing
> DRM_MODE_FB_INTERLACED flag incase of interlaced video with Bottom Field First
> scan order should be processed.

The way I envisioned this long ago is that we would specify the
bff/tff at flip time. In fact we already have the
DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD flags for
setplane. When doing bob deinterlacing these would choose the field
we're going to present, and when doing interlaced scanout these would
choose tff vs. bff. But that approach does fall short with atomic when
you want to flip multiple planes at once.

One problem I see with making this part of the FB is that if you already
missed your original deadline for the first field, and you want to
actually present the second field instead, you're forced to create
another fb. So a plane property might be a bit more flexible. And the
same way as the setplane flags we could then share the properties for
bob deinterlacing field selection as well. There's no way to do bob
deinterlacing with fb flags, unless you create a separate fb for each
field.

-- 
Ville Syrjälä
Intel OTC

boot hang with vmwgfx on 4.5-rc6

[Sebastian Herbszt]

Hello,

I get a boot hang with vmwgfx on 4.5-rc6 (4.5.0-rc6-1.gb239884-default from
openSUSE). This happens on VMware Player 5.0.2.
Same VM works fine with kernel 4.4 but on 4.5-rc6 it hangs with

[drm] Initialized vmwgfx 2.9.0 20150810 for :00:0f.0 on minor 0

I am able to boot the system with "nomodeset".

Sebastian

[PATCH v6 2/7] drm: add parameter-order checking to drm memory allocators

[Dave Gordon]

After the recent addition of drm_malloc_gfp(), it was noticed that
some callers of these functions has swapped the parameters in the
call - it's supposed to be 'number of members' and 'sizeof(element)',
but a few callers had got the size first and the count second. This
isn't otherwise detected because they're both type 'size_t', and
the implementation at present just multiplies them anyway, so the
result is still right. But some future implementation might treat
them differently (e.g. allowing 0 elements but not zero size), so
let's add some compile-time checks and complain if the second (size)
parameter isn't a sizeof() expression, or at least a compile-time
constant.

This patch also fixes those callers where the order was wrong.

v6: removed duplicate BUILD_BUG_ON_MSG(); avoided renaming functions
by shadowing them with #defines and then calling the function
(non-recursively!) from inside the #define [Chris Wilson]

Signed-off-by: Dave Gordon 
Cc: Chris Wilson 
Cc: Ville Syrjälä Cc: dri-
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  8 
 include/drm/drm_mem_util.h   | 27 ---
 3 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 1aba01a..9ae4a71 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -340,7 +340,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
 */
bos = drm_malloc_ab(args->nr_bos, sizeof(*bos));
relocs = drm_malloc_ab(args->nr_relocs, sizeof(*relocs));
-   stream = drm_malloc_ab(1, args->stream_size);
+   stream = drm_malloc_ab(args->stream_size, sizeof(*stream));
cmdbuf = etnaviv_gpu_cmdbuf_new(gpu, ALIGN(args->stream_size, 8) + 8,
args->nr_bos);
if (!bos || !relocs || !stream || !cmdbuf) {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f734b3c..1a136d9 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1686,8 +1686,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
}

/* Copy in the exec list from userland */
-   exec_list = drm_malloc_ab(sizeof(*exec_list), args->buffer_count);
-   exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count);
+   exec_list = drm_malloc_ab(args->buffer_count, sizeof(*exec_list));
+   exec2_list = drm_malloc_ab(args->buffer_count, sizeof(*exec2_list));
if (exec_list == NULL || exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
  args->buffer_count);
@@ -1775,8 +1775,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
return -EINVAL;
}

-   exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
-   args->buffer_count,
+   exec2_list = drm_malloc_gfp(args->buffer_count,
+   sizeof(*exec2_list),
GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
index 741ce75..5b0111c 100644
--- a/include/drm/drm_mem_util.h
+++ b/include/drm/drm_mem_util.h
@@ -29,7 +29,7 @@

 #include 

-static __inline__ void *drm_calloc_large(size_t nmemb, size_t size)
+static __inline__ void *drm_calloc_large(size_t nmemb, const size_t size)
 {
if (size != 0 && nmemb > SIZE_MAX / size)
return NULL;
@@ -41,8 +41,15 @@ static __inline__ void *drm_calloc_large(size_t nmemb, 
size_t size)
 GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO, PAGE_KERNEL);
 }

+#definedrm_calloc_large(nmemb, size)   
\
+({ \
+   BUILD_BUG_ON_MSG(!__builtin_constant_p(size),   \
+   "Non-constant 'size' - check argument ordering?");  \
+   (drm_calloc_large)(nmemb, size);\
+})
+
 /* Modeled after cairo's malloc_ab, it's like calloc but without the zeroing. 
*/
-static __inline__ void *drm_malloc_ab(size_t nmemb, size_t size)
+static __inline__ void *drm_malloc_ab(size_t nmemb, const size_t size)
 {
if (size != 0 && nmemb > SIZE_MAX / size)
return NULL;
@@ -54,7 +61,14 @@ static __inline__ void *drm_malloc_ab(size_t nmemb, size_t 
size)
 GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL);
 }

-static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
+#definedrm_malloc_ab(nmemb, size)   

[PATCH v6 1/7] drm,i915: introduce drm_malloc_gfp()

[Dave Gordon]

From: Chris Wilson 

I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want
to try a high-order kmalloc() before using a vmalloc().

So refactor my usage into drm_malloc_gfp().

Signed-off-by: Chris Wilson 
Cc: dri-devel at lists.freedesktop.org
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie 
Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  8 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  5 +++--
 drivers/gpu/drm/i915/i915_gem_userptr.c| 15 ---
 include/drm/drm_mem_util.h | 19 +++
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1328bc5..f734b3c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1775,11 +1775,9 @@ static bool only_mappable_for_reloc(unsigned int flags)
return -EINVAL;
}

-   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (exec2_list == NULL)
-   exec2_list = drm_malloc_ab(sizeof(*exec2_list),
-  args->buffer_count);
+   exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
+   args->buffer_count,
+   GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
  args->buffer_count);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 49e4f26..6af2462 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3416,8 +3416,9 @@ struct i915_vma *
int ret = -ENOMEM;

/* Allocate a temporary list of source pages for random access. */
-   page_addr_list = drm_malloc_ab(obj->base.size / PAGE_SIZE,
-  sizeof(dma_addr_t));
+   page_addr_list = drm_malloc_gfp(obj->base.size / PAGE_SIZE,
+   sizeof(dma_addr_t),
+   GFP_TEMPORARY);
if (!page_addr_list)
return ERR_PTR(ret);

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 4b09c84..4c98c8c 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -494,10 +494,7 @@ struct get_pages_work {
ret = -ENOMEM;
pinned = 0;

-   pvec = kmalloc(npages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (pvec == NULL)
-   pvec = drm_malloc_ab(npages, sizeof(struct page *));
+   pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;

@@ -634,14 +631,10 @@ struct get_pages_work {
pvec = NULL;
pinned = 0;
if (obj->userptr.mm->mm == current->mm) {
-   pvec = kmalloc(num_pages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
+   pvec = drm_malloc_gfp(num_pages, sizeof(struct page *), 
GFP_TEMPORARY);
if (pvec == NULL) {
-   pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
-   if (pvec == NULL) {
-   __i915_gem_userptr_set_active(obj, false);
-   return -ENOMEM;
-   }
+   __i915_gem_userptr_set_active(obj, false);
+   return -ENOMEM;
}

pinned = __get_user_pages_fast(obj->userptr.ptr, num_pages,
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
index e42495a..741ce75 100644
--- a/include/drm/drm_mem_util.h
+++ b/include/drm/drm_mem_util.h
@@ -54,6 +54,25 @@ static __inline__ void *drm_malloc_ab(size_t nmemb, size_t 
size)
 GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL);
 }

+static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
+{
+   if (size != 0 && nmemb > SIZE_MAX / size)
+   return NULL;
+
+   if (size * nmemb <= PAGE_SIZE)
+   return kmalloc(nmemb * size, gfp);
+
+   if (gfp & __GFP_RECLAIMABLE) {
+   void *ptr = kmalloc(nmemb * size,
+   gfp | __GFP_NOWARN | __GFP_NORETRY);
+   if (ptr)
+   return ptr;
+   }
+
+   return __vmalloc(size * nmemb,
+gfp | __GFP_HIGHMEM, PAGE_KERNEL);
+}
+
 static __inline void drm_free_large(void *ptr)
 {
   

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Rob Clark]

On Mon, Feb 29, 2016 at 7:47 PM, Thulasimani, Sivakumar
 wrote:
>
>
> On 3/1/2016 5:03 AM, Rob Clark wrote:
>>
>> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter  wrote:
>>>
>>> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:


 On 2/24/2016 3:41 AM, Lyude wrote:
>
> As it turns out, resuming DP MST is racey since we don't make sure MST
> is ready before we start modesetting, it just usually happens to be
> ready in time. This isn't the case on all systems, particularly a
> ThinkPad T560 with displays connected through the dock. On these
> systems, resuming the laptop while connected to the dock usually
> results
> in blank monitors. Making sure MST is ready before doing any kind of
> modesetting fixes this issue.

 basic question since i haven't worked on MST much. MST should work like
 any
 other digital panel on resume. i.e detect followed by modeset. in the
 modified
 commit mentioned below is it failing to detect the panel or failing at
 the
 modeset ?
 if we are depending on the intel_display_resume, how about moving the
 intel_dp_mst_resume just above intel_display_resume?


 Generic question to others in mail list on i915_drm_resume
 we are doing a modeset and then doing the detect/hpd init.
 shouldn't this be the other way round ? almost all displays
 will pass a modeset even if display is not connected so we
 are spending time on modeset even for displays that were
 removed during the suspend state. if this is to simply
 drm_state being saved and restored,
>>>
>>> We must restore anyway, we're not really allowed to shut down a display
>>> without userspace's consent. DP mst breaks this, and it's not fun really.
>>
>> well, that isn't completely true.. I mean, if the user unplugs (for
>> example) an hdmi monitor, it isn't with userspace's consent..
>>
>> I wonder if we could just have flag per connector, ie.
>> connector->no_auto_resume and just automatically send unplug events
>> for those to userspace (followed shortly by a plug event if it is
>> still connected and the normal hpd mechanism kicks in?  I mean, for
>> all we know, the user unplugged the DP monitor/hub/etc and plugged in
>> a different one while we were suspended..
>>
>> BR,
>> -R
>
> i agree. performing a modeset on a display without even confirming
> if it is the same one when we had suspended the system will result in
> issues such as applying a mode that may not be supported on the
> new display or corruption or blankout or simply failing the modeset
> restore or worst case of doing modeset without a display connected.
> if we will not allow such a scenario during normal operation, i.e prevent
> incorrect modeset requests during normal functioning, why allow such
> a modeset during suspend-resume alone ?
> we can store the edid hash and if the display has the same hash
> post resume then we can allow mode to be restored.

that seems like a good idea for HDMI/DVI/etc.. although I suspect for
DP there may be 50 more shades of grey.. ie. same monitor re-attached
through different sequence of hubs.. :-(

BR,
-R


> regards,
> Sivakumar
>
>>> So for hotunplug the flow should always be:
>>> 1. kernel notices something has changed in the output config.
>>> 2. kernel sends out uevent
>>> 3. userspace figures out what changed, and what needs to be done
>>> 4. userspace asks the kernel to change display configuration through
>>> setCrtc and Atomic ioctl calls.
>>>
>>> Irrespective of hotunplug handling, the kernel also _must_ restore the
>>> entire display configuration before userspace resumes. We can do that
>>> asynchronously (and there's plans for that), but even then we must stall
>>> userspace on the first KMS ioclt to keep up the illusion that a system
>>> s/r
>>> is transparent.
>>>
>>> In short, even if we do hpd processing before resuming the display,
>>> nothing will be faster - we must wait for userspace to make up its mind,
>>> and that can only happen once we've restored the display config.
>>>
>>> And again, mst is kinda breaking this, since and mst unplug results in a
>>> force-disable. Which can upset userspace and in general results in the
>>> need for lots of fragile error handling all over.
>>>
> We originally changed the resume order in
>
>  commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw
> state")
>
> to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
> issue now anyhow.
>
> CC: stable at vger.kernel.org
> Signed-off-by: Lyude 
>>>
>>> Wrt the patch itself: I think only in 4.6 we've actually fixed up all
>>> these mst WARN_ON. Cc: stable seems extremely risky on this one. Also,
>>> the
>>> modeset state readout for mst is still not entirely correct (it still
>>> relies on software state), so I'm not sure we've actually managed to shut
>>> up all the WARNINGs. Iirc the way to repro them is 

[PATCH 2/2] drm/dp: add DPCD/AUX logging

[Ville Syrjälä]

On Thu, Feb 25, 2016 at 04:15:06PM -0500, Rob Clark wrote:
> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
> with troublesome monitors.
> 
> v2: don't try to hexdump the universe if driver returns -errno, and
> change the "too many retries" traces to DRM_ERROR()
> v3: rename to more generic "AUX" instead of DP specific DPCD, add
> DP_AUX_I2C_WRITE_STATUS_UPDATE
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 62 
> +
>  include/drm/drmP.h  |  8 +-
>  2 files changed, 58 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index df64ed1..3ef35fd 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -160,6 +160,45 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
>  }
>  EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>  
> +static ssize_t aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> *msg)
> +{
> + ssize_t ret;
> +
> + DRM_DEBUG_AUX("%s: req=0x%02x, address=0x%05x, size=%zu\n", aux->name,
> + msg->request, msg->address, msg->size);

Bunch of stuff doesn't seem to be indented quite right in this patch.
This being one of them.

> +
> + if (unlikely(drm_debug & DRM_UT_AUX)) {
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
> + 16, 1, msg->buffer, msg->size, false);

That shouldn't say "DPCD", at least for i2c.

> + break;
> + default:
> + break;
> + }
> + }
> +
> + ret = aux->transfer(aux, msg);
> +
> + DRM_DEBUG_AUX("%s: reply=0x%02x, size=%zd\n", aux->name, msg->reply, 
> ret);
> +
> + if (unlikely(drm_debug & DRM_UT_AUX) && (ret > 0)) {
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
> + 16, 1, msg->buffer, ret, false);

ditto

Otherwise looks all right.

> + break;
> + default:
> + break;
> + }
> + }
> +
> + return ret;
> +}
> +
>  #define AUX_RETRY_INTERVAL 500 /* us */
>  
>  /**
> @@ -197,7 +236,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>*/
>   for (retry = 0; retry < 32; retry++) {
>  
> - err = aux->transfer(aux, );
> + err = aux_transfer(aux, );
>   if (err < 0) {
>   if (err == -EBUSY)
>   continue;
> @@ -205,7 +244,6 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>   goto unlock;
>   }
>  
> -
>   switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
>   case DP_AUX_NATIVE_REPLY_ACK:
>   if (err < size)
> @@ -213,16 +251,18 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, 
> u8 request,
>   goto unlock;
>  
>   case DP_AUX_NATIVE_REPLY_NACK:
> + DRM_DEBUG_AUX("native nack (result=%d, size=%zu)\n", 
> err, msg.size);
>   err = -EIO;
>   goto unlock;
>  
>   case DP_AUX_NATIVE_REPLY_DEFER:
> + DRM_DEBUG_AUX("native defer\n");
>   usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 
> 100);
>   break;
>   }
>   }
>  
> - DRM_DEBUG_KMS("too many retries, giving up\n");
> + DRM_ERROR("DPCD: too many retries, giving up!\n");
>   err = -EIO;
>  
>  unlock:
> @@ -549,12 +589,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   int max_retries = max(7, drm_dp_i2c_retry_count(msg, 
> dp_aux_i2c_speed_khz));
>  
>   for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c); 
> retry++) {
> - ret = aux->transfer(aux, msg);
> + ret = aux_transfer(aux, msg);
>   if (ret < 0) {
>   if (ret == -EBUSY)
>   continue;
>  
> - DRM_DEBUG_KMS("transaction failed: %d\n", ret);
> + DRM_DEBUG_AUX("transaction failed: %d\n", ret);
>   return ret;
>   }
>  
> @@ -568,11 +608,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   break;
>  
>   case DP_AUX_NATIVE_REPLY_NACK:
> - DRM_DEBUG_KMS("native nack (result=%d, size=%zu)\n", 
> ret, msg->size);
> +

[PATCH] dma-buf/fence: fix fence_is_later v2

[Gustavo Padovan]

2016-02-29 Alex Deucher :

> From: Christian König 
> 
> A fence is never later than itself. This caused a bunch of overhead for 
> AMDGPU.
> 
> v2: simplify check as suggested by Michel.
> 
> Signed-off-by: Christian König 
> Reviewed-by: Michel Dänzer 
> Reviewed-by: Alex Deucher 
> Signed-off-by: Alex Deucher 
> ---
>  include/linux/fence.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

Hi Maarten,

2016-02-29 Maarten Lankhorst :

> Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> > From: Gustavo Padovan 
> >
> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> > optimize buffer allocation. In the new approach the ioctl needs to be called
> > twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
> >
> > The first call should pass num_fences = 0, the kernel will then fill
> > info->num_fences. Userspace receives back the number of fences and
> > allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> > info->sync_fence_info.
> >
> > It then call the ioctl again passing num_fences received in 
> > info->num_fences.
> > The kernel checks if info->num_fences > 0 and if yes it fill
> > info->sync_fence_info with an array containing all fence_infos.
> >
> > info->len now represents the length of the buffer sync_fence_info points
> > to. Also, info->sync_fence_info was converted to __u64 pointer.
> >
> > An example userspace code would be:
> >
> > struct sync_file_info *info;
> > int err, size, num_fences;
> >
> > info = malloc(sizeof(*info));
> >
> > memset(info, 0, sizeof(*info));
> >
> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> > num_fences = info->num_fences;
> >
> > if (num_fences) {
> > memset(info, 0, sizeof(*info));
> Would this memset still be needed if we didn't check for nulls in 
> info->status and info->name ?
> 
> Seems to me that it could be skipped in that case.

Yes, I agree.

> > size = sizeof(struct sync_fence_info) * num_fences;
> > info->len = size;
> > info->num_fences = num_fences;
> > info->sync_fence_info = (uint64_t) calloc(num_fences,
> >   sizeof(struct 
> > sync_fence_info));
> >
> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> > }
> >
> > v2: fix fence_info memory leak
> >
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/staging/android/sync.c  | 52 
> > +
> >  drivers/staging/android/uapi/sync.h |  9 +++
> >  2 files changed, 45 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> > index dc5f382..2379f23 100644
> > --- a/drivers/staging/android/sync.c
> > +++ b/drivers/staging/android/sync.c
> > @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, 
> > void *data, int size)
> >  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> > unsigned long arg)
> >  {
> > -   struct sync_file_info *info;
> > +   struct sync_file_info in, *info;
> > +   struct sync_fence_info *fence_info = NULL;
> > __u32 size;
> > __u32 len = 0;
> = 0 unneeded.
> > int ret, i;
> >  
> > -   if (copy_from_user(, (void __user *)arg, sizeof(size)))
> > +   if (copy_from_user(, (void __user *)arg, sizeof(*info)))
> > return -EFAULT;
> >  
> > -   if (size < sizeof(struct sync_file_info))
> > -   return -EINVAL;
> > +   if (in.status || strcmp(in.name, "\0"))
> > +   return -EFAULT;
> These members always get written by the fence ioctl, I'm not sure it adds 
> value to have them explicitly zero'd out by userspace.
> > -   if (size > 4096)
> > -   size = 4096;
> > +   if (in.num_fences && !in.sync_fence_info)
> > +   return -EFAULT;
> This check is unneeded, it will happen in the copy_to_user call anyway.
> > -   info = kzalloc(size, GFP_KERNEL);
> > +   info = kzalloc(sizeof(*info), GFP_KERNEL);
> > if (!info)
> > return -ENOMEM;
> >  
> > @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct 
> > sync_file *sync_file,
> > if (info->status >= 0)
> > info->status = !info->status;
> >  
> > -   info->num_fences = sync_file->num_fences;
> > +   /*
> > +* Passing num_fences = 0 means that userspace want to know how
> > +* many fences are in the sync_file to be able to allocate a buffer to
> > +* fit all sync_fence_infos and call the ioctl again with the buffer
> > +* assigned to info->sync_fence_info. The second call pass the
> > +* num_fences value received in the first call.
> > +*/
> > +   if (!in.num_fences)
> > +   goto no_fences;
> > +
> > +   size = sync_file->num_fences * sizeof(*fence_info);
> > +   if (in.len != size) {
> > +   ret = -EFAULT;
> > +   goto out;
> > +   }
> Maybe check for in.len < size, and set set to size?
> 
> 
> > -   len = sizeof(struct sync_file_info);
> > +   fence_info = kzalloc(size, GFP_KERNEL);
> > +   if (!fence_info) {
> > +   ret = -ENOMEM;
> > +   goto out;
> > +   }
> >  
> > for (i = 0; i < sync_file->num_fences; ++i) {
> > struct fence *fence = sync_file->cbs[i].fence;
> >  
> > -   ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> > +   ret 

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Rob Clark]

On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter  wrote:
> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>
>>
>> On 2/24/2016 3:41 AM, Lyude wrote:
>> >As it turns out, resuming DP MST is racey since we don't make sure MST
>> >is ready before we start modesetting, it just usually happens to be
>> >ready in time. This isn't the case on all systems, particularly a
>> >ThinkPad T560 with displays connected through the dock. On these
>> >systems, resuming the laptop while connected to the dock usually results
>> >in blank monitors. Making sure MST is ready before doing any kind of
>> >modesetting fixes this issue.
>> basic question since i haven't worked on MST much. MST should work like any
>> other digital panel on resume. i.e detect followed by modeset. in the
>> modified
>> commit mentioned below is it failing to detect the panel or failing at the
>> modeset ?
>> if we are depending on the intel_display_resume, how about moving the
>> intel_dp_mst_resume just above intel_display_resume?
>>
>>
>> Generic question to others in mail list on i915_drm_resume
>> we are doing a modeset and then doing the detect/hpd init.
>> shouldn't this be the other way round ? almost all displays
>> will pass a modeset even if display is not connected so we
>> are spending time on modeset even for displays that were
>> removed during the suspend state. if this is to simply
>> drm_state being saved and restored,
>
> We must restore anyway, we're not really allowed to shut down a display
> without userspace's consent. DP mst breaks this, and it's not fun really.

well, that isn't completely true.. I mean, if the user unplugs (for
example) an hdmi monitor, it isn't with userspace's consent..

I wonder if we could just have flag per connector, ie.
connector->no_auto_resume and just automatically send unplug events
for those to userspace (followed shortly by a plug event if it is
still connected and the normal hpd mechanism kicks in?  I mean, for
all we know, the user unplugged the DP monitor/hub/etc and plugged in
a different one while we were suspended..

BR,
-R

> So for hotunplug the flow should always be:
> 1. kernel notices something has changed in the output config.
> 2. kernel sends out uevent
> 3. userspace figures out what changed, and what needs to be done
> 4. userspace asks the kernel to change display configuration through
> setCrtc and Atomic ioctl calls.
>
> Irrespective of hotunplug handling, the kernel also _must_ restore the
> entire display configuration before userspace resumes. We can do that
> asynchronously (and there's plans for that), but even then we must stall
> userspace on the first KMS ioclt to keep up the illusion that a system s/r
> is transparent.
>
> In short, even if we do hpd processing before resuming the display,
> nothing will be faster - we must wait for userspace to make up its mind,
> and that can only happen once we've restored the display config.
>
> And again, mst is kinda breaking this, since and mst unplug results in a
> force-disable. Which can upset userspace and in general results in the
> need for lots of fragile error handling all over.
>
>> >We originally changed the resume order in
>> >
>> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw 
>> > state")
>> >
>> >to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
>> >issue now anyhow.
>> >
>> >CC: stable at vger.kernel.org
>> >Signed-off-by: Lyude 
>
> Wrt the patch itself: I think only in 4.6 we've actually fixed up all
> these mst WARN_ON. Cc: stable seems extremely risky on this one. Also, the
> modeset state readout for mst is still not entirely correct (it still
> relies on software state), so I'm not sure we've actually managed to shut
> up all the WARNINGs. Iirc the way to repro them is to hot-unplug something
> while suspended. In short the get_hw_state functions for mst should not
> rely on any mst software state, but instead just look at hw registers and
> dp aux registers to figure out what's going on. But not sure whether this
> will result on WARNINGs on resume, since generally the bios doesn't enable
> anything in that case.
>
> Furthermore MST still does a force-modeset when processing a hotunplug.
> Doing that before we've resumed the display is likely a very bad idea.
> What we need to fix that part is to separate the dp mst connector
> hotplug/unplugging from actually updating the modeset change. This needs
> reference-counting on drm_connector (so that we can lazily free
> drm_connector structs after hot-unplug), and is a major change.
>
> In short: I'm scared about this patch ;-)
>
> Thanks, Daniel
>
>
>> >---
>> >  drivers/gpu/drm/i915/i915_drv.c | 10 --
>> >  1 file changed, 8 insertions(+), 2 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> >b/drivers/gpu/drm/i915/i915_drv.c
>> >index f357058..4dcf3dd 100644
>> >--- a/drivers/gpu/drm/i915/i915_drv.c
>> >+++ b/drivers/gpu/drm/i915/i915_drv.c
>> >@@ -733,6 

[PATCH 2/2] drm/i915: remove dead code

[Daniel Vetter]

On Mon, Feb 29, 2016 at 04:24:07PM +, Eric Engestrom wrote:
> 79e539453b34e35f39299a899d263b0a1f1670bd ("DRM: i915: add mode setting
> support") added those variables but never used them.
> 
> Signed-off-by: Eric Engestrom 

Both applied for 4.7, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_tv.c | 12 
>  1 file changed, 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 948cbff..14f0b41 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -326,24 +326,12 @@ static const struct color_conversion sdtv_csc_yprpb = {
>   .rv = 0x0100, .gv = 0x03ad, .bv = 0x074d, .av = 0x0200,
>  };
>  
> -static const struct color_conversion sdtv_csc_rgb = {
> - .ry = 0x, .gy = 0x0f00, .by = 0x, .ay = 0x0166,
> - .ru = 0x, .gu = 0x, .bu = 0x0f00, .au = 0x0166,
> - .rv = 0x0f00, .gv = 0x, .bv = 0x, .av = 0x0166,
> -};
> -
>  static const struct color_conversion hdtv_csc_yprpb = {
>   .ry = 0x05b3, .gy = 0x016e, .by = 0x0728, .ay = 0x0145,
>   .ru = 0x07d5, .gu = 0x038b, .bu = 0x0100, .au = 0x0200,
>   .rv = 0x0100, .gv = 0x03d1, .bv = 0x06bc, .av = 0x0200,
>  };
>  
> -static const struct color_conversion hdtv_csc_rgb = {
> - .ry = 0x, .gy = 0x0f00, .by = 0x, .ay = 0x0166,
> - .ru = 0x, .gu = 0x, .bu = 0x0f00, .au = 0x0166,
> - .rv = 0x0f00, .gv = 0x, .bv = 0x, .av = 0x0166,
> -};
> -
>  static const struct video_levels component_levels = {
>   .blank = 279, .black = 279, .burst = 0,
>  };
> -- 
> 2.7.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[REGRESSION] i915: No HDMI output with 4.4

[Daniel Vetter]

On Mon, Feb 29, 2016 at 03:41:59PM +, Sharma, Shashank wrote:
> No problems, I guessed the mail situation :)

Ok, caught up now, at least on dri-devel. There's 2 bug report mail
threads:
- A new one from Oleksandr, still being investigated.
- This one here where Sonika asked for some logs from Nick, but Nick has
  already provided those. Since then (24th Feb) nothing new seems to have
  happened.

There's also other threads in the past, but I think we have resolved them
all. I guess we need to start tracking all these in some JIRA? I'll bring
this up in tomorrow's display sync meeting.

Thanks, Daniel
> 
> Regards
> Shashank
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel 
> Vetter
> Sent: Monday, February 29, 2016 9:12 PM
> To: Sharma, Shashank
> Cc: Daniel Vetter; Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; 
> intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
> linux-kernel at vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C
> Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> 
> On Mon, Feb 29, 2016 at 03:16:08PM +, Sharma, Shashank wrote:
> > Please see the latest mail chain, Sonika has already started on it.
> 
> Ah ok, crawling through 1k mails after one week of vacation, so I'm still 
> catching up ;-) My apologies for the confusion.
> 
> Thanks, Daniel
> > 
> > Regards
> > Shashank
> > 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of 
> > Daniel Vetter
> > Sent: Monday, February 29, 2016 8:44 PM
> > To: Sharma, Shashank
> > Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; 
> > intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
> > linux-kernel at vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, 
> > Gary C
> > Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> > 
> > On Wed, Feb 24, 2016 at 06:07:25AM +, Sharma, Shashank wrote:
> > > Hi Ville,
> > > We will look into this in sometime. Right now team is slightly loaded due 
> > > to project milestone. 
> > > Last time I looked into this, we dint have this HW to reproduce this 
> > > issue.
> > 
> > This is an upstream regression. Either you can handle it, or your code must 
> > be reverted again. Please either assign someone for this, or send in the 
> > patch to revert.
> > 
> > I'll discuss this with Indranil, too.
> > 
> > Thanks, Daniel
> > > 
> > > Regards
> > > Shashank
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > > Sent: Tuesday, February 23, 2016 8:38 PM
> > > To: Oleksandr Natalenko
> > > Cc: Vetter, Daniel; intel-gfx at lists.freedesktop.org; 
> > > dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; 
> > > Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C
> > > Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> > > 
> > > On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
> > > > Ville, Daniel,
> > > > 
> > > > any additional info I could provide? I have to return dual-link 
> > > > DVI cable back, so let me know if I could reveal more details if 
> > > > necessary.
> > > 
> > > Unfortunately I'm out of ideas for now. Daniel is on vacation.
> > > Anyone else? VPG folks should take the ball here since they broke it.
> > > 
> > > In the meantime I think as a workaround I think you could use something 
> > > like video=HDMI-A-1:e on the kernel command line (not sure I got the 
> > > connector name right for your system). I think that should result in the 
> > > live status check to be skipped, at least when populating the mode list.
> > > 
> > > Might be a good idea to collect all the information here and put in a bug 
> > > report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all 
> > > the logs and such would be in one place.
> > > 
> > > > 
> > > > Regards,
> > > >Oleksandr
> > > > 
> > > > 16.02.2016 14:54, Daniel Vetter написав:
> > > > > On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
> > > > >> Ville, Daniel,
> > > > >> 
> > > > >> I've just got another monitor and another DVI-HDMI cable, and 
> > > > >> here what I've got.
> > > > >> 
> > > > >> ===Single Link DVI-D cable with 3 different monitors===
> > > > >> 
> > > > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI 
> > > > >> LG 
> > > > >> 23MP65HQ-P === not working
> > > > > 
> > > > > I presume the above LG screen is what you've called previously 
> > > > > "old monitor"?
> > > > > 
> > > > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI 
> > > > >> LG 
> > > > >> 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single 
> > > > >> Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
> > > > >> 
> > > > >> ===Dual Link DVI-D cable with monitor that doesn't work with 
> > > > >> Single Link cable===
> > > > >> 
> > > > >> Computer DVI ——— 

[PATCH] drm/exynos/dsi: use core helper to create DSI packet

[Inki Dae]

Picked it up.

Thanks,
Inki Dae

2016년 02월 17일 22:33에 Andrzej Hajda 이(가) 쓴 글:
> Core provides generic helper to create DSI packet, use it instead of
> custom code.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 69 
> +++--
>  1 file changed, 23 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 77e17ae..f17be93 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -10,6 +10,8 @@
>   * published by the Free Software Foundation.
>  */
>  
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -222,12 +224,8 @@ struct exynos_dsi_transfer {
>   struct list_head list;
>   struct completion completed;
>   int result;
> - u8 data_id;
> - u8 data[2];
> + struct mipi_dsi_packet packet;
>   u16 flags;
> -
> - const u8 *tx_payload;
> - u16 tx_len;
>   u16 tx_done;
>  
>   u8 *rx_payload;
> @@ -322,6 +320,7 @@ enum reg_idx {
>  static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
>   u32 val)
>  {
> +
>   writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
>  }
>  
> @@ -983,13 +982,14 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   struct exynos_dsi_transfer *xfer)
>  {
>   struct device *dev = dsi->dev;
> - const u8 *payload = xfer->tx_payload + xfer->tx_done;
> - u16 length = xfer->tx_len - xfer->tx_done;
> + struct mipi_dsi_packet *pkt = >packet;
> + const u8 *payload = pkt->payload + xfer->tx_done;
> + u16 length = pkt->payload_length - xfer->tx_done;
>   bool first = !xfer->tx_done;
>   u32 reg;
>  
>   dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> - xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, xfer->rx_done);
> + xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>  
>   if (length > DSI_TX_FIFO_SIZE)
>   length = DSI_TX_FIFO_SIZE;
> @@ -998,8 +998,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>  
>   /* Send payload */
>   while (length >= 4) {
> - reg = (payload[3] << 24) | (payload[2] << 16)
> - | (payload[1] << 8) | payload[0];
> + reg = get_unaligned_le32(payload);
>   exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
>   payload += 4;
>   length -= 4;
> @@ -1017,16 +1016,13 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   reg |= payload[0];
>   exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
>   break;
> - case 0:
> - /* Do nothing */
> - break;
>   }
>  
>   /* Send packet header */
>   if (!first)
>   return;
>  
> - reg = (xfer->data[1] << 16) | (xfer->data[0] << 8) | xfer->data_id;
> + reg = get_unaligned_le32(pkt->header);
>   if (exynos_dsi_wait_for_hdr_fifo(dsi)) {
>   dev_err(dev, "waiting for header FIFO timed out\n");
>   return;
> @@ -1147,13 +1143,14 @@ again:
>  
>   spin_unlock_irqrestore(>transfer_lock, flags);
>  
> - if (xfer->tx_len && xfer->tx_done == xfer->tx_len)
> + if (xfer->packet.payload_length &&
> + xfer->tx_done == xfer->packet.payload_length)
>   /* waiting for RX */
>   return;
>  
>   exynos_dsi_send_to_fifo(dsi, xfer);
>  
> - if (xfer->tx_len || xfer->rx_len)
> + if (xfer->packet.payload_length || xfer->rx_len)
>   return;
>  
>   xfer->result = 0;
> @@ -1189,10 +1186,11 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
>   spin_unlock_irqrestore(>transfer_lock, flags);
>  
>   dev_dbg(dsi->dev,
> - "> xfer %p, tx_len %u, tx_done %u, rx_len %u, rx_done %u\n",
> - xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, xfer->rx_done);
> + "> xfer %p, tx_len %lu, tx_done %u, rx_len %u, rx_done %u\n",
> + xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
> + xfer->rx_done);
>  
> - if (xfer->tx_done != xfer->tx_len)
> + if (xfer->tx_done != xfer->packet.payload_length)
>   return true;
>  
>   if (xfer->rx_done != xfer->rx_len)
> @@ -1263,9 +1261,10 @@ static int exynos_dsi_transfer(struct exynos_dsi *dsi,
>   wait_for_completion_timeout(>completed,
>   msecs_to_jiffies(DSI_XFER_TIMEOUT_MS));
>   if (xfer->result == -ETIMEDOUT) {
> + struct mipi_dsi_packet *pkt = >packet;
>   exynos_dsi_remove_transfer(dsi, xfer);
> - dev_err(dsi->dev, "xfer timed out: %*ph %*ph\n", 2, xfer->data,
> - xfer->tx_len, xfer->tx_payload);
> +   

[PATCH] drm/crtc: Use drm_mode_object_put() in __drm_framebuffer_unregister()

[Daniel Vetter]

On Mon, Feb 29, 2016 at 11:21:10AM +0800, Liu Ying wrote:
> The function __drm_framebuffer_unregister() has boilerplate code to drop idr
> reference.  Let's replace it with drm_mode_object_put() to simplify the code.
> 
> Signed-off-by: Liu Ying 

Applied to drm-misc, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 65258ac..579505c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -430,9 +430,7 @@ EXPORT_SYMBOL(drm_framebuffer_init);
>  static void __drm_framebuffer_unregister(struct drm_device *dev,
>struct drm_framebuffer *fb)
>  {
> - mutex_lock(>mode_config.idr_mutex);
> - idr_remove(>mode_config.crtc_idr, fb->base.id);
> - mutex_unlock(>mode_config.idr_mutex);
> + drm_mode_object_put(dev, >base);
>  
>   fb->base.id = 0;
>  }
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 2/2] drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree.

[Eric Anholt]

The original Raspberry Pi had the GPIO active high, but the later
models are active low.  The DT GPIO bindings allow specifying the
active flag, except that it doesn't get propagated to the gpiodesc, so
you have to handle it yourself.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 709ed57..dc60485 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -47,6 +47,7 @@ struct vc4_hdmi {
void __iomem *hdmicore_regs;
void __iomem *hd_regs;
int hpd_gpio;
+   bool hpd_active_low;

struct clk *pixel_clock;
struct clk *hsm_clock;
@@ -165,7 +166,8 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
struct vc4_dev *vc4 = to_vc4_dev(dev);

if (vc4->hdmi->hpd_gpio) {
-   if (gpio_get_value_cansleep(vc4->hdmi->hpd_gpio))
+   if (gpio_get_value_cansleep(vc4->hdmi->hpd_gpio) ^
+   vc4->hdmi->hpd_active_low)
return connector_status_connected;
else
return connector_status_disconnected;
@@ -506,11 +508,17 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
 * we'll use the HDMI core's register.
 */
if (of_find_property(dev->of_node, "hpd-gpios", )) {
-   hdmi->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpios", 
0);
+   enum of_gpio_flags hpd_gpio_flags;
+
+   hdmi->hpd_gpio = of_get_named_gpio_flags(dev->of_node,
+"hpd-gpios", 0,
+_gpio_flags);
if (hdmi->hpd_gpio < 0) {
ret = hdmi->hpd_gpio;
goto err_unprepare_hsm;
}
+
+   hdmi->hpd_active_low = hpd_gpio_flags & OF_GPIO_ACTIVE_LOW;
}

vc4->hdmi = hdmi;
-- 
2.7.0

[PATCH 1/2] drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.

[Eric Anholt]

Fixes an error thrown every few seconds when we poll HPD when it's on
a I2C to GPIO expander.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c69c046..709ed57 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -165,7 +165,7 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
struct vc4_dev *vc4 = to_vc4_dev(dev);

if (vc4->hdmi->hpd_gpio) {
-   if (gpio_get_value(vc4->hdmi->hpd_gpio))
+   if (gpio_get_value_cansleep(vc4->hdmi->hpd_gpio))
return connector_status_connected;
else
return connector_status_disconnected;
-- 
2.7.0

[PATCH 0/2] drm/vc4: Fixes for Raspberry Pi 3

[Eric Anholt]

These are for fixing the vc4 driver on the Pi 3.  Note that patch 2
will also be necessary for fixing HPD on the Pi2, which we've been
carrying downstream patches to work around until now.

Eric Anholt (2):
  drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.
  drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree.

 drivers/gpu/drm/vc4/vc4_hdmi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

-- 
2.7.0

[PATCH 1/2] drm/exynos: refactor driver and device registration code

[Inki Dae]

For 1 and 2, picked it up.

Thanks,
Inki Dae


2016년 02월 18일 22:34에 Marek Szyprowski 이(가) 쓴 글:
> This patch refactors driver and device registration by moving all drivers
> to the common array. This way additional flags can be added later for
> new features. #ifdef-based code has been replaced by IS_ENABLED() macro
> usage.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 233 
> +++-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |   1 -
>  2 files changed, 107 insertions(+), 127 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 68f0f36f6e7e..5ab8f1240d7b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -495,69 +495,64 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
>  /* forward declaration */
>  static struct platform_driver exynos_drm_platform_driver;
>  
> +struct exynos_drm_driver_info {
> + struct platform_driver *driver;
> + unsigned int flags;
> +};
> +
> +#define DRM_COMPONENT_DRIVER BIT(0)  /* supports component framework */
> +#define DRM_VIRTUAL_DEVICE   BIT(1)  /* create virtual platform device */
> +
> +#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ?  : NULL)
> +
>  /*
>   * Connector drivers should not be placed before associated crtc drivers,
>   * because connector requires pipe number of its crtc during initialization.
>   */
> -static struct platform_driver *const exynos_drm_kms_drivers[] = {
> -#ifdef CONFIG_DRM_EXYNOS_FIMD
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS5433_DECON
> - _decon_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS7_DECON
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_MIC
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DP
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DSI
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_MIXER
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_HDMI
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_VIDI
> - _driver,
> -#endif
> -};
> -
> -static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
> -#ifdef CONFIG_DRM_EXYNOS_G2D
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_FIMC
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_ROTATOR
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_GSC
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_IPP
> - _driver,
> -#endif
> - _drm_platform_driver,
> -};
> -
> -static struct platform_driver *const exynos_drm_drv_with_simple_dev[] = {
> -#ifdef CONFIG_DRM_EXYNOS_VIDI
> - _driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_IPP
> - _driver,
> -#endif
> - _drm_platform_driver,
> +static struct exynos_drm_driver_info exynos_drm_drivers[] = {
> + {
> + DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(dp_driver, CONFIG_DRM_EXYNOS_DP),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(dsi_driver, CONFIG_DRM_EXYNOS_DSI),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(hdmi_driver, CONFIG_DRM_EXYNOS_HDMI),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(vidi_driver, CONFIG_DRM_EXYNOS_VIDI),
> + DRM_COMPONENT_DRIVER | DRM_VIRTUAL_DEVICE
> + }, {
> + DRV_PTR(g2d_driver, CONFIG_DRM_EXYNOS_G2D),
> + }, {
> + DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
> + }, {
> + DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
> + }, {
> + DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
> + }, {
> + DRV_PTR(ipp_driver, CONFIG_DRM_EXYNOS_IPP),
> + DRM_VIRTUAL_DEVICE
> + }, {
> + _drm_platform_driver,
> + DRM_VIRTUAL_DEVICE
> + }
>  };
> -#define PDEV_COUNT ARRAY_SIZE(exynos_drm_drv_with_simple_dev)
>  
>  static int compare_dev(struct device *dev, void *data)
>  {
> @@ -569,11 +564,15 @@ static struct component_match 
> *exynos_drm_match_add(struct device *dev)
>   struct component_match *match = NULL;
>   int i;
>  
> - for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
> - struct device_driver *drv = _drm_kms_drivers[i]->driver;
> + for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
> + struct exynos_drm_driver_info *info = _drm_drivers[i];
>   struct device *p = NULL, *d;
>  
> 

[PATCH] drm: sti: remove sti_gem_prime_export hack

[Daniel Vetter]

On Fri, Feb 26, 2016 at 09:50:15AM +0100, Benjamin Gaignard wrote:
> Thanks to "drm: prime: Honour O_RDWR during prime-handle-to-fd"
> commit we don't need to hack flags anymore.
> 
> Signed-off-by: Benjamin Gaignard 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/sti/sti_drv.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 506b562..32a3eec 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -181,15 +181,6 @@ static const struct file_operations sti_driver_fops = {
>   .release = drm_release,
>  };
>  
> -static struct dma_buf *sti_gem_prime_export(struct drm_device *dev,
> - struct drm_gem_object *obj,
> - int flags)
> -{
> - /* we want to be able to write in mmapped buffer */
> - flags |= O_RDWR;
> - return drm_gem_prime_export(dev, obj, flags);
> -}
> -
>  static struct drm_driver sti_driver = {
>   .driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
>   DRIVER_GEM | DRIVER_PRIME,
> @@ -207,7 +198,7 @@ static struct drm_driver sti_driver = {
>  
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = sti_gem_prime_export,
> + .gem_prime_export = drm_gem_prime_export,
>   .gem_prime_import = drm_gem_prime_import,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 1/2] drm/dp: move hw_mutex up the call stack

[Daniel Vetter]

On Thu, Feb 25, 2016 at 04:15:05PM -0500, Rob Clark wrote:
> 1) don't let other threads trying to bang on aux channel interrupt the
> defer timeout/logic
> 2) don't let other threads interrupt the i2c over aux logic
> 
> Technically, according to people who actually have the DP spec, this
> should not be required.  In practice, it makes some troublesome Dell
> monitor (and perhaps others) work, so probably a case of "It's compliant
> if it works with windows" on the hw vendor's part..
> 
> v2: rebased to come before DPCD/AUX logging patch for easier backport
> to stable branches.
> 
> Reported-by: Dave Wysochanski 
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274157
> Cc: stable at vger.kernel.org
> Signed-off-by: Rob Clark 

Reviewed-by: Daniel Vetter 

Dave, can you pls pick up?

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 7d58f59..df64ed1 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -179,7 +179,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>  {
>   struct drm_dp_aux_msg msg;
>   unsigned int retry;
> - int err;
> + int err = 0;
>  
>   memset(, 0, sizeof(msg));
>   msg.address = offset;
> @@ -187,6 +187,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>   msg.buffer = buffer;
>   msg.size = size;
>  
> + mutex_lock(>hw_mutex);
> +
>   /*
>* The specification doesn't give any recommendation on how often to
>* retry native transactions. We used to retry 7 times like for
> @@ -195,25 +197,24 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, 
> u8 request,
>*/
>   for (retry = 0; retry < 32; retry++) {
>  
> - mutex_lock(>hw_mutex);
>   err = aux->transfer(aux, );
> - mutex_unlock(>hw_mutex);
>   if (err < 0) {
>   if (err == -EBUSY)
>   continue;
>  
> - return err;
> + goto unlock;
>   }
>  
>  
>   switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
>   case DP_AUX_NATIVE_REPLY_ACK:
>   if (err < size)
> - return -EPROTO;
> - return err;
> + err = -EPROTO;
> + goto unlock;
>  
>   case DP_AUX_NATIVE_REPLY_NACK:
> - return -EIO;
> + err = -EIO;
> + goto unlock;
>  
>   case DP_AUX_NATIVE_REPLY_DEFER:
>   usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 
> 100);
> @@ -222,7 +223,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>   }
>  
>   DRM_DEBUG_KMS("too many retries, giving up\n");
> - return -EIO;
> + err = -EIO;
> +
> +unlock:
> + mutex_unlock(>hw_mutex);
> + return err;
>  }
>  
>  /**
> @@ -544,9 +549,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   int max_retries = max(7, drm_dp_i2c_retry_count(msg, 
> dp_aux_i2c_speed_khz));
>  
>   for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c); 
> retry++) {
> - mutex_lock(>hw_mutex);
>   ret = aux->transfer(aux, msg);
> - mutex_unlock(>hw_mutex);
>   if (ret < 0) {
>   if (ret == -EBUSY)
>   continue;
> @@ -685,6 +688,8 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>  
>   memset(, 0, sizeof(msg));
>  
> + mutex_lock(>hw_mutex);
> +
>   for (i = 0; i < num; i++) {
>   msg.address = msgs[i].addr;
>   drm_dp_i2c_msg_set_request(, [i]);
> @@ -739,6 +744,8 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>   msg.size = 0;
>   (void)drm_dp_i2c_do_msg(aux, );
>  
> + mutex_unlock(>hw_mutex);
> +
>   return err;
>  }
>  
> -- 
> 2.5.0
> 

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

Enable CONFIG_VGA_SWITCHEROO cause lspci on MSI GS60-070XCN stuck

[Daniel Vetter]

On Thu, Feb 25, 2016 at 12:18:25PM +0100, Lukas Wunner wrote:
> Hi,
> 
> On Wed, Feb 24, 2016 at 11:32:15PM +0800, Drunkard Zhang wrote:
> > I may hit a bug, when enabled CONFIG_VGA_SWITCHEROO, run lspci command
> > on MSI GS60-070XCN will stuck, it eats 100% CPU of one core, and
> > CPU/memory allocation on this system fails sometimes.
> 
> Sounds like a deadlock. Does reverting 8f12a3118f55 ("vga_switcheroo:
> Add missing locking") help?
> 
> If not I'd suspect this to be caused by a codepath in nouveau which is
> only executed if CONFIG_VGA_SWITCHEROO is enabled. I believe Maxwell
> support is still somewhat limited. Does unloading or blacklisting
> nouveau help?

http://www.spinics.net/lists/dri-devel/msg101339.html

might be relevant, no idea ...
-Daniel

> 
> Best regards,
> 
> Lukas
> 
> > 
> > I'll bisect later, put my enviroment here, hope you guys give me some hint 
> > :)
> > 
> > Tested kernel versions are: latest Linus' kernel code, 4.4.2-gentoo;
> > 
> > My hardware info:
> > 
> > 23:25:37 ~ # lspci
> > 00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM
> > Registers (rev 07)
> > 00:01.0 PCI bridge: Intel Corporation Sky Lake PCIe Controller (x16) (rev 
> > 07)
> > 00:02.0 VGA compatible controller: Intel Corporation Device 191b (rev 06)
> > 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI
> > Controller (rev 31)
> > 00:14.2 Signal processing controller: Intel Corporation Sunrise
> > Point-H Thermal subsystem (rev 31)
> > 00:16.0 Communication controller: Intel Corporation Sunrise Point-H
> > CSME HECI #1 (rev 31)
> > 00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA
> > Controller [AHCI mode] (rev 31)
> > 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
> > Port #1 (rev f1)
> > 00:1c.2 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
> > Port #3 (rev f1)
> > 00:1c.3 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
> > Port #4 (rev f1)
> > 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
> > Port #5 (rev f1)
> > 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
> > Port #9 (rev f1)
> > 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 
> > 31)
> > 00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
> > 00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
> > 00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
> > 01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev a2)
> > 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
> > Network Adapter (rev 20)
> > 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
> > RTS5249 PCI Express Card Reader (rev 01)
> > 04:00.0 Ethernet controller: Qualcomm Atheros Device e0a1 (rev 10)
> > 05:00.0 PCI bridge: Intel Corporation Device 1576
> > 06:00.0 PCI bridge: Intel Corporation Device 1576
> > 06:01.0 PCI bridge: Intel Corporation Device 1576
> > 06:02.0 PCI bridge: Intel Corporation Device 1576
> > 07:00.0 System peripheral: Intel Corporation Device 1575
> > 09:00.0 USB controller: Intel Corporation Device 15b5
> > 3e:00.0 Non-Volatile memory controller: Toshiba America Info Systems
> > Device 010f (rev 01)
> > 
> > Any other hints?
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 1/2] drm: Add DRM_MODE_FB_BFF flag definition

[Daniel Vetter]

On Mon, Feb 29, 2016 at 05:16:13PM +0100, Vincent ABRIOU wrote:
> 
> 
> On 02/29/2016 04:32 PM, Daniel Vetter wrote:
> > On Fri, Feb 26, 2016 at 11:33:08AM +0100, Vincent ABRIOU wrote:
> >> Hi,
> >>
> >> Have you any comment for this proposal?
> >
> > I guess since we don't really have userspace that uses interlaced modes,
> > much less actually bothers to get the fields correct I think just have
> > some (open-source) userspace somewhere (does gstreamer care enough about
> > this?) which needs this and it's good.
> >
> 
> Hi Daniel,
> 
> At Gstreamer side, an interlaced GstBuffer could be tagged with flags:
> https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstvideo.html#GstVideoFrameFlags
> 
> GST_VIDEO_FRAME_FLAG_TFF is one of them and it is used to warn that the 
> buffer is interlaced with Top Field First (TFF).
> 
> At kernel side, we preferred to tag the interlaced buffer with Bottom 
> Field First (BFF) because most of the interlaced buffer are TFF and that 
> BFF are the exception.
> 
> Further, we made tests with weston to validate the full path and it is 
> working fine.

Cool, so it's all there. Please add link to the patches/support for this
(e.g. Weston patches need to be on the m-l, reviewed by weston maintainers
to be considered "ready"). Then once the userspace is all ready we can
pull in the kernel patch. After that userspace side can land.

Yes this is a bit of work to orchestrated, but this process is the result
of getting it wrong a few too many times in DRM-land. ABI is hard ;-)

So please resend your patch once all that is done, with links to gstreamer
and weston patches with their r-b tags from maintainers.

Thanks, Daniel

> 
> BR
> Vincent
> 
> > Without userspace this is a hard sell.
> >
> > Thanks, Daniel
> >
> >>
> >> BR
> >> Vincent
> >>
> >> On 02/12/2016 10:26 AM, Vincent Abriou wrote:
> >>> From: Fabien Dessenne 
> >>>
> >>> If a buffer is interlaced, this "Bottom Field First" flag specifies
> >>> which of the top or the bottom field shall be displayed first.
> >>> When set, the bottom field shall be displayed first.
> >>> When unset the top field shall be displayed first.
> >>>
> >>> Signed-off-by: Fabien Dessenne 
> >>> ---
> >>>drivers/gpu/drm/drm_crtc.c  | 3 ++-
> >>>include/uapi/drm/drm_mode.h | 1 +
> >>>2 files changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >>> index d40bab2..64b4fdac 100644
> >>> --- a/drivers/gpu/drm/drm_crtc.c
> >>> +++ b/drivers/gpu/drm/drm_crtc.c
> >>> @@ -3315,7 +3315,8 @@ internal_framebuffer_create(struct drm_device *dev,
> >>>   struct drm_framebuffer *fb;
> >>>   int ret;
> >>>
> >>> - if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
> >>> + if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS
> >>> + | DRM_MODE_FB_BFF)) {
> >>>   DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", 
> >>> r->flags);
> >>>   return ERR_PTR(-EINVAL);
> >>>   }
> >>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>> index 50adb46..f7c9111 100644
> >>> --- a/include/uapi/drm/drm_mode.h
> >>> +++ b/include/uapi/drm/drm_mode.h
> >>> @@ -354,6 +354,7 @@ struct drm_mode_fb_cmd {
> >>>
> >>>#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */
> >>>#define DRM_MODE_FB_MODIFIERS  (1<<1) /* enables ->modifer[] */
> >>> +#define DRM_MODE_FB_BFF  (1<<2) /* if interlaced, bottom field 
> >>> first */
> >>>
> >>>struct drm_mode_fb_cmd2 {
> >>>   __u32 fb_id;
> >>>
> >

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

[PATCH v5 4/5] drm: add generic blending related properties

[Ville Syrjälä]

On Wed, Jan 27, 2016 at 03:44:42PM +0100, Marek Szyprowski wrote:
> This patch adds code and documentation for the following blending
> related properties: 'alpha', 'blending' and 'alpha_premult'.
> 
> 'alpha' property defines plane's transparency used for some blending
> modes.
> 
> 'alpha_premult' property defines if RGB pixel data in the framebuffer
> contains values pre-multiplied by its alpha value or full range RGB
> values (0-255), which needs to be multiplied by pixel alpha value for
> blending operation.
> 
> 'blending' property selects blending mode - by selecting one of the
> predefined values, user can select a pair of factors, which will be
> used in the generic blending equation. For more information, see
> the kerneldoc for the added code.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  Documentation/DocBook/gpu.tmpl |  47 +-
>  drivers/gpu/drm/drm_atomic.c   |  12 +
>  drivers/gpu/drm/drm_blend.c| 110 
> +
>  include/drm/drm_crtc.h |  15 ++
>  include/uapi/drm/drm_mode.h| 101 +
>  5 files changed, 283 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index ae7d913adf60..e5197368e68f 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1110,6 +1110,22 @@ int max_width, max_height;
>  
>
>  
> +  
> +
> +  
> +Plane blending
> +
> +
> +  Plane Blending Overview
> +!Pinclude/uapi/drm/drm_mode.h Generic plane blending operation
> +
> +
> +  Blending Function Reference
> +!Iinclude/uapi/drm/drm_mode.h
> +!Edrivers/gpu/drm/drm_blend.c
> +
> +  
> +
>
>  
>
> @@ -1816,7 +1832,7 @@ void intel_crt_init(struct drm_device *dev)
>   Description/Restrictions
>   
>   
> - DRM
> + DRM
>   Generic
>   “rotation”
>   BITMASK
> @@ -2068,7 +2084,7 @@ void intel_crt_init(struct drm_device *dev)
>   property to suggest an Y offset for a connector
>   
>   
> - Optional
> + Optional
>   “scaling mode”
>   ENUM
>   { "None", "Full", "Center", "Full aspect" }
> @@ -2102,6 +2118,33 @@ void intel_crt_init(struct drm_device *dev)
>   planes' order. Exact value range is driver dependent.
>   
>   
> +  "alpha" 
> + RANGE
> + Min=0, Max= driver dependent
> + Plane
> + Plane's alpha value (transparency) for blending 
> operation. Used in some blending modes. 
> + 
> + 
> +  "alpha_premult" 
> + BOOL
> + Min=0, Max=1
> + Plane
> + Indicates the range of the RGB data of the 
> framebuffer attached to the given plane.
> + When enabled, RGB values fits the range from 0 to pixel's alpha 
> value. When disabled, RGB
> + values are from 0 to 255 range and during blending operations 
> they will be multiplied by
> + the pixel's alpha value first before computing result of 
> blending equations. Value of this
> + property is used in some blending modes and only when user 
> attaches framebuffer with pixel
> + format, which contains non-binary alpha channel.

I have a hard to figure out what that is saying. The fact that it goes
on talking about ranges of the RGB values is IMO just confusing.

I'm pretty sure I've suggested it before, but I would just make this
some kind of 'alpha_premultiply' which when enabled will perform the
premultiplication, and when disabled it won't.

Description could IMO be something as simple as 
"Premultiply the source RGB values with the source alpha before blending?"

> + 
> + 
> +  "blending" 
> + ENUM
> + { "disabled", "pixel-alpha", "const-alpha" 
> "pixel-const-alpha" }
> + Plane
> + Selects algorithm used in plane blending operation. 
> For more information, see
> + DRM_BLEND_* symbolic constant documentation. 
> + 
> + 
>   i915
>   Generic
>   "Broadcast RGB"
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a19201efb7d1..a85da144fd95 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -632,6 +632,12 @@ int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   state->rotation = val;
>   } else if (property == config->zpos_property) {
>   state->zpos = val;
> + } else if (property == config->alpha_property) {
> + state->alpha = val;
> + } else if (property == config->alpha_premult_property) {
> + state->alpha_premult = val;
> + } else if (property == config->blending_property) {
> + state->blending = val;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -690,6 +696,12 @@ 

[PATCH] drm/etnaviv: move GPU linear window to end of DMA window

[Lucas Stach]

If the end of the system DMA window is farther away from the start of
physical RAM than the size of the GPU linear window, move the linear
window so that it ends at the same address than the system DMA window.

This allows to map command buffer from CMA, which is likely to reside
at the end of the system DMA window, while also overlapping as much
RAM as possible, in order to optimize regular buffer mappings through
the linear window.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 40f2a37f56e3..e9e66b99ab7c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1563,6 +1563,7 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
 {
struct device *dev = >dev;
struct etnaviv_gpu *gpu;
+   u32 dma_mask;
int err = 0;

gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL);
@@ -1573,12 +1574,16 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
mutex_init(>lock);

/*
-* Set the GPU base address to the start of physical memory.  This
-* ensures that if we have up to 2GB, the v1 MMU can address the
-* highest memory.  This is important as command buffers may be
-* allocated outside of this limit.
+* Set the GPU linear window to be at the end of the DMA window, where
+* the CMA area is likely to reside. This ensures that we are able to
+* map the command buffers while having the linear window overlap as
+* much RAM as possible, so we can optimize mappings for other buffers.
 */
-   gpu->memory_base = PHYS_OFFSET;
+   dma_mask = (u32)dma_get_required_mask(dev);
+   if (dma_mask < PHYS_OFFSET + SZ_2G)
+   gpu->memory_base = PHYS_OFFSET;
+   else
+   gpu->memory_base = dma_mask - SZ_2G + 1;

/* Map registers: */
gpu->mmio = etnaviv_ioremap(pdev, NULL, dev_name(gpu->dev));
-- 
2.7.0

[PATCH 1/2] drm: Add DRM_MODE_FB_BFF flag definition

[Vincent ABRIOU]

On 02/29/2016 04:32 PM, Daniel Vetter wrote:
> On Fri, Feb 26, 2016 at 11:33:08AM +0100, Vincent ABRIOU wrote:
>> Hi,
>>
>> Have you any comment for this proposal?
>
> I guess since we don't really have userspace that uses interlaced modes,
> much less actually bothers to get the fields correct I think just have
> some (open-source) userspace somewhere (does gstreamer care enough about
> this?) which needs this and it's good.
>

Hi Daniel,

At Gstreamer side, an interlaced GstBuffer could be tagged with flags:
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstvideo.html#GstVideoFrameFlags

GST_VIDEO_FRAME_FLAG_TFF is one of them and it is used to warn that the 
buffer is interlaced with Top Field First (TFF).

At kernel side, we preferred to tag the interlaced buffer with Bottom 
Field First (BFF) because most of the interlaced buffer are TFF and that 
BFF are the exception.

Further, we made tests with weston to validate the full path and it is 
working fine.

BR
Vincent

> Without userspace this is a hard sell.
>
> Thanks, Daniel
>
>>
>> BR
>> Vincent
>>
>> On 02/12/2016 10:26 AM, Vincent Abriou wrote:
>>> From: Fabien Dessenne 
>>>
>>> If a buffer is interlaced, this "Bottom Field First" flag specifies
>>> which of the top or the bottom field shall be displayed first.
>>> When set, the bottom field shall be displayed first.
>>> When unset the top field shall be displayed first.
>>>
>>> Signed-off-by: Fabien Dessenne 
>>> ---
>>>drivers/gpu/drm/drm_crtc.c  | 3 ++-
>>>include/uapi/drm/drm_mode.h | 1 +
>>>2 files changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index d40bab2..64b4fdac 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -3315,7 +3315,8 @@ internal_framebuffer_create(struct drm_device *dev,
>>> struct drm_framebuffer *fb;
>>> int ret;
>>>
>>> -   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
>>> +   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS
>>> +   | DRM_MODE_FB_BFF)) {
>>> DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
>>> return ERR_PTR(-EINVAL);
>>> }
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 50adb46..f7c9111 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -354,6 +354,7 @@ struct drm_mode_fb_cmd {
>>>
>>>#define DRM_MODE_FB_INTERLACED   (1<<0) /* for interlaced framebuffers */
>>>#define DRM_MODE_FB_MODIFIERS(1<<1) /* enables ->modifer[] */
>>> +#define DRM_MODE_FB_BFF(1<<2) /* if interlaced, bottom field 
>>> first */
>>>
>>>struct drm_mode_fb_cmd2 {
>>> __u32 fb_id;
>>>
>

[PATCH 2/2] drm/i915: Add functions to execute the new sequences from VBT

[Deepak M]

From: Gaurav K Singh 

New sequences are added in the mipi sequence block of the
VBT from version 3 onwards. The sequences are added to
make the code more generic as the panel related info
are placed in the VBT.

Cc: David Airlie 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Gaurav K Singh 
Signed-off-by: Shobhit Kumar 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_dsi.c   |  8 
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 32 ++
 2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b928c50..82f6822 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -461,6 +461,8 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
intel_dsi_port_enable(encoder);
}

+   drm_panel_backlight_on(intel_dsi->panel);
+
intel_panel_enable_backlight(intel_dsi->attached_connector);
 }

@@ -485,6 +487,8 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);

+   /* Panel Enable */
+   drm_panel_power_on(intel_dsi->panel);
msleep(intel_dsi->panel_on_delay);

if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
@@ -537,6 +541,7 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder)
DRM_DEBUG_KMS("\n");

intel_panel_disable_backlight(intel_dsi->attached_connector);
+   drm_panel_backlight_off(intel_dsi->panel);

if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
@@ -651,6 +656,9 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)

drm_panel_unprepare(intel_dsi->panel);

+   /* Disable Panel */
+   drm_panel_power_off(intel_dsi->panel);
+
msleep(intel_dsi->panel_off_delay);
msleep(intel_dsi->panel_pwr_cycle_delay);

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 787f01c..01a2743 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -404,12 +404,44 @@ static int vbt_panel_get_modes(struct drm_panel *panel)
return 1;
 }

+static int vbt_panel_power_on(struct drm_panel *panel)
+{
+   generic_exec_sequence(panel, MIPI_SEQ_POWER_ON);
+
+   return 0;
+}
+
+static int vbt_panel_power_off(struct drm_panel *panel)
+{
+   generic_exec_sequence(panel, MIPI_SEQ_POWER_OFF);
+
+   return 0;
+}
+
+static int vbt_panel_backlight_on(struct drm_panel *panel)
+{
+   generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_ON);
+
+   return 0;
+}
+
+static int vbt_panel_backlight_off(struct drm_panel *panel)
+{
+   generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_OFF);
+
+   return 0;
+}
+
 static const struct drm_panel_funcs vbt_panel_funcs = {
.disable = vbt_panel_disable,
.unprepare = vbt_panel_unprepare,
.prepare = vbt_panel_prepare,
.enable = vbt_panel_enable,
.get_modes = vbt_panel_get_modes,
+   .power_on = vbt_panel_power_on,
+   .power_off = vbt_panel_power_off,
+   .backlight_on = vbt_panel_backlight_on,
+   .backlight_off = vbt_panel_backlight_off,
 };

 struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id)
-- 
1.9.1

[PATCH 1/2] drm: Add few more wrapper functions for drm panel

[Deepak M]

Currently there are few pair of functions which
are called during the panel enable/disable sequence.
To improve the granularity, adding few more wrapper
functions so that the functions are more specific
on what they are doing.

Cc: David Airlie 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Deepak M 
Signed-off-by: Gaurav K Singh 
---
 include/drm/drm_panel.h | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 13ff44b..c729f6d 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -73,6 +73,12 @@ struct drm_panel_funcs {
int (*get_modes)(struct drm_panel *panel);
int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
   struct display_timing *timings);
+   int (*power_on)(struct drm_panel *panel);
+   int (*power_off)(struct drm_panel *panel);
+   int (*backlight_on)(struct drm_panel *panel);
+   int (*backlight_off)(struct drm_panel *panel);
+   int (*get_info)(struct drm_panel *panel,
+   struct drm_connector *connector);
 };

 struct drm_panel {
@@ -117,6 +123,47 @@ static inline int drm_panel_enable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
 }

+static inline int drm_panel_power_on(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->power_on)
+   return panel->funcs->power_on(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_power_off(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->power_off)
+   return panel->funcs->power_off(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_backlight_on(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->backlight_on)
+   return panel->funcs->backlight_on(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_backlight_off(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->backlight_off)
+   return panel->funcs->backlight_off(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_get_info(struct drm_panel *panel,
+   struct drm_connector *connector)
+{
+   if (connector && panel && panel->funcs && panel->funcs->get_info)
+   return panel->funcs->get_info(panel, connector);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
 static inline int drm_panel_get_modes(struct drm_panel *panel)
 {
if (panel && panel->funcs && panel->funcs->get_modes)
-- 
1.9.1

[PATCH v5 3/5] drm: simplify initialization of rotation property

[Ville Syrjälä]

On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> This patch simplifies initialization of generic rotation property and
> aligns the code to match recently introduced function for intializing
> generic zpos property. It also adds missing documentation.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 -
>  drivers/gpu/drm/drm_crtc.c  | 29 
> -
>  drivers/gpu/drm/i915/intel_display.c|  6 ++---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  3 +--
>  drivers/gpu/drm/omapdrm/omap_drv.c  |  3 +--
>  include/drm/drm_crtc.h  |  4 ++--
>  6 files changed, 33 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 1ffe9c329c46..4f9606cdf0f2 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -967,12 +967,10 @@ atmel_hlcdc_plane_create_properties(struct drm_device 
> *dev)
>   if (!props->alpha)
>   return ERR_PTR(-ENOMEM);
>  
> - dev->mode_config.rotation_property =
> - drm_mode_create_rotation_property(dev,
> -   BIT(DRM_ROTATE_0) |
> -   BIT(DRM_ROTATE_90) |
> -   BIT(DRM_ROTATE_180) |
> -   BIT(DRM_ROTATE_270));
> + drm_mode_create_rotation_property(dev, BIT(DRM_ROTATE_0) |
> +BIT(DRM_ROTATE_90) |
> +BIT(DRM_ROTATE_180) |
> +BIT(DRM_ROTATE_270));
>   if (!dev->mode_config.rotation_property)
>   return ERR_PTR(-ENOMEM);
>  
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d40bab29747e..822ad6928144 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5875,10 +5875,23 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>  
> -struct drm_property *drm_mode_create_rotation_property(struct drm_device 
> *dev,
> -unsigned int 
> supported_rotations)
> +/**
> + * drm_mode_create_rotation_property - create generic rotation property
> + * @dev: DRM device
> + * @supported_rotations: bitmask of supported rotation modes
> + *
> + * This function initializes generic rotation property and enables support
> + * for it in drm core. Drivers can then attach this property to planes to 
> enable
> + * support for different rotation modes.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_create_rotation_property(struct drm_device *dev,
> +   unsigned int supported_rotations)
>  {
> - static const struct drm_prop_enum_list props[] = {
> + struct drm_property *prop;
> + static const struct drm_prop_enum_list values[] = {
>   { DRM_ROTATE_0,   "rotate-0" },
>   { DRM_ROTATE_90,  "rotate-90" },
>   { DRM_ROTATE_180, "rotate-180" },
> @@ -5887,9 +5900,13 @@ struct drm_property 
> *drm_mode_create_rotation_property(struct drm_device *dev,
>   { DRM_REFLECT_Y,  "reflect-y" },
>   };
>  
> - return drm_property_create_bitmask(dev, 0, "rotation",
> -props, ARRAY_SIZE(props),
> -supported_rotations);
> + prop = drm_property_create_bitmask(dev, 0, "rotation", values,
> + ARRAY_SIZE(values), supported_rotations);
> + if (!prop)
> + return -ENOMEM;
> +
> + dev->mode_config.rotation_property = prop;

Again, per-plane rotation properties are going to be needed, so this
isn't good.

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Daniel Vetter]

On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
> 
> 
> On 2/24/2016 3:41 AM, Lyude wrote:
> >As it turns out, resuming DP MST is racey since we don't make sure MST
> >is ready before we start modesetting, it just usually happens to be
> >ready in time. This isn't the case on all systems, particularly a
> >ThinkPad T560 with displays connected through the dock. On these
> >systems, resuming the laptop while connected to the dock usually results
> >in blank monitors. Making sure MST is ready before doing any kind of
> >modesetting fixes this issue.
> basic question since i haven't worked on MST much. MST should work like any
> other digital panel on resume. i.e detect followed by modeset. in the
> modified
> commit mentioned below is it failing to detect the panel or failing at the
> modeset ?
> if we are depending on the intel_display_resume, how about moving the
> intel_dp_mst_resume just above intel_display_resume?
> 
> 
> Generic question to others in mail list on i915_drm_resume
> we are doing a modeset and then doing the detect/hpd init.
> shouldn't this be the other way round ? almost all displays
> will pass a modeset even if display is not connected so we
> are spending time on modeset even for displays that were
> removed during the suspend state. if this is to simply
> drm_state being saved and restored,

We must restore anyway, we're not really allowed to shut down a display
without userspace's consent. DP mst breaks this, and it's not fun really.
So for hotunplug the flow should always be:
1. kernel notices something has changed in the output config.
2. kernel sends out uevent
3. userspace figures out what changed, and what needs to be done
4. userspace asks the kernel to change display configuration through
setCrtc and Atomic ioctl calls.

Irrespective of hotunplug handling, the kernel also _must_ restore the
entire display configuration before userspace resumes. We can do that
asynchronously (and there's plans for that), but even then we must stall
userspace on the first KMS ioclt to keep up the illusion that a system s/r
is transparent.

In short, even if we do hpd processing before resuming the display,
nothing will be faster - we must wait for userspace to make up its mind,
and that can only happen once we've restored the display config.

And again, mst is kinda breaking this, since and mst unplug results in a
force-disable. Which can upset userspace and in general results in the
need for lots of fragile error handling all over.

> >We originally changed the resume order in
> >
> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
> >
> >to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
> >issue now anyhow.
> >
> >CC: stable at vger.kernel.org
> >Signed-off-by: Lyude 

Wrt the patch itself: I think only in 4.6 we've actually fixed up all
these mst WARN_ON. Cc: stable seems extremely risky on this one. Also, the
modeset state readout for mst is still not entirely correct (it still
relies on software state), so I'm not sure we've actually managed to shut
up all the WARNINGs. Iirc the way to repro them is to hot-unplug something
while suspended. In short the get_hw_state functions for mst should not
rely on any mst software state, but instead just look at hw registers and
dp aux registers to figure out what's going on. But not sure whether this
will result on WARNINGs on resume, since generally the bios doesn't enable
anything in that case.

Furthermore MST still does a force-modeset when processing a hotunplug.
Doing that before we've resumed the display is likely a very bad idea.
What we need to fix that part is to separate the dp mst connector
hotplug/unplugging from actually updating the modeset change. This needs
reference-counting on drm_connector (so that we can lazily free
drm_connector structs after hot-unplug), and is a major change.

In short: I'm scared about this patch ;-)

Thanks, Daniel


> >---
> >  drivers/gpu/drm/i915/i915_drv.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >b/drivers/gpu/drm/i915/i915_drv.c
> >index f357058..4dcf3dd 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.c
> >+++ b/drivers/gpu/drm/i915/i915_drv.c
> >@@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev)
> > intel_opregion_setup(dev);
> > intel_init_pch_refclk(dev);
> >+
> >+/*
> >+ * We need to make sure that we resume MST before doing anything
> >+ * display related, otherwise we risk trying to bring up a display on
> >+ * MST before the hub is actually ready
> >+ */
> >+intel_dp_mst_resume(dev);
> >+
> This does not look proper. if the CD clock is turned off during suspend
> our dpcd read itself might fail till we enable CD Clock.
> 
> regards,
> Sivakumar
> > drm_mode_config_reset(dev);
> > /*
> >@@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev)
> > 

[PATCH v5 1/5] drm: add generic zpos property

[Ville Syrjälä]

On Wed, Jan 27, 2016 at 03:44:39PM +0100, Marek Szyprowski wrote:
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to drm core and plane state structures
> - added helpers for normalizing zpos properties of given set of planes
> - well defined semantics: planes are sorted by zpos values and then plane
>   id value if zpos equals
> 
> Normalized zpos values are calculated automatically when generic
> muttable zpos property has been initialized. Drivers can simply use
> plane_state->normalized_zpos in their atomic_check and/or plane_update
> callbacks without any additional calls to DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> Tested-by: Benjamin Gaignard 
> ---
>  Documentation/DocBook/gpu.tmpl  |  14 ++-
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_atomic.c|   4 +
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
>  drivers/gpu/drm/drm_blend.c | 227 
> 
>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
>  include/drm/drm_crtc.h  |  17 +++
>  7 files changed, 270 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_blend.c
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index a8669330b456..ae7d913adf60 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
>   Description/Restrictions
>   
>   
> - DRM
> + DRM
>   Generic
>   “rotation”
>   BITMASK
> @@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
>   property to suggest an Y offset for a connector
>   
>   
> - Optional
> + Optional
>   “scaling mode”
>   ENUM
>   { "None", "Full", "Center", "Full aspect" }
> @@ -2092,6 +2092,16 @@ void intel_crt_init(struct drm_device *dev)
>   TBD
>   
>   
> +  "zpos" 
> + RANGE
> + Min=0, Max= driver dependent
> + Plane
> + Plane's 'z' position during blending operation (0 for 
> background, highest for frontmost).
> + If two planes assigned to same CRTC have equal zpos values, the 
> plane with higher plane
> + id is treated as closer to front. Can be IMMUTABLE if driver 
> doesn't support changing
> + planes' order. Exact value range is driver dependent.
> + 
> + 
>   i915
>   Generic
>   "Broadcast RGB"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 61766dec6a8d..eeefaba1c092 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the drm device driver.  This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
> -drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
> +drm-y   :=   drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
>   drm_context.o drm_dma.o \
>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>   drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3f74193885f1..a19201efb7d1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -630,6 +630,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_h = val;
>   } else if (property == config->rotation_property) {
>   state->rotation = val;
> + } else if (property == config->zpos_property) {
> + state->zpos = val;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -686,6 +688,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_h;
>   } else if (property == config->rotation_property) {
>   *val = state->rotation;
> + } else if (property == config->zpos_property) {
> + *val = state->zpos;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 53db2d9120be..9fbfb672b317 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
>  
> +#include "drm_crtc_internal.h"
> +
>  /**
>   * DOC: overview
>   *
> @@ -530,6 +532,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>   struct drm_plane_state *plane_state;
>   int i, ret = 0;
>  
> + ret = drm_atomic_helper_normalize_zpos(dev, state);
> + if (ret)
> + return ret;
> +
>   for_each_plane_in_state(state, plane, plane_state, i) {
>   

[PATCH 2/4] drm/i915: Respect DP++ adaptor TMDS clock limit

[Daniel Vetter]

On Tue, Feb 23, 2016 at 06:46:26PM +0200, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
> and take it into account when checking the port clock.
> 
> Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
> the adaptor TMDS clock limit in the modeset path, in case users are
> already "overclocking" their TMDS links. One subtle change here is that
> we'll have to respect the adaptor TMDS clock limit when we decide whether
> to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
> accidentally driving the TMDS link out of spec even when the user chose
> a mode that fits wihting the limits at 8bpc. This means you can't
> "overclock" your DP++ dongle at 12bpc anymore, but you can continue to
> do so at 8bpc.
> 
> Note that for simplicity we'll use the I2C access method for all dual
> mode adaptors including type 2. Otherwise we'd have to start mixing
> DP AUX and HDMI together. In the future we may need to do that if we
> come across any board designs that don't hook up the DDC pins to the
> DP++ connectors. Such boards would obviously only work with type 2
> dual mode adaptors, and not type 1.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Daniel Vetter 

And on this patch and patch 1:

Cc: drm-intel-fixes at lists.freedesktop.org

I'll review patch 1 too if someone pities me with the spec ;-)

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_drv.h  |  3 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 65 
> ++-
>  2 files changed, 60 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 4852049c9ab3..944eacbfb6a9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -704,6 +704,9 @@ struct cxsr_latency {
>  struct intel_hdmi {
>   i915_reg_t hdmi_reg;
>   int ddc_bus;
> + struct {
> + int max_tmds_clock;
> + } dp_dual_mode;
>   bool limited_color_range;
>   bool color_range_auto;
>   bool has_hdmi_sink;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 80b44c054087..1e8cfdb18dc7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "intel_drv.h"
>  #include 
>  #include "i915_drv.h"
> @@ -1168,27 +1169,42 @@ static void pch_post_disable_hdmi(struct 
> intel_encoder *encoder)
>   intel_disable_hdmi(encoder);
>  }
>  
> -static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool 
> respect_dvi_limit)
> +static int intel_hdmi_source_max_tmds_clock(struct drm_i915_private 
> *dev_priv)
>  {
> - struct drm_device *dev = intel_hdmi_to_dev(hdmi);
> -
> - if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
> + if (IS_G4X(dev_priv))
>   return 165000;
> - else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
> + else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
>   return 30;
>   else
>   return 225000;
>  }
>  
> +static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
> +  bool respect_downstream_limits)
> +{
> + struct drm_device *dev = intel_hdmi_to_dev(hdmi);
> + int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
> +
> + if (respect_downstream_limits) {
> + if (hdmi->dp_dual_mode.max_tmds_clock)
> + max_tmds_clock = min(max_tmds_clock,
> +  hdmi->dp_dual_mode.max_tmds_clock);
> + if (!hdmi->has_hdmi_sink)
> + max_tmds_clock = min(max_tmds_clock, 165000);
> + }
> +
> + return max_tmds_clock;
> +}
> +
>  static enum drm_mode_status
>  hdmi_port_clock_valid(struct intel_hdmi *hdmi,
> -   int clock, bool respect_dvi_limit)
> +   int clock, bool respect_downstream_limits)
>  {
>   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
>  
>   if (clock < 25000)
>   return MODE_CLOCK_LOW;
> - if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
> + if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits))
>   return MODE_CLOCK_HIGH;
>  
>   /* BXT DPLL can't generate 223-240 MHz */
> @@ -1312,7 +1328,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>* within limits.
>*/
>   if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink &&
> - hdmi_port_clock_valid(intel_hdmi, clock_12bpc, false) == MODE_OK &&
> + hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true) == MODE_OK &&
>   hdmi_12bpc_possible(pipe_config)) {
>   DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
>   desired_bpp = 12*3;
> @@ 

[Intel-gfx] [PATCH v5 2/7] drm: add parameter-order checking to drm memory allocators

[Emil Velikov]

 On 29 February 2016 at 16:16, Tvrtko Ursulin
 wrote:
>
> On 29/02/16 11:13, Dave Gordon wrote:
>>
>> After the recent addition of drm_malloc_gfp(), it was noticed that
>> some callers of these functions has swapped the parameters in the
>> call - it's supposed to be 'number of members' and 'sizeof(element)',
>> but a few callers had got the size first and the count second. This
>> isn't otherwise detected because they're both type 'size_t', and
>> the implementation at present just multiplies them anyway, so the
>> result is still right. But some future implementation might treat
>> them differently (e.g. allowing 0 elements but not zero size), so
>> let's add some compile-time checks and complain if the second (size)
>> parameter isn't a sizeof() expression, or at least a compile-time
>> constant.
>>
>> This patch also fixes those callers where the order was wrong.
>>
>> Signed-off-by: Dave Gordon 
>> Cc: Chris Wilson 
>> Cc: Ville Syrjälä Cc: dri-
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>>   drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
>>   drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  8 
>>   include/drm/drm_mem_util.h   | 30
>> +---
>>   3 files changed, 32 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>> index 1aba01a..9ae4a71 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>> @@ -340,7 +340,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev,
>> void *data,
>>  */
>> bos = drm_malloc_ab(args->nr_bos, sizeof(*bos));
>> relocs = drm_malloc_ab(args->nr_relocs, sizeof(*relocs));
>> -   stream = drm_malloc_ab(1, args->stream_size);
>> +   stream = drm_malloc_ab(args->stream_size, sizeof(*stream));
>
>
> I was surprised sizeof(void) == 1. On further research that seems to be an
> GCC extension.
>
Afaict pointer arithmetic (-Wpointer-arith) has/is been used in the
kernel extensively. In userspace we try to avoid it libdrm and mesa,
there might be a few cases where it's still around. No too sure about
libva{,-intel}.

> I am not sure how active projects to compile the kernel with for example ICC
> are, just remember some talks about it in the past. Maybe it is even
> possible? In that case it would be better to just leave "1" there to not
> rely on GCC extensions.
>
While I'm all for the idea, I doubt we'll get there any time soon. My
last suggestion (do not use zero sized arrays) went down in flames :-(

Regards,
Emil

[PATCH v3 26/26] drm/amdgpu: Use dal driver for Carrizo, Tonga, and Fiji

[Harry Wentland]

Start to use dal by default on Carrizo, Tonga, and Fiji ASICs.

v3 changes:
- rebase on Alex's latest drm-next-4.6-wip
- export some functions to share with DAL
- remove has_dal_support macro and move logic into amdgpu_device_has_dal_support

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/Kconfig |   3 +
 drivers/gpu/drm/amd/amdgpu/Makefile|  17 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  70 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |   5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|  20 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |  63 +++-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  12 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.h |   7 +
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  12 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.h |   7 +
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  12 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.h  |   7 +
 drivers/gpu/drm/amd/amdgpu/vi.c| 250 +
 15 files changed, 449 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index b30fcfa4b1f2..3a37e37bef28 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -15,3 +15,6 @@ config DRM_AMDGPU_USERPTR
help
  This option selects CONFIG_MMU_NOTIFIER if it isn't already
  selected to enabled full userptr support.
+
+source "drivers/gpu/drm/amd/dal/Kconfig"
+
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index c7fcdcedaadb..c434ee5c589f 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -3,13 +3,19 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

 FULL_AMD_PATH=$(src)/..
+DAL_FOLDER_NAME=dal
+FULL_AMD_DAL_PATH = $(FULL_AMD_PATH)/$(DAL_FOLDER_NAME)

 ccflags-y := -Iinclude/drm -I$(FULL_AMD_PATH)/include/asic_reg \
-I$(FULL_AMD_PATH)/include \
-I$(FULL_AMD_PATH)/amdgpu \
-I$(FULL_AMD_PATH)/scheduler \
-I$(FULL_AMD_PATH)/powerplay/inc \
-   -I$(FULL_AMD_PATH)/acp/include
+   -I$(FULL_AMD_PATH)/acp/include \
+   -I$(FULL_AMD_DAL_PATH) \
+   -I$(FULL_AMD_DAL_PATH)/include \
+   -I$(FULL_AMD_DAL_PATH)/dc \
+   -I$(FULL_AMD_DAL_PATH)/amdgpu_dm

 amdgpu-y := amdgpu_drv.o

@@ -118,6 +124,15 @@ amdgpu-y += $(AMD_POWERPLAY_FILES)

 endif

+ifneq ($(CONFIG_DRM_AMD_DAL),)
+
+RELATIVE_AMD_DAL_PATH = ../$(DAL_FOLDER_NAME)
+include $(FULL_AMD_DAL_PATH)/Makefile
+
+amdgpu-y += $(AMD_DAL_FILES)
+
+endif
+
 obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o

 CFLAGS_amdgpu_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f5bac97a438b..9e14c2a4bcda 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -54,6 +54,7 @@
 #include "amdgpu_gds.h"
 #include "amd_powerplay.h"
 #include "amdgpu_acp.h"
+#include "amdgpu_dm.h"

 #include "gpu_scheduler.h"

@@ -85,6 +86,7 @@ extern int amdgpu_vm_debug;
 extern int amdgpu_sched_jobs;
 extern int amdgpu_sched_hw_submission;
 extern int amdgpu_powerplay;
+extern int amdgpu_dal;

 #define AMDGPU_WAIT_IDLE_TIMEOUT_IN_MS 3000
 #define AMDGPU_MAX_USEC_TIMEOUT10  /* 100 ms */
@@ -2016,6 +2018,7 @@ struct amdgpu_device {

/* display */
struct amdgpu_mode_info mode_info;
+   /* For pre-DCE11. DCE11 and later are in "struct amdgpu_device->dm" */
struct work_struct  hotplug_work;
struct amdgpu_irq_src   crtc_irq;
struct amdgpu_irq_src   pageflip_irq;
@@ -2063,6 +2066,9 @@ struct amdgpu_device {
/* GDS */
struct amdgpu_gds   gds;

+   /* display related functionality */
+   struct amdgpu_display_manager dm;
+
const struct amdgpu_ip_block_version *ip_blocks;
int num_ip_blocks;
struct amdgpu_ip_block_status   *ip_block_status;
@@ -2096,7 +2102,7 @@ void amdgpu_io_wreg(struct amdgpu_device *adev, u32 reg, 
u32 v);

 u32 amdgpu_mm_rdoorbell(struct amdgpu_device *adev, u32 index);
 void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, u32 index, u32 v);
-
+bool amdgpu_device_has_dal_support(struct amdgpu_device *adev);
 /*
  * Cast helper
  */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index db20d2783def..fc8c765feabf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1369,6 +1369,33 @@ static int amdgpu_resume(struct amdgpu_device *adev)
return 0;
 }

+
+/**
+ * amdgpu_device_has_dal_support - check if dal is supported
+ *
+ * @adev: amdgpu_device_pointer
+ *
+ * Returns true for 

[PATCH v3 25/26] drm/amd/dal: Adding amdgpu_dm for dal

[Harry Wentland]

Implements DRM's atomic KMS interfaces using DC.

v3 changes:
- use amdgpu's existing dce functions for some things, such as mc_access
- add stoney to dal check
- add missing hawaii and stoney case statements
- remove page work flip queue and use system queue instead
- minor dm_helpers function name cleanup
- expose I2C through i2c_adapter and route dal i2c calls through this

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile |   17 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c  | 1271 ++
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.h  |  168 ++
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_helpers.c  |  517 
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.c  |  820 ++
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.h  |  122 +
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.c|  480 
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.h|   36 +
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_services.c |  457 
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c| 2649 
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.h|  100 +
 drivers/gpu/drm/amd/dal/dc/dm_services.h   |   17 -
 12 files changed, 6637 insertions(+), 17 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.h
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_helpers.c
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.c
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.h
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.c
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.h
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_services.c
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c
 create mode 100644 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.h

diff --git a/drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile 
b/drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile
new file mode 100644
index ..0f365c65342e
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile
@@ -0,0 +1,17 @@
+#
+# Makefile for the 'dm' sub-component of DAL.
+# It provides the control and status of dm blocks.
+
+
+
+AMDGPUDM = amdgpu_dm_types.o amdgpu_dm.o amdgpu_dm_irq.o amdgpu_dm_mst_types.o
+
+ifneq ($(CONFIG_DRM_AMD_DAL),)
+AMDGPUDM += amdgpu_dm_services.o amdgpu_dm_helpers.o
+endif
+
+subdir-ccflags-y += -I$(FULL_AMD_DAL_PATH)/dc
+
+AMDGPU_DM = $(addprefix $(AMDDALPATH)/amdgpu_dm/,$(AMDGPUDM))
+
+AMD_DAL_FILES += $(AMDGPU_DM)
diff --git a/drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c
new file mode 100644
index ..e3475b767e0f
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c
@@ -0,0 +1,1271 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dm_services_types.h"
+#include "dc.h"
+
+#include "vid.h"
+#include "amdgpu.h"
+#include "atom.h"
+#include "amdgpu_dm.h"
+#include "amdgpu_dm_types.h"
+
+#include "amd_shared.h"
+#include "amdgpu_dm_irq.h"
+#include "dm_helpers.h"
+
+#include "dce_v8_0.h"
+#include "dce_v10_0.h"
+#include "dce_v11_0.h"
+
+#include "ivsrcid/ivsrcid_vislands30.h"
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Define variables here
+ * These values will be passed to DAL for feature enable purpose
+ * Disable ALL for HDMI light up
+ * TODO: follow up if need this mechanism*/
+struct dal_override_parameters display_param = {
+   .bool_param_enable_mask = 0,
+   .bool_param_values = 0,
+   .int_param_values[DAL_PARAM_MAX_COFUNC_NON_DP_DISPLAYS] = 
DAL_PARAM_INVALID_INT,
+   .int_param_values[DAL_PARAM_DRR_SUPPORT] = 

[PATCH v3 24/26] drm/amd/dal: Add display core

[Harry Wentland]

Adds a logical representation of our hardware. Provides ability to
- dc_validate_resources - validate a display configuration
- dc_commit_targets - commit a display configuration
- dc_commit_surfaces_to_target - update surfaces
- dc_link_detect - detect displays at link
- dc_resume - resume display HW
- dc_interrupt_set/ack - set and ack interrupts
- etc.

v3 changes:
- minor dm_helpers name cleanup
- expose I2C through i2c_adapter and route dal i2c calls through this

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/Makefile   |   28 +
 drivers/gpu/drm/amd/dal/dc/core/dc.c  |  947 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_hw_sequencer.c |   56 +
 drivers/gpu/drm/amd/dal/dc/core/dc_link.c | 1645 
 drivers/gpu/drm/amd/dal/dc/core/dc_link_ddc.c | 1121 +
 drivers/gpu/drm/amd/dal/dc/core/dc_link_dp.c  | 1728 +
 drivers/gpu/drm/amd/dal/dc/core/dc_link_hwss.c|  201 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_resource.c | 1243 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_sink.c |  116 ++
 drivers/gpu/drm/amd/dal/dc/core/dc_stream.c   |  188 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_surface.c  |  123 ++
 drivers/gpu/drm/amd/dal/dc/core/dc_target.c   |  548 +++
 12 files changed, 7944 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_hw_sequencer.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link_ddc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link_dp.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link_hwss.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_resource.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_sink.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_stream.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_surface.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_target.c

diff --git a/drivers/gpu/drm/amd/dal/dc/Makefile 
b/drivers/gpu/drm/amd/dal/dc/Makefile
new file mode 100644
index ..aed26eec81f9
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/Makefile
@@ -0,0 +1,28 @@
+#
+# Makefile for Display Core (dc) component.
+#
+
+DC_LIBS = adapter asic_capability audio basics bios calcs \
+gpio gpu i2caux irq virtual
+
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+DC_LIBS += dce110
+endif
+
+ifdef CONFIG_DRM_AMD_DAL_DCE10_0
+DC_LIBS += dce100
+endif
+
+AMD_DC = $(addsuffix /Makefile, $(addprefix 
$(FULL_AMD_DAL_PATH)/dc/,$(DC_LIBS)))
+
+include $(AMD_DC)
+
+DISPLAY_CORE = dc.o dc_link.o dc_resource.o dc_target.o dc_sink.o dc_stream.o \
+dc_hw_sequencer.o dc_surface.o dc_link_hwss.o dc_link_dp.o dc_link_ddc.o
+
+AMD_DISPLAY_CORE = $(addprefix $(AMDDALPATH)/dc/core/,$(DISPLAY_CORE))
+
+AMD_DAL_FILES += $(AMD_DISPLAY_CORE)
+
+
+
diff --git a/drivers/gpu/drm/amd/dal/dc/core/dc.c 
b/drivers/gpu/drm/amd/dal/dc/core/dc.c
new file mode 100644
index ..3ba7af0390f5
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/core/dc.c
@@ -0,0 +1,947 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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.
+ *
+ * Authors: AMD
+ */
+
+#include "dm_services.h"
+
+#include "dc.h"
+
+#include "core_status.h"
+#include "core_types.h"
+#include "hw_sequencer.h"
+
+#include "resource.h"
+
+#include "adapter_service_interface.h"
+#include "clock_source.h"
+#include "dc_bios_types.h"
+
+#include "bandwidth_calcs.h"
+#include "include/irq_service_interface.h"
+#include "transform.h"
+#include "timing_generator.h"
+#include "virtual/virtual_link_encoder.h"
+
+#include "link_hwss.h"
+#include "link_encoder.h"
+
+#include "dc_link_ddc.h"
+
+/***
+ * 

[PATCH v3 07/26] drm/amd/dal: BIOS Parser

[Harry Wentland]

Wrapper to access Video BIOS command and data tables

v3 changes:
- expose I2C through i2c_adapter and route dal i2c calls through this

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/bios/Makefile   |   26 +
 drivers/gpu/drm/amd/dal/dc/bios/bios_parser.c  | 5030 
 drivers/gpu/drm/amd/dal/dc/bios/bios_parser.h  |   84 +
 .../gpu/drm/amd/dal/dc/bios/bios_parser_helper.c   |  198 +
 .../gpu/drm/amd/dal/dc/bios/bios_parser_helper.h   |  108 +
 drivers/gpu/drm/amd/dal/dc/bios/command_table.c| 2730 +++
 drivers/gpu/drm/amd/dal/dc/bios/command_table.h|  117 +
 .../gpu/drm/amd/dal/dc/bios/command_table_helper.c |  285 ++
 .../gpu/drm/amd/dal/dc/bios/command_table_helper.h |   90 +
 .../dal/dc/bios/dce110/bios_parser_helper_dce110.c |  484 ++
 .../dal/dc/bios/dce110/bios_parser_helper_dce110.h |   34 +
 .../dc/bios/dce110/command_table_helper_dce110.c   |  366 ++
 .../dc/bios/dce110/command_table_helper_dce110.h   |   34 +
 13 files changed, 9586 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/bios_parser.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/bios_parser.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/bios_parser_helper.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/bios_parser_helper.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/command_table.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/command_table.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/command_table_helper.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/bios/command_table_helper.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/bios/dce110/bios_parser_helper_dce110.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/bios/dce110/bios_parser_helper_dce110.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/bios/dce110/command_table_helper_dce110.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/bios/dce110/command_table_helper_dce110.h

diff --git a/drivers/gpu/drm/amd/dal/dc/bios/Makefile 
b/drivers/gpu/drm/amd/dal/dc/bios/Makefile
new file mode 100644
index ..ddfe457e3a8b
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/bios/Makefile
@@ -0,0 +1,26 @@
+#
+# Makefile for the 'bios' sub-component of DAL.
+# It provides the parsing and executing controls for atom bios image.
+
+BIOS = bios_parser.o bios_parser_helper.o command_table.o 
command_table_helper.o
+
+AMD_DAL_BIOS = $(addprefix $(AMDDALPATH)/dc/bios/,$(BIOS))
+
+AMD_DAL_FILES += $(AMD_DAL_BIOS)
+
+ifndef CONFIG_DRM_AMD_DAL_VBIOS_PRESENT
+AMD_DAL_FILES := $(filter-out 
$(AMDDALPATH)/dc/bios/bios_parser_helper.o,$(AMD_DAL_FILES))
+endif
+
+
+###
+# DCE 11x
+###
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+
+ifdef CONFIG_DRM_AMD_DAL_VBIOS_PRESENT
+AMD_DAL_FILES += $(AMDDALPATH)/dc/bios/dce110/bios_parser_helper_dce110.o
+endif
+
+AMD_DAL_FILES += $(AMDDALPATH)/dc/bios/dce110/command_table_helper_dce110.o
+endif
diff --git a/drivers/gpu/drm/amd/dal/dc/bios/bios_parser.c 
b/drivers/gpu/drm/amd/dal/dc/bios/bios_parser.c
new file mode 100644
index ..586a5ee17705
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/bios/bios_parser.c
@@ -0,0 +1,5030 @@
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
+ *
+ * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dm_services.h"
+
+#include "atom.h"
+
+#include "dc_bios_types.h"
+#include "include/adapter_service_interface.h"
+#include "include/grph_object_ctrl_defs.h"
+#include "include/bios_parser_interface.h"
+#include "include/i2caux_interface.h"
+#include "include/logger_interface.h"
+
+#include "command_table.h"
+#if defined(CONFIG_DRM_AMD_DAL_VBIOS_PRESENT)
+#include "bios_parser_helper.h"
+#endif
+#include 

[PATCH v3 05/26] drm/amd/dal: GPIO (General Purpose IO)

[Harry Wentland]

v3 changes:
- expose I2C through i2c_adapter and route dal i2c calls through this

Manages all DCE GPIO pins. The pins are represented as generic IO
handles as well as handles dedicated for certain functions, such as
DDC, HPD, and DVO.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/gpio/Makefile   |  32 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.c | 882 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.h |  46 ++
 .../drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.c |  81 ++
 .../drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.h |  32 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.c | 366 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.h |  47 ++
 .../amd/dal/dc/gpio/dce110/hw_translate_dce110.c   | 400 ++
 .../amd/dal/dc/gpio/dce110/hw_translate_dce110.h   |  34 +
 drivers/gpu/drm/amd/dal/dc/gpio/ddc.c  | 290 +++
 drivers/gpu/drm/amd/dal/dc/gpio/ddc.h  |  38 +
 .../drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.c  |  97 +++
 .../drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.h  |  34 +
 .../amd/dal/dc/gpio/diagnostics/hw_factory_diag.c  |  65 ++
 .../amd/dal/dc/gpio/diagnostics/hw_factory_diag.h  |  32 +
 .../drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.c  | 101 +++
 .../drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.h  |  35 +
 .../dal/dc/gpio/diagnostics/hw_translate_diag.c|  41 +
 .../dal/dc/gpio/diagnostics/hw_translate_diag.h|  34 +
 drivers/gpu/drm/amd/dal/dc/gpio/gpio.h |  48 ++
 drivers/gpu/drm/amd/dal/dc/gpio/gpio_base.c| 279 +++
 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.c | 386 +
 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.h |  57 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.c   | 104 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.h   |  60 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.c   |  93 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.h   |  71 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.c  | 407 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.h  | 129 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.c  |  92 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.h  |  47 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pin.c  |  85 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pin.h  |  79 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_hpd.c   |  87 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_hpd.h   |  45 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_translate.c |  77 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_translate.h |  50 ++
 drivers/gpu/drm/amd/dal/dc/gpio/irq.c  | 180 +
 drivers/gpu/drm/amd/dal/dc/gpio/irq.h  |  42 +
 39 files changed, 5105 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_translate_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_translate_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/ddc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/ddc.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_factory_diag.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_factory_diag.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_translate_diag.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_translate_diag.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio_base.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.h
 create mode 

[PATCH v3 01/26] drm/amd/dal: Add dal headers

[Harry Wentland]

v3 changes:
- expose I2C through i2c_adapter and route dal i2c calls through this

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dal_services.h | 266 ++
 drivers/gpu/drm/amd/dal/dal_services_types.h   |  62 ++
 drivers/gpu/drm/amd/dal/dc/dc.h| 466 ++
 drivers/gpu/drm/amd/dal/dc/dc_bios_types.h | 277 ++
 drivers/gpu/drm/amd/dal/dc/dc_ddc_types.h  | 129 +++
 drivers/gpu/drm/amd/dal/dc/dc_types.h  | 935 +
 drivers/gpu/drm/amd/dal/dc/dm_helpers.h| 103 +++
 drivers/gpu/drm/amd/dal/dc/dm_services.h   | 485 +++
 drivers/gpu/drm/amd/dal/dc/dm_services_types.h | 167 
 drivers/gpu/drm/amd/dal/dc/inc/bandwidth_calcs.h   | 510 +++
 drivers/gpu/drm/amd/dal/dc/inc/bw_fixed.h  |  64 ++
 drivers/gpu/drm/amd/dal/dc/inc/clock_source.h  | 176 
 drivers/gpu/drm/amd/dal/dc/inc/compressor.h| 140 +++
 drivers/gpu/drm/amd/dal/dc/inc/core_dc.h   |  54 ++
 drivers/gpu/drm/amd/dal/dc/inc/core_status.h   |  46 +
 drivers/gpu/drm/amd/dal/dc/inc/core_types.h| 357 
 drivers/gpu/drm/amd/dal/dc/inc/dc_link_ddc.h   | 152 
 drivers/gpu/drm/amd/dal/dc/inc/dc_link_dp.h|  56 ++
 drivers/gpu/drm/amd/dal/dc/inc/gamma_types.h   | 118 +++
 drivers/gpu/drm/amd/dal/dc/inc/hw_sequencer.h  | 126 +++
 drivers/gpu/drm/amd/dal/dc/inc/ipp.h   | 106 +++
 drivers/gpu/drm/amd/dal/dc/inc/link_encoder.h  | 138 +++
 drivers/gpu/drm/amd/dal/dc/inc/link_hwss.h |  68 ++
 drivers/gpu/drm/amd/dal/dc/inc/mem_input.h |  83 ++
 drivers/gpu/drm/amd/dal/dc/inc/opp.h   | 308 +++
 drivers/gpu/drm/amd/dal/dc/inc/resource.h  |  80 ++
 drivers/gpu/drm/amd/dal/dc/inc/stream_encoder.h|  88 ++
 drivers/gpu/drm/amd/dal/dc/inc/timing_generator.h  | 155 
 drivers/gpu/drm/amd/dal/dc/inc/transform.h | 217 +
 drivers/gpu/drm/amd/dal/dc/irq_types.h | 199 +
 .../amd/dal/include/adapter_service_interface.h| 632 ++
 .../drm/amd/dal/include/adapter_service_types.h|  71 ++
 .../amd/dal/include/asic_capability_interface.h|  58 ++
 .../drm/amd/dal/include/asic_capability_types.h| 134 +++
 drivers/gpu/drm/amd/dal/include/audio_interface.h  | 184 
 drivers/gpu/drm/amd/dal/include/audio_types.h  | 277 ++
 .../drm/amd/dal/include/bios_parser_interface.h|  98 +++
 .../gpu/drm/amd/dal/include/bios_parser_types.h| 327 +++
 drivers/gpu/drm/amd/dal/include/dal_asic_id.h  | 117 +++
 .../gpu/drm/amd/dal/include/dal_register_logger.h  |  43 +
 drivers/gpu/drm/amd/dal/include/dal_types.h| 305 +++
 .../amd/dal/include/dc_clock_generator_interface.h |  77 ++
 drivers/gpu/drm/amd/dal/include/dcs_types.h| 742 
 drivers/gpu/drm/amd/dal/include/ddc_interface.h|  74 ++
 .../gpu/drm/amd/dal/include/ddc_service_types.h| 191 +
 .../drm/amd/dal/include/display_clock_interface.h  | 186 
 .../drm/amd/dal/include/display_path_interface.h   | 436 ++
 drivers/gpu/drm/amd/dal/include/dmcu_interface.h   |  87 ++
 drivers/gpu/drm/amd/dal/include/dmcu_types.h   | 199 +
 drivers/gpu/drm/amd/dal/include/dpcd_defs.h| 873 +++
 .../gpu/drm/amd/dal/include/encoder_interface.h| 278 ++
 drivers/gpu/drm/amd/dal/include/fixed31_32.h   | 389 +
 drivers/gpu/drm/amd/dal/include/fixed32_32.h   |  82 ++
 drivers/gpu/drm/amd/dal/include/gpio_interface.h   |  93 ++
 .../drm/amd/dal/include/gpio_service_interface.h   |  81 ++
 drivers/gpu/drm/amd/dal/include/gpio_types.h   | 337 
 drivers/gpu/drm/amd/dal/include/grph_csc_types.h   |  98 +++
 .../drm/amd/dal/include/grph_object_ctrl_defs.h| 593 +
 drivers/gpu/drm/amd/dal/include/grph_object_defs.h | 328 
 drivers/gpu/drm/amd/dal/include/grph_object_id.h   | 277 ++
 .../drm/amd/dal/include/hw_sequencer_interface.h   | 388 +
 .../gpu/drm/amd/dal/include/hw_sequencer_types.h   | 304 +++
 drivers/gpu/drm/amd/dal/include/i2caux_interface.h | 104 +++
 drivers/gpu/drm/amd/dal/include/irq_interface.h|  53 ++
 .../drm/amd/dal/include/irq_service_interface.h|  55 ++
 .../drm/amd/dal/include/link_service_interface.h   | 202 +
 .../gpu/drm/amd/dal/include/link_service_types.h   | 427 ++
 drivers/gpu/drm/amd/dal/include/logger_interface.h | 153 
 drivers/gpu/drm/amd/dal/include/logger_types.h | 356 
 drivers/gpu/drm/amd/dal/include/scaler_types.h | 196 +
 drivers/gpu/drm/amd/dal/include/set_mode_types.h   | 142 
 drivers/gpu/drm/amd/dal/include/signal_types.h |  59 ++
 drivers/gpu/drm/amd/dal/include/vector.h   | 150 
 drivers/gpu/drm/amd/dal/include/video_csc_types.h  | 135 +++
 .../gpu/drm/amd/dal/include/video_gamma_types.h|  57 ++
 75 files changed, 16579 insertions(+)

[PATCH v3 00/26] Enabling new DAL display driver for amdgpu on Carrizo and Tonga

[Harry Wentland]

Limitting v3 patches to only the modified patches, so as to reduce spam:
0001-drm-amd-dal-Add-dal-headers.patch
0005-drm-amd-dal-GPIO-General-Purpose-IO.patch
0007-drm-amd-dal-BIOS-Parser.patch
0024-drm-amd-dal-Add-display-core.patch
0025-drm-amd-dal-Adding-amdgpu_dm-for-dal.patch
0026-drm-amdgpu-Use-dal-driver-for-Carrizo-Tonga-and-Fiji.patch

Change History
--

v3:
- rebase on Alex's latest drm-next-4.6-wip
- export some functions to share with DAL
- use amdgpu's existing dce functions for some things, such as mc_access
- add stoney to dal check
- add missing hawaii and stoney case statements
- remove page work flip queue and use system queue instead
- minor dm_helpers function name cleanup
- expose I2C through i2c_adapter and route dal i2c calls through this

v2:
This is just a squash of the three small fixes into the main patches to
make for an easier read. No other changes yet.


Description
---

This set of patches enables the new DAL display driver for amdgpu on Carrizo
Tonga, and Fiji ASICs. This driver will allow us going forward to bring
display features on the open amdgpu driver (mostly) on par with the Catalyst
driver.

This driver adds support for 
- Atomic KMS API
- MST
- HDMI 2.0
- Better powerplay integration
- Support of HW bandwidth formula on Carrizo
- Better multi-display support and handling of co-functionality
- Broader support of display dongles
- Timing synchronization between DP and HDMI

This patch series is based on Alex Deucher's drm-next-4.6-wip tree.

Harry Wentland (26):
  drm/amd/dal: Add dal headers
  drm/amd/dal: Add DAL Basic Types and Logger
  drm/amd/dal: Fixed point arithmetic
  drm/amd/dal: Asic Capabilities
  drm/amd/dal: GPIO (General Purpose IO)
  drm/amd/dal: Adapter Service
  drm/amd/dal: BIOS Parser
  drm/amd/dal: I2C Aux Manager
  drm/amd/dal: IRQ Service
  drm/amd/dal: GPU
  drm/amd/dal: Audio
  drm/amd/dal: Bandwidth calculations
  drm/amd/dal: Add encoder HW programming
  drm/amd/dal: Add clock source HW programming
  drm/amd/dal: Add timing generator HW programming
  drm/amd/dal: Add surface HW programming
  drm/amd/dal: Add framebuffer compression HW programming
  drm/amd/dal: Add input pixel processing HW programming
  drm/amd/dal: Add output pixel processing HW programming
  drm/amd/dal: Add transform & scaler HW programming
  drm/amd/dal: Add Carrizo HW sequencer and resource
  drm/amd/dal: Add Tonga/Fiji HW sequencer and resource
  drm/amd/dal: Add empty encoder programming for virtual HW
  drm/amd/dal: Add display core
  drm/amd/dal: Adding amdgpu_dm for dal
  drm/amdgpu: Use dal driver for Carrizo, Tonga, and Fiji

 drivers/gpu/drm/amd/amdgpu/Kconfig |3 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   17 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   70 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|   20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   63 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |   12 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.h |7 +
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |   12 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.h |7 +
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |   12 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.h  |7 +
 drivers/gpu/drm/amd/amdgpu/vi.c|  250 +
 drivers/gpu/drm/amd/dal/Kconfig|   48 +
 drivers/gpu/drm/amd/dal/Makefile   |   21 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile |   17 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c  | 1271 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.h  |  168 +
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_helpers.c  |  517 ++
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.c  |  820 
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.h  |  122 +
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.c|  480 ++
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.h|   36 +
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_services.c |  457 ++
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c| 2649 +++
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.h|  100 +
 drivers/gpu/drm/amd/dal/dal_services.h |  266 ++
 drivers/gpu/drm/amd/dal/dal_services_types.h   |   62 +
 drivers/gpu/drm/amd/dal/dc/Makefile|   28 +
 drivers/gpu/drm/amd/dal/dc/adapter/Makefile|   24 +
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.c   | 2089 
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.h   |   71 +
 .../adapter/dce110/hw_ctx_adapter_service_dce110.c |  304 ++
 .../adapter/dce110/hw_ctx_adapter_service_dce110.h |   40 +
 .../diagnostics/hw_ctx_adapter_service_diag.c  |  133 +
 .../diagnostics/hw_ctx_adapter_service_diag.h  |   33 +
 

[Intel-gfx] [PATCH v5 2/7] drm: add parameter-order checking to drm memory allocators

[Chris Wilson]

On Mon, Feb 29, 2016 at 04:16:57PM +, Tvrtko Ursulin wrote:
> i915 cleanups are good but I am unsure of whether it is good to add
> this constant constraints. All current code seems to use it like
> that, true, but I am not sure that it should be a requirement.

The drm_mem_util allocators are written under that presumption in order
to allow gcc to do some constant-expression elimination - but obviously
that is not strictly required.

I like the assertions, they help describe the API and should allow us to
warn about potential bugs.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] dma-buf/fence: fix fence_is_later v2

[Daniel Vetter]

On Tue, Feb 23, 2016 at 11:04:57AM +0900, Michel Dänzer wrote:
> On 23.02.2016 04:32, Alex Deucher wrote:
> > From: Christian König 
> > 
> > A fence is never later than itself. This caused a bunch of overhead for 
> > AMDGPU.
> > 
> > v2: simplify check as suggested by Michel.
> > 
> > Signed-off-by: Christian König 
> > Reviewed-by: Michel Dänzer 
> > Reviewed-by: Alex Deucher 
> > Signed-off-by: Alex Deucher 
> > ---
> >  include/linux/fence.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/fence.h b/include/linux/fence.h
> > index bb52201..5aa95eb 100644
> > --- a/include/linux/fence.h
> > +++ b/include/linux/fence.h
> > @@ -292,7 +292,7 @@ static inline bool fence_is_later(struct fence *f1, 
> > struct fence *f2)
> > if (WARN_ON(f1->context != f2->context))
> > return false;
> >  
> > -   return f1->seqno - f2->seqno < INT_MAX;
> > +   return (int)(f1->seqno - f2->seqno) > 0;
> >  }
> >  
> >  /**
> > 
> 
> According to
> 
>  scripts/get_maintainer.pl include/linux/fence.h
> 
> this patch should be sent to:
> 
> Sumit Semwal  (maintainer:DMA BUFFER SHARING 
> FRAMEWORK)
> linux-media at vger.kernel.org (open list:DMA BUFFER SHARING FRAMEWORK)
> dri-devel at lists.freedesktop.org (open list:DMA BUFFER SHARING FRAMEWORK)
> linaro-mm-sig at lists.linaro.org (moderated list:DMA BUFFER SHARING 
> FRAMEWORK)
> linux-kernel at vger.kernel.org (open list)
> 
> I'd add at least Sumit and the linaro-mm-sig list.

Plus Maarten Lankhorst please, and Gustavo Padovan maybe. Not sure Sumit
is still all that active on dma-buf/fence maintainership ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

[Daniel Vetter]

On Mon, Feb 22, 2016 at 02:22:49PM -0500, Lyude wrote:
> These warnings still seem to be present with DP MST configurations. They
> don't actually indicate any impending doom, so we may as well use
> I915_STATE_WARN_ON() here to help quiet things down a little bit for
> distro kernel users.
> 
> Signed-off-by: Lyude 

I thought we've fixed up all offenders in drm-intel-nightly? Can you pls
confirm this is the case - this isn't something we should shrug off ...

Also, I kinda wonder whether we should try another attempt at enabling
this, in 4.6/fc rawhide perhaps, and see what happens? We /should/ be a
lot better with all this fail now.

I guess if this is all fixed in upstream/4.6 already then we could apply
this to 4.5 and stable kernels. But I don't really want this in upstream,
if it can be avoided.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a234687..1870185 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3545,7 +3545,7 @@ static void skl_update_other_pipe_wm(struct drm_device 
> *dev,
>* because it was really needed, so we expect the WM values to
>* be different.
>*/
> - WARN_ON(!wm_changed);
> + I915_STATE_WARN_ON(!wm_changed);
>  
>   skl_compute_wm_results(dev, _wm, r, intel_crtc);
>   r->dirty[intel_crtc->pipe] = true;
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[REGRESSION] i915: No HDMI output with 4.4

[Daniel Vetter]

On Mon, Feb 29, 2016 at 03:16:08PM +, Sharma, Shashank wrote:
> Please see the latest mail chain, Sonika has already started on it.

Ah ok, crawling through 1k mails after one week of vacation, so I'm still
catching up ;-) My apologies for the confusion.

Thanks, Daniel
> 
> Regards
> Shashank
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel 
> Vetter
> Sent: Monday, February 29, 2016 8:44 PM
> To: Sharma, Shashank
> Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx at 
> lists.freedesktop.org; dri-devel at lists.freedesktop.org; linux-kernel at 
> vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C
> Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> 
> On Wed, Feb 24, 2016 at 06:07:25AM +, Sharma, Shashank wrote:
> > Hi Ville,
> > We will look into this in sometime. Right now team is slightly loaded due 
> > to project milestone. 
> > Last time I looked into this, we dint have this HW to reproduce this issue.
> 
> This is an upstream regression. Either you can handle it, or your code must 
> be reverted again. Please either assign someone for this, or send in the 
> patch to revert.
> 
> I'll discuss this with Indranil, too.
> 
> Thanks, Daniel
> > 
> > Regards
> > Shashank
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > Sent: Tuesday, February 23, 2016 8:38 PM
> > To: Oleksandr Natalenko
> > Cc: Vetter, Daniel; intel-gfx at lists.freedesktop.org; 
> > dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; Daniel 
> > Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C
> > Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> > 
> > On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
> > > Ville, Daniel,
> > > 
> > > any additional info I could provide? I have to return dual-link DVI 
> > > cable back, so let me know if I could reveal more details if necessary.
> > 
> > Unfortunately I'm out of ideas for now. Daniel is on vacation.
> > Anyone else? VPG folks should take the ball here since they broke it.
> > 
> > In the meantime I think as a workaround I think you could use something 
> > like video=HDMI-A-1:e on the kernel command line (not sure I got the 
> > connector name right for your system). I think that should result in the 
> > live status check to be skipped, at least when populating the mode list.
> > 
> > Might be a good idea to collect all the information here and put in a bug 
> > report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the 
> > logs and such would be in one place.
> > 
> > > 
> > > Regards,
> > >Oleksandr
> > > 
> > > 16.02.2016 14:54, Daniel Vetter написав:
> > > > On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
> > > >> Ville, Daniel,
> > > >> 
> > > >> I've just got another monitor and another DVI-HDMI cable, and 
> > > >> here what I've got.
> > > >> 
> > > >> ===Single Link DVI-D cable with 3 different monitors===
> > > >> 
> > > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI 
> > > >> LG 
> > > >> 23MP65HQ-P === not working
> > > > 
> > > > I presume the above LG screen is what you've called previously 
> > > > "old monitor"?
> > > > 
> > > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI 
> > > >> LG 
> > > >> 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single 
> > > >> Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
> > > >> 
> > > >> ===Dual Link DVI-D cable with monitor that doesn't work with 
> > > >> Single Link cable===
> > > >> 
> > > >> Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 
> > > >> 23MP65HQ-P === works!
> > > > 
> > > > Funky. Can you pls grab the debug logs (with the special patches 
> > > > from
> > > > Ville) for this case? I wonder why suddenly different cable and it 
> > > > works.
> > > > 
> > > > Also: Is this one of these older-ish screens where you must have a 
> > > > dual-link cable to drive it at full resolution rate?
> > > > -Daniel
> > > > 
> > > > 
> > > >> ===Laptop with HDMI output===
> > > >> 
> > > >> Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === 
> > > >> works!
> > > >> 
> > > >> I'd say that single link DVI cables are broken with new kernel, 
> > > >> but one of monitors could work with such a cable. So I have no idea :(.
> > > >> 
> > > >> Regards,
> > > >>   Oleksandr.
> > > >> 
> > > >> 15.02.2016 17:42, Daniel Vetter wrote:
> > > >> >The other downside is that it'll make us non-compliant, which 
> > > >> >was the point of this entire ordeal: HDMI spec forbids us from 
> > > >> >starting any i2c transactions when the hpd isn't signalling a present 
> > > >> >screen.
> > > >> >
> > > >> >So maybe we need to buy one of these broken screens.
> > > >> >
> > > >> >Oleksandr, what exact model are you using? And any chance that 
> > > >> >you could test this on some other 

[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

[Jani Nikula]

On Mon, 29 Feb 2016, Martin Kepplinger  wrote:
> Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
>> Sorry, Cc to Jani was missing mistakenly.
>> 
>> Please check this.  It's a regression in 4.5-rc.
>> 
>> 
>> thanks,
>> 
>> Takashi
>> 
>
> I can confirm that with -rc6 nothing changed and this fixes audio over
> HDMI for me. I added David Airlie and dri-devel to CC aswell and hope
> that this can go in for 4.5 in the last minute.

I'll pick this up when we get the CI results. (This had fallen between
the cracks...)

BR,
Jani.



>
> thanks
> martin
>
>
>> On Wed, 24 Feb 2016 15:35:22 +0100,
>> Takashi Iwai wrote:
>>>
>>> The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between
>>> port and intel_encoder] introduced a reverse mapping to retrieve
>>> intel_dig_port object from the port number.  The code assumed that the
>>> port vs intel_dig_port are 1:1 mapping.  But in reality, this was a
>>> too naive assumption.
>>>
>>> As Martin reported about the missing HDMI audio on his SNB machine,
>>> pre-HSW chips may have multiple intel_dig_port objects corresponding
>>> to the same port.  Since we assign the mapping statically at the init
>>> time and the multiple objects override the map, it may not match with
>>> the actually enabled output.
>>>
>>> This patch tries to address the regression above.  The reverse mapping
>>> is provided basically only for the audio callbacks, so now we set /
>>> clear the mapping dynamically at enabling and disabling HDMI/DP audio,
>>> so that we can always track the latest and correct object
>>> corresponding to the given port.
>>>
>>> Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and 
>>> intel_encoder')
>>> Reported-and-tested-by: Martin Kepplinger 
>>> Signed-off-by: Takashi Iwai 
>>> ---
>>>  drivers/gpu/drm/i915/intel_audio.c | 3 +++
>>>  drivers/gpu/drm/i915/intel_ddi.c   | 1 -
>>>  drivers/gpu/drm/i915/intel_dp.c| 1 -
>>>  drivers/gpu/drm/i915/intel_hdmi.c  | 2 --
>>>  4 files changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>>> b/drivers/gpu/drm/i915/intel_audio.c
>>> index 31f6d212fb1b..30f921421b0c 100644
>>> --- a/drivers/gpu/drm/i915/intel_audio.c
>>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>>> @@ -527,6 +527,8 @@ void intel_audio_codec_enable(struct intel_encoder 
>>> *intel_encoder)
>>>  
>>> mutex_lock(_priv->av_mutex);
>>> intel_dig_port->audio_connector = connector;
>>> +   /* referred in audio callbacks */
>>> +   dev_priv->dig_port_map[port] = intel_encoder;
>>> mutex_unlock(_priv->av_mutex);
>>>  
>>> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
>>> @@ -554,6 +556,7 @@ void intel_audio_codec_disable(struct intel_encoder 
>>> *intel_encoder)
>>>  
>>> mutex_lock(_priv->av_mutex);
>>> intel_dig_port->audio_connector = NULL;
>>> +   dev_priv->dig_port_map[port] = NULL;
>>> mutex_unlock(_priv->av_mutex);
>>>  
>>> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>>> b/drivers/gpu/drm/i915/intel_ddi.c
>>> index 54a165b9c92d..a50fc452d5f1 100644
>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>>> @@ -3312,7 +3312,6 @@ void intel_ddi_init(struct drm_device *dev, enum port 
>>> port)
>>> intel_encoder->get_config = intel_ddi_get_config;
>>>  
>>> intel_dig_port->port = port;
>>> -   dev_priv->dig_port_map[port] = intel_encoder;
>>> intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>>>   (DDI_BUF_PORT_REVERSAL |
>>>DDI_A_4_LANES);
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 1bbd67b046da..acf918728492 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -6035,7 +6035,6 @@ intel_dp_init(struct drm_device *dev,
>>> }
>>>  
>>> intel_dig_port->port = port;
>>> -   dev_priv->dig_port_map[port] = intel_encoder;
>>> intel_dig_port->dp.output_reg = output_reg;
>>>  
>>> intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
>>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>>> b/drivers/gpu/drm/i915/intel_hdmi.c
>>> index 4a77639a489d..23ee48dc765f 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>> @@ -2146,7 +2146,6 @@ void intel_hdmi_init_connector(struct 
>>> intel_digital_port *intel_dig_port,
>>>  void intel_hdmi_init(struct drm_device *dev,
>>>  i915_reg_t hdmi_reg, enum port port)
>>>  {
>>> -   struct drm_i915_private *dev_priv = dev->dev_private;
>>> struct intel_digital_port *intel_dig_port;
>>> struct intel_encoder *intel_encoder;
>>> struct intel_connector *intel_connector;
>>> @@ -2215,7 +2214,6 @@ void intel_hdmi_init(struct drm_device *dev,
>>> intel_encoder->cloneable |= 1 << INTEL_OUTPUT_HDMI;

userptr support in drm drivers

[Daniel Vetter]

On Fri, Feb 19, 2016 at 03:58:24PM +0100, Christian König wrote:
> >If a minority of users need to opt out from MMU_NOTIFIER, then
> >DRM_RADEON_USERPTR and friends should default to y and be hidden behind
> >EXPERT. That way you avoid asking yet more questions to everyone else.
> >Would that work for you?
> No, just the other way around.
> 
> When MMU_NOTIFIER is selected anyway we actually don't want to display the
> option, but that's not possible for none menu entries IIRC the Kconfig
> correctly.
> 
> If somebody configures the kernel and don't selects any of the other
> dependencies for MMU_NOTIFIER the feature should not be available by
> default.
> 
> Making it an expert option is fine with me.

Concurred, if we do this across all drivers supporting userptr.
-Daniel

> 
> Regards,
> Christian.
> 
> Am 19.02.2016 um 15:11 schrieb Jean Delvare:
> >Hi Christian,
> >
> >On Thu, 18 Feb 2016 10:48:18 +0100, Christian König wrote:
> >>Am 18.02.2016 um 09:59 schrieb Jean Delvare:
> >>>Maybe I was not clear enough in my original post, but I am really
> >>>advocating for FEWER kconfig options, not more. Plus I just explained
> >>>why I think the radeon and amdgpu drivers do it wrong, so I'm certainly
> >>>not going to align i915 on that.
> >>>
> Distro kernels pretty much all select MMU_NOTIFIER already for unrelated
> reasons, but it's good to be less suprising for everyone who builds their
> own custom kernel.
> >>>The current situation is actually very surprising and this is what I
> >>>would like to change. The options of one driver depending on choices
> >>>made somewhere else is utterly confusing. CONFIG_RADEON_USERPTR and
> >>>CONFIG_AMDGPU_USERPTR give the user a little more control where i915
> >>>gives none, but that's only in one direction (you can force full
> >>>userptr support in, but you can't force it out.)
> >>As I said, that is perfectly fine and exactly what we want.
> >I don't know what "we" represent in your sentence, but I doubt a
> >majority of users want that.
> >
> >>>I'm still waiting for someone to explain why we can't just
> >>>unconditionally select MMU_NOTIFIER in these 3 drivers and be done with
> >>>it. That's less work at kernel configuration time AND fewer
> >>>preprocessing conditionals within the code, so easier/better testing
> >>>coverage and more readable code. We would need a very good reason for
> >>>NOT doing it.
> >>Adding the MMU Notifier causes overhead in the MM which people want to
> >>avoid when they don't need userptr support.
> >>
> >>We used to select MMU_NOTIFIER unconditionally before and explicitly
> >>added this option on user request. So yes it is clearly necessary.
> >Thanks for the explanation.
> >
> >Can you tell me more about the overhead? Is it actually measurable?
> >Which people need this degree of optimization?
> >
> >Are the i915, radeon or amdgpu drm drivers used on embedded systems?
> >
> >Just because people asked for something doesn't mean that implementing
> >it is a good idea. Keeping things simple is a valid goal on its own.
> >Anyone could ask for features they don't need to become options they
> >can disable, but in the long run this approach can't be sustained.
> >
> >>The additional userptr support code in the drivers are negligible so
> >>always enabling the code when the MMU Notifier is available is also
> >>perfectly fine.
> >Indeed this is a small amount of code. OTOH you have ifdefs in place
> >anyway. Using the right ones would turn the option into a real option,
> >i.e. the user decides to enable a feature or not. Not a "you may or may
> >not get the feature" option as we have at the moment. More control to
> >the user and less confusion.
> >
> >>So if you want to clean it up make a common DRM option which selects MMU
> >>Notifier if it isn't already selected.
> >I will, as it will still be an improvement compared to the current
> >situation. But I still believe this is confusing in its current form.
> >
> >If a minority of users need to opt out from MMU_NOTIFIER, then
> >DRM_RADEON_USERPTR and friends should default to y and be hidden behind
> >EXPERT. That way you avoid asking yet more questions to everyone else.
> >Would that work for you?
> >
> 

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

[PATCH 1/2] drm: Add DRM_MODE_FB_BFF flag definition

[Daniel Vetter]

On Fri, Feb 26, 2016 at 11:33:08AM +0100, Vincent ABRIOU wrote:
> Hi,
> 
> Have you any comment for this proposal?

I guess since we don't really have userspace that uses interlaced modes,
much less actually bothers to get the fields correct I think just have
some (open-source) userspace somewhere (does gstreamer care enough about
this?) which needs this and it's good.

Without userspace this is a hard sell.

Thanks, Daniel

> 
> BR
> Vincent
> 
> On 02/12/2016 10:26 AM, Vincent Abriou wrote:
> > From: Fabien Dessenne 
> >
> > If a buffer is interlaced, this "Bottom Field First" flag specifies
> > which of the top or the bottom field shall be displayed first.
> > When set, the bottom field shall be displayed first.
> > When unset the top field shall be displayed first.
> >
> > Signed-off-by: Fabien Dessenne 
> > ---
> >   drivers/gpu/drm/drm_crtc.c  | 3 ++-
> >   include/uapi/drm/drm_mode.h | 1 +
> >   2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d40bab2..64b4fdac 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -3315,7 +3315,8 @@ internal_framebuffer_create(struct drm_device *dev,
> > struct drm_framebuffer *fb;
> > int ret;
> >
> > -   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
> > +   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS
> > +   | DRM_MODE_FB_BFF)) {
> > DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
> > return ERR_PTR(-EINVAL);
> > }
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 50adb46..f7c9111 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -354,6 +354,7 @@ struct drm_mode_fb_cmd {
> >
> >   #define DRM_MODE_FB_INTERLACED(1<<0) /* for interlaced framebuffers */
> >   #define DRM_MODE_FB_MODIFIERS (1<<1) /* enables ->modifer[] */
> > +#define DRM_MODE_FB_BFF(1<<2) /* if interlaced, bottom field 
> > first */
> >
> >   struct drm_mode_fb_cmd2 {
> > __u32 fb_id;
> >

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

[PATCH 2/2] drm/i915: remove dead code

[Eric Engestrom]

79e539453b34e35f39299a899d263b0a1f1670bd ("DRM: i915: add mode setting
support") added those variables but never used them.

Signed-off-by: Eric Engestrom 
---
 drivers/gpu/drm/i915/intel_tv.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 948cbff..14f0b41 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -326,24 +326,12 @@ static const struct color_conversion sdtv_csc_yprpb = {
.rv = 0x0100, .gv = 0x03ad, .bv = 0x074d, .av = 0x0200,
 };

-static const struct color_conversion sdtv_csc_rgb = {
-   .ry = 0x, .gy = 0x0f00, .by = 0x, .ay = 0x0166,
-   .ru = 0x, .gu = 0x, .bu = 0x0f00, .au = 0x0166,
-   .rv = 0x0f00, .gv = 0x, .bv = 0x, .av = 0x0166,
-};
-
 static const struct color_conversion hdtv_csc_yprpb = {
.ry = 0x05b3, .gy = 0x016e, .by = 0x0728, .ay = 0x0145,
.ru = 0x07d5, .gu = 0x038b, .bu = 0x0100, .au = 0x0200,
.rv = 0x0100, .gv = 0x03d1, .bv = 0x06bc, .av = 0x0200,
 };

-static const struct color_conversion hdtv_csc_rgb = {
-   .ry = 0x, .gy = 0x0f00, .by = 0x, .ay = 0x0166,
-   .ru = 0x, .gu = 0x, .bu = 0x0f00, .au = 0x0166,
-   .rv = 0x0f00, .gv = 0x, .bv = 0x, .av = 0x0166,
-};
-
 static const struct video_levels component_levels = {
.blank = 279, .black = 279, .burst = 0,
 };
-- 
2.7.1

[PATCH 1/2] drm/i915: remove left over dead code

[Eric Engestrom]

ae80152ddad252f33893b92dd69f00cc53c5949f ("drm/i915: Rewrite VLV/CHV
watermark code") removed everything that would have used those vars.

Signed-off-by: Eric Engestrom 
---
 drivers/gpu/drm/i915/intel_pm.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b28c29f..73c290a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -485,20 +485,6 @@ static const struct intel_watermark_params 
g4x_cursor_wm_info = {
.guard_size = 2,
.cacheline_size = G4X_FIFO_LINE_SIZE,
 };
-static const struct intel_watermark_params valleyview_wm_info = {
-   .fifo_size = VALLEYVIEW_FIFO_SIZE,
-   .max_wm = VALLEYVIEW_MAX_WM,
-   .default_wm = VALLEYVIEW_MAX_WM,
-   .guard_size = 2,
-   .cacheline_size = G4X_FIFO_LINE_SIZE,
-};
-static const struct intel_watermark_params valleyview_cursor_wm_info = {
-   .fifo_size = I965_CURSOR_FIFO,
-   .max_wm = VALLEYVIEW_CURSOR_MAX_WM,
-   .default_wm = I965_CURSOR_DFT_WM,
-   .guard_size = 2,
-   .cacheline_size = G4X_FIFO_LINE_SIZE,
-};
 static const struct intel_watermark_params i965_cursor_wm_info = {
.fifo_size = I965_CURSOR_FIFO,
.max_wm = I965_CURSOR_MAX_WM,
-- 
2.7.1

[PATCH v5 3/5] drm: simplify initialization of rotation property

[Daniel Vetter]

On Mon, Feb 29, 2016 at 04:09:31PM +0100, Daniel Vetter wrote:
> On Mon, Feb 29, 2016 at 04:06:40PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> > > This patch simplifies initialization of generic rotation property and
> > > aligns the code to match recently introduced function for intializing
> > > generic zpos property. It also adds missing documentation.
> > > 
> > > Signed-off-by: Marek Szyprowski 
> > 
> > I merged patches 3-5 to drm-misc, thanks. For the blending mode I'd like
> > to gather a few more acks from people who have been proposing ideas in the
> > past (would speed up if you cc them next time around).
> 
> Blergh, I meant patches 1-3 are merged ofc ;-)

Ok, didn't even get around to push it out before I dropped it again on
Ville's request. Please always Cc: everyone who discussed previous
versions of a patch series to get their attention. And please include all
such Cc: lines in the commit messages, so I know whom to ping on irc in
case of doubt first.

And a minor bikeshed: I prefer if there's a per-patch changelog somewhere,
not just in the cover letter. Although I guess doesn't apply here since
most patches are new/completely different.

Thanks, Daniel

> > 
> > Thanks, Daniel
> > > ---
> > >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 -
> > >  drivers/gpu/drm/drm_crtc.c  | 29 
> > > -
> > >  drivers/gpu/drm/i915/intel_display.c|  6 ++---
> > >  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  3 +--
> > >  drivers/gpu/drm/omapdrm/omap_drv.c  |  3 +--
> > >  include/drm/drm_crtc.h  |  4 ++--
> > >  6 files changed, 33 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> > > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > index 1ffe9c329c46..4f9606cdf0f2 100644
> > > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > @@ -967,12 +967,10 @@ atmel_hlcdc_plane_create_properties(struct 
> > > drm_device *dev)
> > >   if (!props->alpha)
> > >   return ERR_PTR(-ENOMEM);
> > >  
> > > - dev->mode_config.rotation_property =
> > > - drm_mode_create_rotation_property(dev,
> > > -   BIT(DRM_ROTATE_0) |
> > > -   BIT(DRM_ROTATE_90) |
> > > -   BIT(DRM_ROTATE_180) |
> > > -   BIT(DRM_ROTATE_270));
> > > + drm_mode_create_rotation_property(dev, BIT(DRM_ROTATE_0) |
> > > +BIT(DRM_ROTATE_90) |
> > > +BIT(DRM_ROTATE_180) |
> > > +BIT(DRM_ROTATE_270));
> > >   if (!dev->mode_config.rotation_property)
> > >   return ERR_PTR(-ENOMEM);
> > >  
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index d40bab29747e..822ad6928144 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -5875,10 +5875,23 @@ void drm_mode_config_cleanup(struct drm_device 
> > > *dev)
> > >  }
> > >  EXPORT_SYMBOL(drm_mode_config_cleanup);
> > >  
> > > -struct drm_property *drm_mode_create_rotation_property(struct drm_device 
> > > *dev,
> > > -unsigned int 
> > > supported_rotations)
> > > +/**
> > > + * drm_mode_create_rotation_property - create generic rotation property
> > > + * @dev: DRM device
> > > + * @supported_rotations: bitmask of supported rotation modes
> > > + *
> > > + * This function initializes generic rotation property and enables 
> > > support
> > > + * for it in drm core. Drivers can then attach this property to planes 
> > > to enable
> > > + * support for different rotation modes.
> > > + *
> > > + * Returns:
> > > + * Zero on success, negative errno on failure.
> > > + */
> > > +int drm_mode_create_rotation_property(struct drm_device *dev,
> > > +   unsigned int supported_rotations)
> > >  {
> > > - static const struct drm_prop_enum_list props[] = {
> > > + struct drm_property *prop;
> > > + static const struct drm_prop_enum_list values[] = {
> > >   { DRM_ROTATE_0,   "rotate-0" },
> > >   { DRM_ROTATE_90,  "rotate-90" },
> > >   { DRM_ROTATE_180, "rotate-180" },
> > > @@ -5887,9 +5900,13 @@ struct drm_property 
> > > *drm_mode_create_rotation_property(struct drm_device *dev,
> > >   { DRM_REFLECT_Y,  "reflect-y" },
> > >   };
> > >  
> > > - return drm_property_create_bitmask(dev, 0, "rotation",
> > > -props, ARRAY_SIZE(props),
> > > -supported_rotations);
> > > + prop = drm_property_create_bitmask(dev, 0, "rotation", values,
> > > +  

[Intel-gfx] [PATCH v5 2/7] drm: add parameter-order checking to drm memory allocators

[Tvrtko Ursulin]

On 29/02/16 11:13, Dave Gordon wrote:
> After the recent addition of drm_malloc_gfp(), it was noticed that
> some callers of these functions has swapped the parameters in the
> call - it's supposed to be 'number of members' and 'sizeof(element)',
> but a few callers had got the size first and the count second. This
> isn't otherwise detected because they're both type 'size_t', and
> the implementation at present just multiplies them anyway, so the
> result is still right. But some future implementation might treat
> them differently (e.g. allowing 0 elements but not zero size), so
> let's add some compile-time checks and complain if the second (size)
> parameter isn't a sizeof() expression, or at least a compile-time
> constant.
>
> This patch also fixes those callers where the order was wrong.
>
> Signed-off-by: Dave Gordon 
> Cc: Chris Wilson 
> Cc: Ville Syrjälä Cc: dri-
> Cc: dri-devel at lists.freedesktop.org
> ---
>   drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  8 
>   include/drm/drm_mem_util.h   | 30 
> +---
>   3 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 1aba01a..9ae4a71 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -340,7 +340,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>*/
>   bos = drm_malloc_ab(args->nr_bos, sizeof(*bos));
>   relocs = drm_malloc_ab(args->nr_relocs, sizeof(*relocs));
> - stream = drm_malloc_ab(1, args->stream_size);
> + stream = drm_malloc_ab(args->stream_size, sizeof(*stream));

I was surprised sizeof(void) == 1. On further research that seems to be 
an GCC extension.

I am not sure how active projects to compile the kernel with for example 
ICC are, just remember some talks about it in the past. Maybe it is even 
possible? In that case it would be better to just leave "1" there to not 
rely on GCC extensions.

And this use of array allocator in Etnaviv is strange since they are 
allocating an unstructured buffer, but whatever, it existing and 
external code. (I am not even sure would I bother touching it, since, is 
the logical view to allocate *one* _buffer_ of a specified size, or 
specified size of bytes make a buffer? :) )

>   cmdbuf = etnaviv_gpu_cmdbuf_new(gpu, ALIGN(args->stream_size, 8) + 8,
>   args->nr_bos);
>   if (!bos || !relocs || !stream || !cmdbuf) {
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 18a5dcc..865876d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1687,8 +1687,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
>   }
>
>   /* Copy in the exec list from userland */
> - exec_list = drm_malloc_ab(sizeof(*exec_list), args->buffer_count);
> - exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count);
> + exec_list = drm_malloc_ab(args->buffer_count, sizeof(*exec_list));
> + exec2_list = drm_malloc_ab(args->buffer_count, sizeof(*exec2_list));
>   if (exec_list == NULL || exec2_list == NULL) {
>   DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
> args->buffer_count);
> @@ -1776,8 +1776,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
>   return -EINVAL;
>   }
>
> - exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
> - args->buffer_count,
> + exec2_list = drm_malloc_gfp(args->buffer_count,
> + sizeof(*exec2_list),
>   GFP_TEMPORARY);
>   if (exec2_list == NULL) {
>   DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
> diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
> index 741ce75..886ff0a 100644
> --- a/include/drm/drm_mem_util.h
> +++ b/include/drm/drm_mem_util.h
> @@ -29,7 +29,7 @@
>
>   #include 
>
> -static __inline__ void *drm_calloc_large(size_t nmemb, size_t size)
> +static __inline__ void *__drm_calloc_large(size_t nmemb, const size_t size)
>   {
>   if (size != 0 && nmemb > SIZE_MAX / size)
>   return NULL;
> @@ -41,8 +41,15 @@ static __inline__ void *drm_calloc_large(size_t nmemb, 
> size_t size)
>GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO, PAGE_KERNEL);
>   }
>
> +#define  drm_calloc_large(nmemb, size)   
> \
> +({   \
> + BUILD_BUG_ON_MSG(!__builtin_constant_p(size),   \
> + "Non-constant 'size' - check argument ordering?");  \
> + __drm_calloc_large(nmemb, size);

[REGRESSION] i915: No HDMI output with 4.4

[Daniel Vetter]

On Wed, Feb 24, 2016 at 06:07:25AM +, Sharma, Shashank wrote:
> Hi Ville, 
> We will look into this in sometime. Right now team is slightly loaded due to 
> project milestone. 
> Last time I looked into this, we dint have this HW to reproduce this issue.

This is an upstream regression. Either you can handle it, or your code
must be reverted again. Please either assign someone for this, or send in
the patch to revert.

I'll discuss this with Indranil, too.

Thanks, Daniel
> 
> Regards
> Shashank
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] 
> Sent: Tuesday, February 23, 2016 8:38 PM
> To: Oleksandr Natalenko
> Cc: Vetter, Daniel; intel-gfx at lists.freedesktop.org; dri-devel at 
> lists.freedesktop.org; linux-kernel at vger.kernel.org; Daniel Vetter; 
> Jindal, Sonika; Sharma, Shashank; Wang, Gary C
> Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> 
> On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
> > Ville, Daniel,
> > 
> > any additional info I could provide? I have to return dual-link DVI 
> > cable back, so let me know if I could reveal more details if necessary.
> 
> Unfortunately I'm out of ideas for now. Daniel is on vacation.
> Anyone else? VPG folks should take the ball here since they broke it.
> 
> In the meantime I think as a workaround I think you could use something like 
> video=HDMI-A-1:e on the kernel command line (not sure I got the connector 
> name right for your system). I think that should result in the live status 
> check to be skipped, at least when populating the mode list.
> 
> Might be a good idea to collect all the information here and put in a bug 
> report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the 
> logs and such would be in one place.
> 
> > 
> > Regards,
> >Oleksandr
> > 
> > 16.02.2016 14:54, Daniel Vetter написав:
> > > On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
> > >> Ville, Daniel,
> > >> 
> > >> I've just got another monitor and another DVI-HDMI cable, and here 
> > >> what I've got.
> > >> 
> > >> ===Single Link DVI-D cable with 3 different monitors===
> > >> 
> > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 
> > >> 23MP65HQ-P === not working
> > > 
> > > I presume the above LG screen is what you've called previously "old 
> > > monitor"?
> > > 
> > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 
> > >> 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single 
> > >> Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
> > >> 
> > >> ===Dual Link DVI-D cable with monitor that doesn't work with Single 
> > >> Link cable===
> > >> 
> > >> Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 
> > >> 23MP65HQ-P === works!
> > > 
> > > Funky. Can you pls grab the debug logs (with the special patches 
> > > from
> > > Ville) for this case? I wonder why suddenly different cable and it 
> > > works.
> > > 
> > > Also: Is this one of these older-ish screens where you must have a 
> > > dual-link cable to drive it at full resolution rate?
> > > -Daniel
> > > 
> > > 
> > >> ===Laptop with HDMI output===
> > >> 
> > >> Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === 
> > >> works!
> > >> 
> > >> I'd say that single link DVI cables are broken with new kernel, but 
> > >> one of monitors could work with such a cable. So I have no idea :(.
> > >> 
> > >> Regards,
> > >>   Oleksandr.
> > >> 
> > >> 15.02.2016 17:42, Daniel Vetter wrote:
> > >> >The other downside is that it'll make us non-compliant, which was 
> > >> >the point of this entire ordeal: HDMI spec forbids us from 
> > >> >starting any i2c transactions when the hpd isn't signalling a present 
> > >> >screen.
> > >> >
> > >> >So maybe we need to buy one of these broken screens.
> > >> >
> > >> >Oleksandr, what exact model are you using? And any chance that you 
> > >> >could test this on some other machine with intel gfx and latest 
> > >> >kernel, just to make sure this really is some issue with the sink 
> > >> >and not with the machine itself? And I guess you've tested with 
> > >> >some other hdmi sink, and that works?
> 
> --
> Ville Syrjälä
> Intel OTC

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

[PATCH v5 3/5] drm: simplify initialization of rotation property

[Daniel Vetter]

On Mon, Feb 29, 2016 at 04:06:40PM +0100, Daniel Vetter wrote:
> On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> > This patch simplifies initialization of generic rotation property and
> > aligns the code to match recently introduced function for intializing
> > generic zpos property. It also adds missing documentation.
> > 
> > Signed-off-by: Marek Szyprowski 
> 
> I merged patches 3-5 to drm-misc, thanks. For the blending mode I'd like
> to gather a few more acks from people who have been proposing ideas in the
> past (would speed up if you cc them next time around).

Blergh, I meant patches 1-3 are merged ofc ;-)
> 
> Thanks, Daniel
> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 -
> >  drivers/gpu/drm/drm_crtc.c  | 29 
> > -
> >  drivers/gpu/drm/i915/intel_display.c|  6 ++---
> >  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  3 +--
> >  drivers/gpu/drm/omapdrm/omap_drv.c  |  3 +--
> >  include/drm/drm_crtc.h  |  4 ++--
> >  6 files changed, 33 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > index 1ffe9c329c46..4f9606cdf0f2 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > @@ -967,12 +967,10 @@ atmel_hlcdc_plane_create_properties(struct drm_device 
> > *dev)
> > if (!props->alpha)
> > return ERR_PTR(-ENOMEM);
> >  
> > -   dev->mode_config.rotation_property =
> > -   drm_mode_create_rotation_property(dev,
> > - BIT(DRM_ROTATE_0) |
> > - BIT(DRM_ROTATE_90) |
> > - BIT(DRM_ROTATE_180) |
> > - BIT(DRM_ROTATE_270));
> > +   drm_mode_create_rotation_property(dev, BIT(DRM_ROTATE_0) |
> > +  BIT(DRM_ROTATE_90) |
> > +  BIT(DRM_ROTATE_180) |
> > +  BIT(DRM_ROTATE_270));
> > if (!dev->mode_config.rotation_property)
> > return ERR_PTR(-ENOMEM);
> >  
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d40bab29747e..822ad6928144 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -5875,10 +5875,23 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> >  }
> >  EXPORT_SYMBOL(drm_mode_config_cleanup);
> >  
> > -struct drm_property *drm_mode_create_rotation_property(struct drm_device 
> > *dev,
> > -  unsigned int 
> > supported_rotations)
> > +/**
> > + * drm_mode_create_rotation_property - create generic rotation property
> > + * @dev: DRM device
> > + * @supported_rotations: bitmask of supported rotation modes
> > + *
> > + * This function initializes generic rotation property and enables support
> > + * for it in drm core. Drivers can then attach this property to planes to 
> > enable
> > + * support for different rotation modes.
> > + *
> > + * Returns:
> > + * Zero on success, negative errno on failure.
> > + */
> > +int drm_mode_create_rotation_property(struct drm_device *dev,
> > + unsigned int supported_rotations)
> >  {
> > -   static const struct drm_prop_enum_list props[] = {
> > +   struct drm_property *prop;
> > +   static const struct drm_prop_enum_list values[] = {
> > { DRM_ROTATE_0,   "rotate-0" },
> > { DRM_ROTATE_90,  "rotate-90" },
> > { DRM_ROTATE_180, "rotate-180" },
> > @@ -5887,9 +5900,13 @@ struct drm_property 
> > *drm_mode_create_rotation_property(struct drm_device *dev,
> > { DRM_REFLECT_Y,  "reflect-y" },
> > };
> >  
> > -   return drm_property_create_bitmask(dev, 0, "rotation",
> > -  props, ARRAY_SIZE(props),
> > -  supported_rotations);
> > +   prop = drm_property_create_bitmask(dev, 0, "rotation", values,
> > +   ARRAY_SIZE(values), supported_rotations);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +
> > +   dev->mode_config.rotation_property = prop;
> > +   return 0;
> >  }
> >  EXPORT_SYMBOL(drm_mode_create_rotation_property);
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 2f00828ccc6e..1bce8750c308 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14046,8 +14046,7 @@ void intel_create_rotation_property(struct 
> > drm_device *dev, struct intel_plane *
> > if (INTEL_INFO(dev)->gen >= 9)
> > flags |= BIT(DRM_ROTATE_90) | 

[PATCH v5 3/5] drm: simplify initialization of rotation property

[Daniel Vetter]

On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> This patch simplifies initialization of generic rotation property and
> aligns the code to match recently introduced function for intializing
> generic zpos property. It also adds missing documentation.
> 
> Signed-off-by: Marek Szyprowski 

I merged patches 3-5 to drm-misc, thanks. For the blending mode I'd like
to gather a few more acks from people who have been proposing ideas in the
past (would speed up if you cc them next time around).

Thanks, Daniel
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 -
>  drivers/gpu/drm/drm_crtc.c  | 29 
> -
>  drivers/gpu/drm/i915/intel_display.c|  6 ++---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  3 +--
>  drivers/gpu/drm/omapdrm/omap_drv.c  |  3 +--
>  include/drm/drm_crtc.h  |  4 ++--
>  6 files changed, 33 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 1ffe9c329c46..4f9606cdf0f2 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -967,12 +967,10 @@ atmel_hlcdc_plane_create_properties(struct drm_device 
> *dev)
>   if (!props->alpha)
>   return ERR_PTR(-ENOMEM);
>  
> - dev->mode_config.rotation_property =
> - drm_mode_create_rotation_property(dev,
> -   BIT(DRM_ROTATE_0) |
> -   BIT(DRM_ROTATE_90) |
> -   BIT(DRM_ROTATE_180) |
> -   BIT(DRM_ROTATE_270));
> + drm_mode_create_rotation_property(dev, BIT(DRM_ROTATE_0) |
> +BIT(DRM_ROTATE_90) |
> +BIT(DRM_ROTATE_180) |
> +BIT(DRM_ROTATE_270));
>   if (!dev->mode_config.rotation_property)
>   return ERR_PTR(-ENOMEM);
>  
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d40bab29747e..822ad6928144 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5875,10 +5875,23 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>  
> -struct drm_property *drm_mode_create_rotation_property(struct drm_device 
> *dev,
> -unsigned int 
> supported_rotations)
> +/**
> + * drm_mode_create_rotation_property - create generic rotation property
> + * @dev: DRM device
> + * @supported_rotations: bitmask of supported rotation modes
> + *
> + * This function initializes generic rotation property and enables support
> + * for it in drm core. Drivers can then attach this property to planes to 
> enable
> + * support for different rotation modes.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_create_rotation_property(struct drm_device *dev,
> +   unsigned int supported_rotations)
>  {
> - static const struct drm_prop_enum_list props[] = {
> + struct drm_property *prop;
> + static const struct drm_prop_enum_list values[] = {
>   { DRM_ROTATE_0,   "rotate-0" },
>   { DRM_ROTATE_90,  "rotate-90" },
>   { DRM_ROTATE_180, "rotate-180" },
> @@ -5887,9 +5900,13 @@ struct drm_property 
> *drm_mode_create_rotation_property(struct drm_device *dev,
>   { DRM_REFLECT_Y,  "reflect-y" },
>   };
>  
> - return drm_property_create_bitmask(dev, 0, "rotation",
> -props, ARRAY_SIZE(props),
> -supported_rotations);
> + prop = drm_property_create_bitmask(dev, 0, "rotation", values,
> + ARRAY_SIZE(values), supported_rotations);
> + if (!prop)
> + return -ENOMEM;
> +
> + dev->mode_config.rotation_property = prop;
> + return 0;
>  }
>  EXPORT_SYMBOL(drm_mode_create_rotation_property);
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2f00828ccc6e..1bce8750c308 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14046,8 +14046,7 @@ void intel_create_rotation_property(struct drm_device 
> *dev, struct intel_plane *
>   if (INTEL_INFO(dev)->gen >= 9)
>   flags |= BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270);
>  
> - dev->mode_config.rotation_property =
> - drm_mode_create_rotation_property(dev, flags);
> + drm_mode_create_rotation_property(dev, flags);
>   }
>   if 

[PATCH v9] dma-buf: Add ioctls to allow userspace to flush

[Daniel Vetter]

On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
> On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> > +static long dma_buf_ioctl(struct file *file,
> > + unsigned int cmd, unsigned long arg)
> > +{
> > +   struct dma_buf *dmabuf;
> > +   struct dma_buf_sync sync;
> > +   enum dma_data_direction direction;
> > +
> > +   dmabuf = file->private_data;
> > +
> > +   switch (cmd) {
> > +   case DMA_BUF_IOCTL_SYNC:
> > +   if (copy_from_user(, (void __user *) arg, sizeof(sync)))
> > +   return -EFAULT;
> > +
> > +   if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> > +   return -EINVAL;
> > +
> > +   switch (sync.flags & DMA_BUF_SYNC_RW) {
> > +   case DMA_BUF_SYNC_READ:
> > +   direction = DMA_FROM_DEVICE;
> > +   break;
> > +   case DMA_BUF_SYNC_WRITE:
> > +   direction = DMA_TO_DEVICE;
> > +   break;
> > +   case DMA_BUF_SYNC_RW:
> > +   direction = DMA_BIDIRECTIONAL;
> > +   break;
> > +   default:
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (sync.flags & DMA_BUF_SYNC_END)
> > +   dma_buf_end_cpu_access(dmabuf, direction);
> > +   else
> > +   dma_buf_begin_cpu_access(dmabuf, direction);
> 
> We forgot to report the error back to userspace. Might as well fixup the
> callchain to propagate error from end-cpu-access as well. Found after
> updating igt/gem_concurrent_blit to exercise dmabuf mmaps vs the GPU.

EINTR? Do we need to make this ABI - I guess so? Tiago, do you have
patches? See drmIoctl() in libdrm for what's needed on the userspace side
if my guess is right.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 11/12] drm/dp: Read AUX read interval from DPCD

[Daniel Vetter]

On Mon, Feb 29, 2016 at 07:38:21AM +0100, Thierry Reding wrote:
> On Tue, Dec 15, 2015 at 11:38:10AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 01:56:03PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > Store the AUX read interval from DPCD, so that it can be used to wait
> > > for the durations given in the specification during link training.
> > > 
> > > Signed-off-by: Thierry Reding 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c |  4 
> > >  include/drm/drm_dp_helper.h | 17 +
> > >  2 files changed, 21 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 76ac68bc1042..da519acfeba7 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -339,6 +339,7 @@ static void drm_dp_link_reset(struct drm_dp_link 
> > > *link)
> > >   link->max_lanes = 0;
> > >  
> > >   drm_dp_link_caps_reset(>caps);
> > > + link->aux_rd_interval = 0;
> > >   link->edp = 0;
> > >  
> > >   link->rate = 0;
> > > @@ -392,6 +393,9 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
> > > drm_dp_link *link)
> > >   link->edp = edp_revs[value];
> > >   }
> > >  
> > > + /* DP_TRAINING_AUX_RD_INTERVAL is in units of 4 milliseconds */
> > > + link->aux_rd_interval = drm_dp_aux_rd_interval(values);
> > 
> > Hm, just wondering a bit of the relationship between link and cap. Is link
> > all about sink really, and not the source? At least in my experience it
> > makes a lot of sense to strictly keep these two separate, since otherwise
> > you'll have lots of fun aligning things in generic code. Anyway, just a
> > thougth.
> 
> The idea is that the link is the intersection between sink and source
> capabilities. Drivers are supposed to call drm_dp_link_probe() to obtain
> the capabilities of the sink and then adjust the struct drm_dp_link
> according to their limitations (e.g. decrease the maximum rate if they
> don't support 5.4 GHz, reduce the number of lanes if they only support
> two, ...).
> 
> Once that's done the drivers can call drm_dp_link_choose() to select the
> "best" set of configuration parameters given the link capabilities.
> 
> Note that this is strictly deriven from reading the specification under
> the assumption that this is how things work in real life. My, arguably
> limited, experience with Tegra shows that this is true. But perhaps that
> is overly naive.
> 
> But I'd like to better understand what other drivers require so that
> these helpers can be improved and be useful by more than a single
> driver. Currently every driver implements their own DP stack, which I
> think is rather unfortunate because we end up with vastly different
> behaviour depending on which driver is in use.
> 
> Of course if that's what's desired, I'm more than happy to move this
> code into the Tegra driver. I might have to duplicate the code that's
> shared with MSM, but it's really not a lot compared to what's coming
> up.

Ah, that makes sense to have a link structure for the negotioted values
that fit both sink and source. In that case I think making it a bit leaner
would be good, and only include parameters which actually need to be
negiotated (link rate, lanes, ...). aux retry intervals and stuff like
that should be agnostic, or at least only depend upon the sink (I hope).

Given that I don't think we should store such values, but instead
recompute them from the read/cached dcpd blocks. That would be more
in-line with the style of the helpers used by i915/radeon. This way the
actually negotiated stuff sticks out more. And like you say we need that
in some struct so that drivers can apply quirks/tricks (i.e. simply to
avoid the midlayer mistake). E.g. one thing i915 does is up-front link
training, to be able to handle usb type C correctly.

Another reason why I think we should charge ahead with caching source/sink
invariant values too much is that I still believe extracting SST helpers
from MST helpers is a good long-term plan. Keeping is simple (and
accepting more copypasting due to that) will make the inevitable
refactoring easier I hope.

Cheers, Daniel

> > > +
> > >   link->rate = link->max_rate;
> > >   link->lanes = link->max_lanes;
> > >  
> > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > > index 825aaf4e8c71..20ae0e413b64 100644
> > > --- a/include/drm/drm_dp_helper.h
> > > +++ b/include/drm/drm_dp_helper.h
> > > @@ -678,6 +678,22 @@ drm_dp_alternate_scrambler_reset_cap(const u8 
> > > dpcd[DP_RECEIVER_CAP_SIZE])
> > >   DP_ALTERNATE_SCRAMBLER_RESET_CAP;
> > >  }
> > >  
> > > +/**
> > > + * drm_dp_read_aux_interval() - read the AUX read interval from the DPCD
> > > + * @dpcd: receiver capacity buffer
> > > + *
> > > + * Reads the AUX read interval (in microseconds) from the DPCD. Note 
> > > that the
> > > + * TRAINING_AUX_RD_INTERVAL stores the value in units of 4 milliseconds.
> > 

[REGRESSION] i915: No HDMI output with 4.4

[Sharma, Shashank]

No problems, I guessed the mail situation :)

Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, February 29, 2016 9:12 PM
To: Sharma, Shashank
Cc: Daniel Vetter; Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; 
intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
linux-kernel at vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C
Subject: Re: [REGRESSION] i915: No HDMI output with 4.4

On Mon, Feb 29, 2016 at 03:16:08PM +, Sharma, Shashank wrote:
> Please see the latest mail chain, Sonika has already started on it.

Ah ok, crawling through 1k mails after one week of vacation, so I'm still 
catching up ;-) My apologies for the confusion.

Thanks, Daniel
> 
> Regards
> Shashank
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of 
> Daniel Vetter
> Sent: Monday, February 29, 2016 8:44 PM
> To: Sharma, Shashank
> Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; 
> intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
> linux-kernel at vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, 
> Gary C
> Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> 
> On Wed, Feb 24, 2016 at 06:07:25AM +, Sharma, Shashank wrote:
> > Hi Ville,
> > We will look into this in sometime. Right now team is slightly loaded due 
> > to project milestone. 
> > Last time I looked into this, we dint have this HW to reproduce this issue.
> 
> This is an upstream regression. Either you can handle it, or your code must 
> be reverted again. Please either assign someone for this, or send in the 
> patch to revert.
> 
> I'll discuss this with Indranil, too.
> 
> Thanks, Daniel
> > 
> > Regards
> > Shashank
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > Sent: Tuesday, February 23, 2016 8:38 PM
> > To: Oleksandr Natalenko
> > Cc: Vetter, Daniel; intel-gfx at lists.freedesktop.org; 
> > dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; 
> > Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C
> > Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> > 
> > On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
> > > Ville, Daniel,
> > > 
> > > any additional info I could provide? I have to return dual-link 
> > > DVI cable back, so let me know if I could reveal more details if 
> > > necessary.
> > 
> > Unfortunately I'm out of ideas for now. Daniel is on vacation.
> > Anyone else? VPG folks should take the ball here since they broke it.
> > 
> > In the meantime I think as a workaround I think you could use something 
> > like video=HDMI-A-1:e on the kernel command line (not sure I got the 
> > connector name right for your system). I think that should result in the 
> > live status check to be skipped, at least when populating the mode list.
> > 
> > Might be a good idea to collect all the information here and put in a bug 
> > report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the 
> > logs and such would be in one place.
> > 
> > > 
> > > Regards,
> > >Oleksandr
> > > 
> > > 16.02.2016 14:54, Daniel Vetter написав:
> > > > On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
> > > >> Ville, Daniel,
> > > >> 
> > > >> I've just got another monitor and another DVI-HDMI cable, and 
> > > >> here what I've got.
> > > >> 
> > > >> ===Single Link DVI-D cable with 3 different monitors===
> > > >> 
> > > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI 
> > > >> LG 
> > > >> 23MP65HQ-P === not working
> > > > 
> > > > I presume the above LG screen is what you've called previously 
> > > > "old monitor"?
> > > > 
> > > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI 
> > > >> LG 
> > > >> 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single 
> > > >> Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
> > > >> 
> > > >> ===Dual Link DVI-D cable with monitor that doesn't work with 
> > > >> Single Link cable===
> > > >> 
> > > >> Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 
> > > >> 23MP65HQ-P === works!
> > > > 
> > > > Funky. Can you pls grab the debug logs (with the special patches 
> > > > from
> > > > Ville) for this case? I wonder why suddenly different cable and 
> > > > it works.
> > > > 
> > > > Also: Is this one of these older-ish screens where you must have 
> > > > a dual-link cable to drive it at full resolution rate?
> > > > -Daniel
> > > > 
> > > > 
> > > >> ===Laptop with HDMI output===
> > > >> 
> > > >> Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === 
> > > >> works!
> > > >> 
> > > >> I'd say that single link DVI cables are broken with new kernel, 
> > > >> but one of monitors could work with such a cable. So I have no idea :(.
> > > >> 
> > > >> Regards,
> > > >>   

[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

[Martin Kepplinger]

Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
> Sorry, Cc to Jani was missing mistakenly.
> 
> Please check this.  It's a regression in 4.5-rc.
> 
> 
> thanks,
> 
> Takashi
> 

I can confirm that with -rc6 nothing changed and this fixes audio over
HDMI for me. I added David Airlie and dri-devel to CC aswell and hope
that this can go in for 4.5 in the last minute.

thanks
martin


> On Wed, 24 Feb 2016 15:35:22 +0100,
> Takashi Iwai wrote:
>>
>> The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between
>> port and intel_encoder] introduced a reverse mapping to retrieve
>> intel_dig_port object from the port number.  The code assumed that the
>> port vs intel_dig_port are 1:1 mapping.  But in reality, this was a
>> too naive assumption.
>>
>> As Martin reported about the missing HDMI audio on his SNB machine,
>> pre-HSW chips may have multiple intel_dig_port objects corresponding
>> to the same port.  Since we assign the mapping statically at the init
>> time and the multiple objects override the map, it may not match with
>> the actually enabled output.
>>
>> This patch tries to address the regression above.  The reverse mapping
>> is provided basically only for the audio callbacks, so now we set /
>> clear the mapping dynamically at enabling and disabling HDMI/DP audio,
>> so that we can always track the latest and correct object
>> corresponding to the given port.
>>
>> Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and 
>> intel_encoder')
>> Reported-and-tested-by: Martin Kepplinger 
>> Signed-off-by: Takashi Iwai 
>> ---
>>  drivers/gpu/drm/i915/intel_audio.c | 3 +++
>>  drivers/gpu/drm/i915/intel_ddi.c   | 1 -
>>  drivers/gpu/drm/i915/intel_dp.c| 1 -
>>  drivers/gpu/drm/i915/intel_hdmi.c  | 2 --
>>  4 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>> b/drivers/gpu/drm/i915/intel_audio.c
>> index 31f6d212fb1b..30f921421b0c 100644
>> --- a/drivers/gpu/drm/i915/intel_audio.c
>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>> @@ -527,6 +527,8 @@ void intel_audio_codec_enable(struct intel_encoder 
>> *intel_encoder)
>>  
>>  mutex_lock(_priv->av_mutex);
>>  intel_dig_port->audio_connector = connector;
>> +/* referred in audio callbacks */
>> +dev_priv->dig_port_map[port] = intel_encoder;
>>  mutex_unlock(_priv->av_mutex);
>>  
>>  if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
>> @@ -554,6 +556,7 @@ void intel_audio_codec_disable(struct intel_encoder 
>> *intel_encoder)
>>  
>>  mutex_lock(_priv->av_mutex);
>>  intel_dig_port->audio_connector = NULL;
>> +dev_priv->dig_port_map[port] = NULL;
>>  mutex_unlock(_priv->av_mutex);
>>  
>>  if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 54a165b9c92d..a50fc452d5f1 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3312,7 +3312,6 @@ void intel_ddi_init(struct drm_device *dev, enum port 
>> port)
>>  intel_encoder->get_config = intel_ddi_get_config;
>>  
>>  intel_dig_port->port = port;
>> -dev_priv->dig_port_map[port] = intel_encoder;
>>  intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>>(DDI_BUF_PORT_REVERSAL |
>> DDI_A_4_LANES);
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 1bbd67b046da..acf918728492 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -6035,7 +6035,6 @@ intel_dp_init(struct drm_device *dev,
>>  }
>>  
>>  intel_dig_port->port = port;
>> -dev_priv->dig_port_map[port] = intel_encoder;
>>  intel_dig_port->dp.output_reg = output_reg;
>>  
>>  intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 4a77639a489d..23ee48dc765f 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -2146,7 +2146,6 @@ void intel_hdmi_init_connector(struct 
>> intel_digital_port *intel_dig_port,
>>  void intel_hdmi_init(struct drm_device *dev,
>>   i915_reg_t hdmi_reg, enum port port)
>>  {
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>>  struct intel_digital_port *intel_dig_port;
>>  struct intel_encoder *intel_encoder;
>>  struct intel_connector *intel_connector;
>> @@ -2215,7 +2214,6 @@ void intel_hdmi_init(struct drm_device *dev,
>>  intel_encoder->cloneable |= 1 << INTEL_OUTPUT_HDMI;
>>  
>>  intel_dig_port->port = port;
>> -dev_priv->dig_port_map[port] = intel_encoder;
>>  intel_dig_port->hdmi.hdmi_reg = hdmi_reg;
>>  intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
>>  
>> -- 
>> 2.7.2
>>
>> 

[REGRESSION] i915: No HDMI output with 4.4

[Sharma, Shashank]

Please see the latest mail chain, Sonika has already started on it.

Regards
Shashank

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, February 29, 2016 8:44 PM
To: Sharma, Shashank
Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx at 
lists.freedesktop.org; dri-devel at lists.freedesktop.org; linux-kernel at 
vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C
Subject: Re: [REGRESSION] i915: No HDMI output with 4.4

On Wed, Feb 24, 2016 at 06:07:25AM +, Sharma, Shashank wrote:
> Hi Ville,
> We will look into this in sometime. Right now team is slightly loaded due to 
> project milestone. 
> Last time I looked into this, we dint have this HW to reproduce this issue.

This is an upstream regression. Either you can handle it, or your code must be 
reverted again. Please either assign someone for this, or send in the patch to 
revert.

I'll discuss this with Indranil, too.

Thanks, Daniel
> 
> Regards
> Shashank
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Tuesday, February 23, 2016 8:38 PM
> To: Oleksandr Natalenko
> Cc: Vetter, Daniel; intel-gfx at lists.freedesktop.org; 
> dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; Daniel 
> Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C
> Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
> 
> On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
> > Ville, Daniel,
> > 
> > any additional info I could provide? I have to return dual-link DVI 
> > cable back, so let me know if I could reveal more details if necessary.
> 
> Unfortunately I'm out of ideas for now. Daniel is on vacation.
> Anyone else? VPG folks should take the ball here since they broke it.
> 
> In the meantime I think as a workaround I think you could use something like 
> video=HDMI-A-1:e on the kernel command line (not sure I got the connector 
> name right for your system). I think that should result in the live status 
> check to be skipped, at least when populating the mode list.
> 
> Might be a good idea to collect all the information here and put in a bug 
> report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the 
> logs and such would be in one place.
> 
> > 
> > Regards,
> >Oleksandr
> > 
> > 16.02.2016 14:54, Daniel Vetter написав:
> > > On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
> > >> Ville, Daniel,
> > >> 
> > >> I've just got another monitor and another DVI-HDMI cable, and 
> > >> here what I've got.
> > >> 
> > >> ===Single Link DVI-D cable with 3 different monitors===
> > >> 
> > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 
> > >> 23MP65HQ-P === not working
> > > 
> > > I presume the above LG screen is what you've called previously 
> > > "old monitor"?
> > > 
> > >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 
> > >> 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single 
> > >> Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
> > >> 
> > >> ===Dual Link DVI-D cable with monitor that doesn't work with 
> > >> Single Link cable===
> > >> 
> > >> Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 
> > >> 23MP65HQ-P === works!
> > > 
> > > Funky. Can you pls grab the debug logs (with the special patches 
> > > from
> > > Ville) for this case? I wonder why suddenly different cable and it 
> > > works.
> > > 
> > > Also: Is this one of these older-ish screens where you must have a 
> > > dual-link cable to drive it at full resolution rate?
> > > -Daniel
> > > 
> > > 
> > >> ===Laptop with HDMI output===
> > >> 
> > >> Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === 
> > >> works!
> > >> 
> > >> I'd say that single link DVI cables are broken with new kernel, 
> > >> but one of monitors could work with such a cable. So I have no idea :(.
> > >> 
> > >> Regards,
> > >>   Oleksandr.
> > >> 
> > >> 15.02.2016 17:42, Daniel Vetter wrote:
> > >> >The other downside is that it'll make us non-compliant, which 
> > >> >was the point of this entire ordeal: HDMI spec forbids us from 
> > >> >starting any i2c transactions when the hpd isn't signalling a present 
> > >> >screen.
> > >> >
> > >> >So maybe we need to buy one of these broken screens.
> > >> >
> > >> >Oleksandr, what exact model are you using? And any chance that 
> > >> >you could test this on some other machine with intel gfx and 
> > >> >latest kernel, just to make sure this really is some issue with 
> > >> >the sink and not with the machine itself? And I guess you've 
> > >> >tested with some other hdmi sink, and that works?
> 
> --
> Ville Syrjälä
> Intel OTC

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

[PATCH v9] dma-buf: Add ioctls to allow userspace to flush

[Chris Wilson]

On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
> On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
> > On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> > > +static long dma_buf_ioctl(struct file *file,
> > > +   unsigned int cmd, unsigned long arg)
> > > +{
> > > + struct dma_buf *dmabuf;
> > > + struct dma_buf_sync sync;
> > > + enum dma_data_direction direction;
> > > +
> > > + dmabuf = file->private_data;
> > > +
> > > + switch (cmd) {
> > > + case DMA_BUF_IOCTL_SYNC:
> > > + if (copy_from_user(, (void __user *) arg, sizeof(sync)))
> > > + return -EFAULT;
> > > +
> > > + if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> > > + return -EINVAL;
> > > +
> > > + switch (sync.flags & DMA_BUF_SYNC_RW) {
> > > + case DMA_BUF_SYNC_READ:
> > > + direction = DMA_FROM_DEVICE;
> > > + break;
> > > + case DMA_BUF_SYNC_WRITE:
> > > + direction = DMA_TO_DEVICE;
> > > + break;
> > > + case DMA_BUF_SYNC_RW:
> > > + direction = DMA_BIDIRECTIONAL;
> > > + break;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (sync.flags & DMA_BUF_SYNC_END)
> > > + dma_buf_end_cpu_access(dmabuf, direction);
> > > + else
> > > + dma_buf_begin_cpu_access(dmabuf, direction);
> > 
> > We forgot to report the error back to userspace. Might as well fixup the
> > callchain to propagate error from end-cpu-access as well. Found after
> > updating igt/gem_concurrent_blit to exercise dmabuf mmaps vs the GPU.
> 
> EINTR? Do we need to make this ABI - I guess so? Tiago, do you have
> patches? See drmIoctl() in libdrm for what's needed on the userspace side
> if my guess is right.

EINTR is the easiest, but conceivably we could also get EIO and
currently EAGAIN.

I am also seeing some strange timing dependent (i.e. valgrind doesn't
show up anything client side and the tests then pass) failures (SIGSEGV,
SIGBUS) with !llc.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 17/18] drm/radeon: make radeon_mn_get wait for mmap_sem killable

[Christian König]

[Dropping CCing the individual people, but adding the dri-devel mailing 
list as well instead].

Am 29.02.2016 um 14:26 schrieb Michal Hocko:
> From: Michal Hocko 
>
> radeon_mn_get which is called during ioct path relies on mmap_sem for
> write. If the waiting task gets killed by the oom killer it would block
> oom_reaper from asynchronous address space reclaim and reduce the
> chances of timely OOM resolving. Wait for the lock in the killable mode
> and return with EINTR if the task got killed while waiting.
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Signed-off-by: Michal Hocko 

This one and patch #18 in this series are Reviewed-by: Christian König 
.

Nice to see some improvements on this side,
Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_mn.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
> b/drivers/gpu/drm/radeon/radeon_mn.c
> index eef006c48584..896f2cf51e4e 100644
> --- a/drivers/gpu/drm/radeon/radeon_mn.c
> +++ b/drivers/gpu/drm/radeon/radeon_mn.c
> @@ -186,7 +186,9 @@ static struct radeon_mn *radeon_mn_get(struct 
> radeon_device *rdev)
>   struct radeon_mn *rmn;
>   int r;
>   
> - down_write(>mmap_sem);
> + if (down_write_killable(>mmap_sem))
> + return ERR_PTR(-EINTR);
> +
>   mutex_lock(>mn_lock);
>   
>   hash_for_each_possible(rdev->mn_hash, rmn, node, (unsigned long)mm)

[PATCH 1/2] drm: Add few more wrapper functions for drm panel

[Jani Nikula]

Cc: Thierry the drm panel maintainer.

On Mon, 29 Feb 2016, Deepak M  wrote:
> Currently there are few pair of functions which
> are called during the panel enable/disable sequence.
> To improve the granularity, adding few more wrapper
> functions so that the functions are more specific
> on what they are doing.
>
> Cc: David Airlie 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Signed-off-by: Deepak M 
> Signed-off-by: Gaurav K Singh 
> ---
>  include/drm/drm_panel.h | 47 +++
>  1 file changed, 47 insertions(+)
>
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 13ff44b..c729f6d 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -73,6 +73,12 @@ struct drm_panel_funcs {
>   int (*get_modes)(struct drm_panel *panel);
>   int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
>  struct display_timing *timings);
> + int (*power_on)(struct drm_panel *panel);
> + int (*power_off)(struct drm_panel *panel);
> + int (*backlight_on)(struct drm_panel *panel);
> + int (*backlight_off)(struct drm_panel *panel);

Please read the kernel-doc comment above the struct, and justify the
need to add new ones. Please update the kernel-doc comment to reflect
the changes.

For example, the documentation for .prepare() says, "drivers can use
this to turn the panel on". What's the order of power_on and prepare
(and their counterparts)?  What's the division of responsibilities?

Similarly, the documentation for .enable() says, "This will typically
enable the backlight". What's the order of backlight_on and prepare (and
their counterparts)? What's the division of responsibilities?

> + int (*get_info)(struct drm_panel *panel,
> + struct drm_connector *connector);

As I said in my earlier review, I don't think this is needed.

BR,
Jani.

>  };
>  
>  struct drm_panel {
> @@ -117,6 +123,47 @@ static inline int drm_panel_enable(struct drm_panel 
> *panel)
>   return panel ? -ENOSYS : -EINVAL;
>  }
>  
> +static inline int drm_panel_power_on(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->power_on)
> + return panel->funcs->power_on(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +
> +static inline int drm_panel_power_off(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->power_off)
> + return panel->funcs->power_off(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +
> +static inline int drm_panel_backlight_on(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->backlight_on)
> + return panel->funcs->backlight_on(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +
> +static inline int drm_panel_backlight_off(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->backlight_off)
> + return panel->funcs->backlight_off(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +
> +static inline int drm_panel_get_info(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + if (connector && panel && panel->funcs && panel->funcs->get_info)
> + return panel->funcs->get_info(panel, connector);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +
>  static inline int drm_panel_get_modes(struct drm_panel *panel)
>  {
>   if (panel && panel->funcs && panel->funcs->get_modes)

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

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

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

--- Comment #40 from Alex Deucher  ---
(In reply to Andrew Randrianasulu from comment #38)
> unfortunately, running with RADEON_DEBUG=notiling gives no visible
> improvements.

You have to disable tiling in the ddx as well in the device section of you xorg
config:
Option "ColorTiling" "false"

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

[PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

[Jyri Sarha]

On 02/26/16 13:21, Russell King - ARM Linux wrote:
> On Fri, Feb 26, 2016 at 12:14:44PM +0200, Jyri Sarha wrote:
>> On 02/26/16 02:43, Russell King - ARM Linux wrote:
>>> On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote:
 On 02/18/16 16:35, Rob Herring wrote:
> This should be implied from the port unit address. In other words,
> port at 0 is defined to be the rgb port. Now, if this is one of several
> modes for the video port, then that is a different story.
>

 Do you suggest that also the audio i2s and s/p-dif port-types should be
 coded in the port unit addresses? Something like: port at 0 is always rgb,
 port at 1 is i2s, and port at 2 is spdif?
>>>
>>> For the audio inputs, the port address corresponds to the input pin.
>>> TDA998x devices can have multiple streams routed to the pins, and can
>>> select between them.
>>>
>>> For example, there may be four I2S data pins and one I2S clock pin.
>>> When using stereo, you can select which of the four I2S data pins
>>> carries the audio data.
>>>
>>
>> Sure, but I do not think that would be the usual setup. The only "normal"
>> situation I can think for having a need to have two alternative audio setups
>> would one for i2s and another for s/p-dif. But then again it is possible to
>> come up with a design with multiple alternative audio wirings and it
>> relatively simple handle that in DT binding, so why not.
>
> There's another reason: if you want to support 8 channel audio using I2S
> rather than SPDIF, then you need to use four I2S data inputs.  Each I2S
> data input can support only two channels.
>

Yes, but surely in the situation where there is 4 data wires, those 
should all be seen as a single audio port, as they are all sharing the 
same bit and frame clock wires. In such a situation I can't see why we 
would ever want to configure anything less that all four connected 
wires. ALSA and CPU—DAI driver can then deal with the situations when we 
only have two channels of data, or the HDMI sink can only play stereo.

If we start to think how to describe multiple alternative endpoints for 
I have to have a unit address, but do I have to have a reg property? I 
did not know about such a rule when I already made an alternative 
binding and implementation that appears to work just fine with multiple 
ports without reg property, but maybe I have over looked some piece of 
specification that forbids that.essentially the same entity (=the single 
i2s port, with up to 4 data wires), then there is no upper limit to the 
amount of ports we'd need to support.

On the other hand, if there are multiple i2s components sharing the same 
clock wires (and maybe some data wires with TDM too), then graph-style 
binding is probably not the best way to describe that kind of setup.

The more I think about this the more I think the graph binding is a bad 
choice to for i2s connections. For SPDIF the graph works better, but why 
use something that does not work for every DAI format?

>>> When using SPDIF, there may be two SPDIF inputs, and you can select
>>> which SPDIF input is used.
>>>
>>> So, "reg" may not be an address in terms of a CPU visible address, but
>>> it's an address as far as selecting the appropriate input - and it
>>> fits in with the requirements of ePAPR, which are that if you have
>>> a unit-address (which is required to distinguish different port nodes)
>>> then you must have a matching "reg" property.
>>
>> Still I do not see why it is desirable to reuse reg property, when we can
>> introduce new property for describing the audio wiring.
>
> Different people have different opinions.  Your opinion is just another
> example of someone holding a different view.
>
> You _have_ to have a unit address, and therefore you _have_ to have a
> reg property.  If you want to use some other property to describe the

I have to have a unit address, but do I have to have a reg property? I 
did not know about such a rule when I already made an alternative 
binding and implementation that appears to work just fine with multiple 
ports without reg property, but maybe I have over looked some piece of 
specification that forbids that.

> audio input pin, then you will need to make up a totally ficticious
> unit-address and reg property for each audio input pin.
>
> That's adding complexity, arguably unnecessary complexity, and making
> the binding unnecessarily more complex for no good reason.
>
>>> I don't particularly like the video node using the RGB routing register
>>> value either for the reg property, but I've kept quiet because I have
>>> nothing to offer there: again, this comes down to ePAPR requirements
>>> and the need to specify multiple "port { }" nodes.  You can't have two
>>> "port { }" nodes without using a unit-address, and we'd need to chose
>>> a unit-address for it which doesn't conflict with the audio ports...
>>> so there's a kind of logic to using the RGB routing value, which will
>>> never conflict.

[4.4-rc1][Regression] drm/i915: Check live status before reading edid

[Jani Nikula]

On Wed, 24 Feb 2016, Joseph Salisbury  wrote:
> Hi Sonika,
>
> A kernel bug report was opened against Ubuntu [0].  After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
>
> commit 237ed86c693d8a8e4db476976aeb30df4deac74b
> Author: Sonika Jindal 
> Date:   Tue Sep 15 09:44:20 2015 +0530
>
> drm/i915: Check live status before reading edid
>
>
>
> The regression was introduced as of v4.4-rc1.
>
> I was hoping to get your feedback, since you are the patch author.  Do
> think increasing the number of tries in intel_hdmi_detect() is worth
> trying?  Do you think gathering any additional data will help diagnose
> this issue, or would it be best to submit a revert request?

There are at least the following commits claiming to fix issues in the
above commit. Please make sure you have them.

BR,
Jani.


commit 8d409cb3e8a24196be7271defafd4638f3e0b514
Author: Ville Syrjälä 
Date:   Wed Feb 10 19:59:05 2016 +0200

drm/i915: Fix hpd live status bits for g4x

commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
Author: Gary Wang 
Date:   Wed Dec 23 16:11:35 2015 +0800

drm/i915: increase the tries for HDMI hotplug live status checking

commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715
Author: Daniel Vetter 
Date:   Fri Dec 11 19:44:15 2015 +0100

drm/i915: mdelay(10) considered harmful

commit 0f5a9be15797f78c9a34e432f26c796165b6e49a
Author: Imre Deak 
Date:   Fri Nov 27 18:55:29 2015 +0200

drm/i915: take a power domain reference while checking the HDMI live status




-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/crtc: Use drm_mode_object_put() in __drm_framebuffer_unregister()

[Liu Ying]

The function __drm_framebuffer_unregister() has boilerplate code to drop idr
reference.  Let's replace it with drm_mode_object_put() to simplify the code.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/drm_crtc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 65258ac..579505c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -430,9 +430,7 @@ EXPORT_SYMBOL(drm_framebuffer_init);
 static void __drm_framebuffer_unregister(struct drm_device *dev,
 struct drm_framebuffer *fb)
 {
-   mutex_lock(>mode_config.idr_mutex);
-   idr_remove(>mode_config.crtc_idr, fb->base.id);
-   mutex_unlock(>mode_config.idr_mutex);
+   drm_mode_object_put(dev, >base);

fb->base.id = 0;
 }
-- 
2.5.0

[PATCH] drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

[Rob Clark]

On Feb 29 2016 or thereabouts, Daniel Vetter wrote:
> On Mon, Feb 22, 2016 at 02:22:49PM -0500, Lyude wrote:
> > These warnings still seem to be present with DP MST configurations. They
> > don't actually indicate any impending doom, so we may as well use
> > I915_STATE_WARN_ON() here to help quiet things down a little bit for
> > distro kernel users.
> > 
> > Signed-off-by: Lyude 
> 
> I thought we've fixed up all offenders in drm-intel-nightly? Can you pls
> confirm this is the case - this isn't something we should shrug off ...

I was still seeing this w/ nightly as of perhaps ~mid last week..

Note that upstream default is still to have verbose state warn's so this
would still be the splat that you want to see ;-)

BR,
-R

> Also, I kinda wonder whether we should try another attempt at enabling
> this, in 4.6/fc rawhide perhaps, and see what happens? We /should/ be a
> lot better with all this fail now.
> 
> I guess if this is all fixed in upstream/4.6 already then we could apply
> this to 4.5 and stable kernels. But I don't really want this in upstream,
> if it can be avoided.
> 
> Thanks, Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index a234687..1870185 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3545,7 +3545,7 @@ static void skl_update_other_pipe_wm(struct 
> > drm_device *dev,
> >  * because it was really needed, so we expect the WM values to
> >  * be different.
> >  */
> > -   WARN_ON(!wm_changed);
> > +   I915_STATE_WARN_ON(!wm_changed);
> >  
> > skl_compute_wm_results(dev, _wm, r, intel_crtc);
> > r->dirty[intel_crtc->pipe] = true;
> > -- 
> > 2.5.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[PATCH v5 2/7] drm: add parameter-order checking to drm memory allocators

[Dave Gordon]

After the recent addition of drm_malloc_gfp(), it was noticed that
some callers of these functions has swapped the parameters in the
call - it's supposed to be 'number of members' and 'sizeof(element)',
but a few callers had got the size first and the count second. This
isn't otherwise detected because they're both type 'size_t', and
the implementation at present just multiplies them anyway, so the
result is still right. But some future implementation might treat
them differently (e.g. allowing 0 elements but not zero size), so
let's add some compile-time checks and complain if the second (size)
parameter isn't a sizeof() expression, or at least a compile-time
constant.

This patch also fixes those callers where the order was wrong.

Signed-off-by: Dave Gordon 
Cc: Chris Wilson 
Cc: Ville Syrjälä Cc: dri-
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  8 
 include/drm/drm_mem_util.h   | 30 +---
 3 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 1aba01a..9ae4a71 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -340,7 +340,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
 */
bos = drm_malloc_ab(args->nr_bos, sizeof(*bos));
relocs = drm_malloc_ab(args->nr_relocs, sizeof(*relocs));
-   stream = drm_malloc_ab(1, args->stream_size);
+   stream = drm_malloc_ab(args->stream_size, sizeof(*stream));
cmdbuf = etnaviv_gpu_cmdbuf_new(gpu, ALIGN(args->stream_size, 8) + 8,
args->nr_bos);
if (!bos || !relocs || !stream || !cmdbuf) {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 18a5dcc..865876d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1687,8 +1687,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
}

/* Copy in the exec list from userland */
-   exec_list = drm_malloc_ab(sizeof(*exec_list), args->buffer_count);
-   exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count);
+   exec_list = drm_malloc_ab(args->buffer_count, sizeof(*exec_list));
+   exec2_list = drm_malloc_ab(args->buffer_count, sizeof(*exec2_list));
if (exec_list == NULL || exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
  args->buffer_count);
@@ -1776,8 +1776,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
return -EINVAL;
}

-   exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
-   args->buffer_count,
+   exec2_list = drm_malloc_gfp(args->buffer_count,
+   sizeof(*exec2_list),
GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
index 741ce75..886ff0a 100644
--- a/include/drm/drm_mem_util.h
+++ b/include/drm/drm_mem_util.h
@@ -29,7 +29,7 @@

 #include 

-static __inline__ void *drm_calloc_large(size_t nmemb, size_t size)
+static __inline__ void *__drm_calloc_large(size_t nmemb, const size_t size)
 {
if (size != 0 && nmemb > SIZE_MAX / size)
return NULL;
@@ -41,8 +41,15 @@ static __inline__ void *drm_calloc_large(size_t nmemb, 
size_t size)
 GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO, PAGE_KERNEL);
 }

+#definedrm_calloc_large(nmemb, size)   
\
+({ \
+   BUILD_BUG_ON_MSG(!__builtin_constant_p(size),   \
+   "Non-constant 'size' - check argument ordering?");  \
+   __drm_calloc_large(nmemb, size);\
+})
+
 /* Modeled after cairo's malloc_ab, it's like calloc but without the zeroing. 
*/
-static __inline__ void *drm_malloc_ab(size_t nmemb, size_t size)
+static __inline__ void *__drm_malloc_ab(size_t nmemb, const size_t size)
 {
if (size != 0 && nmemb > SIZE_MAX / size)
return NULL;
@@ -54,8 +61,18 @@ static __inline__ void *drm_malloc_ab(size_t nmemb, size_t 
size)
 GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL);
 }

-static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
+#definedrm_malloc_ab(nmemb, size)  
\
+({ \
+   BUILD_BUG_ON_MSG(!__builtin_constant_p(size),   \
+  

[PATCH v5 1/7] drm,i915: introduce drm_malloc_gfp()

[Dave Gordon]

From: Chris Wilson 

I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want
to try a high-order kmalloc() before using a vmalloc().

So refactor my usage into drm_malloc_gfp().

Signed-off-by: Chris Wilson 
Cc: dri-devel at lists.freedesktop.org
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie 
Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  8 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  5 +++--
 drivers/gpu/drm/i915/i915_gem_userptr.c| 15 ---
 include/drm/drm_mem_util.h | 19 +++
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8fd00d2..18a5dcc 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1776,11 +1776,9 @@ static bool only_mappable_for_reloc(unsigned int flags)
return -EINVAL;
}

-   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (exec2_list == NULL)
-   exec2_list = drm_malloc_ab(sizeof(*exec2_list),
-  args->buffer_count);
+   exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
+   args->buffer_count,
+   GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
  args->buffer_count);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9127f8f..2b04c3a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3414,8 +3414,9 @@ struct i915_vma *
int ret = -ENOMEM;

/* Allocate a temporary list of source pages for random access. */
-   page_addr_list = drm_malloc_ab(obj->base.size / PAGE_SIZE,
-  sizeof(dma_addr_t));
+   page_addr_list = drm_malloc_gfp(obj->base.size / PAGE_SIZE,
+   sizeof(dma_addr_t),
+   GFP_TEMPORARY);
if (!page_addr_list)
return ERR_PTR(ret);

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 7107f2f..b4be458 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -494,10 +494,7 @@ struct get_pages_work {
ret = -ENOMEM;
pinned = 0;

-   pvec = kmalloc(npages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (pvec == NULL)
-   pvec = drm_malloc_ab(npages, sizeof(struct page *));
+   pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;

@@ -634,14 +631,10 @@ struct get_pages_work {
pvec = NULL;
pinned = 0;
if (obj->userptr.mm->mm == current->mm) {
-   pvec = kmalloc(num_pages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
+   pvec = drm_malloc_gfp(num_pages, sizeof(struct page *), 
GFP_TEMPORARY);
if (pvec == NULL) {
-   pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
-   if (pvec == NULL) {
-   __i915_gem_userptr_set_active(obj, false);
-   return -ENOMEM;
-   }
+   __i915_gem_userptr_set_active(obj, false);
+   return -ENOMEM;
}

pinned = __get_user_pages_fast(obj->userptr.ptr, num_pages,
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
index e42495a..741ce75 100644
--- a/include/drm/drm_mem_util.h
+++ b/include/drm/drm_mem_util.h
@@ -54,6 +54,25 @@ static __inline__ void *drm_malloc_ab(size_t nmemb, size_t 
size)
 GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL);
 }

+static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
+{
+   if (size != 0 && nmemb > SIZE_MAX / size)
+   return NULL;
+
+   if (size * nmemb <= PAGE_SIZE)
+   return kmalloc(nmemb * size, gfp);
+
+   if (gfp & __GFP_RECLAIMABLE) {
+   void *ptr = kmalloc(nmemb * size,
+   gfp | __GFP_NOWARN | __GFP_NORETRY);
+   if (ptr)
+   return ptr;
+   }
+
+   return __vmalloc(size * nmemb,
+gfp | __GFP_HIGHMEM, PAGE_KERNEL);
+}
+
 static __inline void drm_free_large(void *ptr)
 {
   

[PATCH 12/12] drm/dp: Add drm_dp_link_choose() helper

[Jani Nikula]

On Mon, 29 Feb 2016, Thierry Reding  wrote:
> On Sun, Jan 31, 2016 at 04:39:51PM +0200, Jani Nikula wrote:
>> On Mon, 14 Dec 2015, Thierry Reding  wrote:
>> > From: Thierry Reding 
>> >
>> > This helper chooses an appropriate configuration, according to the
>> > bitrate requirements of the video mode and the capabilities of the
>> > DisplayPort sink.
>> >
>> > Signed-off-by: Thierry Reding 
>> > ---
>> >  drivers/gpu/drm/drm_dp_helper.c | 55 
>> > +
>> >  include/drm/drm_dp_helper.h |  5 
>> >  2 files changed, 60 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> > b/drivers/gpu/drm/drm_dp_helper.c
>> > index da519acfeba7..95825155dc89 100644
>> > --- a/drivers/gpu/drm/drm_dp_helper.c
>> > +++ b/drivers/gpu/drm/drm_dp_helper.c
>> > @@ -512,6 +512,61 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, 
>> > struct drm_dp_link *link)
>> >  }
>> >  EXPORT_SYMBOL(drm_dp_link_configure);
>> >  
>> > +/**
>> > + * drm_dp_link_choose() - choose the lowest possible configuration for a 
>> > mode
>> > + * @link: DRM DP link object
>> > + * @mode: DRM display mode
>> > + * @info: DRM display information
>> > + *
>> > + * According to the eDP specification, a source should select a 
>> > configuration
>> > + * with the lowest number of lanes and the lowest possible link rate that 
>> > can
>> > + * match the bitrate requirements of a video mode. However it must ensure 
>> > not
>> > + * to exceed the capabilities of the sink.
>> 
>> Eventually this would have to take into account the intersection of
>> per-sink and per-source supported rates, including the intermediate
>> frequencies. Until then, i915 couldn't switch over.
>
> I'm not sure I understand what you're saying. The idea is that drivers
> will call the drm_dp_link_probe() helper to probe the sink for supported
> frequencies, number of lanes and capabilities.
>
> After that, drivers are supposed to adjust the maximum values to account
> for their limitations. Hence the name for struct drm_dp_*link*, because
> it contains the negotiated parameters for the link between source and
> sink.
>
> That seems to me like the logical procedure when following the spec. Is
> that not how i915 works?

eDP v1.4 introduces more link rates. DPCD 10h through 1fh may contain a
table of the supported link rates, AFAICT the spec is written in a way
to allow arbitrary rates, but at least 1.62, 2.16, 2.43, 2.7, 3.24,
4.32, and 5.4 Gbps are cited and more details are provided for
those. The support is not limited by the maximum only, so an
intersection of the rates supported by source and sink will be required.

Obviously _link_probe() needs to be updated to figure out the supported
rates, not just the max, and _link_choose() can't assume a fixed set of
rates either.

i915 supports this. I'm not saying that what you're doing must support
all of this from the start, but I think you should get the eDP v1.4 spec
to make sure adding the support later on will be as straightforward as
possible.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] dma-buf/fence: fix fence_is_later v2

[Alex Deucher]

From: Christian König 

A fence is never later than itself. This caused a bunch of overhead for AMDGPU.

v2: simplify check as suggested by Michel.

Signed-off-by: Christian König 
Reviewed-by: Michel Dänzer 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 include/linux/fence.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index bb52201..5aa95eb 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -292,7 +292,7 @@ static inline bool fence_is_later(struct fence *f1, struct 
fence *f2)
if (WARN_ON(f1->context != f2->context))
return false;

-   return f1->seqno - f2->seqno < INT_MAX;
+   return (int)(f1->seqno - f2->seqno) > 0;
 }

 /**
-- 
2.5.0

[PATCH 1/7] drm/hisilicon:Add hisilicon hibmc master driver.

[Emil Velikov]

On 29 February 2016 at 00:58, lijianhua  wrote:
> Add hibmc DRM master driver for hi1710 which used in arm64 board.
>
Would be nice to give examples of what "arm64 board" this hardware is
presently available. Some information about the device as seen in the
cover letter, and/or a link to the cover letter would be nice to have.

> Signed-off-by: lijianhua 
> ---
>  drivers/gpu/drm/Kconfig |   2 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/hisilicon/Kconfig   |   4 +
>  drivers/gpu/drm/hisilicon/Makefile  |   4 +
>  drivers/gpu/drm/hisilicon/hibmc/Kconfig |  13 +
>  drivers/gpu/drm/hisilicon/hibmc/Makefile|   5 +
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 301 +++
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |  49 +++
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.c  |  83 
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.h  | 484 
> 
>  10 files changed, 946 insertions(+)
>  create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
>  create mode 100644 drivers/gpu/drm/hisilicon/Makefile
>  create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig
>  create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile
>  create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>  create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>  create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.c
>  create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 8ae7ab6..600f94d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -269,3 +269,5 @@ source "drivers/gpu/drm/imx/Kconfig"
>  source "drivers/gpu/drm/vc4/Kconfig"
>
>  source "drivers/gpu/drm/etnaviv/Kconfig"
> +
> +source "drivers/gpu/drm/hisilicon/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 61766de..6055483 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -74,3 +74,4 @@ obj-y += panel/
>  obj-y  += bridge/
>  obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>  obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> +obj-y  += hisilicon/
> diff --git a/drivers/gpu/drm/hisilicon/Kconfig 
> b/drivers/gpu/drm/hisilicon/Kconfig
> new file mode 100644
> index 000..1f10e17
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/Kconfig
> @@ -0,0 +1,4 @@
> +# hisilicon drm device configuration.
> +# Please keep this sorted alphabetically.
> +
> +source "drivers/gpu/drm/hisilicon/hibmc/Kconfig"
> diff --git a/drivers/gpu/drm/hisilicon/Makefile 
> b/drivers/gpu/drm/hisilicon/Makefile
> new file mode 100644
> index 000..487d5b0
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/Makefile
> @@ -0,0 +1,4 @@
> +# Makefile for hisilicon drm drivers.
> +# Please keep this list sorted alphabetically
> +
> +obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc/
> \ No newline at end of file
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig 
> b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> new file mode 100644
> index 000..c60ace6
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> @@ -0,0 +1,13 @@
> +config DRM_HISI_HIBMC
> +   tristate "DRM Support for hisilicon hibmc dispi vga interface"
Use proper capitalisation in the above ? Is the driver copied/derived
from bochs - the above does not sounds right.

> +   depends on DRM && PCI
> +   select DRM_KMS_HELPER
> +   select DRM_KMS_FB_HELPER
> +   select DRM_GEM_CMA_HELPER
> +   select DRM_KMS_CMA_HELPER
> +   select FB_SYS_FILLRECT
> +   select FB_SYS_COPYAREA
> +   select FB_SYS_IMAGEBLIT
> +   help
> + Choose this option for qemu.
Err what - too much copy/pasta ?

> + If M is selected the module will be called hibmc-drm.
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
> b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> new file mode 100644
> index 000..28e59bb
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> @@ -0,0 +1,5 @@
> +ccflags-y := -Iinclude/drm
Based on the includes in hibmc_drm_drv.c the above include isn't needed.

> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_hw.o
> +
> +obj-$(CONFIG_DRM_HISI_HIBMC)   +=hibmc-drm.o
> +#obj-y += hibmc-drm.o
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> new file mode 100644
> index 000..444ced8
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -0,0 +1,301 @@
> +/*
> + * Copyright (c) 2016 Huawei Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> 

[PATCH v4 3/5] staging/android: remove redundant comments on sync_merge_data

[Maarten Lankhorst]

Op 26-02-16 om 19:31 schreef Gustavo Padovan:
> From: Gustavo Padovan 
>
> struct sync_merge_data already have documentation on top of the
> struct definition. No need to duplicate it.
>
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/staging/android/uapi/sync.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/uapi/sync.h 
> b/drivers/staging/android/uapi/sync.h
> index dd0dd84..f0b41ce 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -21,9 +21,9 @@
>   * @fence:   returns the fd of the new fence to userspace
>   */
>  struct sync_merge_data {
> - __s32   fd2; /* fd of second fence */
> - charname[32]; /* name of new fence */
> - __s32   fence; /* fd on newly created fence */
> + __s32   fd2;
> + charname[32];
> + __s32   fence;
>  };
>  
>  /**
For the first 3 patches:

Reviewed-by: Maarten Lankhorst 

[PATCH v4 5/5] staging/android: add flags member to sync ioctl structs

[Maarten Lankhorst]

Op 26-02-16 om 19:31 schreef Gustavo Padovan:
> From: Gustavo Padovan 
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
> v2: check if flags are valid (zero, in this case)
>
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/staging/android/sync.c  | 7 ++-
>  drivers/staging/android/uapi/sync.h | 6 ++
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index 837cff5..54fd5ab 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
> *sync_file,
>   goto err_put_fd;
>   }
>  
> + if (data.flags) {
> + err = -EFAULT;
> + goto err_put_fd;
> + }
-EINVAL
>   fence2 = sync_file_fdget(data.fd2);
>   if (!fence2) {
>   err = -ENOENT;
> @@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
> *sync_file,
>   if (copy_from_user(, (void __user *)arg, sizeof(*info)))
>   return -EFAULT;
>  
> - if (in.status || strcmp(in.name, "\0"))
> + if (in.status || in.flags || strcmp(in.name, "\0"))
>   return -EFAULT;
-EINVAL
>   if (in.num_fences && !in.sync_fence_info)
> diff --git a/drivers/staging/android/uapi/sync.h 
> b/drivers/staging/android/uapi/sync.h
> index 9aad623..f56a6c2 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -19,11 +19,13 @@
>   * @fd2: file descriptor of second fence
>   * @name:name of new fence
>   * @fence:   returns the fd of the new fence to userspace
> + * @flags:   merge_data flags
>   */
>  struct sync_merge_data {
>   __s32   fd2;
>   charname[32];
>   __s32   fence;
> + __u32   flags;
>  };
>  
>  /**
> @@ -31,12 +33,14 @@ struct sync_merge_data {
>   * @obj_name:name of parent sync_timeline
>   * @driver_name: name of driver implementing the parent
>   * @status:  status of the fence 0:active 1:signaled <0:error
> + * @flags:   fence_info flags
>   * @timestamp_ns:timestamp of status change in nanoseconds
>   */
>  struct sync_fence_info {
>   charobj_name[32];
>   chardriver_name[32];
>   __s32   status;
> + __u32   flags;
>   __u64   timestamp_ns;
>  };
>  
> @@ -44,6 +48,7 @@ struct sync_fence_info {
>   * struct sync_file_info - data returned from fence info ioctl
>   * @name:name of fence
>   * @status:  status of fence. 1: signaled 0:active <0:error
> + * @flags:   sync_file_info flags
>   * @num_fences   number of fences in the sync_file
>   * @len: ioctl caller writes the size of the buffer its passing in.
>   *   ioctl returns length of all fence_infos summed.
> @@ -52,6 +57,7 @@ struct sync_fence_info {
>  struct sync_file_info {
>   charname[32];
>   __s32   status;
> + __u32   flags;
>   __u32   num_fences;
>   __u32   len;
>  

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2016-02-14:
- lots and lots of fbc work from Paulo
- max pixel clock checks from Mika Kahola
- prep work for nv12 offset handling from Ville
- piles of small fixes and refactorings all around

I've forgotten to send you this one before I left for vacation, oops. So
there'll be another/final i915 feature pull in a few days still.

Cheers, Daniel


The following changes since commit 382ab95d1af85381d8a5dff09b16a80c7e492534:

  drm/msm: remove unused variable (2016-02-11 11:48:39 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-02-14

for you to fetch changes up to 59bbf84d8958a6e6cf579c8ddcca88e3f3924dbd:

  drm/i915: Update DRIVER_DATE to 20160214 (2016-02-14 22:40:52 +0100)


- lots and lots of fbc work from Paulo
- max pixel clock checks from Mika Kahola
- prep work for nv12 offset handling from Ville
- piles of small fixes and refactorings all around


Abhay Kumar (1):
  drm/i915: edp resume/On time optimization.

Alex Dai (1):
  drm/i915/guc: Decouple GuC engine id from ring id

Andreas Ziegler (1):
  drm/i915: Remove select to deleted STOP_MACHINE from Kconfig

Arun Siluvery (9):
  drm/i915/gen9: Add framework to whitelist specific GPU registers
  drm/i915/gen9: Add GEN8_CS_CHICKEN1 to HW whitelist
  drm/i915/gen9: Add HDC_CHICKEN1 to HW whitelist
  drm/i915/bxt: Add GEN9_CS_DEBUG_MODE1 to HW whitelist
  drm/i915/bxt: Add GEN8_L3SQCREG4 to HW whitelist
  drm/i915/skl: Add GEN8_L3SQCREG4 to HW whitelist
  drm/i915/skl: Enable Per context Preemption granularity control
  drm/i915/gen9: Add WaOCLCoherentLineFlush
  drm/i915: Capture PCI revision and subsytem details in error state

Chris Wilson (2):
  drm/i915: Improve handling of overlapping objects
  drm/i915: Allow i915_gem_object_get_page() on userptr as well

Daniel Vetter (6):
  Revert "drm/i915: Fix context/engine cleanup order"
  agp/intel-gtt: Don't leak the scratch page
  drm/i915: Stop depending upon CONFIG_AGP_INTEL
  agp/intel-gtt: Only register fake agp driver for gen1
  Merge tag 'topic/drm-misc-2016-02-12' into drm-intel-next-queued
  drm/i915: Update DRIVER_DATE to 20160214

Daniele Ceraolo Spurio (1):
  drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem

Dave Gordon (1):
  Fix pointer tests in error-handling paths

Deepak M (1):
  drm/i915: Extend gpio read/write to other cores

Gabriel Feceoru (1):
  drm/i915: Handle PipeC fused off on IVB/HSW/BDW

Gerd Hoffmann (1):
  drm/i915: refine qemu south bridge detection

Imre Deak (12):
  drm/i915: Sanitize DMC/CSR ucode cleanup code
  drm/i915: Sanitize i915_get_bridge_dev() error path
  drm/i915: Sanitize GEM shrinker init and clean-up
  drm/i915: Sanitize i915_gem_load() init and clean-up
  drm/i915: Move allocation of various workqueues earlier during init
  drm/i915: Move MCHBAR setup earlier during init
  drm/i915: Move stolen memory initialization earlier during loading
  drm/i915/bxt: update list of PCIIDs
  drm/i915: Sanity check DP AUX message buffer and size
  drm/i915/chv: Fix error path in GPU freq helpers
  drm/i915: Add debug info for failed MSI enabling
  drm/i915: Properly terminate KMS mode name string during tv init

Jani Nikula (7):
  drm/i915/dsi: defend gpio table against out of bounds access
  drm/i915/dsi: don't pass arbitrary data to sideband
  drm/i915: put the IOSF port defines in numerical order
  drm/i915/vlv: drop unused vlv_gps_core_read/write functions
  drm/i915/dsi: skip gpio element execution when not supported
  drm/i915/dp: abstract training pattern selection
  drm/i915/dp: reduce missing TPS3 support errors to debug logging

Lyude (3):
  drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()
  drm/i915/skl: Explicitly check for eDP in skl_ddi_pll_select()
  drm/i915/skl: Fix typo in DPLL_CFGCR1 definition

Maarten Lankhorst (3):
  drm/i915: Remove intel_crtc->atomic.disable_ips.
  drm/i915: Remove atomic.pre_disable_primary.
  drm/i915: Do not disable cxsr when crtc is disabled.

Mat Martineau (2):
  drm/i915: Fix file permissions
  drm/i915/skl: Fix DMC load on Skylake J0 and K0

Matt Roper (3):
  drm/i915/bxt: Don't save/restore eDP panel power during suspend (v3)
  drm/i915: Check DDI max lanes after applying BXT workaround
  drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)

Michał Winiarski (1):
  drm/i915/skl: Add missing SKL ids

Mika Kahola (7):
  drm/i915: Skip DDI PLL selection for DSI
  drm/i915: DisplayPort pixel clock check
  drm/i915: HDMI pixel clock check
  drm/i915: DisplayPort-MST pixel clock check
  drm/i915: SDVO pixel clock 

[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Maarten Lankhorst]

Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> From: Gustavo Padovan 
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer allocation. In the new approach the ioctl needs to be called
> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
>
> The first call should pass num_fences = 0, the kernel will then fill
> info->num_fences. Userspace receives back the number of fences and
> allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> info->sync_fence_info.
>
> It then call the ioctl again passing num_fences received in info->num_fences.
> The kernel checks if info->num_fences > 0 and if yes it fill
> info->sync_fence_info with an array containing all fence_infos.
>
> info->len now represents the length of the buffer sync_fence_info points
> to. Also, info->sync_fence_info was converted to __u64 pointer.
>
> An example userspace code would be:
>
>   struct sync_file_info *info;
>   int err, size, num_fences;
>
>   info = malloc(sizeof(*info));
>
>   memset(info, 0, sizeof(*info));
>
>   err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>   num_fences = info->num_fences;
>
>   if (num_fences) {
>   memset(info, 0, sizeof(*info));
Would this memset still be needed if we didn't check for nulls in info->status 
and info->name ?

Seems to me that it could be skipped in that case.
>   size = sizeof(struct sync_fence_info) * num_fences;
>   info->len = size;
>   info->num_fences = num_fences;
>   info->sync_fence_info = (uint64_t) calloc(num_fences,
> sizeof(struct 
> sync_fence_info));
>
>   err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>   }
>
> v2: fix fence_info memory leak
>
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/staging/android/sync.c  | 52 
> +
>  drivers/staging/android/uapi/sync.h |  9 +++
>  2 files changed, 45 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index dc5f382..2379f23 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, 
> void *data, int size)
>  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>   unsigned long arg)
>  {
> - struct sync_file_info *info;
> + struct sync_file_info in, *info;
> + struct sync_fence_info *fence_info = NULL;
>   __u32 size;
>   __u32 len = 0;
= 0 unneeded.
>   int ret, i;
>  
> - if (copy_from_user(, (void __user *)arg, sizeof(size)))
> + if (copy_from_user(, (void __user *)arg, sizeof(*info)))
>   return -EFAULT;
>  
> - if (size < sizeof(struct sync_file_info))
> - return -EINVAL;
> + if (in.status || strcmp(in.name, "\0"))
> + return -EFAULT;
These members always get written by the fence ioctl, I'm not sure it adds value 
to have them explicitly zero'd out by userspace.
> - if (size > 4096)
> - size = 4096;
> + if (in.num_fences && !in.sync_fence_info)
> + return -EFAULT;
This check is unneeded, it will happen in the copy_to_user call anyway.
> - info = kzalloc(size, GFP_KERNEL);
> + info = kzalloc(sizeof(*info), GFP_KERNEL);
>   if (!info)
>   return -ENOMEM;
>  
> @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file 
> *sync_file,
>   if (info->status >= 0)
>   info->status = !info->status;
>  
> - info->num_fences = sync_file->num_fences;
> + /*
> +  * Passing num_fences = 0 means that userspace want to know how
> +  * many fences are in the sync_file to be able to allocate a buffer to
> +  * fit all sync_fence_infos and call the ioctl again with the buffer
> +  * assigned to info->sync_fence_info. The second call pass the
> +  * num_fences value received in the first call.
> +  */
> + if (!in.num_fences)
> + goto no_fences;
> +
> + size = sync_file->num_fences * sizeof(*fence_info);
> + if (in.len != size) {
> + ret = -EFAULT;
> + goto out;
> + }
Maybe check for in.len < size, and set set to size?


> - len = sizeof(struct sync_file_info);
> + fence_info = kzalloc(size, GFP_KERNEL);
> + if (!fence_info) {
> + ret = -ENOMEM;
> + goto out;
> + }
>  
>   for (i = 0; i < sync_file->num_fences; ++i) {
>   struct fence *fence = sync_file->cbs[i].fence;
>  
> - ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> + ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
> +size - len);
>  
>   if (ret < 0)
>   goto out;
> @@ -540,14 

[PATCH 7/7] MAINTAINERS:Add maintainer for hibmc DRM driver

[lijianhua]

Add maintainer for hibmc DRM driver.

Signed-off-by: lijianhua 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc1..2bf23eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,6 +3774,13 @@ S:   Maintained
 F: drivers/gpu/drm/gma500
 F: include/drm/gma500*

+DRM DRIVERS FOR HIBMC
+M: lijianhua 
+M: Rongrong Zou 
+L: dri-devel at lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/hisilicon/hibmc
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M: Thierry Reding 
 M: Terje Bergström 
-- 
1.9.1

[PATCH 6/7] drm/hisilicon:Add fbdev

[lijianhua]

Add fbdev.

Signed-off-by: lijianhua 
---
 drivers/gpu/drm/hisilicon/hibmc/Makefile  |   2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |   5 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |   2 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 290 ++
 4 files changed, 298 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index 6ab59b1..1ca1d49 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,5 +1,5 @@
 ccflags-y := -Iinclude/drm
-hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_hw.o
+hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o 
hibmc_drm_fbdev.o hibmc_drm_hw.o

 obj-$(CONFIG_DRM_HISI_HIBMC)   +=hibmc-drm.o
 #obj-y += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 673a8cd..7439f62 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -250,6 +250,7 @@ static int hibmc_unload(struct drm_device *dev)
 {
struct hibmc_private *hiprivate = dev->dev_private;

+   hibmc_fbdev_fini(hiprivate);
hibmc_kms_fini(hiprivate);
hibmc_hw_fini(dev);
dev->dev_private = NULL;
@@ -283,6 +284,10 @@ static int hibmc_load(struct drm_device *dev, unsigned 
long flags)
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);

+   ret = hibmc_fbdev_init(hiprivate);
+   if (ret)
+   goto err;
+
return 0;

 err:
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 1f6b25c..e863e1a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -50,5 +50,7 @@ int hibmc_plane_init(struct drm_device *dev);
 int hibmc_crtc_init(struct drm_device *dev);
 int hibmc_encoder_init(struct drm_device *dev);
 int hibmc_connector_init(struct drm_device *dev);
+int hibmc_fbdev_init(struct hibmc_private *hiprivate);
+void hibmc_fbdev_fini(struct hibmc_private *hiprivate);

 #endif
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
new file mode 100644
index 000..416a6c6
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright (c) 2016 Huawei Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "hibmc_drm_drv.h"
+
+/* -- */
+
+void hibmc_drm_fb_destroy(struct drm_framebuffer *fb)
+{
+   struct hibmc_private *hiprivate =
+   container_of(fb, struct hibmc_private, fbdev.fb.fb);
+   struct drm_gem_object *base = >fbdev.fb.obj->base;
+
+   if (hiprivate->fbdev.fb.obj)
+   drm_gem_object_unreference_unlocked(base);
+   drm_framebuffer_cleanup(fb);
+   kfree(fb);
+}
+
+static struct drm_framebuffer_funcs hibmc_drm_fb_funcs = {
+   .destroy= hibmc_drm_fb_destroy,
+};
+
+int hibmc_drm_fb_init(struct drm_device *dev,
+ struct hibmc_framebuffer *gfb,
+ struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_cma_object *obj)
+{
+   int ret;
+
+   drm_helper_mode_fill_fb_struct(>fb, mode_cmd);
+   gfb->obj = obj;
+   gfb->is_fbdev_fb = true;
+   ret = drm_framebuffer_init(dev, >fb, _drm_fb_funcs);
+   if (ret) {
+   DRM_ERROR("drm_framebuffer_init failed: %d\n", ret);
+   return ret;
+   }
+   return 0;
+}
+
+struct drm_gem_cma_object *hibmc_drm_gem_create_object(
+   struct hibmc_private *hiprivate,
+   size_t size)
+{
+   struct drm_gem_cma_object *cma_obj;
+   struct drm_gem_object *gem_obj;
+   struct drm_device *drm = hiprivate->dev;
+   int ret;
+
+   cma_obj = devm_kzalloc(drm->dev, sizeof(*cma_obj), GFP_KERNEL);
+   if (!cma_obj)
+   return ERR_PTR(-ENOMEM);
+
+   gem_obj = _obj->base;
+
+   ret = drm_gem_object_init(drm, gem_obj, size);
+   if (ret)
+   return ERR_PTR(ret);
+
+   cma_obj->vaddr = hiprivate->fb_map;
+   cma_obj->paddr = hiprivate->fb_base;
+   return cma_obj;
+}
+
+void hibmc_drm_gem_free_object(struct drm_gem_object *gem_obj)
+{
+   struct drm_gem_cma_object *cma_obj;
+
+   cma_obj = 

[PATCH 5/7] drm/hisilicon:Add connector for VDAC

[lijianhua]

Add connector funcs and helper funcs for VDAC.

Signed-off-by: lijianhua 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  |  8 +++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  1 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 89 
 3 files changed, 98 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index aa7f8415..673a8cd 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -143,6 +143,14 @@ int hibmc_kms_init(struct hibmc_private *hiprivate)
return ret;
}

+   ret = hibmc_connector_init(hiprivate->dev);
+   if (ret) {
+   DRM_ERROR("failed to init connector\n");
+   return ret;
+   }
+
+   drm_mode_connector_attach_encoder(>connector,
+ >encoder);
return 0;
 }

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 7f3c4bb..1f6b25c 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -49,5 +49,6 @@ struct hibmc_private {
 int hibmc_plane_init(struct drm_device *dev);
 int hibmc_crtc_init(struct drm_device *dev);
 int hibmc_encoder_init(struct drm_device *dev);
+int hibmc_connector_init(struct drm_device *dev);

 #endif
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index 06d9549..e832e22 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -15,6 +15,14 @@
 #include "hibmc_drm_drv.h"
 #include "hibmc_drm_hw.h"

+static int defx = 800;
+static int defy = 600;
+
+module_param(defx, int, 0444);
+module_param(defy, int, 0444);
+MODULE_PARM_DESC(defx, "default x resolution");
+MODULE_PARM_DESC(defy, "default y resolution");
+
 static void hibmc_encoder_disable(struct drm_encoder *encoder)
 {
 }
@@ -71,3 +79,84 @@ int hibmc_encoder_init(struct drm_device *dev)
return 0;
 }

+int hibmc_connector_get_modes(struct drm_connector *connector)
+{
+   int count;
+
+   count = drm_add_modes_noedid(connector, 800, 600);
+   drm_set_preferred_mode(connector, defx, defy);
+   return count;
+}
+
+static int hibmc_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   struct hibmc_private *hiprivate =
+container_of(connector, struct hibmc_private, connector);
+   unsigned long size = mode->hdisplay * mode->vdisplay * 4;
+
+   /*
+   * Make sure we can fit two framebuffers into video memory.
+   * This allows up to 1600x1200 with 16 MB (default size).
+   * If you want more try this:
+   * 'qemu -vga std -global VGA.vgamem_mb=32 $otherargs'
+   */
+   if (size * 2 > hiprivate->fb_size)
+   return MODE_BAD;
+
+   return MODE_OK;
+}
+
+static struct drm_encoder *
+hibmc_connector_best_encoder(struct drm_connector *connector)
+{
+   int enc_id = connector->encoder_ids[0];
+
+   /* pick the encoder ids */
+   if (enc_id)
+   return drm_encoder_find(connector->dev, enc_id);
+
+   return NULL;
+}
+
+static enum drm_connector_status hibmc_connector_detect(struct drm_connector
+*connector, bool force)
+{
+   return connector_status_connected;
+}
+
+struct drm_connector_helper_funcs hibmc_connector_connector_helper_funcs = {
+   .get_modes = hibmc_connector_get_modes,
+   .mode_valid = hibmc_connector_mode_valid,
+   .best_encoder = hibmc_connector_best_encoder,
+};
+
+struct drm_connector_funcs hibmc_connector_connector_funcs = {
+   .dpms = drm_atomic_helper_connector_dpms,
+   .detect = hibmc_connector_detect,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = drm_connector_cleanup,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+int hibmc_connector_init(struct drm_device *dev)
+{
+   struct hibmc_private *hiprivate = dev->dev_private;
+   struct drm_connector *connector = >connector;
+   int ret;
+
+   ret = drm_connector_init(dev, connector,
+_connector_connector_funcs,
+DRM_MODE_CONNECTOR_VIRTUAL);
+   if (ret) {
+   DRM_ERROR("failed to init connector\n");
+   return ret;
+   }
+   drm_connector_helper_add(connector,
+_connector_connector_helper_funcs);
+   drm_connector_register(connector);
+   return 0;
+}
+
-- 
1.9.1

[PATCH 4/7] drm/hisilicon:Add encoder for VDAC

[lijianhua]

Add encoder funcs and helpers for VDAC.

Signed-off-by: lijianhua 
---
 drivers/gpu/drm/hisilicon/hibmc/Makefile |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  |  6 ++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  1 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 73 
 4 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index bca651b..6ab59b1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,5 +1,5 @@
 ccflags-y := -Iinclude/drm
-hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_hw.o
+hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_hw.o

 obj-$(CONFIG_DRM_HISI_HIBMC)   +=hibmc-drm.o
 #obj-y += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 732836d..aa7f8415 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -137,6 +137,12 @@ int hibmc_kms_init(struct hibmc_private *hiprivate)
return ret;
}

+   ret = hibmc_encoder_init(hiprivate->dev);
+   if (ret) {
+   DRM_ERROR("failed to init encoder\n");
+   return ret;
+   }
+
return 0;
 }

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 7b4cb5e..7f3c4bb 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -48,5 +48,6 @@ struct hibmc_private {

 int hibmc_plane_init(struct drm_device *dev);
 int hibmc_crtc_init(struct drm_device *dev);
+int hibmc_encoder_init(struct drm_device *dev);

 #endif
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
new file mode 100644
index 000..06d9549
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -0,0 +1,73 @@
+/*
+ * Copyright (c) 2016 Huawei Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "hibmc_drm_drv.h"
+#include "hibmc_drm_hw.h"
+
+static void hibmc_encoder_disable(struct drm_encoder *encoder)
+{
+}
+
+static void hibmc_encoder_enable(struct drm_encoder *encoder)
+{
+}
+
+static void hibmc_encoder_mode_set(struct drm_encoder *encoder,
+  struct drm_display_mode *mode,
+  struct drm_display_mode *adj_mode)
+{
+   u32 reg;
+
+   /* just open DISPLAY_CONTROL_HISILE register bit 3:0*/
+   reg = PEEK32(DISPLAY_CONTROL_HISILE);
+   reg |= 0xf;
+   POKE32(DISPLAY_CONTROL_HISILE, reg);
+}
+
+static int hibmc_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+   return 0;
+}
+
+static const struct drm_encoder_helper_funcs hibmc_encoder_helper_funcs = {
+   .mode_set = hibmc_encoder_mode_set,
+   .disable = hibmc_encoder_disable,
+   .enable = hibmc_encoder_enable,
+   .atomic_check = hibmc_encoder_atomic_check,
+};
+
+static const struct drm_encoder_funcs hibmc_encoder_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+int hibmc_encoder_init(struct drm_device *dev)
+{
+   struct hibmc_private *hiprivate = dev->dev_private;
+   struct drm_encoder *encoder = >encoder;
+   int ret;
+
+   encoder->possible_crtcs = 0x1;
+   ret = drm_encoder_init(dev, encoder, _encoder_encoder_funcs,
+  DRM_MODE_ENCODER_DAC, NULL);
+   if (ret) {
+   DRM_ERROR("failed to init encoder\n");
+   return ret;
+   }
+
+   drm_encoder_helper_add(encoder, _encoder_helper_funcs);
+   return 0;
+}
+
-- 
1.9.1

[PATCH 3/7] drm/hisilicon:Add crtc for DE

[lijianhua]

Add crtc funcs and helper funcs for DE.

Signed-off-by: lijianhua 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 279 
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h  |  20 ++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |   6 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |   1 +
 4 files changed, 306 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 35a675c..5d3ed66 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -18,6 +18,7 @@

 #include "hibmc_drm_drv.h"
 #include "hibmc_drm_hw.h"
+#include "hibmc_drm_de.h"

 /* -- */

@@ -156,3 +157,281 @@ int hibmc_plane_init(struct drm_device *dev)
return 0;
 }

+static void hibmc_crtc_enable(struct drm_crtc *crtc)
+{
+   unsigned int reg;
+   /* power mode 0 is default. */
+   set_power_mode(POWER_MODE_CTRL_MODE_MODE0);
+
+   /* Enable display power gate & LOCALMEM power gate*/
+   reg = PEEK32(CURRENT_GATE);
+   reg = FIELD_SET(reg, CURRENT_GATE, DISPLAY, ON);
+   reg = FIELD_SET(reg, CURRENT_GATE, LOCALMEM, ON);
+   set_current_gate(reg);
+}
+
+static void hibmc_crtc_disable(struct drm_crtc *crtc)
+{
+   unsigned int reg;
+
+   set_power_mode(POWER_MODE_CTRL_MODE_SLEEP);
+
+   /* Enable display power gate & LOCALMEM power gate*/
+   reg = PEEK32(CURRENT_GATE);
+   reg = FIELD_SET(reg, CURRENT_GATE, DISPLAY, OFF);
+   reg = FIELD_SET(reg, CURRENT_GATE, LOCALMEM, OFF);
+   set_current_gate(reg);
+}
+
+int hibmc_crtc_atomic_check(struct drm_crtc *crtc,
+   struct drm_crtc_state *state)
+{
+   return 0;
+}
+
+unsigned int format_pll_reg(void)
+{
+   unsigned int pllreg = 0;
+   struct panel_pll pll = {0};
+
+   /* Note that all PLL's have the same format. Here,
+ * we just use Panel PLL parameter to work out the bit
+ * fields in the register.On returning a 32 bit number, the value can
+ * be applied to any PLL in the calling function.
+ */
+   pllreg = FIELD_SET(0, PANEL_PLL_CTRL, BYPASS, OFF) |
+   FIELD_SET(0, PANEL_PLL_CTRL, POWER,  ON) |
+   FIELD_SET(0, PANEL_PLL_CTRL, INPUT,  OSC) |
+   FIELD_VALUE(0, PANEL_PLL_CTRL, POD,pll.POD) |
+   FIELD_VALUE(0, PANEL_PLL_CTRL, OD, pll.OD) |
+   FIELD_VALUE(0, PANEL_PLL_CTRL, N,  pll.N) |
+   FIELD_VALUE(0, PANEL_PLL_CTRL, M,  pll.M);
+
+   return pllreg;
+}
+
+void set_vclock_hisilicon(unsigned long pll)
+{
+   unsigned long tmp0, tmp1;
+
+/* 1. outer_bypass_n=0 */
+   tmp0 = PEEK32(CRT_PLL1_HS);
+   tmp0 &= 0xBFFF;
+   POKE32(CRT_PLL1_HS, tmp0);
+
+   /* 2. pll_pd=1?inter_bypass=1 */
+   POKE32(CRT_PLL1_HS, 0x2100);
+
+   /* 3. config pll */
+   POKE32(CRT_PLL1_HS, pll);
+
+   /* 4. delay  */
+   mdelay(1);
+
+   /* 5. pll_pd =0 */
+   tmp1 = pll & ~0x0100;
+   POKE32(CRT_PLL1_HS, tmp1);
+
+   /* 6. delay  */
+   mdelay(1);
+
+   /* 7. inter_bypass=0 */
+   tmp1 &= ~0x2000;
+   POKE32(CRT_PLL1_HS, tmp1);
+
+   /* 8. delay  */
+   mdelay(1);
+
+   /* 9. outer_bypass_n=1 */
+   tmp1 |= 0x4000;
+   POKE32(CRT_PLL1_HS, tmp1);
+}
+
+/* This function takes care the extra registers and bit fields required to
+*setup a mode in board.
+*Explanation about Display Control register:
+*FPGA only supports 7 predefined pixel clocks, and clock select is
+*in bit 4:0 of new register 0x802a8.
+*/
+unsigned int display_ctrl_adjust(struct drm_display_mode *mode,
+unsigned int ctrl)
+{
+   unsigned long x, y;
+   unsigned long pll1; /* bit[31:0] of PLL */
+   unsigned long pll2; /* bit[63:32] of PLL */
+
+   x = mode->hdisplay;
+   y = mode->vdisplay;
+
+   /* Hisilicon has to set up a new register for PLL control
+*(CRT_PLL1_HS & CRT_PLL2_HS).
+*/
+   if (x == 800 && y == 600) {
+   pll1 = CRT_PLL1_HS_40MHZ;
+   pll2 = CRT_PLL2_HS_40MHZ;
+   } else if (x == 1024 && y == 768) {
+   pll1 = CRT_PLL1_HS_65MHZ;
+   pll2 = CRT_PLL2_HS_65MHZ;
+   } else if (x == 1152 && y == 864) {
+   pll1 = CRT_PLL1_HS_80MHZ_1152;
+   pll2 = CRT_PLL2_HS_80MHZ;
+   } else if (x == 1280 && y == 768) {
+   pll1 = CRT_PLL1_HS_80MHZ;
+   pll2 = CRT_PLL2_HS_80MHZ;
+   } else if (x == 1280 && y == 720) {
+   pll1 = CRT_PLL1_HS_74MHZ;
+   pll2 = CRT_PLL2_HS_74MHZ;
+   } else if (x == 1280 && y == 960) {
+   pll1 = CRT_PLL1_HS_108MHZ;
+   pll2 = CRT_PLL2_HS_108MHZ;
+   } else if (x == 1280 && y == 1024) {
+   pll1 = 

[PATCH 2/7] drm/hisilicon:Add plane for DE

[lijianhua]

Add plane funcs and helper funcs for DE.

Signed-off-by: lijianhua 
---
 drivers/gpu/drm/hisilicon/hibmc/Makefile|   2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 158 
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |  48 +++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |   2 +
 4 files changed, 209 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index 28e59bb..bca651b 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,5 +1,5 @@
 ccflags-y := -Iinclude/drm
-hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_hw.o
+hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_hw.o

 obj-$(CONFIG_DRM_HISI_HIBMC)   +=hibmc-drm.o
 #obj-y += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
new file mode 100644
index 000..35a675c
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2016 Huawei Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hibmc_drm_drv.h"
+#include "hibmc_drm_hw.h"
+
+/* -- */
+
+static int
+hibmc_plane_prepare_fb(struct drm_plane *plane,
+  const struct drm_plane_state *new_state)
+{
+   /* do nothing */
+   return 0;
+}
+
+static void hibmc_plane_cleanup_fb(struct drm_plane *plane,
+  const struct drm_plane_state *old_state)
+{
+   /* do nothing */
+}
+
+static int hibmc_plane_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   struct drm_framebuffer *fb = state->fb;
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_crtc_state *crtc_state;
+   u32 src_x = state->src_x >> 16;
+   u32 src_y = state->src_y >> 16;
+   u32 src_w = state->src_w >> 16;
+   u32 src_h = state->src_h >> 16;
+   int crtc_x = state->crtc_x;
+   int crtc_y = state->crtc_y;
+   u32 crtc_w = state->crtc_w;
+   u32 crtc_h = state->crtc_h;
+
+   if (!crtc || !fb)
+   return 0;
+
+   crtc_state = drm_atomic_get_crtc_state(state->state, crtc);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+
+   if (src_w != crtc_w || src_h != crtc_h) {
+   DRM_ERROR("Scale not support!!!\n");
+   return -EINVAL;
+   }
+
+   if (src_x + src_w > fb->width ||
+   src_y + src_h > fb->height)
+   return -EINVAL;
+
+   if (crtc_x < 0 || crtc_y < 0)
+   return -EINVAL;
+
+   if (crtc_x + crtc_w > crtc_state->adjusted_mode.hdisplay ||
+   crtc_y + crtc_h > crtc_state->adjusted_mode.vdisplay)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void hibmc_plane_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+   struct drm_plane_state  *state  = plane->state;
+   u32 reg;
+   unsigned int line_length;
+
+   /* now just support one plane */
+   POKE32(CRT_FB_ADDRESS, 0);
+   reg = state->fb->width * (state->fb->bits_per_pixel >> 3);
+   /* now line_pad is 16 */
+   reg = PADDING(16, reg);
+
+   line_length = state->fb->width * state->fb->bits_per_pixel / 8;
+   line_length = PADDING(16, line_length);
+   POKE32(CRT_FB_WIDTH,
+  FIELD_VALUE(0, CRT_FB_WIDTH, WIDTH, reg) |
+ FIELD_VALUE(0, CRT_FB_WIDTH, OFFSET, line_length));
+
+   /* SET PIXEL FORMAT */
+   reg = PEEK32(CRT_DISPLAY_CTRL);
+   reg = FIELD_VALUE(reg, CRT_DISPLAY_CTRL,
+ FORMAT, state->fb->bits_per_pixel >> 4);
+   POKE32(CRT_DISPLAY_CTRL, reg);
+}
+
+static void hibmc_plane_atomic_disable(struct drm_plane *plane,
+  struct drm_plane_state *old_state)
+{
+}
+
+static const u32 channel_formats1[] = {
+   DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888, DRM_FORMAT_XRGB, DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGBA, DRM_FORMAT_BGRA, DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR
+};
+
+static struct drm_plane_funcs hibmc_plane_funcs = {
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .destroy = drm_plane_cleanup,
+   .reset = 

[PATCH 1/7] drm/hisilicon:Add hisilicon hibmc master driver.

[lijianhua]

Add hibmc DRM master driver for hi1710 which used in arm64 board.

Signed-off-by: lijianhua 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/hisilicon/Kconfig   |   4 +
 drivers/gpu/drm/hisilicon/Makefile  |   4 +
 drivers/gpu/drm/hisilicon/hibmc/Kconfig |  13 +
 drivers/gpu/drm/hisilicon/hibmc/Makefile|   5 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 301 +++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |  49 +++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.c  |  83 
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.h  | 484 
 10 files changed, 946 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8ae7ab6..600f94d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -269,3 +269,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"

 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/hisilicon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766de..6055483 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-y  += hisilicon/
diff --git a/drivers/gpu/drm/hisilicon/Kconfig 
b/drivers/gpu/drm/hisilicon/Kconfig
new file mode 100644
index 000..1f10e17
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -0,0 +1,4 @@
+# hisilicon drm device configuration.
+# Please keep this sorted alphabetically.
+
+source "drivers/gpu/drm/hisilicon/hibmc/Kconfig"
diff --git a/drivers/gpu/drm/hisilicon/Makefile 
b/drivers/gpu/drm/hisilicon/Makefile
new file mode 100644
index 000..487d5b0
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -0,0 +1,4 @@
+# Makefile for hisilicon drm drivers.
+# Please keep this list sorted alphabetically
+
+obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc/
\ No newline at end of file
diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig 
b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
new file mode 100644
index 000..c60ace6
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
@@ -0,0 +1,13 @@
+config DRM_HISI_HIBMC
+   tristate "DRM Support for hisilicon hibmc dispi vga interface"
+   depends on DRM && PCI
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   help
+ Choose this option for qemu.
+ If M is selected the module will be called hibmc-drm.
diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
new file mode 100644
index 000..28e59bb
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -0,0 +1,5 @@
+ccflags-y := -Iinclude/drm
+hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_hw.o
+
+obj-$(CONFIG_DRM_HISI_HIBMC)   +=hibmc-drm.o
+#obj-y += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
new file mode 100644
index 000..444ced8
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -0,0 +1,301 @@
+/*
+ * Copyright (c) 2016 Huawei Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hibmc_drm_drv.h"
+#include "hibmc_drm_hw.h"
+
+unsigned char __iomem *mmio_bmc_vga;
+
+static const struct file_operations hibmc_fops = {
+   .owner  = THIS_MODULE,
+   .open   = drm_open,
+   .release= drm_release,
+   .unlocked_ioctl = drm_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = drm_compat_ioctl,
+#endif
+   .poll   = drm_poll,
+   .read   = drm_read,
+   .llseek = no_llseek,
+};
+
+int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   return 0;
+}
+
+void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+}
+
+static struct 

[PATCH 0/7] Add DRM driver for Hisilicon hi1710

[lijianhua]

This patch set adds a new drm driver for Hisilicon hi1710.
hi1710 is an BMC controller, and now we use it in arm64 board.
In this patch set, we just support basic function for hi1710 display subsystem.
hi1710 display subsytem is connected to arm64 by PCIe as bellow:

+-++---+
| |  PCIe  |   hi1710  |
|  arm64  |<-->|  display  |
| || subsystem |
+-++---+

Hardware Detail for hi1710 display subsystem

  The display sybsystem of hi1710 is show as bellow:
  ++ +--+ +--+ ++
  || |  | |  | ||
  | FB |>|  DE  |>| VDAC |>|  External  |
  || |  | |  | |VGA |
  ++ +--+ +--+ ++

 - DE(Display Engine) is the display controller.
 - VDAC(Video Digital-to-Analog Converter) converts the RGB digital data stream 
 from DE to VGA analog signals. 

lijianhua (7):
  drm/hisilicon:Add hisilicon hibmc master driver.
  drm/hisilicon:Add plane for DE
  drm/hisilicon:Add crtc for DE
  drm/hisilicon:Add encoder for VDAC
  drm/hisilicon:Add connector for VDAC
  drm/hisilicon:Add fbdev
  MAINTAINERS:Add maintainer for hibmc DRM driver

 MAINTAINERS   |   7 +
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/hisilicon/Kconfig |   4 +
 drivers/gpu/drm/hisilicon/Makefile|   4 +
 drivers/gpu/drm/hisilicon/hibmc/Kconfig   |  13 +
 drivers/gpu/drm/hisilicon/hibmc/Makefile  |   5 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 437 +++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h|  20 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 374 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |  56 +++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 290 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.c|  83 
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.h| 484 ++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c  | 162 
 15 files changed, 1942 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_hw.h
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c

-- 
1.9.1

[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Emil Velikov]

Hi Gustavo,

On 27 February 2016 at 15:25, Gustavo Padovan
 wrote:
> Hi Emil,
>
> 2016-02-27 Emil Velikov :
>
>> Hi Gustavo,
>>
>> On 26 February 2016 at 21:00, Gustavo Padovan  wrote:
>> > From: Gustavo Padovan 
>> >
>> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
>> > optimize buffer allocation. In the new approach the ioctl needs to be 
>> > called
>> > twice to retrieve the array of fence_infos pointed by 
>> > info->sync_fence_info.
>> >
>> I might have misunderstood things but I no one says you "need" to call
>> it twice - you can just request a "random" amount of fences_info. Upon
>> return (if num_fences was non zero) it will report how many fence_info
>> were retrieved.
>
> Right, I don't see any problem doing it in one request, I just didn't
> think about that in the new proposal. I'll update the code and commit
> message accordinly.
>
>>
>> > The first call should pass num_fences = 0, the kernel will then fill
>> > info->num_fences. Userspace receives back the number of fences and
>> > allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
>> > info->sync_fence_info.
>> >
>> > It then call the ioctl again passing num_fences received in 
>> > info->num_fences.
>> "calls"
>>
>> > The kernel checks if info->num_fences > 0 and if yes it fill
>> > info->sync_fence_info with an array containing all fence_infos.
>> >
>> The above sentence sounds a bit strange. I believe you meant to say
>> something like "Then the kernel fills the fence_infos array with data.
>> One should read back the actual number from info->num_fences." ?
>>
>> > info->len now represents the length of the buffer sync_fence_info points
>> > to.
>> Now that I think about it, I'm wondering if there'll be a case where
>> len != info->num_fences * sizeof(struct sync_file_info). If that's not
>> possible one could just drop len and nicely simplify things.
>>
>> > Also, info->sync_fence_info was converted to __u64 pointer.
>> >
>> ... pointer to prevent 32bit compatibility issues.
>>
>> > An example userspace code would be:
>> >
>> > struct sync_file_info *info;
>> > int err, size, num_fences;
>> >
>> > info = malloc(sizeof(*info));
>> >
>> > memset(info, 0, sizeof(*info));
>> >
>> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>> > num_fences = info->num_fences;
>> >
>> > if (num_fences) {
>> > memset(info, 0, sizeof(*info));
>> > size = sizeof(struct sync_fence_info) * num_fences;
>> > info->len = size;
>> > info->num_fences = num_fences;
>> > info->sync_fence_info = (uint64_t) calloc(num_fences,
>> >   sizeof(struct 
>> > sync_fence_info));
>> >
>> > err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>> > }
>> >
>> > v2: fix fence_info memory leak
>> >
>> > Signed-off-by: Gustavo Padovan 
>> > ---
>> >  drivers/staging/android/sync.c  | 52 
>> > +
>> >  drivers/staging/android/uapi/sync.h |  9 +++
>> >  2 files changed, 45 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/staging/android/sync.c 
>> > b/drivers/staging/android/sync.c
>> > index dc5f382..2379f23 100644
>> > --- a/drivers/staging/android/sync.c
>> > +++ b/drivers/staging/android/sync.c
>> > @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, 
>> > void *data, int size)
>> >  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>> > unsigned long arg)
>> >  {
>> > -   struct sync_file_info *info;
>> > +   struct sync_file_info in, *info;
>> > +   struct sync_fence_info *fence_info = NULL;
>> > __u32 size;
>> > __u32 len = 0;
>> > int ret, i;
>> >
>> > -   if (copy_from_user(, (void __user *)arg, sizeof(size)))
>> > +   if (copy_from_user(, (void __user *)arg, sizeof(*info)))
>> s/*info/in/
>>
>> > return -EFAULT;
>> >
>> > -   if (size < sizeof(struct sync_file_info))
>> > -   return -EINVAL;
>> > +   if (in.status || strcmp(in.name, "\0"))
>> Afaict these two are outputs, so we should be checking them ?
>
> Hmm. Maybe not.
>
>>
>> > +   return -EFAULT;
>> >
>> As originally, input validation should return -EINVAL on error.
>>
>>
>> > -   if (size > 4096)
>> > -   size = 4096;
>> > +   if (in.num_fences && !in.sync_fence_info)
>> > +   return -EFAULT;
>> >
>> Ditto.
>>
>> > -   info = kzalloc(size, GFP_KERNEL);
>> > +   info = kzalloc(sizeof(*info), GFP_KERNEL);
>> > if (!info)
>> > return -ENOMEM;
>> >
>> > @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct 
>> > sync_file *sync_file,
>> > if (info->status >= 0)
>> > info->status = !info->status;
>> >
>> > -   info->num_fences = sync_file->num_fences;

[PATCH v5 5/5] drm/exynos: add support for blending properties

[Inki Dae]

2016년 01월 27일 23:44에 Marek Szyprowski 이(가) 쓴 글:
> This patch adds support for blending related properties to Exynos DRM
> core and Exynos Mixer CRTC device.

To drm-misc.

Acked-by : Inki Dae 

Thanks,
Inki Dae

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  5 +++
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 60 
> +++
>  2 files changed, 65 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 816537886e4e..b33d69b8bb38 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -92,6 +92,9 @@ struct exynos_drm_plane {
>  #define EXYNOS_DRM_PLANE_CAP_DOUBLE  (1 << 0)
>  #define EXYNOS_DRM_PLANE_CAP_SCALE   (1 << 1)
>  #define EXYNOS_DRM_PLANE_CAP_ZPOS(1 << 2)
> +#define EXYNOS_DRM_PLANE_CAP_PLANE_ALPHA (1 << 3)
> +#define EXYNOS_DRM_PLANE_CAP_PREMULT_ALPHA   (1 << 4)
> +#define EXYNOS_DRM_PLANE_CAP_BLENDING(1 << 5)
>  
>  /*
>   * Exynos DRM plane configuration structure.
> @@ -100,6 +103,7 @@ struct exynos_drm_plane {
>   * @type: type of the plane (primary, cursor or overlay).
>   * @pixel_formats: supported pixel formats.
>   * @num_pixel_formats: number of elements in 'pixel_formats'.
> + * @blending_mode: default blending mode.
>   * @capabilities: supported features (see EXYNOS_DRM_PLANE_CAP_*)
>   */
>  
> @@ -108,6 +112,7 @@ struct exynos_drm_plane_config {
>   enum drm_plane_type type;
>   const uint32_t *pixel_formats;
>   unsigned int num_pixel_formats;
> + unsigned int blending_mode;
>   unsigned int capabilities;
>  };
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 3a486939168e..28502aac135f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -140,6 +140,9 @@ static void exynos_drm_plane_reset(struct drm_plane 
> *plane)
>   plane->state = _state->base;
>   plane->state->plane = plane;
>   plane->state->zpos = exynos_plane->config->zpos;
> + plane->state->alpha = 255;
> + plane->state->alpha_premult = 1;
> + plane->state->blending = exynos_plane->config->blending_mode;
>   }
>  }
>  
> @@ -284,6 +287,53 @@ static void exynos_plane_attach_zpos_property(struct 
> drm_plane *plane,
>   drm_object_attach_property(>base, prop, zpos);
>  }
>  
> +static void exynos_plane_attach_alpha_property(struct drm_plane *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + if (!dev->mode_config.alpha_property)
> + if (drm_mode_create_alpha_property(dev, 255))
> + return;
> +
> + drm_object_attach_property(>base,
> +dev->mode_config.alpha_property, 255);
> +}
> +
> +static void exynos_plane_attach_alpha_premult_property(struct drm_plane 
> *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + if (!dev->mode_config.alpha_premult_property)
> + if (drm_mode_create_alpha_premult_property(dev)) {
> + printk("failed to create alpha premult property\n");
> + return;
> + }
> +
> + drm_object_attach_property(>base,
> +dev->mode_config.alpha_premult_property, 1);
> +}
> +
> +static void exynos_plane_attach_blending_property(struct drm_plane *plane,
> +   unsigned int blending_mode)
> +{
> + struct drm_device *dev = plane->dev;
> + static unsigned int blending_modes[] = {
> + DRM_BLEND_DISABLED,
> + DRM_BLEND_PIXEL_ALPHA,
> + DRM_BLEND_CONST_ALPHA,
> + DRM_BLEND_PIXEL_CONST_ALPHA,
> + };
> +
> + if (!dev->mode_config.blending_property)
> + if (drm_mode_create_blending_property(dev, blending_modes,
> + ARRAY_SIZE(blending_modes)))
> + return;
> +
> + drm_object_attach_property(>base,
> +dev->mode_config.blending_property,
> +blending_mode);
> +}
> +
>  int exynos_plane_init(struct drm_device *dev,
> struct exynos_drm_plane *exynos_plane,
> unsigned int index, unsigned long possible_crtcs,
> @@ -310,5 +360,15 @@ int exynos_plane_init(struct drm_device *dev,
>   exynos_plane_attach_zpos_property(_plane->base, config->zpos,
>  !(config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS));
>  
> + if (config->capabilities & EXYNOS_DRM_PLANE_CAP_PLANE_ALPHA)
> + exynos_plane_attach_alpha_property(_plane->base);
> +
> + if (config->capabilities & EXYNOS_DRM_PLANE_CAP_PREMULT_ALPHA)
> + exynos_plane_attach_alpha_premult_property(_plane->base);
> +

[Intel-gfx] i915 Skylake: "Invalid ROM contents"

[Andy Lutomirski]

On Sun, Jan 10, 2016 at 11:12 AM, Andy Lutomirski  
wrote:
> On Sun, Jan 10, 2016 at 10:41 AM, Andy Lutomirski  
> wrote:
>> On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone  
>> wrote:
>>> Hi,
>>>
>>> On 18 November 2015 at 15:59, Andy Lutomirski  
>>> wrote:
 On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
  wrote:
> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>> Typing:
>>
>> # cat /sys/devices/pci:00/:00:02.0/rom
>>
>> Provokes:
>>
>> i915 :00:02.0: Invalid ROM contents
>
> Hmm. So there's no PCI option ROM there. I wonder what is there. I
> get the same on my Braswell BTW. I tried to look through the UEFI
> spec a bit, and it seems to say that even for non-legacy option ROMs
> the 0x55aa signature should be there.
>
> But this being the GPU means we may be using the shadow ROM stuff,
> which IIRC assumes that the shadow is at 0xc000. I'm not sure that
> holds anymore with UEFI, and maybe we should be using some UEFI
> trick instead to find out where it actually lives?
>
> BTW what does 'lspci -vv -s 00:02.0' say on your machine?
>

 00:02.0 VGA compatible controller: Intel Corporation Sky Lake
 Integrated Graphics (rev 07) (prog-if 00 [VGA controller])
 DeviceName:  Onboard IGD
 Subsystem: Dell Device 0704
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
 SERR- >>> Latency: 0
 Interrupt: pin A routed to IRQ 128
 Region 0: Memory at db00 (64-bit, non-prefetchable) [size=16M]
 Region 2: Memory at 9000 (64-bit, prefetchable) [size=256M]
 Region 4: I/O ports at f000 [size=64]
 Expansion ROM at  [disabled]
>>>
>>> UEFI has an option to enable option ROMs, which is disabled by
>>> default; I wonder if having it disabled prevents all access to the
>>> ROM.
>>>
>>> Mind you, it doesn't seem to be fatal; I've not had any issues with
>>> the same machine that I can pin down to lack of ROM.
>>>
>>
>> FWIW, my logs also get spammed with:
>>
>> [  127.101881] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
>> has bogus alignment
>>
>> I suspect that the PCI core is just failing to recognize that the ROM
>> is disabled.
>>
>
> A bit more info:
>
> I think I only get this error when suspending for the second time
> after boot.  No clue why.
>
> I instrumented the code a bit.  At the time of that error, res->flags
> == 0x2.  It's probably not a coincidence that:
>
> #define IORESOURCE_ROM_SHADOW(1<<1)/* ROM is copy at C000:0 */
>
> Should pci_fixup_video check that the resource exists in the first
> place before setting flags on it?

*ping*

Hi, PCI people.

--Andy

[PATCH v5 2/5] drm/exynos: use generic code for managing zpos plane property

[Inki Dae]

2016년 01월 27일 23:44에 Marek Szyprowski 이(가) 쓴 글:
> This patch replaces zpos property handling custom code in Exynos DRM
> driver with calls to generic DRM code.

It'd be better to go to drm-misc.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 68 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
>  3 files changed, 20 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 17b5ded72ff1..816537886e4e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
>   struct exynos_drm_rect src;
>   unsigned int h_ratio;
>   unsigned int v_ratio;
> - unsigned int zpos;
>  };
>  
>  static inline struct exynos_drm_plane_state *
> @@ -217,7 +216,6 @@ struct exynos_drm_private {
>* this array is used to be aware of which crtc did it request vblank.
>*/
>   struct drm_crtc *crtc[MAX_CRTC];
> - struct drm_property *plane_zpos_property;
>  
>   unsigned long da_start;
>   unsigned long da_space_size;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index d86227236f55..3a486939168e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -137,9 +137,9 @@ static void exynos_drm_plane_reset(struct drm_plane 
> *plane)
>  
>   exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
>   if (exynos_state) {
> - exynos_state->zpos = exynos_plane->config->zpos;
>   plane->state = _state->base;
>   plane->state->plane = plane;
> + plane->state->zpos = exynos_plane->config->zpos;
>   }
>  }
>  
> @@ -155,7 +155,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
>   return NULL;
>  
>   __drm_atomic_helper_plane_duplicate_state(plane, >base);
> - copy->zpos = exynos_state->zpos;
>   return >base;
>  }
>  
> @@ -168,43 +167,6 @@ static void exynos_drm_plane_destroy_state(struct 
> drm_plane *plane,
>   kfree(old_exynos_state);
>  }
>  
> -static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
> - struct drm_plane_state *state,
> - struct drm_property *property,
> - uint64_t val)
> -{
> - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> - struct exynos_drm_plane_state *exynos_state =
> - to_exynos_plane_state(state);
> - struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> - const struct exynos_drm_plane_config *config = exynos_plane->config;
> -
> - if (property == dev_priv->plane_zpos_property &&
> - (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
> - exynos_state->zpos = val;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
> -   const struct drm_plane_state *state,
> -   struct drm_property *property,
> -   uint64_t *val)
> -{
> - const struct exynos_drm_plane_state *exynos_state =
> - container_of(state, const struct exynos_drm_plane_state, base);
> - struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> -
> - if (property == dev_priv->plane_zpos_property)
> - *val = exynos_state->zpos;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
>  static struct drm_plane_funcs exynos_plane_funcs = {
>   .update_plane   = drm_atomic_helper_update_plane,
>   .disable_plane  = drm_atomic_helper_disable_plane,
> @@ -213,8 +175,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
>   .reset  = exynos_drm_plane_reset,
>   .atomic_duplicate_state = exynos_drm_plane_duplicate_state,
>   .atomic_destroy_state = exynos_drm_plane_destroy_state,
> - .atomic_set_property = exynos_drm_plane_atomic_set_property,
> - .atomic_get_property = exynos_drm_plane_atomic_get_property,
>  };
>  
>  static int
> @@ -302,20 +262,23 @@ static const struct drm_plane_helper_funcs 
> plane_helper_funcs = {
>  };
>  
>  static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
> -   unsigned int zpos)
> +   unsigned int zpos, bool immutable)
>  {
>   struct drm_device *dev = plane->dev;
> - struct exynos_drm_private *dev_priv = dev->dev_private;
>   struct 

[PATCH v4 5/5] staging/android: add flags member to sync ioctl structs

[Emil Velikov]

On 27 February 2016 at 15:27, Gustavo Padovan
 wrote:
> Hi Emil,
>
> 2016-02-27 Emil Velikov :
>
>> Hi Gustavo,
>>
>> On 26 February 2016 at 18:31, Gustavo Padovan  wrote:
>> > From: Gustavo Padovan 
>> >
>> > Play safe and add flags member to all structs. So we don't need to
>> > break API or create new IOCTL in the future if new features that requires
>> > flags arises.
>> >
>> > v2: check if flags are valid (zero, in this case)
>> >
>> > Signed-off-by: Gustavo Padovan 
>> > ---
>> >  drivers/staging/android/sync.c  | 7 ++-
>> >  drivers/staging/android/uapi/sync.h | 6 ++
>> >  2 files changed, 12 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/staging/android/sync.c 
>> > b/drivers/staging/android/sync.c
>> > index 837cff5..54fd5ab 100644
>> > --- a/drivers/staging/android/sync.c
>> > +++ b/drivers/staging/android/sync.c
>> > @@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
>> > *sync_file,
>> > goto err_put_fd;
>> > }
>> >
>> > +   if (data.flags) {
>> > +   err = -EFAULT;
>> -EINVAL ?
>>
>> > +   goto err_put_fd;
>> > +   }
>> > +
>> > fence2 = sync_file_fdget(data.fd2);
>> > if (!fence2) {
>> > err = -ENOENT;
>> > @@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct 
>> > sync_file *sync_file,
>> > if (copy_from_user(, (void __user *)arg, sizeof(*info)))
>> > return -EFAULT;
>> >
>> > -   if (in.status || strcmp(in.name, "\0"))
>> > +   if (in.status || in.flags || strcmp(in.name, "\0"))
>> > return -EFAULT;
>> -EINVAL ?
>>
>> >
>> > if (in.num_fences && !in.sync_fence_info)
>> > diff --git a/drivers/staging/android/uapi/sync.h 
>> > b/drivers/staging/android/uapi/sync.h
>> > index 9aad623..f56a6c2 100644
>> > --- a/drivers/staging/android/uapi/sync.h
>> > +++ b/drivers/staging/android/uapi/sync.h
>> > @@ -19,11 +19,13 @@
>> >   * @fd2:   file descriptor of second fence
>> >   * @name:  name of new fence
>> >   * @fence: returns the fd of the new fence to userspace
>> > + * @flags: merge_data flags
>> >   */
>> >  struct sync_merge_data {
>> > __s32   fd2;
>> > charname[32];
>> > __s32   fence;
>> > +   __u32   flags;
>> The overall size of the struct is not multiple of 64bit, so things
>> will end up badly if we decide to extend it in the future. Even if
>> there's a small chance that update will be needed, we might as well
>> pad it now (and check the padding for zero, returning -EINVAL).
>
> I think name could be the first field here.
>
Up-to you really. I'm afraid that it doesn't resolve the issue :-(
As a test add a u64 value at the end of the struct and check the
output of pahole for 32 and 64 bit build.

>>
>> >  };
>> >
>> >  /**
>> > @@ -31,12 +33,14 @@ struct sync_merge_data {
>> >   * @obj_name:  name of parent sync_timeline
>> >   * @driver_name:   name of driver implementing the parent
>> >   * @status:status of the fence 0:active 1:signaled <0:error
>> > + * @flags: fence_info flags
>> >   * @timestamp_ns:  timestamp of status change in nanoseconds
>> >   */
>> >  struct sync_fence_info {
>> > charobj_name[32];
>> > chardriver_name[32];
>> > __s32   status;
>> > +   __u32   flags;
>> > __u64   timestamp_ns;
>> Should we be doing some form of validation in sync_fill_fence_info()
>> of 'flags' ?
>
> Do you think it is necessary? The kernel allocates a zero'ed buffer to
> fill sync_fence_info array.
>
Good point. Missed out the z in kzalloc :-)

-Emil

[PATCH 11/12] drm/dp: Read AUX read interval from DPCD

[Thierry Reding]

On Tue, Dec 15, 2015 at 11:38:10AM +0100, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 01:56:03PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > Store the AUX read interval from DPCD, so that it can be used to wait
> > for the durations given in the specification during link training.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c |  4 
> >  include/drm/drm_dp_helper.h | 17 +
> >  2 files changed, 21 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 76ac68bc1042..da519acfeba7 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -339,6 +339,7 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
> > link->max_lanes = 0;
> >  
> > drm_dp_link_caps_reset(>caps);
> > +   link->aux_rd_interval = 0;
> > link->edp = 0;
> >  
> > link->rate = 0;
> > @@ -392,6 +393,9 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
> > drm_dp_link *link)
> > link->edp = edp_revs[value];
> > }
> >  
> > +   /* DP_TRAINING_AUX_RD_INTERVAL is in units of 4 milliseconds */
> > +   link->aux_rd_interval = drm_dp_aux_rd_interval(values);
> 
> Hm, just wondering a bit of the relationship between link and cap. Is link
> all about sink really, and not the source? At least in my experience it
> makes a lot of sense to strictly keep these two separate, since otherwise
> you'll have lots of fun aligning things in generic code. Anyway, just a
> thougth.

The idea is that the link is the intersection between sink and source
capabilities. Drivers are supposed to call drm_dp_link_probe() to obtain
the capabilities of the sink and then adjust the struct drm_dp_link
according to their limitations (e.g. decrease the maximum rate if they
don't support 5.4 GHz, reduce the number of lanes if they only support
two, ...).

Once that's done the drivers can call drm_dp_link_choose() to select the
"best" set of configuration parameters given the link capabilities.

Note that this is strictly deriven from reading the specification under
the assumption that this is how things work in real life. My, arguably
limited, experience with Tegra shows that this is true. But perhaps that
is overly naive.

But I'd like to better understand what other drivers require so that
these helpers can be improved and be useful by more than a single
driver. Currently every driver implements their own DP stack, which I
think is rather unfortunate because we end up with vastly different
behaviour depending on which driver is in use.

Of course if that's what's desired, I'm more than happy to move this
code into the Tegra driver. I might have to duplicate the code that's
shared with MSM, but it's really not a lot compared to what's coming
up.

> > +
> > link->rate = link->max_rate;
> > link->lanes = link->max_lanes;
> >  
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 825aaf4e8c71..20ae0e413b64 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -678,6 +678,22 @@ drm_dp_alternate_scrambler_reset_cap(const u8 
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > DP_ALTERNATE_SCRAMBLER_RESET_CAP;
> >  }
> >  
> > +/**
> > + * drm_dp_read_aux_interval() - read the AUX read interval from the DPCD
> > + * @dpcd: receiver capacity buffer
> > + *
> > + * Reads the AUX read interval (in microseconds) from the DPCD. Note that 
> > the
> > + * TRAINING_AUX_RD_INTERVAL stores the value in units of 4 milliseconds.
> > + *
> > + * Returns:
> > + * The read AUX interval in microseconds.
> > + */
> > +static inline unsigned int
> > +drm_dp_aux_rd_interval(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> 
> We should use this one here in the 2 delay helpers for channel_eq and
> clock_recovery imo.

Agreed.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160229/3be6cf9b/attachment.sig>

[PATCH 12/12] drm/dp: Add drm_dp_link_choose() helper

[Thierry Reding]

On Sun, Jan 31, 2016 at 04:39:51PM +0200, Jani Nikula wrote:
> On Mon, 14 Dec 2015, Thierry Reding  wrote:
> > From: Thierry Reding 
> >
> > This helper chooses an appropriate configuration, according to the
> > bitrate requirements of the video mode and the capabilities of the
> > DisplayPort sink.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 55 
> > +
> >  include/drm/drm_dp_helper.h |  5 
> >  2 files changed, 60 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index da519acfeba7..95825155dc89 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -512,6 +512,61 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, 
> > struct drm_dp_link *link)
> >  }
> >  EXPORT_SYMBOL(drm_dp_link_configure);
> >  
> > +/**
> > + * drm_dp_link_choose() - choose the lowest possible configuration for a 
> > mode
> > + * @link: DRM DP link object
> > + * @mode: DRM display mode
> > + * @info: DRM display information
> > + *
> > + * According to the eDP specification, a source should select a 
> > configuration
> > + * with the lowest number of lanes and the lowest possible link rate that 
> > can
> > + * match the bitrate requirements of a video mode. However it must ensure 
> > not
> > + * to exceed the capabilities of the sink.
> 
> Eventually this would have to take into account the intersection of
> per-sink and per-source supported rates, including the intermediate
> frequencies. Until then, i915 couldn't switch over.

I'm not sure I understand what you're saying. The idea is that drivers
will call the drm_dp_link_probe() helper to probe the sink for supported
frequencies, number of lanes and capabilities.

After that, drivers are supposed to adjust the maximum values to account
for their limitations. Hence the name for struct drm_dp_*link*, because
it contains the negotiated parameters for the link between source and
sink.

That seems to me like the logical procedure when following the spec. Is
that not how i915 works?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160229/4a80c4ed/attachment.sig>