[PATCH v3 1/6] dt-bindings: add LG LP097QX1-SPA1 panel binding

2016-07-07 Thread Thierry Reding
On Thu, Jul 07, 2016 at 11:55:23PM +0200, Thierry Reding wrote:
> On Sun, Jun 12, 2016 at 10:53:30AM +0800, Yakir Yang wrote:
> > The LG LP097QX1-SPA1 is an 9.7", 2048x1536 (QXGA) TFT-LCD panel
> > connected using eDP interfaces.
> > 
> > Signed-off-by: Yakir Yang 
> > Acked-by: Rob Herring 
> > ---
> > Changes in v3: None
> > Changes in v2:
> > - Add Rob's acked for dt-bindings of LG LP097QX1-SPA1 panel
> > 
> >  .../devicetree/bindings/display/panel/lg,lp097qx1-spa1.txt | 7 
> > +++
> >  1 file changed, 7 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/lg,lp097qx1-spa1.txt
> 
> Applied all six patches, though I modified 3/6 as Doug suggested.

I mean patch 4/6, of course.

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/20160707/9e7f3ccd/attachment.sig>


[PATCH v3 1/6] dt-bindings: add LG LP097QX1-SPA1 panel binding

2016-07-07 Thread Thierry Reding
On Sun, Jun 12, 2016 at 10:53:30AM +0800, Yakir Yang wrote:
> The LG LP097QX1-SPA1 is an 9.7", 2048x1536 (QXGA) TFT-LCD panel
> connected using eDP interfaces.
> 
> Signed-off-by: Yakir Yang 
> Acked-by: Rob Herring 
> ---
> Changes in v3: None
> Changes in v2:
> - Add Rob's acked for dt-bindings of LG LP097QX1-SPA1 panel
> 
>  .../devicetree/bindings/display/panel/lg,lp097qx1-spa1.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,lp097qx1-spa1.txt

Applied all six patches, though I modified 3/6 as Doug suggested.

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/20160707/524e7120/attachment.sig>


[PATCH v1 2/5] drm/panel: simple: Add support for LG LP079QX1-SP0V 1536x2048 panel

2016-07-07 Thread Thierry Reding
On Tue, Jun 28, 2016 at 12:51:15PM +0800, Yakir Yang wrote:
> The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
> 32 pins eDP interface. This module supports 1536x2048 mode.
> 
> Signed-off-by: Yakir Yang 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 26 ++
>  1 file changed, 26 insertions(+)

Applied, thanks.

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/20160707/21518cd6/attachment.sig>


[PATCH v1 1/5] dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel

2016-07-07 Thread Thierry Reding
On Tue, Jun 28, 2016 at 12:51:12PM +0800, Yakir Yang wrote:
> The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
> 32 pins eDP interface. This module supports 1536x2048 mode.
> 
> Signed-off-by: Yakir Yang 
> ---
>  .../devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt

Applied, thanks.

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/20160707/eda340cd/attachment.sig>


next-20160707 build: 1 failures 6 warnings (next-20160707)

2016-07-07 Thread Tomasz Figa
Hi Mark,

On Thu, Jul 7, 2016 at 9:22 PM, Mark Brown  wrote:
> On Thu, Jul 07, 2016 at 10:23:56AM +0100, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
>>   arm64-allmodconfig
>> ../drivers/gpu/drm/rockchip/rockchip_drm_drv.c:17:27: fatal error: 
>> asm/dma-iommu.h: No such file or directory
>
> triggered by c51f43a9c171ea (iommu/rockchip: Enable Rockchip IOMMU on
> ARM64) which enables the Rockchip IOMMU driver on ARM64 which lacks the
> above header.  Either the use of the header needs to be removed or an
> explicit ARM64 dependency added at the DRM level.

Looks like next is missing the DRM side of the series, which makes the
driver in question not need this header anymore.

This is probably because we missed this hidden dependency and decided
to push the IOMMU part separately through the IOMMU tree. I guess we
can remove the offending patch from the IOMMU tree and let the DRM
tree include it based on a topic branch from Joerg.

Joerg, David, Mark Yao, what do you think?

Best regards,
Tomasz


[PATCH] drm/vc4: Implement precise vblank timestamping.

2016-07-07 Thread Eric Anholt
.

Want to respin using reads of the regs?  Reading them once at
initialization of the HVS should be fine.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160707/c5f3b115/attachment-0001.sig>


[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-07-07 Thread Ville Syrjälä
On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > Cc: Ville
> > > 
> > > On Mon, 20 Jun 2016, James Bottomley <
> > > James.Bottomley at HansenPartnership.com> wrote:
> > > > OK, my candidate bad commit is this one:
> > > > 
> > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > Author: Ville Syrjälä 
> > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > 
> > > > drm/i915: Get panel_type from OpRegion panel details
> > > > 
> > > > After being more careful about waiting to identify flicker, this 
> > > > one seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > > with this one reverted and am currently seeing no flicker problems.
> > > >   It is, however, early days because the flicker can hide for long 
> > > > periods, so I 'll wait until Monday evening and a few reboots 
> > > > before declaring victory.
> > > 
> > > If that turns out to be the bad commit, it doesn't really surprise 
> > > me, and that in itself is depressing.
> > 
> > As far as I can tell, after running for a day with this reverted, this
> > is the problem.  The flicker hasn't appeared with it reverted.  It's
> > pretty noticeable with this commit included.
> 
> Hmm. The only difference I can see is low vs. normal vswing. Panel 0 has
> low, panel 2 has normal. So either the VBT or opregion is telling utter
> lies, or there's some other bug in our low vswing support.

I did a quick once over of out DDI vswing stuff and didn't find anything
too serious. There were some buglets in the iboost handling, but I'm not
very hopeful that fixing those would help with your machine.

Here's a branch anyway in case you want to give it a go:
git://github.com/vsyrjala/linux.git ddi_iboost_fixes

Actually, I think the only patch in there that might make a difference is
15d887855180 ("drm/i915: Fix iboost setting for DDI with 4 lanes on SKL")

-- 
Ville Syrjälä
Intel OTC


[PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

2016-07-07 Thread Ard Biesheuvel
The 100c08 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)

So move the dma_map_page() to the .init hook, and set the streaming DMA
mask based on the MMU subdev parameters before performing the call.

Signed-off-by: Ard Biesheuvel 
---
I am sure there is a much better way to address this, but this fixes the
problem I get on AMD Seattle with a GeForce 210 PCIe card:

   nouveau :02:00.0: enabling device ( -> 0003)
   nouveau :02:00.0: NVIDIA GT218 (0a8280b1)
   nouveau :02:00.0: bios: version 70.18.a6.00.00
   nouveau :02:00.0: fb ctor failed, -14
   nouveau: probe of :02:00.0 failed with error -14

v2: replace incorrect comparison of dma_addr_t type var against NULL
v3: rework code to get rid of DMA_ERROR_CODE references, which is not
defined on all architectures

 drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 40 ++--
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
index 1b5fb02eab2a..f713cb3fe56c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
@@ -216,11 +216,33 @@ nv50_fb_init(struct nvkm_fb *base)
struct nv50_fb *fb = nv50_fb(base);
struct nvkm_device *device = fb->base.subdev.device;

+   if (!fb->r100c08) {
+   /* We are calling the DMA api way before the TTM layer sets the
+* DMA mask based on the MMU subdev parameters. This means we
+* are using the default DMA mask of 32, which may cause
+* problems on systems with no RAM below the 4 GB mark. So set
+* the streaming DMA mask here as well.
+*/
+   dma_addr_t addr;
+
+   dma_set_mask(device->dev, DMA_BIT_MASK(device->mmu->dma_bits));
+
+   addr = dma_map_page(device->dev, fb->r100c08_page, 0, PAGE_SIZE,
+   DMA_BIDIRECTIONAL);
+   if (!dma_mapping_error(device->dev, addr)) {
+   fb->r100c08 = addr;
+   } else {
+   nvkm_warn(&fb->base.subdev,
+ "dma_map_page() failed on 100c08 page\n");
+   }
+   }
+
/* Not a clue what this is exactly.  Without pointing it at a
 * scratch page, VRAM->GART blits with M2MF (as in DDX DFS)
 * cause IOMMU "read from address 0" errors (rh#561267)
 */
-   nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8);
+   if (fb->r100c08)
+   nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8);

/* This is needed to get meaningful information from 100c90
 * on traps. No idea what these values mean exactly. */
@@ -233,11 +255,11 @@ nv50_fb_dtor(struct nvkm_fb *base)
struct nv50_fb *fb = nv50_fb(base);
struct nvkm_device *device = fb->base.subdev.device;

-   if (fb->r100c08_page) {
+   if (fb->r100c08)
dma_unmap_page(device->dev, fb->r100c08, PAGE_SIZE,
   DMA_BIDIRECTIONAL);
-   __free_page(fb->r100c08_page);
-   }
+
+   __free_page(fb->r100c08_page);

return fb;
 }
@@ -264,13 +286,9 @@ nv50_fb_new_(const struct nv50_fb_func *func, struct 
nvkm_device *device,
*pfb = &fb->base;

fb->r100c08_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
-   if (fb->r100c08_page) {
-   fb->r100c08 = dma_map_page(device->dev, fb->r100c08_page, 0,
-  PAGE_SIZE, DMA_BIDIRECTIONAL);
-   if (dma_mapping_error(device->dev, fb->r100c08))
-   return -EFAULT;
-   } else {
-   nvkm_warn(&fb->base.subdev, "failed 100c08 page alloc\n");
+   if (!fb->r100c08_page) {
+   nvkm_error(&fb->base.subdev, "failed 100c08 page alloc\n");
+   return -ENOMEM;
}

return 0;
-- 
2.7.4



[PATCH v5 4/4] drm: rcar: use generic code for managing zpos plane property

2016-07-07 Thread Laurent Pinchart
Hi Benjamin,

Thank you for the patch.

The git://linuxtv.org/media_tree.git vsp1 branch will be merged in v4.8 and 
will conflict with this series. If you target v4.8 you should rebase the 
patches on top of that branch.

For your convenience I've pushed a branch in which I've resolved the conflicts 
for v4 of your patches series to

git://linuxtv.org/pinchartl/media.git drm/du/zorder

On Thursday 07 Jul 2016 15:01:24 Benjamin Gaignard wrote:
> version 4:
> fix null pointer issue while setting zpos in plane reset function
> 
> This patch replaces zpos property handling custom code in rcar DRM
> driver with calls to generic DRM code.
> 
> Signed-off-by: Benjamin Gaignard 
> 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Laurent Pinchart 
> Cc: Marek Szyprowski 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 5 -
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
>  drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
>  5 files changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 0d8bdda..28d2cb6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,
> 
>  static unsigned int plane_zpos(struct rcar_du_plane *plane)
>  {
> - return to_rcar_plane_state(plane->plane.state)->zpos;
> + return plane->plane.state->normalized_zpos;
>  }
> 
>  static const struct rcar_du_format_info *
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index ed35467..c843c31 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -92,7 +92,6 @@ struct rcar_du_device {
>   struct {
>   struct drm_property *alpha;
>   struct drm_property *colorkey;
> - struct drm_property *zpos;
>   } props;
> 
>   unsigned int dpad0_source;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 6bb032d..f03eb55 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct
> rcar_du_device *rcdu) if (rcdu->props.colorkey == NULL)
>   return -ENOMEM;
> 
> - rcdu->props.zpos =
> - drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
> - if (rcdu->props.zpos == NULL)
> - return -ENOMEM;
> -
>   return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index bfe31ca..dc9bb96 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -652,7 +652,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
> state->source = RCAR_DU_PLANE_MEMORY;
>   state->alpha = 255;
>   state->colorkey = RCAR_DU_COLORKEY_NONE;
> - state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> + state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> 
>   plane->state = &state->state;
>   plane->state->plane = plane;
> @@ -670,8 +670,6 @@ static int rcar_du_plane_atomic_set_property(struct
> drm_plane *plane, rstate->alpha = val;
>   else if (property == rcdu->props.colorkey)
>   rstate->colorkey = val;
> - else if (property == rcdu->props.zpos)
> - rstate->zpos = val;
>   else
>   return -EINVAL;
> 
> @@ -690,8 +688,6 @@ static int rcar_du_plane_atomic_get_property(struct
> drm_plane *plane, *val = rstate->alpha;
>   else if (property == rcdu->props.colorkey)
>   *val = rstate->colorkey;
> - else if (property == rcdu->props.zpos)
> - *val = rstate->zpos;
>   else
>   return -EINVAL;
> 
> @@ -763,8 +759,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
>   drm_object_attach_property(&plane->plane.base,
>  rcdu->props.colorkey,
>  RCAR_DU_COLORKEY_NONE);
> - drm_object_attach_property(&plane->plane.base,
> -rcdu->props.zpos, 1);
> + drm_plane_create_zpos_property(&plane->plane, 1, 7);
>   }
> 
>   return 0;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h index b18b7b2..8b91dd3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> @@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
> drm_plane *plane) * @hwindex: 0-based hardware plane index, -1 means unused
>   * @alpha: value of the plane alpha property
>   * @colorkey: value of the plane colorkey property
> - * @zpos: value of the pla

[PATCH 2/2] drm: vc4: enable XBGR8888 and ABGR8888 pixel formats

2016-07-07 Thread Eric Anholt
Eric Anholt  writes:

> Rob Herring  writes:
>
>> DRM_FORMAT_XBGR and DRM_FORMAT_ABGR are 2 of the native formats
>> used in Android, so enable them for VC4. There seems to be no logic behind
>> HVS_PIXEL_ORDER_ naming, but HVS_PIXEL_ORDER_ARGB seems to work
>> correctly.
>
> Spent a little bit digging into how the pixel orderings work and didn't
> come up with an answer.  I'll try to look into this one again later.

Never came up with a good answer, but it's rendering correctly in
modetest, so I've reviewed and applied it to drm-vc4-next.

Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160707/690f680e/attachment.sig>


[PATCH 7/7] gpu: drm: vc4_hdmi: add missing of_node_put after calling of_parse_phandle

2016-07-07 Thread Eric Anholt
Peter Chen  writes:

> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
>
> Cc: Eric Anholt 
> Signed-off-by: Peter Chen 

Applied this to drm-vc4-next.  Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160707/a8374225/attachment.sig>


[PATCH v2 2/3] drm: Add API for capturing frame CRCs

2016-07-07 Thread Ville Syrjälä
On Thu, Jul 07, 2016 at 05:06:08PM +0200, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
> 
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
> 
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
> 
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
>   generation gets enabled for the first time.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
>  Documentation/gpu/drm-uapi.rst|   6 +
>  drivers/gpu/drm/Makefile  |   3 +-
>  drivers/gpu/drm/drm_crtc.c|  11 ++
>  drivers/gpu/drm/drm_debugfs.c |  36 +++-
>  drivers/gpu/drm/drm_debugfs_crc.c | 394 
> ++
>  drivers/gpu/drm/drm_drv.c |   9 +
>  drivers/gpu/drm/drm_internal.h|  10 +
>  include/drm/drmP.h|   5 +
>  include/drm/drm_crtc.h|  40 
>  include/drm/drm_debugfs_crc.h |  71 +++
>  10 files changed, 583 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
>  create mode 100644 include/drm/drm_debugfs_crc.h
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 536bf3eaadd4..33f778696ccd 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -109,3 +109,9 @@ interfaces. Especially since all hardware-acceleration 
> interfaces to
>  userspace are driver specific for efficiency and other reasons these
>  interfaces can be rather substantial. Hence every driver has its own
>  chapter.
> +
> +Testing and validation
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> +   :doc: CRC ABI
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index e3dba6f44a79..b53b5aaaeb4d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -12,7 +12,8 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>   drm_info.o drm_debugfs.o drm_encoder_slave.o \
>   drm_trace_points.o drm_global.o drm_prime.o \
>   drm_rect.o drm_vma_manager.o drm_flip_work.o \
> - drm_modeset_lock.o drm_atomic.o drm_bridge.o
> + drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> + drm_debugfs_crc.o
>  
>  drm-$(CONFIG_COMPAT) += drm_ioc32.o
>  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 10b73f68c023..48155e0439df 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -738,6 +739,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   if (cursor)
>   cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
>  
> +#ifdef CONFIG_DEBUG_FS
> + spin_lock_init(&crtc->crc.lock);
> + init_waitqueue_head(&crtc->crc.wq);
> +#endif
> +
>   if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>   drm_object_attach_property(&crtc->base, config->prop_active, 0);
>   drm_object_attach_property(&crtc->base, config->prop_mode_id, 
> 0);
> @@ -764,6 +770,11 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
>* the indices on the drm_crtc after us in the crtc_list.
>*/
>  
> +#ifdef CONFIG_DEBUG_FS
> + drm_debugfs_crtc_remove(crtc);
> + kfree(crtc->crc.source);
> +#endif
> +
>   kfree(crtc->gamma_store);
>   crtc->gamma_store = NULL;
>  
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index fa10cef2ba37..73530cbf1316 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -415,5 +415,39 @@ void drm_debugfs_connector_remove(struct drm_connector 
> *connector)
>   connector->debugfs_entry = NULL;
>  }
>  
> -#endif /* CONFIG_DEBUG_FS */
> +int drm_debugfs_crtc_add(struct drm_crtc *crtc)
> +{
> + struct drm_minor *minor = crtc->dev->primary;
> + struct dentry *root;
> + char *name;
> +
> + name = kasprintf(GFP_KERNEL, "crtc-%d", crtc->index);
> + if (!name)
> + return -ENOMEM;
>  
> + root = debugfs_create_dir(name, minor->debugfs_root);
> + kfree(name);
> + if (!root)
> + return -ENOMEM;
> +
> + crtc->debugfs_entry = root;
> +
> + if (drm_debugfs_crtc_crc_add(crtc))
> + goto error;
> +
> + return 0;
> +
> +error:
> + debugfs_remove_recursive(crtc->debugfs_entry);
> + crtc->debugfs_entry = NULL;
> + return -ENOMEM;
> +}
> +
> +void drm_debugfs_crtc_remove(struct drm_crtc *crtc)
> +{
> + debugfs_remove_re

[PATCH v5 0/4] Generic zpos property

2016-07-07 Thread Tobias Jakobi
Benjamin Gaignard wrote:
> zpos new fields are correctly documented in drm-kms.html after running
> make htmldocs.
I'm not sure I understand. Where does htmldocs get the information from
then?

- Tobias


> Benjamin
> 
> 2016-07-07 16:01 GMT+02:00 Tobias Jakobi :
>> Hello Benjamin,
>>
>>
>> Benjamin Gaignard wrote:
>>> version 5:
>>> rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't
>>> exist anymore.
>> I think the documentation has just moved to Documentation/gpu, so the
>> zpos property should be documented there then.
>>
>>
>> With best wishes,
>> Tobias
>>
>>
>>> rework sti patch because some plane functions have changed since v4
>>>
>>> version 4:
>>> make sure that normalized zpos value is stay in the defined property
>>> range and warn user if not.
>>> Fix NULL pointer bug in rcar-du while setting zpos value.
>>> No changes in the other drivers.
>>>
>>> version 3:
>>> use kmalloc_array instead of kmalloc.
>>> Correct normalize_zpos computation (comeback to Mareck original code)
>>>
>>> version 2:
>>> add a zpos property into drm_plane structure to simplify code.
>>> This allow to get/set zpos value in core and not in drivers code.
>>> Fix various remarks.
>>>
>>> version 1:
>>> refactor Marek's patches to have per plane zpos property instead of only
>>> one in core.
>>>
>>> Benjamin Gaignard (2):
>>>   drm: sti: use generic zpos for plane
>>>   drm: rcar: use generic code for managing zpos plane property
>>>
>>> Marek Szyprowski (2):
>>>   drm: add generic zpos property
>>>   drm/exynos: use generic code for managing zpos plane property
>>>
>>>  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   |   4 +
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
>>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
>>>  drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
>>>  drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
>>>  drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
>>>  drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
>>>  drivers/gpu/drm/sti/sti_gdp.c |   4 +-
>>>  drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
>>>  drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
>>>  drivers/gpu/drm/sti/sti_plane.c   |  76 --
>>>  drivers/gpu/drm/sti/sti_plane.h   |   7 +-
>>>  include/drm/drm_crtc.h|  30 
>>>  20 files changed, 324 insertions(+), 147 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/drm_blend.c
>>>
>>> Cc: Inki Dae 
>>> Cc: Daniel Vetter 
>>> Cc: Ville Syrjala 
>>> Cc: Joonyoung Shim 
>>> Cc: Seung-Woo Kim 
>>> Cc: Andrzej Hajda 
>>> Cc: Krzysztof Kozlowski 
>>> Cc: Bartlomiej Zolnierkiewicz 
>>> Cc: Tobias Jakobi 
>>> Cc: Gustavo Padovan 
>>> Cc: vincent.abriou at st.com
>>> Cc: fabien.dessenne at st.com
>>> Cc: Laurent Pinchart 
>>>
>>
> 
> 
> 



next-20160707 build: 1 failures 6 warnings (next-20160707)

2016-07-07 Thread Joerg Roedel
On Thu, Jul 07, 2016 at 10:18:02PM +0900, Tomasz Figa wrote:
> This is probably because we missed this hidden dependency and decided
> to push the IOMMU part separately through the IOMMU tree. I guess we
> can remove the offending patch from the IOMMU tree and let the DRM
> tree include it based on a topic branch from Joerg.
> 
> Joerg, David, Mark Yao, what do you think?

Will the DRM patches go upstream soon, or is there still discussion
around them? For now I am going to remove/revert that patch in my tree.


Joerg


[PATCH v5 0/4] Generic zpos property

2016-07-07 Thread Benjamin Gaignard
zpos new fields are correctly documented in drm-kms.html after running
make htmldocs.

Benjamin

2016-07-07 16:01 GMT+02:00 Tobias Jakobi :
> Hello Benjamin,
>
>
> Benjamin Gaignard wrote:
>> version 5:
>> rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't
>> exist anymore.
> I think the documentation has just moved to Documentation/gpu, so the
> zpos property should be documented there then.
>
>
> With best wishes,
> Tobias
>
>
>> rework sti patch because some plane functions have changed since v4
>>
>> version 4:
>> make sure that normalized zpos value is stay in the defined property
>> range and warn user if not.
>> Fix NULL pointer bug in rcar-du while setting zpos value.
>> No changes in the other drivers.
>>
>> version 3:
>> use kmalloc_array instead of kmalloc.
>> Correct normalize_zpos computation (comeback to Mareck original code)
>>
>> version 2:
>> add a zpos property into drm_plane structure to simplify code.
>> This allow to get/set zpos value in core and not in drivers code.
>> Fix various remarks.
>>
>> version 1:
>> refactor Marek's patches to have per plane zpos property instead of only
>> one in core.
>>
>> Benjamin Gaignard (2):
>>   drm: sti: use generic zpos for plane
>>   drm: rcar: use generic code for managing zpos plane property
>>
>> Marek Szyprowski (2):
>>   drm: add generic zpos property
>>   drm/exynos: use generic code for managing zpos plane property
>>
>>  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   |   4 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
>>  drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
>>  drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
>>  drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
>>  drivers/gpu/drm/sti/sti_gdp.c |   4 +-
>>  drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
>>  drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
>>  drivers/gpu/drm/sti/sti_plane.c   |  76 --
>>  drivers/gpu/drm/sti/sti_plane.h   |   7 +-
>>  include/drm/drm_crtc.h|  30 
>>  20 files changed, 324 insertions(+), 147 deletions(-)
>>  create mode 100644 drivers/gpu/drm/drm_blend.c
>>
>> Cc: Inki Dae 
>> Cc: Daniel Vetter 
>> Cc: Ville Syrjala 
>> Cc: Joonyoung Shim 
>> Cc: Seung-Woo Kim 
>> Cc: Andrzej Hajda 
>> Cc: Krzysztof Kozlowski 
>> Cc: Bartlomiej Zolnierkiewicz 
>> Cc: Tobias Jakobi 
>> Cc: Gustavo Padovan 
>> Cc: vincent.abriou at st.com
>> Cc: fabien.dessenne at st.com
>> Cc: Laurent Pinchart 
>>
>



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog


[PATCH] backlight: Avoid double fbcon backlight handling

2016-07-07 Thread joeyli
On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
> Backlights controlled by i915.ko and only associated with its connectors
> and also only associated with the intel_drmfb fbcon, controlled by
> i915.ko. In this situation, we already handle adjusting the backlight
> when the fbcon is blanked/unblanked and do not require backlight trying
> to do the same.
> 
> Attempting to register with the fbdev as a client causes lockdep to warn
> about a dependency cycle:
> 
> [   18.983763] ==
> [   18.983763] [ INFO: possible circular locking dependency detected ]
> [   18.983766] 4.7.0-rc5+ #524 Tainted: G   O
> [   18.983767] ---
> [   18.983767] kworker/u8:0/6 is trying to acquire lock:
> [   18.983777]  (&dev->mode_config.mutex){+.+.+.}, at: [] 
> drm_modeset_lock_all+0x40/0x120
> [   18.983777]
>but task is already holding lock:
> [   18.983782]  ((fb_notifier_list).rwsem){.+}, at: [] 
> __blocking_notifier_call_chain+0x35/0x70
> [   18.983783]
>which lock already depends on the new lock.
> 
> [   18.983783]
>the existing dependency chain (in reverse order) is:
> [   18.983785]
>-> #1 ((fb_notifier_list).rwsem){.+}:
> [   18.983789][] lock_acquire+0xb1/0x200
> [   18.983792][] down_write+0x44/0x80
> [   18.983795][] 
> blocking_notifier_chain_register+0x21/0xb0
> [   18.983798][] fb_register_client+0x18/0x20
> [   18.983800][] 
> backlight_device_register+0x136/0x260
> [   18.983852][] 
> intel_backlight_device_register+0xa2/0x160 [i915]
> [   18.983892][] intel_connector_register+0xe/0x10 
> [i915]
> [   18.983932][] 
> intel_dp_connector_register+0x1b/0x80 [i915]
> [   18.983936][] drm_connector_register+0x4a/0x80
> [   18.983938][] 
> drm_connector_register_all+0x64/0xf0
> [   18.983940][] 
> drm_modeset_register_all+0x174/0x1c0
> [   18.983942][] drm_dev_register+0xc2/0xd0
> [   18.983976][] i915_driver_load+0x1547/0x2200 
> [i915]
> [   18.984010][] i915_pci_probe+0x4f/0x70 [i915]
> [   18.984014][] local_pci_probe+0x45/0xa0
> [   18.984015][] pci_device_probe+0xdb/0x130
> [   18.984018][] driver_probe_device+0x223/0x440
> [   18.984020][] __driver_attach+0xd5/0x100
> [   18.984022][] bus_for_each_dev+0x66/0xa0
> [   18.984023][] driver_attach+0x1e/0x20
> [   18.984025][] bus_add_driver+0x1ee/0x280
> [   18.984028][] driver_register+0x60/0xe0
> [   18.984030][] __pci_register_driver+0x60/0x70
> [   18.984063][] i915_init+0x5b/0x62 [i915]
> [   18.984067][] do_one_initcall+0x3d/0x150
> [   18.984070][] do_init_module+0x5f/0x1d9
> [   18.984073][] load_module+0x20e6/0x27e0
> [   18.984075][] SYSC_finit_module+0xc3/0xf0
> [   18.984076][] SyS_finit_module+0xe/0x10
> [   18.984079][] entry_SYSCALL_64_fastpath+0x1c/0xac
> [   18.984081]
>-> #0 (&dev->mode_config.mutex){+.+.+.}:
> [   18.984083][] __lock_acquire+0x10fc/0x1260
> [   18.984085][] lock_acquire+0xb1/0x200
> [   18.984088][] mutex_lock_nested+0x67/0x3c0
> [   18.984090][] drm_modeset_lock_all+0x40/0x120
> [   18.984093][] 
> drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
> [   18.984095][] drm_fb_helper_set_par+0x2d/0x50
> [   18.984134][] intel_fbdev_set_par+0x1a/0x60 
> [i915]
> [   18.984136][] fbcon_init+0x586/0x610
> [   18.984139][] visual_init+0xca/0x130
> [   18.984141][] do_bind_con_driver+0x1c1/0x3a0
> [   18.984143][] do_take_over_console+0x116/0x180
> [   18.984145][] do_fbcon_takeover+0x57/0xb0
> [   18.984147][] fbcon_event_notify+0x658/0x750
> [   18.984150][] notifier_call_chain+0x3e/0xb0
> [   18.984152][] 
> __blocking_notifier_call_chain+0x4d/0x70
> [   18.984154][] 
> blocking_notifier_call_chain+0x16/0x20
> [   18.984156][] fb_notifier_call_chain+0x1b/0x20
> [   18.984158][] register_framebuffer+0x251/0x330
> [   18.984160][] 
> drm_fb_helper_initial_config+0x25f/0x3f0
> [   18.984199][] 
> intel_fbdev_initial_config+0x18/0x30 [i915]
> [   18.984201][] async_run_entry_fn+0x48/0x150
> [   18.984203][] process_one_work+0x1e7/0x750
> [   18.984205][] worker_thread+0x4b/0x4f0
> [   18.984207][] kthread+0xef/0x110
> [   18.984208][] ret_from_fork+0x1f/0x40
> [   18.984209]
>other info that might help us debug this:
> 
> [   18.984210]  Possible unsafe locking scenario:
> 
> [   18.984210]CPU0CPU1
> [   18.984211]
> [   18.984212]   lock((fb_notifier_list).rwsem);
> [   18.984213]lo

[PATCH v2 3/3] drm/i915: Use new CRC debugfs API

2016-07-07 Thread Tomeu Vizoso
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.

v2:
- Leave the legacy implementation in place as the ABI implementation
  in the core is incompatible with it.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/i915/i915_irq.c   | 57 ---
 drivers/gpu/drm/i915/intel_display.c  |  1 +
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 17 +++
 4 files changed, 51 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b77d808b71cd..1c5c6bdbb66c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1492,41 +1492,48 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
 {
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
+   struct drm_crtc *crtc = intel_get_crtc_for_pipe(&dev_priv->drm, pipe);
+   struct drm_driver *driver = dev_priv->drm.driver;
+   uint32_t frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
int head, tail;

-   spin_lock(&pipe_crc->lock);
+   if (pipe_crc->opened) {
+   spin_lock(&pipe_crc->lock);

-   if (!pipe_crc->entries) {
-   spin_unlock(&pipe_crc->lock);
-   DRM_DEBUG_KMS("spurious interrupt\n");
-   return;
-   }
+   if (!pipe_crc->entries) {
+   spin_unlock(&pipe_crc->lock);
+   DRM_DEBUG_KMS("spurious interrupt\n");
+   return;
+   }

-   head = pipe_crc->head;
-   tail = pipe_crc->tail;
+   head = pipe_crc->head;
+   tail = pipe_crc->tail;

-   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
-   spin_unlock(&pipe_crc->lock);
-   DRM_ERROR("CRC buffer overflowing\n");
-   return;
-   }
+   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+   spin_unlock(&pipe_crc->lock);
+   DRM_ERROR("CRC buffer overflowing\n");
+   return;
+   }

-   entry = &pipe_crc->entries[head];
+   entry = &pipe_crc->entries[head];

-   entry->frame = dev_priv->drm.driver->get_vblank_counter(&dev_priv->drm,
-pipe);
-   entry->crc[0] = crc0;
-   entry->crc[1] = crc1;
-   entry->crc[2] = crc2;
-   entry->crc[3] = crc3;
-   entry->crc[4] = crc4;
+   entry->frame = frame;
+   entry->crc[0] = crc0;
+   entry->crc[1] = crc1;
+   entry->crc[2] = crc2;
+   entry->crc[3] = crc3;
+   entry->crc[4] = crc4;

-   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
-   pipe_crc->head = head;
+   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+   pipe_crc->head = head;

-   spin_unlock(&pipe_crc->lock);
+   spin_unlock(&pipe_crc->lock);

-   wake_up_interruptible(&pipe_crc->wq);
+   wake_up_interruptible(&pipe_crc->wq);
+   } else {
+   drm_crtc_add_crc_entry(crtc, frame, crc0, crc1, crc2, crc3,
+  crc4);
+   }
 }
 #else
 static inline void
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 111b350d1d7e..d91a2f779fb1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14019,6 +14019,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
+   .set_crc_source = intel_crtc_set_crc_source,
 };

 /**
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5d06cb2425a1..4cd8689afe90 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1782,6 +1782,7 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state);
 /* intel_pipe_crc.c */
 int intel_pipe_crc_create(struct drm_minor *minor);
 void intel_pipe_crc_cleanup(struct drm_minor *minor);
+int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name);
 extern const struct file_operations i915_display_crc_ctl_fops;

 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 590e909bcf1b..51047ad37ffa 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -823,6 +823,11 @@ display_crc_ctl_parse_source(const char *buf, enum 
intel_pipe_crc_source *s)
 {
int i;


[PATCH v2 2/3] drm: Add API for capturing frame CRCs

2016-07-07 Thread Tomeu Vizoso
Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:

dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data

Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.

v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
  generation gets enabled for the first time.

Signed-off-by: Tomeu Vizoso 
---

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  11 ++
 drivers/gpu/drm/drm_debugfs.c |  36 +++-
 drivers/gpu/drm/drm_debugfs_crc.c | 394 ++
 drivers/gpu/drm/drm_drv.c |   9 +
 drivers/gpu/drm/drm_internal.h|  10 +
 include/drm/drmP.h|   5 +
 include/drm/drm_crtc.h|  40 
 include/drm/drm_debugfs_crc.h |  71 +++
 10 files changed, 583 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 536bf3eaadd4..33f778696ccd 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -109,3 +109,9 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+   :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e3dba6f44a79..b53b5aaaeb4d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,8 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
-   drm_modeset_lock.o drm_atomic.o drm_bridge.o
+   drm_modeset_lock.o drm_atomic.o drm_bridge.o \
+   drm_debugfs_crc.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 10b73f68c023..48155e0439df 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -738,6 +739,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
if (cursor)
cursor->possible_crtcs = 1 << drm_crtc_index(crtc);

+#ifdef CONFIG_DEBUG_FS
+   spin_lock_init(&crtc->crc.lock);
+   init_waitqueue_head(&crtc->crc.wq);
+#endif
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(&crtc->base, config->prop_active, 0);
drm_object_attach_property(&crtc->base, config->prop_mode_id, 
0);
@@ -764,6 +770,11 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
 * the indices on the drm_crtc after us in the crtc_list.
 */

+#ifdef CONFIG_DEBUG_FS
+   drm_debugfs_crtc_remove(crtc);
+   kfree(crtc->crc.source);
+#endif
+
kfree(crtc->gamma_store);
crtc->gamma_store = NULL;

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index fa10cef2ba37..73530cbf1316 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -415,5 +415,39 @@ void drm_debugfs_connector_remove(struct drm_connector 
*connector)
connector->debugfs_entry = NULL;
 }

-#endif /* CONFIG_DEBUG_FS */
+int drm_debugfs_crtc_add(struct drm_crtc *crtc)
+{
+   struct drm_minor *minor = crtc->dev->primary;
+   struct dentry *root;
+   char *name;
+
+   name = kasprintf(GFP_KERNEL, "crtc-%d", crtc->index);
+   if (!name)
+   return -ENOMEM;

+   root = debugfs_create_dir(name, minor->debugfs_root);
+   kfree(name);
+   if (!root)
+   return -ENOMEM;
+
+   crtc->debugfs_entry = root;
+
+   if (drm_debugfs_crtc_crc_add(crtc))
+   goto error;
+
+   return 0;
+
+error:
+   debugfs_remove_recursive(crtc->debugfs_entry);
+   crtc->debugfs_entry = NULL;
+   return -ENOMEM;
+}
+
+void drm_debugfs_crtc_remove(struct drm_crtc *crtc)
+{
+   debugfs_remove_recursive(crtc->debugfs_entry);
+
+   crtc->debugfs_entry = NULL;
+}
+
+#endif /* CONFIG_DEBUG_FS */
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
new file mode 100644
index ..7995600bebf0
--- /dev/null
+++ b/drivers/gpu/drm/drm

[PATCH v2 1/3] drm/i915/debugfs: Move out pipe CRC code

2016-07-07 Thread Tomeu Vizoso
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.

Eventually, only the Intel-specific code will remain in this new file.

v2: Rebased.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 892 +--
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 953 ++
 4 files changed, 963 insertions(+), 889 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 684fc1cd08fa..9419e0c2e2c0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -19,7 +19,7 @@ i915-y := i915_drv.o \
  intel_runtime_pm.o

 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
-i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o

 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a59e0caeda64..c37bfda32e53 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,19 +26,9 @@
  *
  */

-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include "intel_drv.h"
-#include "intel_ringbuffer.h"
-#include 
-#include "i915_drv.h"

 enum {
ACTIVE_LIST,
@@ -3490,12 +3480,6 @@ static int i915_drrs_status(struct seq_file *m, void 
*unused)
return 0;
 }

-struct pipe_crc_info {
-   const char *name;
-   struct drm_device *dev;
-   enum pipe pipe;
-};
-
 static int i915_dp_mst_info(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = (struct drm_info_node *) m->private;
@@ -3525,853 +3509,6 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
return 0;
 }

-static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = to_i915(info->dev);
-   struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
-
-   if (info->pipe >= INTEL_INFO(info->dev)->num_pipes)
-   return -ENODEV;
-
-   spin_lock_irq(&pipe_crc->lock);
-
-   if (pipe_crc->opened) {
-   spin_unlock_irq(&pipe_crc->lock);
-   return -EBUSY; /* already open */
-   }
-
-   pipe_crc->opened = true;
-   filep->private_data = inode->i_private;
-
-   spin_unlock_irq(&pipe_crc->lock);
-
-   return 0;
-}
-
-static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = to_i915(info->dev);
-   struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
-
-   spin_lock_irq(&pipe_crc->lock);
-   pipe_crc->opened = false;
-   spin_unlock_irq(&pipe_crc->lock);
-
-   return 0;
-}
-
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define PIPE_CRC_LINE_LEN  (6 * 8 + 5 + 1)
-/* account for \'0' */
-#define PIPE_CRC_BUFFER_LEN(PIPE_CRC_LINE_LEN + 1)
-
-static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
-{
-   assert_spin_locked(&pipe_crc->lock);
-   return CIRC_CNT(pipe_crc->head, pipe_crc->tail,
-   INTEL_PIPE_CRC_ENTRIES_NR);
-}
-
-static ssize_t
-i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
-  loff_t *pos)
-{
-   struct pipe_crc_info *info = filep->private_data;
-   struct drm_device *dev = info->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
-   char buf[PIPE_CRC_BUFFER_LEN];
-   int n_entries;
-   ssize_t bytes_read;
-
-   /*
-* Don't allow user space to provide buffers not big enough to hold
-* a line of data.
-*/
-   if (count < PIPE_CRC_LINE_LEN)
-   return -EINVAL;
-
-   if (pipe_crc->source == INTEL_PIPE_CRC_SOURCE_NONE)
-   return 0;
-
-   /* nothing to read */
-   spin_lock_irq(&pipe_crc->lock);
-   while (pipe_crc_data_count(pipe_crc) == 0) {
-   int ret;
-
-   if (filep->f_flags & O_NONBLOCK) {
-   spin_unlock_irq(&pipe_crc->lock);
-   return -EAGAIN;
-   }
-
-   ret = wait_event_interruptible_lock_irq(pipe_crc->wq,
-   pipe_crc_data_count(pipe_crc), pipe_crc->lock);
-   if (ret) {
-   spin_unlock_irq(&pipe_crc->lock);
-   return ret;
-   }
-   }
-
-   /* We now have one or more entries to read */
-   n_entries = count / PIPE_CRC_LINE_LEN

[PATCH v2 0/3] New debugfs API for capturing CRC of frames

2016-07-07 Thread Tomeu Vizoso
Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

Thanks,

Tomeu


Tomeu Vizoso (3):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  11 +
 drivers/gpu/drm/drm_debugfs.c |  36 +-
 drivers/gpu/drm/drm_debugfs_crc.c | 394 ++
 drivers/gpu/drm/drm_drv.c |   9 +
 drivers/gpu/drm/drm_internal.h|  10 +
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 892 +--
 drivers/gpu/drm/i915/i915_irq.c   |  57 +-
 drivers/gpu/drm/i915/intel_display.c  |   1 +
 drivers/gpu/drm/i915/intel_drv.h  |   6 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 970 ++
 include/drm/drmP.h|   5 +
 include/drm/drm_crtc.h|  40 ++
 include/drm/drm_debugfs_crc.h |  71 +++
 16 files changed, 1597 insertions(+), 916 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.5.5



[PATCH 0/7] de-stage SW_SYNC validation frawework

2016-07-07 Thread Gustavo Padovan
Hi Greg,

Any comment on this?

Thanks,

Gustavo

2016-06-20 Gustavo Padovan :

> From: Gustavo Padovan 
> 
> Hi Greg,
> 
> This is the last step in the Sync Framwork de-stage task. It de-stage
> the SW_SYNC validation framework and the sync_debug info debugfs file.
> 
> The first 3 patches are clean up and improvements and the rest is preparation
> to de-stage and then finally the actual de-stage.
> 
> Please review,
> 
> Gustavo
> 
> ---
> Gustavo Padovan (7):
>   staging/android: move trace/sync.h to sync_trace.h
>   staging/android: remove doc from sw_sync
>   staging/android: display sync_pt name on debugfs
>   staging/android: do not let userspace trigger WARN_ON
>   staging/android: prepare sw_sync files for de-staging
>   dma-buf/sw_sync: de-stage SW_SYNC
>   staging/android: remove sync framework TODO
> 
>  drivers/dma-buf/Kconfig| 14 +++
>  drivers/dma-buf/Makefile   |  1 +
>  drivers/{staging/android => dma-buf}/sw_sync.c | 46 
> +++---
>  drivers/{staging/android => dma-buf}/sync_debug.c  |  7 ++--
>  drivers/{staging/android => dma-buf}/sync_debug.h  | 26 +---
>  .../android/trace/sync.h => dma-buf/sync_trace.h}  |  6 +--
>  drivers/staging/android/Kconfig| 13 --
>  drivers/staging/android/Makefile   |  1 -
>  drivers/staging/android/TODO   |  8 
>  9 files changed, 38 insertions(+), 84 deletions(-)
>  rename drivers/{staging/android => dma-buf}/sw_sync.c (84%)
>  rename drivers/{staging/android => dma-buf}/sync_debug.c (97%)
>  rename drivers/{staging/android => dma-buf}/sync_debug.h (72%)
>  rename drivers/{staging/android/trace/sync.h => dma-buf/sync_trace.h} (84%)
> 
> -- 
> 2.5.5
> 



[Bug 96835] "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96835

--- Comment #6 from raffarti at zoho.com ---
Created attachment 124948
  --> https://bugs.freedesktop.org/attachment.cgi?id=124948&action=edit
steam gdb stack trace without gallium hud and mesa debug

-- 
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/20160707/70a9e12b/attachment-0001.html>


[Bug 96835] "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96835

--- Comment #5 from raffarti at zoho.com ---
Created attachment 124947
  --> https://bugs.freedesktop.org/attachment.cgi?id=124947&action=edit
steam gdb stack trace with gallium hud and mesa debug

-- 
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/20160707/5995c53d/attachment.html>


[Bug 96835] "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96835

--- Comment #4 from raffarti at zoho.com ---
The previous commit does just fine, this one does not.
I've found the traces to be different with and without the gallium hud, so I'm
attaching both traces.

-- 
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/20160707/bf96d748/attachment.html>


[PATCH] radeon and amdgpu drm-next-4.8

2016-07-07 Thread Alex Deucher
Hi Dave,

This is the main 4.8 pull for radeon and amdgpu.  Sorry for the delay,
I meant to send this out last week, but I was moving house.  Lots of
changes here:
- ATPX improvements for better dGPU power control on PX systems
- New power features for CZ/BR/ST
- Pipelined BO moves and evictions in TTM
- GPU scheduler improvements
- GPU reset improvements
- Overclocking on dGPUs with amdgpu
- Lots of code cleanup
- Bug fixes

The following changes since commit 5dd0775e502b26b44e5bcb5f504a977a565f2f3e:

  Merge tag 'asoc-hdmi-codec-pdata' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into drm-next 
(2016-07-05 09:57:23 +1000)

are available in the git repository at:

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

for you to fetch changes up to b1814a1def0564a2a1d3be7fa5bf7243ff899a28:

  drm/amd/powerplay: don't add invalid voltage. (2016-07-07 15:06:24 -0400)


Alex Deucher (49):
  drm/amdgpu: load different smc firmware on some CI variants
  drm/radeon: load different smc firmware on some SI variants
  drm/radeon: load different smc firmware on some CI variants
  drm/amdgpu/gfx7: expand cp jt size to handle GDS as well
  drm/radeon/gfx7: expand cp jt size to handle GDS as well
  drm/amdgpu/gfx8: add state setup for CZ/ST GFX power gating
  drm/amdgpu/gfx8: rename some pg functions
  drm/amdgpu: add new GFX powergating types
  drm/amdgpu/gfx8: add powergating support for CZ/ST
  drm/amdgpu/gfx8: clean up polaris11 PG enable
  drm/amdgpu: disable power control on hybrid laptops
  drm/amdgpu: clean up atpx power control handling
  drm/amdgpu: add a delay after ATPX dGPU power off
  drm/amdgpu/atpx: add a query for ATPX dGPU power control
  drm/amdgpu: use PCI_D3hot for PX systems without dGPU power control
  drm/amdgpu/atpx: drop forcing of dGPU power control
  drm/radeon: disable power control on hybrid laptops
  drm/radeon: clean up atpx power control handling
  drm/radeon: add a delay after ATPX dGPU power off
  drm/radeon/atpx: add a query for ATPX dGPU power control
  drm/radeon: use PCI_D3hot for PX systems without dGPU power control
  drm/radeon/atpx: drop forcing of dGPU power control
  drm/amdgpu/atpx: track whether if this is a hybrid graphics platform
  drm/amdgpu/atpx: hybrid platforms use d3cold
  drm/amdgpu: drop explicit pci D3/D0 setting for ATPX power control
  drm/radeon/atpx: track whether if this is a hybrid graphics platform
  drm/radeon/atpx: hybrid platforms use d3cold
  drm/radeon: drop explicit pci D3/D0 setting for ATPX power control
  drm/amdgpu: work around lack of upstream ACPI support for D3cold
  drm/radeon: work around lack of upstream ACPI support for D3cold
  drm/amdgpu: properly clean up runtime pm
  drm/amdgpu/gfx8: fix CP jump table size
  drm/amdgpu/gfx7: fix CP jump table size
  drm/radeon/cik: fix CP jump table size
  drm/amdgpu: disable compute pipeline sync workaround when using fixed fw
  drm/amdgpu/gmc: make some functions static
  drm/amdgpu: drop wait_for_mc_idle asic callback
  drm/amdgpu: move get_gpu_clock_counter into the gfx struct
  drm/amdgpu: move select_se_sh into the gfx struct
  drm/amdgpu/gfx7: switch to using the existing rlc callbacks
  drm/amdgpu/gfx7: make gfx_v7_0_rlc_stop static
  drm/amdgpu/dce11: update async flip update time
  drm/amdgpu/powerplay/cz: add missing call to powergate VCE
  drm/amdgpu: add IP helpers for wait_for_idle and is_idle
  drm/amdgpu: add missing breaks
  drm/amdgpu: skip invalid ip blocks in ip helpers
  drm/amdgpu/gmc8: remove duplicate wait_for_idle functions
  drm/amdgpu/gmc7: remove duplicate wait_for_idle functions
  drm/amdgpu: remove more of the ring backup code

Alex Xie (3):
  drm/amdgpu: Change some variable names to make code easier understood
  drm/amdgpu: Add comment to describe the purpose of one difficult if 
statement
  drm/amdgpu: Initialize the variables in a straight-forward way

Alexandre Demers (2):
  drm/amd/powerplay: fix trivial typo and tidy comment
  drm/amd/powerplay: fix typos in comment in polaris' hwmgr

Arindam Nath (2):
  drm/amd/amdgpu: make sure VCE is disabled by default
  drm/amd/powerplay: make sure VCE is disabled by default

Arnd Bergmann (1):
  amdgpu: use NULL instead of 0 for pointer

Christian König (44):
  drm/amdgpu: fix coding style in the scheduler v2
  drm/amdgpu: remove begin_job/finish_job
  drm/amdgpu: remove duplicated timeout callback
  drm/amdgpu: fix coding style in amdgpu_job_free
  drm/amdgpu: remove use_shed hack in job cleanup
  drm/amdgpu: properly abstract scheduler timeout handling
  drm/amdgpu: move locking into the functions who need it
  drm/amdgpu: fix and cleanup job destruction
  drm/amdgpu: document a

[PATCH 16/16] gpu: ipu-v3: rename CSI client device

2016-07-07 Thread Steve Longerbeam
Rename the CSI client device in the client_reg[] table to
"imx-ipuv3-csi".

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 374100e..bd6771b 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1153,14 +1153,14 @@ static struct ipu_platform_reg client_reg[] = {
.dma[0] = IPUV3_CHANNEL_CSI0,
.dma[1] = -EINVAL,
},
-   .name = "imx-ipuv3-camera",
+   .name = "imx-ipuv3-csi",
}, {
.pdata = {
.csi = 1,
.dma[0] = IPUV3_CHANNEL_CSI1,
.dma[1] = -EINVAL,
},
-   .name = "imx-ipuv3-camera",
+   .name = "imx-ipuv3-csi",
}, {
.pdata = {
.di = 0,
-- 
1.9.1



[PATCH 15/16] gpu: ipu-ic: allow multiple handles to ic

2016-07-07 Thread Steve Longerbeam
The image converter kernel API supports conversion contexts and
job queues, so we should allow more than one handle to the IC, so
that multiple users can add jobs to the queue.

Note however that users that control the IC manually (that do not
use the image converter APIs but setup the IC task by hand via calls
to ipu_ic_task_enable(), ipu_ic_enable(), etc.) must still be careful not
to share the IC handle with other threads. At this point, the only user
that still controls the IC manually is the i.mx capture driver. In that
case the capture driver only allows one open context to get a handle
to the IC at a time, so we should be ok there.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-ic.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index f6a1125..51e34a1 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -342,7 +342,6 @@ struct ipu_ic {
enum ipu_color_space out_cs;
bool graphics;
bool rotation;
-   bool in_use;

struct image_converter cvt;

@@ -2380,38 +2379,16 @@ EXPORT_SYMBOL_GPL(ipu_ic_disable);
 struct ipu_ic *ipu_ic_get(struct ipu_soc *ipu, enum ipu_ic_task task)
 {
struct ipu_ic_priv *priv = ipu->ic_priv;
-   unsigned long flags;
-   struct ipu_ic *ic, *ret;

if (task >= IC_NUM_TASKS)
return ERR_PTR(-EINVAL);

-   ic = &priv->task[task];
-
-   spin_lock_irqsave(&priv->lock, flags);
-
-   if (ic->in_use) {
-   ret = ERR_PTR(-EBUSY);
-   goto unlock;
-   }
-
-   ic->in_use = true;
-   ret = ic;
-
-unlock:
-   spin_unlock_irqrestore(&priv->lock, flags);
-   return ret;
+   return &priv->task[task];
 }
 EXPORT_SYMBOL_GPL(ipu_ic_get);

 void ipu_ic_put(struct ipu_ic *ic)
 {
-   struct ipu_ic_priv *priv = ic->priv;
-   unsigned long flags;
-
-   spin_lock_irqsave(&priv->lock, flags);
-   ic->in_use = false;
-   spin_unlock_irqrestore(&priv->lock, flags);
 }
 EXPORT_SYMBOL_GPL(ipu_ic_put);

-- 
1.9.1



[PATCH 14/16] gpu: ipu-ic: Add complete image conversion support with tiling

2016-07-07 Thread Steve Longerbeam
This patch implements complete image conversion support to ipu-ic,
with tiling to support scaling to and from images up to 4096x4096.
Image rotation is also supported.

The internal API is subsystem agnostic (no V4L2 dependency except
for the use of V4L2 fourcc pixel formats).

Callers prepare for image conversion by calling
ipu_image_convert_prepare(), which initializes the parameters of
the conversion. The caller passes in the ipu_ic task to use for
the conversion, the input and output image formats, a rotation mode,
and a completion callback and completion context pointer:

struct image_converter_ctx *
ipu_image_convert_prepare(struct ipu_ic *ic,
  struct ipu_image *in, struct ipu_image *out,
  enum ipu_rotate_mode rot_mode,
  image_converter_cb_t complete,
  void *complete_context);

The caller is given a new conversion context that must be passed to
the further APIs:

struct image_converter_run *
ipu_image_convert_run(struct image_converter_ctx *ctx,
  dma_addr_t in_phys, dma_addr_t out_phys);

This queues a new image conversion request to a run queue, and
starts the conversion immediately if the run queue is empty. Only
the physaddr's of the input and output image buffers are needed,
since the conversion context was created previously with
ipu_image_convert_prepare(). Returns a new run object pointer. When
the conversion completes, the run pointer is returned to the
completion callback.

void image_convert_abort(struct image_converter_ctx *ctx);

This will abort any active or pending conversions for this context.
Any currently active or pending runs belonging to this context are
returned via the completion callback with an error status.

void ipu_image_convert_unprepare(struct image_converter_ctx *ctx);

Unprepares the conversion context. Any active or pending runs will
be aborted by calling image_convert_abort().
---
 drivers/gpu/ipu-v3/ipu-ic.c | 1691 ++-
 include/video/imx-ipu-v3.h  |   57 +-
 2 files changed, 1736 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 5329bfe..f6a1125 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "ipu-prv.h"

 /* IC Register Offsets */
@@ -82,6 +84,40 @@
 #define IC_IDMAC_3_PP_WIDTH_MASK(0x3ff << 20)
 #define IC_IDMAC_3_PP_WIDTH_OFFSET  20

+/*
+ * The IC Resizer has a restriction that the output frame from the
+ * resizer must be 1024 or less in both width (pixels) and height
+ * (lines).
+ *
+ * The image conversion support attempts to split up a conversion when
+ * the desired output (converted) frame resolution exceeds the IC resizer
+ * limit of 1024 in either dimension.
+ *
+ * If either dimension of the output frame exceeds the limit, the
+ * dimension is split into 1, 2, or 4 equal stripes, for a maximum
+ * of 4*4 or 16 tiles. A conversion is then carried out for each
+ * tile (but taking care to pass the full frame stride length to
+ * the DMA channel's parameter memory!). IDMA double-buffering is used
+ * to convert each tile back-to-back when possible (see note below
+ * when double_buffering boolean is set).
+ *
+ * Note that the input frame must be split up into the same number
+ * of tiles as the output frame.
+ */
+#define MAX_STRIPES_W4
+#define MAX_STRIPES_H4
+#define MAX_TILES (MAX_STRIPES_W * MAX_STRIPES_H)
+
+#define MIN_W 128
+#define MIN_H 128
+#define MAX_W 4096
+#define MAX_H 4096
+
+enum image_convert_type {
+   IMAGE_CONVERT_IN = 0,
+   IMAGE_CONVERT_OUT,
+};
+
 struct ic_task_regoffs {
u32 rsc;
u32 tpmem_csc[2];
@@ -96,6 +132,16 @@ struct ic_task_bitfields {
u32 ic_cmb_galpha_bit;
 };

+struct ic_task_channels {
+   int in;
+   int out;
+   int rot_in;
+   int rot_out;
+   int vdi_in_p;
+   int vdi_in;
+   int vdi_in_n;
+};
+
 static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
[IC_TASK_ENCODER] = {
.rsc = IC_PRP_ENC_RSC,
@@ -138,12 +184,159 @@ static const struct ic_task_bitfields 
ic_task_bit[IC_NUM_TASKS] = {
},
 };

+static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
+   [IC_TASK_ENCODER] = {
+   .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
+   .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
+   .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
+   },
+   [IC_TASK_VIEWFINDER] = {
+   .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
+   .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
+   .rot_in = IPUV3_CHANNEL_MEM_ROT_VF,
+   .rot_out = IPUV3_CHANNEL_ROT_VF_MEM,
+   .vdi_in_p = IPUV3_CHANNEL_MEM_VDI_P,
+   .vdi_in = IPUV3_CHANNEL_MEM_VDI,
+   .vdi_in_n = IPUV3_CHANNEL_MEM_VDI_N,
+   }

[PATCH 13/16] gpu: ipu-v3: Fix IRT usage

2016-07-07 Thread Steve Longerbeam
There can be multiple IC tasks using the IRT, so the IRT needs
a separate use counter. Create a private ipu_irt_enable() to
enable the IRT module when any IC task requires rotation, and
ipu_irt_disable() when a task no longer needs the IRT.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-ic.c | 43 ++-
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index f306a9c..5329bfe 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -160,6 +160,7 @@ struct ipu_ic_priv {
spinlock_t lock;
struct ipu_soc *ipu;
int use_count;
+   int irt_use_count;
struct ipu_ic task[IC_NUM_TASKS];
 };

@@ -379,8 +380,6 @@ void ipu_ic_task_disable(struct ipu_ic *ic)

ipu_ic_write(ic, ic_conf, IC_CONF);

-   ic->rotation = ic->graphics = false;
-
spin_unlock_irqrestore(&priv->lock, flags);
 }
 EXPORT_SYMBOL_GPL(ipu_ic_task_disable);
@@ -639,22 +638,44 @@ int ipu_ic_set_src(struct ipu_ic *ic, int csi_id, bool 
vdi)
 }
 EXPORT_SYMBOL_GPL(ipu_ic_set_src);

+static void ipu_irt_enable(struct ipu_ic *ic)
+{
+   struct ipu_ic_priv *priv = ic->priv;
+
+   if (!priv->irt_use_count)
+   ipu_module_enable(priv->ipu, IPU_CONF_ROT_EN);
+
+   priv->irt_use_count++;
+}
+
+static void ipu_irt_disable(struct ipu_ic *ic)
+{
+   struct ipu_ic_priv *priv = ic->priv;
+
+   priv->irt_use_count--;
+
+   if (!priv->irt_use_count)
+   ipu_module_disable(priv->ipu, IPU_CONF_ROT_EN);
+
+   if (priv->irt_use_count < 0)
+   priv->irt_use_count = 0;
+}
+
 int ipu_ic_enable(struct ipu_ic *ic)
 {
struct ipu_ic_priv *priv = ic->priv;
unsigned long flags;
-   u32 module = IPU_CONF_IC_EN;

spin_lock_irqsave(&priv->lock, flags);

-   if (ic->rotation)
-   module |= IPU_CONF_ROT_EN;
-
if (!priv->use_count)
-   ipu_module_enable(priv->ipu, module);
+   ipu_module_enable(priv->ipu, IPU_CONF_IC_EN);

priv->use_count++;

+   if (ic->rotation)
+   ipu_irt_enable(ic);
+
spin_unlock_irqrestore(&priv->lock, flags);

return 0;
@@ -665,18 +686,22 @@ int ipu_ic_disable(struct ipu_ic *ic)
 {
struct ipu_ic_priv *priv = ic->priv;
unsigned long flags;
-   u32 module = IPU_CONF_IC_EN | IPU_CONF_ROT_EN;

spin_lock_irqsave(&priv->lock, flags);

priv->use_count--;

if (!priv->use_count)
-   ipu_module_disable(priv->ipu, module);
+   ipu_module_disable(priv->ipu, IPU_CONF_IC_EN);

if (priv->use_count < 0)
priv->use_count = 0;

+   if (ic->rotation)
+   ipu_irt_disable(ic);
+
+   ic->rotation = ic->graphics = false;
+
spin_unlock_irqrestore(&priv->lock, flags);

return 0;
-- 
1.9.1



[PATCH 12/16] gpu: ipu-v3: Fix CSI0 blur in NTSC format

2016-07-07 Thread Steve Longerbeam
From: Suresh Dhandapani 

This patch will change the register IPU_CSI0_CCIR_CODE_2 value from
0x40596 to 0x405A6. The change is related to the Start of field 1
first blanking line command bit[5-3] for NTSC format only. This
change is dependent with ADV chip where the NEWAVMODE is set to 0
in register 0x31. Setting NEWAVMODE to "0" in ADV means "EAV/SAV
codes generated to suit analog devices encoders".

Signed-off-by: Suresh Dhandapani 
---
 drivers/gpu/ipu-v3/ipu-csi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 0eac28c..ec81958 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -422,7 +422,7 @@ int ipu_csi_init_interface(struct ipu_csi *csi,

ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
  CSI_CCIR_CODE_1);
-   ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+   ipu_csi_write(csi, 0x405A6, CSI_CCIR_CODE_2);
ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
} else {
dev_err(csi->ipu->dev,
-- 
1.9.1



[PATCH 11/16] gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats

2016-07-07 Thread Steve Longerbeam
The CSI data format was being programmed incorrectly for the
1x16 media bus formats. The CSI data format for 16-bit must
be bayer/generic (CSI_SENS_CONF_DATA_FMT_BAYER).

Suggested-by: Carsten Resch 
Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-csi.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 07c7091..0eac28c 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -258,12 +258,8 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config 
*cfg, u32 mbus_code)
cfg->data_width = IPU_CSI_DATA_WIDTH_8;
break;
case MEDIA_BUS_FMT_UYVY8_1X16:
-   cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_UYVY;
-   cfg->mipi_dt = MIPI_DT_YUV422;
-   cfg->data_width = IPU_CSI_DATA_WIDTH_16;
-   break;
case MEDIA_BUS_FMT_YUYV8_1X16:
-   cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_YUYV;
+   cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
cfg->mipi_dt = MIPI_DT_YUV422;
cfg->data_width = IPU_CSI_DATA_WIDTH_16;
break;
-- 
1.9.1



[PATCH 10/16] gpu: ipu-v3: set correct full sensor frame for PAL/NTSC

2016-07-07 Thread Steve Longerbeam
Set the sensor full frame based on whether the passed in mbus_fmt
is 720x480 (NTSC) or 720x576 (PAL).

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-csi.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 336dc06..07c7091 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -365,10 +365,14 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
 {
struct ipu_csi_bus_config cfg;
unsigned long flags;
-   u32 data = 0;
+   u32 width, height, data = 0;

fill_csi_bus_cfg(&cfg, mbus_cfg, mbus_fmt);

+   /* set default sensor frame width and height */
+   width = mbus_fmt->width;
+   height = mbus_fmt->height;
+
/* Set the CSI_SENS_CONF register remaining fields */
data |= cfg.data_width << CSI_SENS_CONF_DATA_WIDTH_SHIFT |
cfg.data_fmt << CSI_SENS_CONF_DATA_FMT_SHIFT |
@@ -386,11 +390,6 @@ int ipu_csi_init_interface(struct ipu_csi *csi,

ipu_csi_write(csi, data, CSI_SENS_CONF);

-   /* Setup sensor frame size */
-   ipu_csi_write(csi,
- (mbus_fmt->width - 1) | ((mbus_fmt->height - 1) << 16),
- CSI_SENS_FRM_SIZE);
-
/* Set CCIR registers */

switch (cfg.clk_mode) {
@@ -408,11 +407,12 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
 * Field1BlankEnd = 0x7, Field1BlankStart = 0x3,
 * Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1
 */
+   height = 625; /* framelines for PAL */
+
ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
  CSI_CCIR_CODE_1);
ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
-
} else if (mbus_fmt->width == 720 && mbus_fmt->height == 480) {
/*
 * NTSC case
@@ -422,6 +422,8 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
 * Field1BlankEnd = 0x6, Field1BlankStart = 0x2,
 * Field1ActiveEnd = 0x4, Field1ActiveStart = 0
 */
+   height = 525; /* framelines for NTSC */
+
ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
  CSI_CCIR_CODE_1);
ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
@@ -447,6 +449,10 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
break;
}

+   /* Setup sensor frame size */
+   ipu_csi_write(csi, (width - 1) | ((height - 1) << 16),
+ CSI_SENS_FRM_SIZE);
+
dev_dbg(csi->ipu->dev, "CSI_SENS_CONF = 0x%08X\n",
ipu_csi_read(csi, CSI_SENS_CONF));
dev_dbg(csi->ipu->dev, "CSI_ACT_FRM_SIZE = 0x%08X\n",
-- 
1.9.1



[PATCH 09/16] gpu: ipu-v3: Add ipu_ic_set_src()

2016-07-07 Thread Steve Longerbeam
Adds ipu_ic_set_src() which is just aa wrapper around
ipu_set_ic_src_mux().

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-ic.c | 10 ++
 include/video/imx-ipu-v3.h  |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 1dcb96c..f306a9c 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -629,6 +629,16 @@ unlock:
 }
 EXPORT_SYMBOL_GPL(ipu_ic_task_idma_init);

+int ipu_ic_set_src(struct ipu_ic *ic, int csi_id, bool vdi)
+{
+   struct ipu_ic_priv *priv = ic->priv;
+
+   ipu_set_ic_src_mux(priv->ipu, csi_id, vdi);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_ic_set_src);
+
 int ipu_ic_enable(struct ipu_ic *ic)
 {
struct ipu_ic_priv *priv = ic->priv;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 57b487d..8f77ddb 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -334,6 +334,7 @@ void ipu_ic_task_disable(struct ipu_ic *ic);
 int ipu_ic_task_idma_init(struct ipu_ic *ic, struct ipuv3_channel *channel,
  u32 width, u32 height, int burst_size,
  enum ipu_rotate_mode rot);
+int ipu_ic_set_src(struct ipu_ic *ic, int csi_id, bool vdi);
 int ipu_ic_enable(struct ipu_ic *ic);
 int ipu_ic_disable(struct ipu_ic *ic);
 struct ipu_ic *ipu_ic_get(struct ipu_soc *ipu, enum ipu_ic_task task);
-- 
1.9.1



[PATCH 08/16] gpu: ipu-v3: Add ipu_csi_set_src()

2016-07-07 Thread Steve Longerbeam
Adds ipu_csi_set_src() which is just a wrapper around
ipu_set_csi_src_mux().

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-csi.c | 8 
 include/video/imx-ipu-v3.h   | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 06631ac..336dc06 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -609,6 +609,14 @@ int ipu_csi_set_skip_smfc(struct ipu_csi *csi, u32 skip,
 }
 EXPORT_SYMBOL_GPL(ipu_csi_set_skip_smfc);

+int ipu_csi_set_src(struct ipu_csi *csi, u32 vc, bool select_mipi_csi2)
+{
+   ipu_set_csi_src_mux(csi->ipu, csi->id, select_mipi_csi2);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_csi_set_src);
+
 int ipu_csi_set_dest(struct ipu_csi *csi, enum ipu_csi_dest csi_dest)
 {
unsigned long flags;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 2302fc5..57b487d 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -301,6 +301,7 @@ int ipu_csi_set_mipi_datatype(struct ipu_csi *csi, u32 vc,
  struct v4l2_mbus_framefmt *mbus_fmt);
 int ipu_csi_set_skip_smfc(struct ipu_csi *csi, u32 skip,
  u32 max_ratio, u32 id);
+int ipu_csi_set_src(struct ipu_csi *csi, u32 vc, bool select_mipi_csi2);
 int ipu_csi_set_dest(struct ipu_csi *csi, enum ipu_csi_dest csi_dest);
 int ipu_csi_enable(struct ipu_csi *csi);
 int ipu_csi_disable(struct ipu_csi *csi);
-- 
1.9.1



[PATCH 07/16] gpu: ipu-v3: Add VDI input IDMAC channels

2016-07-07 Thread Steve Longerbeam
Adds the VDIC field input IDMAC channels. These channels
transfer fields F(n-1), F(n), and F(N+1) from memory to
the VDIC (channels 8, 9, 10 respectively).

Signed-off-by: Steve Longerbeam 
---
 include/video/imx-ipu-v3.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 586979e..2302fc5 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -107,6 +107,9 @@ enum ipu_channel_irq {
 #define IPUV3_CHANNEL_CSI2  2
 #define IPUV3_CHANNEL_CSI3  3
 #define IPUV3_CHANNEL_VDI_MEM_IC_VF 5
+#define IPUV3_CHANNEL_MEM_VDI_P 8
+#define IPUV3_CHANNEL_MEM_VDI   9
+#define IPUV3_CHANNEL_MEM_VDI_N10
 #define IPUV3_CHANNEL_MEM_IC_PP11
 #define IPUV3_CHANNEL_MEM_IC_PRP_VF12
 #define IPUV3_CHANNEL_G_MEM_IC_PRP_VF  14
-- 
1.9.1



[PATCH 06/16] gpu: ipu-v3: Add ipu_set_vdi_src_mux()

2016-07-07 Thread Steve Longerbeam
Adds ipu_set_vdi_src_mux() that selects the VDIC input
(from CSI or memory).

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-common.c | 20 
 include/video/imx-ipu-v3.h  |  1 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 6d1676e..374100e 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -730,6 +730,26 @@ void ipu_set_ic_src_mux(struct ipu_soc *ipu, int csi_id, 
bool vdi)
 }
 EXPORT_SYMBOL_GPL(ipu_set_ic_src_mux);

+/*
+ * Set the source for the VDIC. Selects either from CSI[01] or memory.
+ */
+void ipu_set_vdi_src_mux(struct ipu_soc *ipu, bool csi)
+{
+   unsigned long flags;
+   u32 val;
+
+   spin_lock_irqsave(&ipu->lock, flags);
+
+   val = ipu_cm_read(ipu, IPU_FS_PROC_FLOW1);
+   val &= ~(0x3 << 28);
+   if (csi)
+   val |= (0x01 << 28);
+   ipu_cm_write(ipu, val, IPU_FS_PROC_FLOW1);
+
+   spin_unlock_irqrestore(&ipu->lock, flags);
+}
+EXPORT_SYMBOL_GPL(ipu_set_vdi_src_mux);
+

 /* IDMAC Channel Linking */

diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 0a39c64..586979e 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -152,6 +152,7 @@ int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct 
ipuv3_channel *channel,
 int ipu_get_num(struct ipu_soc *ipu);
 void ipu_set_csi_src_mux(struct ipu_soc *ipu, int csi_id, bool mipi_csi2);
 void ipu_set_ic_src_mux(struct ipu_soc *ipu, int csi_id, bool vdi);
+void ipu_set_vdi_src_mux(struct ipu_soc *ipu, bool csi);
 void ipu_dump(struct ipu_soc *ipu);

 /*
-- 
1.9.1



[PATCH 05/16] gpu: ipu-v3: Add IDMA channel linking support

2016-07-07 Thread Steve Longerbeam
Adds functions to link and unlink IDMAC source channels to sink
channels.

So far the following links are supported:

IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC
PUV3_CHANNEL_IC_PRP_VF_MEM   -> IPUV3_CHANNEL_MEM_ROT_VF
IPUV3_CHANNEL_IC_PP_MEM  -> IPUV3_CHANNEL_MEM_ROT_PP

More links can be added to the idmac_link_info[] array.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-common.c | 112 
 include/video/imx-ipu-v3.h  |   3 ++
 2 files changed, 115 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 49af121..6d1676e 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -730,6 +730,118 @@ void ipu_set_ic_src_mux(struct ipu_soc *ipu, int csi_id, 
bool vdi)
 }
 EXPORT_SYMBOL_GPL(ipu_set_ic_src_mux);

+
+/* IDMAC Channel Linking */
+
+struct idmac_link_reg_info {
+   int chno;
+   u32 reg;
+   int shift;
+   int bits;
+   u32 sel;
+};
+
+struct idmac_link_info {
+   struct idmac_link_reg_info src;
+   struct idmac_link_reg_info sink;
+};
+
+static const struct idmac_link_info idmac_link_info[] = {
+   {
+   .src  = { 20, IPU_FS_PROC_FLOW1,  0, 4, 7 },
+   .sink = { 45, IPU_FS_PROC_FLOW2,  0, 4, 1 },
+   }, {
+   .src =  { 21, IPU_FS_PROC_FLOW1,  8, 4, 8 },
+   .sink = { 46, IPU_FS_PROC_FLOW2,  4, 4, 1 },
+   }, {
+   .src =  { 22, IPU_FS_PROC_FLOW1, 16, 4, 5 },
+   .sink = { 47, IPU_FS_PROC_FLOW2, 12, 4, 3 },
+   },
+};
+
+static const struct idmac_link_info *find_idmac_link_info(
+   struct ipuv3_channel *src, struct ipuv3_channel *sink)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(idmac_link_info); i++) {
+   if (src->num == idmac_link_info[i].src.chno &&
+   sink->num == idmac_link_info[i].sink.chno)
+   return &idmac_link_info[i];
+   }
+
+   return NULL;
+}
+
+/*
+ * Links an IDMAC source channel to a sink channel.
+ */
+int ipu_idmac_link(struct ipuv3_channel *src, struct ipuv3_channel *sink)
+{
+   struct ipu_soc *ipu = src->ipu;
+   const struct idmac_link_info *link;
+   u32 src_reg, sink_reg, src_mask, sink_mask;
+   unsigned long flags;
+
+   link = find_idmac_link_info(src, sink);
+   if (!link)
+   return -EINVAL;
+
+   src_mask = ((1 << link->src.bits) - 1) << link->src.shift;
+   sink_mask = ((1 << link->sink.bits) - 1) << link->sink.shift;
+
+   spin_lock_irqsave(&ipu->lock, flags);
+
+   src_reg = ipu_cm_read(ipu, link->src.reg);
+   sink_reg = ipu_cm_read(ipu, link->sink.reg);
+
+   src_reg &= ~src_mask;
+   src_reg |= (link->src.sel << link->src.shift);
+
+   sink_reg &= ~sink_mask;
+   sink_reg |= (link->sink.sel << link->sink.shift);
+
+   ipu_cm_write(ipu, src_reg, link->src.reg);
+   ipu_cm_write(ipu, sink_reg, link->sink.reg);
+
+   spin_unlock_irqrestore(&ipu->lock, flags);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_idmac_link);
+
+/*
+ * Unlinks IDMAC source and sink channels.
+ */
+int ipu_idmac_unlink(struct ipuv3_channel *src, struct ipuv3_channel *sink)
+{
+   struct ipu_soc *ipu = src->ipu;
+   const struct idmac_link_info *link;
+   u32 src_reg, sink_reg, src_mask, sink_mask;
+   unsigned long flags;
+
+   link = find_idmac_link_info(src, sink);
+   if (!link)
+   return -EINVAL;
+
+   src_mask = ((1 << link->src.bits) - 1) << link->src.shift;
+   sink_mask = ((1 << link->sink.bits) - 1) << link->sink.shift;
+
+   spin_lock_irqsave(&ipu->lock, flags);
+
+   src_reg = ipu_cm_read(ipu, link->src.reg);
+   sink_reg = ipu_cm_read(ipu, link->sink.reg);
+
+   src_reg &= ~src_mask;
+   sink_reg &= ~sink_mask;
+
+   ipu_cm_write(ipu, src_reg, link->src.reg);
+   ipu_cm_write(ipu, sink_reg, link->sink.reg);
+
+   spin_unlock_irqrestore(&ipu->lock, flags);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_idmac_unlink);
+
 struct ipu_devtype {
const char *name;
unsigned long cm_ofs;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index b174f8a..0a39c64 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -128,6 +128,7 @@ enum ipu_channel_irq {
 #define IPUV3_CHANNEL_ROT_VF_MEM   49
 #define IPUV3_CHANNEL_ROT_PP_MEM   50
 #define IPUV3_CHANNEL_MEM_BG_SYNC_ALPHA51
+#define IPUV3_NUM_CHANNELS 64

 int ipu_map_irq(struct ipu_soc *ipu, int irq);
 int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
@@ -171,6 +172,8 @@ int ipu_idmac_get_current_buffer(struct ipuv3_channel 
*channel);
 bool ipu_idmac_buffer_is_ready(struct ipuv3_channel *channel, u32 buf_num);
 void ipu_idmac_select_buffer(struct ipuv3_channel *channel, u32 buf_num);
 void ipu_idmac_clear_buffer(str

[PATCH 04/16] gpu: ipu-v3: Add ipu_get_num()

2016-07-07 Thread Steve Longerbeam
Adds of-alias id to ipu_soc and retrieve with ipu_get_num().

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-common.c | 8 
 drivers/gpu/ipu-v3/ipu-prv.h| 1 +
 include/video/imx-ipu-v3.h  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 30dc115..49af121 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -45,6 +45,12 @@ static inline void ipu_cm_write(struct ipu_soc *ipu, u32 
value, unsigned offset)
writel(value, ipu->cm_reg + offset);
 }

+int ipu_get_num(struct ipu_soc *ipu)
+{
+   return ipu->id;
+}
+EXPORT_SYMBOL_GPL(ipu_get_num);
+
 void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
 {
u32 val;
@@ -1220,6 +1226,7 @@ static int ipu_probe(struct platform_device *pdev)
 {
const struct of_device_id *of_id =
of_match_device(imx_ipu_dt_ids, &pdev->dev);
+   struct device_node *np = pdev->dev.of_node;
struct ipu_soc *ipu;
struct resource *res;
unsigned long ipu_base;
@@ -1248,6 +1255,7 @@ static int ipu_probe(struct platform_device *pdev)
ipu->channel[i].ipu = ipu;
ipu->devtype = devtype;
ipu->ipu_type = devtype->type;
+   ipu->id = of_alias_get_id(np, "ipu");

spin_lock_init(&ipu->lock);
mutex_init(&ipu->channel_lock);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index 845f64c..02057d8 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -153,6 +153,7 @@ struct ipu_soc {
void __iomem*cm_reg;
void __iomem*idmac_reg;

+   int id;
int usecount;

struct clk  *clk;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 60540ead..b174f8a 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -148,6 +148,7 @@ int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct 
ipuv3_channel *channel,
 /*
  * IPU Common functions
  */
+int ipu_get_num(struct ipu_soc *ipu);
 void ipu_set_csi_src_mux(struct ipu_soc *ipu, int csi_id, bool mipi_csi2);
 void ipu_set_ic_src_mux(struct ipu_soc *ipu, int csi_id, bool vdi);
 void ipu_dump(struct ipu_soc *ipu);
-- 
1.9.1



[PATCH 03/16] gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()

2016-07-07 Thread Steve Longerbeam
Adds ipu_cpmem_get_burstsize().

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c | 6 ++
 include/video/imx-ipu-v3.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index a36c35e..fcb7dc8 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -275,6 +275,12 @@ void ipu_cpmem_set_axi_id(struct ipuv3_channel *ch, u32 id)
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_axi_id);

+int ipu_cpmem_get_burstsize(struct ipuv3_channel *ch)
+{
+   return ipu_ch_param_read_field(ch, IPU_FIELD_NPB) + 1;
+}
+EXPORT_SYMBOL_GPL(ipu_cpmem_get_burstsize);
+
 void ipu_cpmem_set_burstsize(struct ipuv3_channel *ch, int burstsize)
 {
ipu_ch_param_write_field(ch, IPU_FIELD_NPB, burstsize - 1);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 904fd12..60540ead 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -197,6 +197,7 @@ void ipu_cpmem_set_buffer(struct ipuv3_channel *ch, int 
bufnum, dma_addr_t buf);
 void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 u_off, u32 v_off);
 void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride);
 void ipu_cpmem_set_axi_id(struct ipuv3_channel *ch, u32 id);
+int ipu_cpmem_get_burstsize(struct ipuv3_channel *ch);
 void ipu_cpmem_set_burstsize(struct ipuv3_channel *ch, int burstsize);
 void ipu_cpmem_set_block_mode(struct ipuv3_channel *ch);
 void ipu_cpmem_set_rotation(struct ipuv3_channel *ch,
-- 
1.9.1



[PATCH 02/16] gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()

2016-07-07 Thread Steve Longerbeam
Adds ipu_cpmem_set_uv_offset(), to set planar U/V offsets.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c | 7 +++
 include/video/imx-ipu-v3.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 6494a4d..a36c35e 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -253,6 +253,13 @@ void ipu_cpmem_set_buffer(struct ipuv3_channel *ch, int 
bufnum, dma_addr_t buf)
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_buffer);

+void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 u_off, u32 v_off)
+{
+   ipu_ch_param_write_field(ch, IPU_FIELD_UBO, u_off / 8);
+   ipu_ch_param_write_field(ch, IPU_FIELD_VBO, v_off / 8);
+}
+EXPORT_SYMBOL_GPL(ipu_cpmem_set_uv_offset);
+
 void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride)
 {
ipu_ch_param_write_field(ch, IPU_FIELD_SO, 1);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 22662a1..904fd12 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -194,6 +194,7 @@ void ipu_cpmem_set_resolution(struct ipuv3_channel *ch, int 
xres, int yres);
 void ipu_cpmem_set_stride(struct ipuv3_channel *ch, int stride);
 void ipu_cpmem_set_high_priority(struct ipuv3_channel *ch);
 void ipu_cpmem_set_buffer(struct ipuv3_channel *ch, int bufnum, dma_addr_t 
buf);
+void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 u_off, u32 v_off);
 void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride);
 void ipu_cpmem_set_axi_id(struct ipuv3_channel *ch, u32 id);
 void ipu_cpmem_set_burstsize(struct ipuv3_channel *ch, int burstsize);
-- 
1.9.1



[PATCH 01/16] gpu: ipu-v3: Add Video Deinterlacer unit

2016-07-07 Thread Steve Longerbeam
Adds the Video Deinterlacer (VDIC) unit.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/Makefile |   2 +-
 drivers/gpu/ipu-v3/ipu-common.c |  11 ++
 drivers/gpu/ipu-v3/ipu-prv.h|   6 +
 drivers/gpu/ipu-v3/ipu-vdi.c| 266 
 include/video/imx-ipu-v3.h  |  27 
 5 files changed, 311 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c

diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
index 107ec23..aeba9dc 100644
--- a/drivers/gpu/ipu-v3/Makefile
+++ b/drivers/gpu/ipu-v3/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o

 imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
-   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o
+   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o ipu-vdi.o
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 99dcacf..30dc115 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -833,6 +833,14 @@ static int ipu_submodules_init(struct ipu_soc *ipu,
goto err_ic;
}

+   ret = ipu_vdi_init(ipu, dev, ipu_base + devtype->vdi_ofs,
+  IPU_CONF_VDI_EN | IPU_CONF_ISP_EN |
+  IPU_CONF_IC_INPUT);
+   if (ret) {
+   unit = "vdi";
+   goto err_vdi;
+   }
+
ret = ipu_di_init(ipu, dev, 0, ipu_base + devtype->disp0_ofs,
  IPU_CONF_DI0_EN, ipu_clk);
if (ret) {
@@ -887,6 +895,8 @@ err_dc:
 err_di_1:
ipu_di_exit(ipu, 0);
 err_di_0:
+   ipu_vdi_exit(ipu);
+err_vdi:
ipu_ic_exit(ipu);
 err_ic:
ipu_csi_exit(ipu, 1);
@@ -971,6 +981,7 @@ static void ipu_submodules_exit(struct ipu_soc *ipu)
ipu_dc_exit(ipu);
ipu_di_exit(ipu, 1);
ipu_di_exit(ipu, 0);
+   ipu_vdi_exit(ipu);
ipu_ic_exit(ipu);
ipu_csi_exit(ipu, 1);
ipu_csi_exit(ipu, 0);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index bfb1e8a..845f64c 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -138,6 +138,7 @@ struct ipu_dc_priv;
 struct ipu_dmfc_priv;
 struct ipu_di;
 struct ipu_ic_priv;
+struct ipu_vdi;
 struct ipu_smfc_priv;

 struct ipu_devtype;
@@ -169,6 +170,7 @@ struct ipu_soc {
struct ipu_di   *di_priv[2];
struct ipu_csi  *csi_priv[2];
struct ipu_ic_priv  *ic_priv;
+   struct ipu_vdi  *vdi_priv;
struct ipu_smfc_priv*smfc_priv;
 };

@@ -199,6 +201,10 @@ int ipu_ic_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base, unsigned long tpmem_base);
 void ipu_ic_exit(struct ipu_soc *ipu);

+int ipu_vdi_init(struct ipu_soc *ipu, struct device *dev,
+unsigned long base, u32 module);
+void ipu_vdi_exit(struct ipu_soc *ipu);
+
 int ipu_di_init(struct ipu_soc *ipu, struct device *dev, int id,
unsigned long base, u32 module, struct clk *ipu_clk);
 void ipu_di_exit(struct ipu_soc *ipu, int id);
diff --git a/drivers/gpu/ipu-v3/ipu-vdi.c b/drivers/gpu/ipu-v3/ipu-vdi.c
new file mode 100644
index 000..1303bcc
--- /dev/null
+++ b/drivers/gpu/ipu-v3/ipu-vdi.c
@@ -0,0 +1,266 @@
+/*
+ * Copyright (C) 2012 Mentor Graphics Inc.
+ * Copyright (C) 2005-2009 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu-prv.h"
+
+struct ipu_vdi {
+   void __iomem *base;
+   u32 module;
+   spinlock_t lock;
+   int use_count;
+   struct ipu_soc *ipu;
+};
+
+
+/* VDI Register Offsets */
+#define VDI_FSIZE 0x
+#define VDI_C 0x0004
+
+/* VDI Register Fields */
+#define VDI_C_CH_420 (0 << 1)
+#define VDI_C_CH_422 (1 << 1)
+#define VDI_C_MOT_SEL_MASK   (0x3 << 2)
+#define VDI_C_MOT_SEL_FULL   (2 << 2)
+#define VDI_C_MOT_SEL_LOW(1 << 2)
+#define VDI_C_MOT_SEL_MED(0 << 2)
+#define VDI_C_BURST_SIZE1_4  (3 << 4)
+#define VDI_C_BURST_SIZE2_4  (3 << 8)
+#define VDI_C_BURST_SIZE3_4  (3 << 12)
+#define VDI_C_BURST_SIZE_MASK0xF
+#define VDI_C_BURST_SIZE1_OFFSET 4
+#define VDI_C_BURST_SIZE2_OFFSET 8
+#define VDI_C_BURST_SIZE3_OFFSET 12
+#define VDI_C_VWM1_SET_1 (0 << 16)
+#define VDI_C_VWM1_SET_2 (1 << 16)
+#define VDI_C_V

[PATCH 00/16] IPUv3 prep for i.MX5/6 v4l2 staging drivers

2016-07-07 Thread Steve Longerbeam
These updates to IPUv3 are needed for media staging drivers
for i.MX5/6 video capture and mem2mem.

Steve Longerbeam (15):
  gpu: ipu-v3: Add Video Deinterlacer unit
  gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
  gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()
  gpu: ipu-v3: Add ipu_get_num()
  gpu: ipu-v3: Add IDMA channel linking support
  gpu: ipu-v3: Add ipu_set_vdi_src_mux()
  gpu: ipu-v3: Add VDI input IDMAC channels
  gpu: ipu-v3: Add ipu_csi_set_src()
  gpu: ipu-v3: Add ipu_ic_set_src()
  gpu: ipu-v3: set correct full sensor frame for PAL/NTSC
  gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats
  gpu: ipu-v3: Fix IRT usage
  gpu: ipu-ic: Add complete image conversion support with tiling
  gpu: ipu-ic: allow multiple handles to ic
  gpu: ipu-v3: rename CSI client device

Suresh Dhandapani (1):
  gpu: ipu-v3: Fix CSI0 blur in NTSC format

 drivers/gpu/ipu-v3/Makefile |2 +-
 drivers/gpu/ipu-v3/ipu-common.c |  155 +++-
 drivers/gpu/ipu-v3/ipu-cpmem.c  |   13 +
 drivers/gpu/ipu-v3/ipu-csi.c|   36 +-
 drivers/gpu/ipu-v3/ipu-ic.c | 1769 ++-
 drivers/gpu/ipu-v3/ipu-prv.h|7 +
 drivers/gpu/ipu-v3/ipu-vdi.c|  266 ++
 include/video/imx-ipu-v3.h  |   96 ++-
 8 files changed, 2283 insertions(+), 61 deletions(-)
 create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c

-- 
1.9.1



[PATCH v5 0/4] Generic zpos property

2016-07-07 Thread Tobias Jakobi
Hello Benjamin,


Benjamin Gaignard wrote:
> version 5:
> rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't
> exist anymore.
I think the documentation has just moved to Documentation/gpu, so the
zpos property should be documented there then.


With best wishes,
Tobias


> rework sti patch because some plane functions have changed since v4
> 
> version 4:
> make sure that normalized zpos value is stay in the defined property 
> range and warn user if not.
> Fix NULL pointer bug in rcar-du while setting zpos value.
> No changes in the other drivers.
> 
> version 3:
> use kmalloc_array instead of kmalloc.
> Correct normalize_zpos computation (comeback to Mareck original code)
> 
> version 2:
> add a zpos property into drm_plane structure to simplify code.
> This allow to get/set zpos value in core and not in drivers code.
> Fix various remarks.
> 
> version 1:
> refactor Marek's patches to have per plane zpos property instead of only
> one in core.
> 
> Benjamin Gaignard (2):
>   drm: sti: use generic zpos for plane
>   drm: rcar: use generic code for managing zpos plane property
> 
> Marek Szyprowski (2):
>   drm: add generic zpos property
>   drm/exynos: use generic code for managing zpos plane property
> 
>  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   |   4 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
>  drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
>  drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
>  drivers/gpu/drm/sti/sti_gdp.c |   4 +-
>  drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
>  drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
>  drivers/gpu/drm/sti/sti_plane.c   |  76 --
>  drivers/gpu/drm/sti/sti_plane.h   |   7 +-
>  include/drm/drm_crtc.h|  30 
>  20 files changed, 324 insertions(+), 147 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_blend.c
> 
> Cc: Inki Dae 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Andrzej Hajda 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Tobias Jakobi 
> Cc: Gustavo Padovan 
> Cc: vincent.abriou at st.com
> Cc: fabien.dessenne at st.com
> Cc: Laurent Pinchart 
> 



[PATCH 0/3] imx drm atomic mode setting fixups

2016-07-07 Thread Ying Liu
Hi Philipp,

On Wed, Jul 6, 2016 at 11:52 PM, Philipp Zabel  
wrote:
> Hi,
>
> I have tested Liu Ying's imx drm atomic mode setting conversion series [1]

Thanks for the testing!

> with three different outputs (DPI + eDP bridge, LVDS + panel, HDMI)
> and noticed that in the LDB case bus_format handling doesn't work
> correctly if the format is determined by the panel instead of the
> device tree. In that case, the LVDS bus_format is not yet known at bind
> time, but is filled into the display_info structure by the panel driver
> in the get_modes callback. The LDB driver then has to translate from the
> LVDS bus format to the corresponding internal parallel bus format and
> let the crtc know about the format before crtc mode_set is called.
> The same issue occurs when the bus_format is determined by a bridge driver
> which implements its own connector. To solve this, and because crtc state
> seems to be the right place for potentially dynamic crtc settings, I have
> moved the bus_format, bus_flags, and di_*sync_pin configuration into an
> imx-drm specific crtc state structure and removed imx_drm_encoder again.

I didn't program imx_ldb_ch->imx_encoder.bus_format correctly
in imx_ldb_connector_get_modes() - I forgot to translate the bus format
from LVDS bus format to internal bus format.  Also, data width and
LVDS data mapping(SPWG/JEIDA) can be set to ldb->ldb_ctrl in
the function. So, one option to fix the issue you found is to simply
modify the function and respin the particular patch in my patch set.
Actually, I have got a fix tested with the format determined by the panel.

I don't have strong opinion on storing bus_format, bus_flags and
di_*sync_pin in imx_crtc_state.  But, very likely, they will not be
dynamically changed.  Setting them again and again at atomic_check
is somewhat wasting CPU cycles...

BTW, the imx-drm atomic conversion patch set has reached version 3
which uses the new non-blocking atomic commit helpers.

Regards,
Liu Ying

>
> I have also removed the now optional empty encoder mode_set callbacks
> and turned the container_of helper macros into inline functions.
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2016-May/108218.html
>
> regards
> Philipp
>
> Philipp Zabel (3):
>   drm/imx: remove empty mode_set encoder callbacks
>   drm/imx: store internal bus configuration in crtc state
>   drm/imx: turn remaining container_of macros into inline functions
>
>  drivers/gpu/drm/imx/dw_hdmi-imx.c  |  38 +
>  drivers/gpu/drm/imx/imx-drm.h  |   9 ++-
>  drivers/gpu/drm/imx/imx-ldb.c  | 142 
> +
>  drivers/gpu/drm/imx/imx-tve.c  |  45 ---
>  drivers/gpu/drm/imx/ipuv3-crtc.c   |  72 +
>  drivers/gpu/drm/imx/ipuv3-plane.c  |   5 +-
>  drivers/gpu/drm/imx/parallel-display.c |  85 +++-
>  7 files changed, 259 insertions(+), 137 deletions(-)
>
> --
> 2.8.1
>


[PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

2016-07-07 Thread Bibby Hsieh
Some panels only accept bpc (bit per color) 6-bit.
But, the default bpc in mt8173 display data path is 8-bit.
If we didn't enable dithering function to convert bpc,
display cannot show the smooth grayscale image.

In mt8173, the dithering function in OD (OverDrive) and
GAMMA module, we have to config them with
connector->display_mode.bpc when CRTC initial.

1. Clear the default value at *_DITHER_5 and *_DITHER_7 register.
2. Calculate the LSB_ERR_SHIFT bits and ADD_LSHIFT bits two values.
i.e. Input bpc of OD is 10 bits, we assume the bpc of panel is 6-bit,
so, we need to set 4-bit to LSB_ERR_SHIFT and ADD_LSHIFT bits respectively.
3. Then, set the OD or GAMMA to dithering mode depends on path-1 or path-2.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   21 ++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   77 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |6 +--
 5 files changed, 92 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8f62671f..019b7ca 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -103,7 +103,8 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
 }

 static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
-  unsigned int h, unsigned int vrefresh)
+  unsigned int h, unsigned int vrefresh,
+  unsigned int bpc)
 {
if (w != 0 && h != 0)
writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 5fb80cb..0df05f9 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -106,7 +106,8 @@ static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
 }

 static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
-   unsigned int height, unsigned int vrefresh)
+   unsigned int height, unsigned int vrefresh,
+   unsigned int bpc)
 {
unsigned int threshold;
unsigned int reg;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ee219bb..18c9d0d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -222,7 +222,9 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc 
*mtk_crtc)
 static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
 {
struct drm_crtc *crtc = &mtk_crtc->base;
-   unsigned int width, height, vrefresh;
+   struct drm_connector *connector;
+   struct drm_encoder *encoder;
+   unsigned int width, height, vrefresh, bpc = 0;
int ret;
int i;

@@ -234,6 +236,19 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
height = crtc->state->adjusted_mode.vdisplay;
vrefresh = crtc->state->adjusted_mode.vrefresh;

+   drm_for_each_encoder(encoder, crtc->dev) {
+   if (encoder->crtc != crtc)
+   continue;
+
+   drm_for_each_connector(connector, crtc->dev) {
+   if (connector->encoder != encoder)
+   continue;
+   if (connector->display_info.bpc >= 3 &&
+   (bpc == 0 || bpc > connector->display_info.bpc))
+   bpc = connector->display_info.bpc;
+   }
+   }
+
ret = pm_runtime_get_sync(crtc->dev->dev);
if (ret < 0) {
DRM_ERROR("Failed to enable power domain: %d\n", ret);
@@ -266,7 +281,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];

-   mtk_ddp_comp_config(comp, width, height, vrefresh);
+   mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
mtk_ddp_comp_start(comp);
}

@@ -469,7 +484,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct 
mtk_ddp_comp *ovl)
if (state->pending_config) {
mtk_ddp_comp_config(ovl, state->pending_width,
state->pending_height,
-   state->pending_vrefresh);
+   state->pending_vrefresh, 0);

state->pending_config = false;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 56c5894..c10faac 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -30,7 +30,26 @@
 #define D

[PATCH v3 1/2] drm/mediatek: Add gamma correction

2016-07-07 Thread Bibby Hsieh
Apply gamma function to correct brightness values.
It applies arbitrary mapping curve to compensate the
incorrect transfer function of the panel.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 +++
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   89 ++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +++
 4 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 24aa3ba..ee219bb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -409,6 +409,10 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
*crtc,
}
if (pending_planes)
mtk_crtc->pending_planes = true;
+   if (crtc->state->color_mgmt_changed)
+   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
+   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
+
 }

 static const struct drm_crtc_funcs mtk_crtc_funcs = {
@@ -418,6 +422,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
.reset  = mtk_drm_crtc_reset,
.atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
.atomic_destroy_state   = mtk_drm_crtc_destroy_state,
+   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
 };

 static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
@@ -569,6 +574,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (ret < 0)
goto unprepare;

+   drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
+   drm_helper_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
+ MTK_LUT_SIZE);
priv->crtc[pipe] = &mtk_crtc->base;
priv->num_pipes++;

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index 81e5566..d332564 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -19,6 +19,7 @@
 #include "mtk_drm_plane.h"

 #define OVL_LAYER_NR   4
+#define MTK_LUT_SIZE   512

 int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
 void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3970fcf..56c5894 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -24,6 +24,7 @@
 #include "mtk_drm_drv.h"
 #include "mtk_drm_plane.h"
 #include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_crtc.h"

 #define DISP_OD_EN 0x
 #define DISP_OD_INTEN  0x0008
@@ -38,6 +39,21 @@
 #define DISP_COLOR_WIDTH   0x0c50
 #define DISP_COLOR_HEIGHT  0x0c54

+#define DISP_AAL_EN0x000
+#define DISP_AAL_SIZE  0x030
+
+#define DISP_GAMMA_EN  0x000
+#define DISP_GAMMA_CFG 0x020
+#define DISP_GAMMA_SIZE0x030
+#define DISP_GAMMA_LUT 0x700
+
+#define LUT_10BIT_MASK 0x3ff
+
+#define AAL_EN BIT(0)
+
+#define GAMMA_EN   BIT(0)
+#define GAMMA_LUT_EN   BIT(1)
+
 #defineOD_RELAY_MODE   BIT(0)

 #defineUFO_BYPASS  BIT(2)
@@ -76,6 +92,61 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
 }

+static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
+  unsigned int h, unsigned int vrefresh)
+{
+   writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
+}
+
+static void mtk_aal_start(struct mtk_ddp_comp *comp)
+{
+   writel(AAL_EN, comp->regs  + DISP_AAL_EN);
+}
+
+static void mtk_aal_stop(struct mtk_ddp_comp *comp)
+{
+   writel_relaxed(0x0, comp->regs  + DISP_AAL_EN);
+}
+
+static void mtk_gamma_config(struct mtk_ddp_comp *comp, unsigned int w,
+unsigned int h, unsigned int vrefresh)
+{
+   writel(h << 16 | w, comp->regs + DISP_GAMMA_SIZE);
+}
+
+static void mtk_gamma_start(struct mtk_ddp_comp *comp)
+{
+   writel(GAMMA_EN, comp->regs  + DISP_GAMMA_EN);
+}
+
+static void mtk_gamma_stop(struct mtk_ddp_comp *comp)
+{
+   writel_relaxed(0x0, comp->regs  + DISP_GAMMA_EN);
+}
+
+static void mtk_gamma_set(struct mtk_ddp_comp *comp,
+ struct drm_crtc_state *state)
+{
+   unsigned int i, reg;
+   struct drm_color_lut *lut;
+   void __iomem *lut_base;
+   u32 word;
+
+   if (state->gamma_lut) {
+   reg = readl(comp->regs + DISP_GAMMA_CFG);
+   reg = reg | GAMMA_LUT_EN;
+   writel(reg,

[PATCH v3 0/2] drm/mediatek: MT8173 gamma & dither support

2016-07-07 Thread Bibby Hsieh
This is MT8173 gamma & dither support PATCH v3, based on 4.7-rc1.

Changes since v2:
 -Modify defines to match the register field names in the MT8173 datasheet
 -Made dithering function support hardware mirroring well on two  monitor.

Bibby Hsieh (2):
  drm/mediatek: Add gamma correction
  drm/mediatek: set mt8173 dithering function

 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   29 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  154 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   16 ++-
 6 files changed, 192 insertions(+), 14 deletions(-)

-- 
1.7.9.5



[PATCH v5 4/4] drm: rcar: use generic code for managing zpos plane property

2016-07-07 Thread Benjamin Gaignard
version 4:
fix null pointer issue while setting zpos in plane reset function

This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.

Signed-off-by: Benjamin Gaignard 

Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Laurent Pinchart 
Cc: Marek Szyprowski 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
 5 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda..28d2cb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,

 static unsigned int plane_zpos(struct rcar_du_plane *plane)
 {
-   return to_rcar_plane_state(plane->plane.state)->zpos;
+   return plane->plane.state->normalized_zpos;
 }

 static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
-   struct drm_property *zpos;
} props;

unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 6bb032d..f03eb55 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;

-   rcdu->props.zpos =
-   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
-   if (rcdu->props.zpos == NULL)
-   return -ENOMEM;
-
return 0;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index bfe31ca..dc9bb96 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -652,7 +652,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
-   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+   state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;

plane->state = &state->state;
plane->state->plane = plane;
@@ -670,8 +670,6 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rcdu->props.zpos)
-   rstate->zpos = val;
else
return -EINVAL;

@@ -690,8 +688,6 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rcdu->props.zpos)
-   *val = rstate->zpos;
else
return -EINVAL;

@@ -763,8 +759,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(&plane->plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
-   drm_object_attach_property(&plane->plane.base,
-  rcdu->props.zpos, 1);
+   drm_plane_create_zpos_property(&plane->plane, 1, 7);
}

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @hwindex: 0-based hardware plane index, -1 means unused
  * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
  */
 struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {

unsigned int alpha;
unsigned int colorkey;
-   unsigned int zpos;
 };

 static inline struct rcar_du_plane_state *
-- 
1.9.1



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

2016-07-07 Thread Benjamin Gaignard
From: Marek Szyprowski 

This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
 3 files changed, 13 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cc33ec9..b34a7b9 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 *
@@ -221,7 +220,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;

struct device *dma_dev;
unsigned long da_start;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 77f12c0..915e804 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,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 = &exynos_state->base;
plane->state->plane = plane;
+   plane->state->zpos = exynos_plane->config->zpos;
}
 }

@@ -157,7 +157,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;
 }

@@ -170,43 +169,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,
@@ -215,8 +177,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
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
 {
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_private *dev_priv = dev->dev

[PATCH v5 2/4] drm: sti: use generic zpos for plane

2016-07-07 Thread Benjamin Gaignard
remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/sti/sti_cursor.c |  4 +--
 drivers/gpu/drm/sti/sti_gdp.c|  4 +--
 drivers/gpu/drm/sti/sti_hqvdp.c  |  4 +--
 drivers/gpu/drm/sti/sti_mixer.c  |  9 ++---
 drivers/gpu/drm/sti/sti_plane.c  | 76 ++--
 drivers/gpu/drm/sti/sti_plane.h  |  7 +---
 6 files changed, 36 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index a263bbb..3b53f7f 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -349,8 +349,8 @@ struct drm_plane_funcs sti_cursor_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_cursor_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_cursor_late_register,
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index bf63086..b8d942c 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -886,8 +886,8 @@ struct drm_plane_funcs sti_gdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_gdp_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_gdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 33d2f42..5a435c1 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1254,8 +1254,8 @@ struct drm_plane_funcs sti_hqvdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_hqvdp_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_hqvdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index 1885c7a..7d9aea8 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -239,13 +239,10 @@ static void sti_mixer_set_background_area(struct 
sti_mixer *mixer,

 int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
 {
-   int plane_id, depth = plane->zorder;
+   int plane_id, depth = plane->drm_plane.state->normalized_zpos;
unsigned int i;
u32 mask, val;

-   if ((depth < 1) || (depth > GAM_MIXER_NB_DEPTH_LEVEL))
-   return 1;
-
switch (plane->desc) {
case STI_GDP_0:
plane_id = GAM_DEPTH_GDP0_ID;
@@ -278,8 +275,8 @@ int sti_mixer_set_plane_depth(struct sti_mixer *mixer, 
struct sti_plane *plane)
break;
}

-   mask |= GAM_DEPTH_MASK_ID << (3 * (depth - 1));
-   plane_id = plane_id << (3 * (depth - 1));
+   mask |= GAM_DEPTH_MASK_ID << (3 * depth);
+   plane_id = plane_id << (3 * depth);

DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
 sti_plane_to_str(plane), depth);
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index 0cf3335..6472333 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
 #include "sti_drv.h"
 #include "sti_plane.h"

-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
-   STI_GDP_0,
-   STI_GDP_1,
-   STI_HQVDP_0,
-   STI_GDP_2,
-   STI_GDP_3,
-};
-
 const char *sti_plane_to_str(struct sti_plane *plane)
 {
switch (plane->desc) {
@@ -96,59 +87,44 @@ 

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

2016-07-07 Thread Benjamin Gaignard
From: Marek Szyprowski 

version 5:
- remove zpos range check and comeback to 0 to N-1
  normalization algorithm

version 4:
- make sure that normalized zpos value is stay
  in the defined property range and warn user if not

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane 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 

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 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 |   4 +
 include/drm/drm_crtc.h  |  30 +
 6 files changed, 272 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e3dba6f..7fbcf3f 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 3cee084..e503b8f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -712,6 +712,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 == plane->zpos_property) {
+   state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -768,6 +770,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 == plane->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 de7fddc..0694ae1 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
  *
@@ -592,6 +594,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) {
const struct drm_plane_helper_funcs *funcs;

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
new file mode 100644
index 000..5ae6e0e
--- /dev/null
+++ b/drivers/gpu/drm/drm_blend.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright (C) 2016 Samsung Electronics Co.Ltd
+ * Authors:
+ * Marek Szyprowski 
+ *
+ * DRM core plane blending related functions
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permis

[PATCH v5 0/4] Generic zpos property

2016-07-07 Thread Benjamin Gaignard
version 5:
rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't
exist anymore.
rework sti patch because some plane functions have changed since v4

version 4:
make sure that normalized zpos value is stay in the defined property 
range and warn user if not.
Fix NULL pointer bug in rcar-du while setting zpos value.
No changes in the other drivers.

version 3:
use kmalloc_array instead of kmalloc.
Correct normalize_zpos computation (comeback to Mareck original code)

version 2:
add a zpos property into drm_plane structure to simplify code.
This allow to get/set zpos value in core and not in drivers code.
Fix various remarks.

version 1:
refactor Marek's patches to have per plane zpos property instead of only
one in core.

Benjamin Gaignard (2):
  drm: sti: use generic zpos for plane
  drm: rcar: use generic code for managing zpos plane property

Marek Szyprowski (2):
  drm: add generic zpos property
  drm/exynos: use generic code for managing zpos plane property

 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   |   4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
 drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
 drivers/gpu/drm/sti/sti_gdp.c |   4 +-
 drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
 drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
 drivers/gpu/drm/sti/sti_plane.c   |  76 --
 drivers/gpu/drm/sti/sti_plane.h   |   7 +-
 include/drm/drm_crtc.h|  30 
 20 files changed, 324 insertions(+), 147 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
-- 
1.9.1



next-20160707 build: 1 failures 6 warnings (next-20160707)

2016-07-07 Thread Mark Brown
On Thu, Jul 07, 2016 at 10:23:56AM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

>   arm64-allmodconfig
> ../drivers/gpu/drm/rockchip/rockchip_drm_drv.c:17:27: fatal error: 
> asm/dma-iommu.h: No such file or directory

triggered by c51f43a9c171ea (iommu/rockchip: Enable Rockchip IOMMU on
ARM64) which enables the Rockchip IOMMU driver on ARM64 which lacks the
above header.  Either the use of the header needs to be removed or an
explicit ARM64 dependency added at the DRM level.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160707/bbf16e3b/attachment.sig>


[Nouveau] [PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-07 Thread Alexandre Courbot
On Wed, Jul 6, 2016 at 7:56 AM, Joe Perches  wrote:
> On Tue, 2016-07-05 at 15:36 -0700, Markus Mayer wrote:
>> On 5 July 2016 at 15:14, Joe Perches  wrote:
>> > On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
>> > > This series introduces a family of generic string case conversion
>> > > functions. This kind of functionality is needed in several places in
>> > > the kernel. Right now, everybody seems to be implementing their own
>> > > copy of this functionality.
>> > >
>> > > Based on the discussion of the previous version of this series[1] and
>> > > the use cases found in the kernel, it does look like having several
>> > > flavours of case conversion functions is beneficial. The use cases fall
>> > > into three categories:
>> > > - copying a string and converting the case while specifying a
>> > >   maximum length to mimic strncpy()
>> > > - copying a string and converting the case without specifying a
>> > >   length to mimic strcpy()
>> > > - converting the case of a string in-place (i.e. modifying the
>> > >   string that was passed in)
>> > >
>> > > Consequently, I am proposing these new functions:
>> > > char *strncpytoupper(char *dst, const char *src, size_t len);
>> > > char *strncpytolower(char *dst, const char *src, size_t len);
>> > > char *strcpytoupper(char *dst, const char *src);
>> > > char *strcpytolower(char *dst, const char *src);
>> > > char *strtoupper(char *s);
>> > > char *strtolower(char *s);
>> > I think there isn't much value in anything other
>> > than strto.
>> >
>> > Using str[n]cpy followed by strto is
>> > pretty obvious and rarely used anyway.
>> First time around, folks were proposing the "copy" variants when I
>> submitted just strtolower() by itself[1]. They just asked for source
>> and destination parameters to strtolower(), but looking at the use
>> cases that wouldn't have worked so well. Hence it evolved into these 6
>> functions.
>>
>> Here's a breakdown of how the functions are being used (patches 2-7),
>> see also [2]:
>>
>> Patch 2: strncpytolower()
>> Patch 3: strtolower()
>> Patch 4: strncpytolower() and strtolower()
>> Patch 5: strtolower()
>> Patch 6: strcpytoupper()
>> Patch 7: strcpytoupper()
>>
>> So it does look like the copy + change case variant is more frequently
>> used than just strto.
>
> Are these functions useful?   Not to me, not so much.
>
> None of the functions would have the strcpy performance of
> the arch / asm
> versions of strcpy and the savings in overall
> code isn't significant (or
> measured?).
>
> Of course none of the uses are runtime performance important.

I tend to agree. strcpy is better left to architecture-specific code
when it exists. Then doing a strcpy() followed by strtolower() is not
exactly unintuitive. An explosion of closely related function is
certainly more confusing to me.

I'd just keep strtolower()/strtoupper() because they are commonly done
operations and we can probably save some space by having a unique
implementation. But going beyond that is overthinking the problem
IMHO.


[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #23 from Quentin Quaadgras  ---
Created attachment 124944
  --> https://bugs.freedesktop.org/attachment.cgi?id=124944&action=edit
Complete Valgrind output

I added --error-limit=no and then deleted the 1000 harmless conditional errors
from before. This looks better.

-- 
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/20160707/e664d320/attachment.html>


[PATCH -next] drm/tegra: sor: Fix invalid kfree of devm_kzalloc allocated data

2016-07-07 Thread Alexandre Courbot
On Mon, Jul 4, 2016 at 4:19 PM,   wrote:
> From: Wei Yongjun 
>
> data allocated with devm_kzalloc should not be freed using kfree,
> because doing so causes a dangling pointer, and a subsequent
> double free, use devm_kfree instead.
>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/tegra/sor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 8425eda..af98587 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -363,7 +363,7 @@ static struct clk *tegra_clk_sor_brick_register(struct 
> tegra_sor *sor,
>
> clk = devm_clk_register(sor->dev, &brick->hw);
> if (IS_ERR(clk))
> -   kfree(brick);
> +   devm_kfree(sor->dev, brick);
>
> return clk;
>  }

Dan sent another fix for this:

https://lkml.org/lkml/2016/7/4/83

I tend to prefer his solution since it has a negative line count and
also doesn't do the (unneeded) explicit devm_kfree().

Thanks though!
Alex.


[Bug 96835] "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96835

--- Comment #3 from Nicolai Hähnle  ---
The backtrace looks completely unrelated to the commit you cite. Why do you
think that this particular commit is at fault?

Just to be sure, could you please provide a backtrace with debug symbols
enabled (-g)?

-- 
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/20160707/0a4d6acd/attachment.html>


[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #22 from Nicolai Hähnle  ---
Valgrind has options --gen-suppressions and --suppressions to help with
suppressing unrelated errors. The first option will output suggested
suppression statements that need to be put into a file that can be loaded with
the suppressions option on a second run. Based on the Valgrind log, something
like

{
   
   Memcheck:Cond

obj:/home/user/.steam/steam/steamapps/common/Awesomenauts/Awesomenauts.bin.x86
}

should actually be sufficient as a suppression file.

-- 
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/20160707/e07236d5/attachment.html>


[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-07 Thread Michel Dänzer
On 06.07.2016 22:45, Tejun Heo wrote:
> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
> 
>> Not being very familiar with the workqueue APIs, I'll describe how it's
>> supposed to work from a driver POV, which will hopefully help you guys
>> decide on the most appropriate alloc_workqueue parameters.
>>
>> There is one flip work queue for each hardware CRTC. At most one
>> radeon_flip_work_func item can be queued for any of them at any time.
>> When a radeon_flip_work_func item is queued, it should be executed ASAP
>> (so WQ_HIGHPRI might be appropriate?).
> 
> Hmmm... the only time WQ_HIGHPRI should be used is when it'd otherwise
> require a kthread w/ nice value at -20.  Would that be the case here?
> What are the consequences of the work item getting delayed?

A page flip may be delayed to a later display refresh cycle.


> Also, what kind of delays matter here?  Is it millisec range or micro?

It can be the latter in theory, but normally rather the former.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160707/5178613d/attachment.sig>


[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-07-07 Thread James Bottomley
On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > Cc: Ville
> > > > > 
> > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > James.Bottomley at HansenPartnership.com> wrote:
> > > > > > OK, my candidate bad commit is this one:
> > > > > > 
> > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > Author: Ville Syrjälä 
> > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > 
> > > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > > 
> > > > > > After being more careful about waiting to identify flicker,
> > > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > > seeing no flicker problems.   It is, however, early days 
> > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > wait 
> > > > > > until Monday evening and a few reboots before declaring
> > > > > > victory.
> > > > > 
> > > > > If that turns out to be the bad commit, it doesn't really 
> > > > > surprise me, and that in itself is depressing.
> > > > 
> > > > As far as I can tell, after running for a day with this
> > > > reverted, 
> > > > this is the problem.  The flicker hasn't appeared with it 
> > > > reverted.  It's pretty noticeable with this commit included.
> > > 
> > > Hmm. The only difference I can see is low vs. normal vswing.
> > > Panel 
> > > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > > telling utter lies, or there's some other bug in our low vswing
> > > support.
> > 
> > I did a quick once over of out DDI vswing stuff and didn't find 
> > anything too serious. There were some buglets in the iboost
> > handling, 
> > but I'm not very hopeful that fixing those would help with your 
> > machine. 
> > 
> > Here's a branch anyway in case you want to give it a go:
> > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > 
> > Actually, I think the only patch in there that might make a 
> > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> > with 4 lanes on SKL")
> 
> Running with it now (the entire branch).  So far it looks OK, but 
> I'll give it a couple of days to see if anything manifests before
> declaring victory.

Bad news, I'm afraid: after a couple of hours of run time, there is now
noticeable flicker on the display, so although the iboost fixes may
have lessened it, it's still present.

James




[PATCH v2 1/7] lib: string: add functions to case-convert strings

2016-07-07 Thread Eric Engestrom
On Tue, Jul 05, 2016 at 01:47:05PM -0700, Markus Mayer wrote:
> All functions return a pointer to the terminating '\0' character in the
> modified string ("dst" or "s", respectively).

I think this is going to be confusing. From the man:

The strcpy() and strncpy() functions return a pointer to the
destination string dest.

I think it would be better to keep the same behaviour, especially since
you used the same name for your functions (which I think is sensible),
not to mention you don't use this return value in any of your calls.
(IMHO strcpy() shouldn't have had a return value and neither should your
functions, but since it does, yours should match.)

Cheers,
  Eric


[PATCH] drm: atmel-hlcdc: Fix vertical scaling

2016-07-07 Thread Boris Brezillon
From: Jan Leupold 

The code is applying the same scaling for the X and Y components,
thus making the scaling feature only functional when both components
have the same scaling factor.

Do the s/_w/_h/ replacement where appropriate to fix vertical scaling.

Signed-off-by: Jan Leupold 
Fixes: 1a396789f65a2 ("drm: add Atmel HLCDC Display Controller support")
Cc: 
Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 016c191221f3..52c527f6642a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -320,19 +320,19 @@ atmel_hlcdc_plane_update_pos_and_size(struct 
atmel_hlcdc_plane *plane,
u32 *coeff_tab = heo_upscaling_ycoef;
u32 max_memsize;

-   if (state->crtc_w < state->src_w)
+   if (state->crtc_h < state->src_h)
coeff_tab = heo_downscaling_ycoef;
for (i = 0; i < ARRAY_SIZE(heo_upscaling_ycoef); i++)
atmel_hlcdc_layer_update_cfg(&plane->layer,
 33 + i,
 0x,
 coeff_tab[i]);
-   factor = ((8 * 256 * state->src_w) - (256 * 4)) /
-state->crtc_w;
+   factor = ((8 * 256 * state->src_h) - (256 * 4)) /
+state->crtc_h;
factor++;
-   max_memsize = ((factor * state->crtc_w) + (256 * 4)) /
+   max_memsize = ((factor * state->crtc_h) + (256 * 4)) /
  2048;
-   if (max_memsize > state->src_w)
+   if (max_memsize > state->src_h)
factor--;
factor_reg |= (factor << 16) | 0x8000;
}
-- 
2.7.4



[PATCH] drm/vmwgfx: Fix error paths when mapping framebuffer

2016-07-07 Thread Sinclair Yeh
Rather than returning immediately, make sure to unlock the
mutexes first.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Charmaine Lee 
Reported-by: Emil Velikov 
Cc: 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index 66eaa30..d2d9395 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -589,7 +589,7 @@ static int vmw_fb_set_par(struct fb_info *info)
ret = vfb->pin(vfb);
if (ret) {
DRM_ERROR("Could not pin the fbdev framebuffer.\n");
-   return ret;
+   goto out_unlock;
}

ret = ttm_bo_kmap(&par->vmw_bo->base, 0,
@@ -597,7 +597,7 @@ static int vmw_fb_set_par(struct fb_info *info)
if (ret) {
vfb->unpin(vfb);
DRM_ERROR("Could not map the fbdev framebuffer.\n");
-   return ret;
+   goto out_unlock;
}

par->bo_ptr = ttm_kmap_obj_virtual(&par->map, &par->bo_iowrite);
-- 
2.7.4



[PATCH] backlight: Avoid double fbcon backlight handling

2016-07-07 Thread Jiri Kosina
On Thu, 30 Jun 2016, Chris Wilson wrote:

> Backlights controlled by i915.ko and only associated with its connectors
> and also only associated with the intel_drmfb fbcon, controlled by
> i915.ko. In this situation, we already handle adjusting the backlight
> when the fbcon is blanked/unblanked and do not require backlight trying
> to do the same.
> 
> Attempting to register with the fbdev as a client causes lockdep to warn
> about a dependency cycle:
[ ... snip ... ]
>  drivers/hid/hid-picolcd_backlight.c  |  3 ++-

For this one:

Acked-by: Jiri Kosina 

-- 
Jiri Kosina
SUSE Labs



[PATCH 0/3] imx drm atomic mode setting fixups

2016-07-07 Thread Philipp Zabel
Hi Liu,

Am Donnerstag, den 07.07.2016, 15:44 +0800 schrieb Ying Liu:
> Hi Philipp,
> 
> On Wed, Jul 6, 2016 at 11:52 PM, Philipp Zabel  
> wrote:
> > Hi,
> >
> > I have tested Liu Ying's imx drm atomic mode setting conversion series [1]
> 
> Thanks for the testing!
[...]
> I didn't program imx_ldb_ch->imx_encoder.bus_format correctly
> in imx_ldb_connector_get_modes() - I forgot to translate the bus format
> from LVDS bus format to internal bus format.  Also, data width and
> LVDS data mapping(SPWG/JEIDA) can be set to ldb->ldb_ctrl in
> the function. So, one option to fix the issue you found is to simply
> modify the function and respin the particular patch in my patch set.
> Actually, I have got a fix tested with the format determined by the panel.
> 
> I don't have strong opinion on storing bus_format, bus_flags and
> di_*sync_pin in imx_crtc_state.  But, very likely, they will not be
> dynamically changed.  Setting them again and again at atomic_check
> is somewhat wasting CPU cycles...

That really only should be a concern if you can measure the difference.
Further, with upcoming bridge support in the parallel-display and
imx-ldb drivers the encoder doesn't have direct access to the connector
anymore (get_modes is handled by the bridges' connector). I could also
think of bridges where the optimal input bus_format depends on the mode.
So I'd prefer the internal bus configuration to reside in imx_crtc_state
instead of imx_encoder.

> BTW, the imx-drm atomic conversion patch set has reached version 3
> which uses the new non-blocking atomic commit helpers.

Yes, thank you for the update. I chose the wrong link, I have tested
version 3. If you are willing to respin your series once more, feel free
to integrate all or part of my changes in the appropriate places (the
mode_set removal could be squashed into the "Legacy callback fixups"
patch, for example). I could then retest and potentially rebase the
remaining changes on your next version.

regards
Philipp



[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-07-07 Thread James Bottomley
On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > Cc: Ville
> > > > 
> > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > James.Bottomley at HansenPartnership.com> wrote:
> > > > > OK, my candidate bad commit is this one:
> > > > > 
> > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > Author: Ville Syrjälä 
> > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > 
> > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > 
> > > > > After being more careful about waiting to identify flicker, 
> > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > seeing no flicker problems.   It is, however, early days 
> > > > > because the flicker can hide for long periods, so I 'll wait 
> > > > > until Monday evening and a few reboots before declaring
> > > > > victory.
> > > > 
> > > > If that turns out to be the bad commit, it doesn't really 
> > > > surprise me, and that in itself is depressing.
> > > 
> > > As far as I can tell, after running for a day with this reverted, 
> > > this is the problem.  The flicker hasn't appeared with it 
> > > reverted.  It's pretty noticeable with this commit included.
> > 
> > Hmm. The only difference I can see is low vs. normal vswing. Panel 
> > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > telling utter lies, or there's some other bug in our low vswing
> > support.
> 
> I did a quick once over of out DDI vswing stuff and didn't find 
> anything too serious. There were some buglets in the iboost handling, 
> but I'm not very hopeful that fixing those would help with your 
> machine. 
> 
> Here's a branch anyway in case you want to give it a go:
> git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> 
> Actually, I think the only patch in there that might make a 
> difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> with 4 lanes on SKL")

Running with it now (the entire branch).  So far it looks OK, but I'll
give it a couple of days to see if anything manifests before declaring
victory.

James



[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #21 from Bart van Heukelom  ---
Another Awesomenauts developer here. I don't know much about our OpenGL code,
but I do about our Linux version. Our linking options in CMakeLists are as
follows:

SET_TARGET_PROPERTIES(Awesomenauts
PROPERTIES
LINK_FLAGS_RELEASE "-Wl,--allow-shlib-undefined,-s,-x"

We don't do anything special with libstdc++

-- 
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/20160707/dd522995/attachment.html>


[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-07 Thread Christian König
Am 07.07.2016 um 05:32 schrieb Michel Dänzer:
> On 06.07.2016 22:45, Tejun Heo wrote:
>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
>>
>>> Not being very familiar with the workqueue APIs, I'll describe how it's
>>> supposed to work from a driver POV, which will hopefully help you guys
>>> decide on the most appropriate alloc_workqueue parameters.
>>>
>>> There is one flip work queue for each hardware CRTC. At most one
>>> radeon_flip_work_func item can be queued for any of them at any time.
>>> When a radeon_flip_work_func item is queued, it should be executed ASAP
>>> (so WQ_HIGHPRI might be appropriate?).
>> Hmmm... the only time WQ_HIGHPRI should be used is when it'd otherwise
>> require a kthread w/ nice value at -20.  Would that be the case here?
>> What are the consequences of the work item getting delayed?
> A page flip may be delayed to a later display refresh cycle.
>
>
>> Also, what kind of delays matter here?  Is it millisec range or micro?
> It can be the latter in theory, but normally rather the former.

Well to be precise with a typical 1920x1080 at 60 resolution you have about 
2.16ms time under ideal conditions for the flip.

So using the high priority queue still sounds like a good idea to me.

Regards,
Christian.


[PATCH 06/64] drm: Restore double clflush on the last partial cacheline

2016-07-07 Thread Chris Wilson
This effectively reverts

commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson 
Date:   Wed Jun 10 15:58:01 2015 +0100

drm: Avoid the double clflush on the last cache line in 
drm_clflush_virt_range()

as we have observed issues with serialisation of the clflush operations
on Baytrail+ Atoms with partial updates. Applying the double flush on the
last cacheline forces that clflush to be ordered with respect to the
previous clflush, and the mfence then protects against prefetches crossing
the clflush boundary.

The same issue can be demonstrated in userspace with igt/gem_exec_flush.

Fixes: afcd950cafea6 (drm: Avoid the double clflush on the last cache...)
Testcase: igt/gem_concurrent_blit
Testcase: igt/gem_partial_pread_pwrite
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92845
Signed-off-by: Chris Wilson 
Cc: dri-devel at lists.freedesktop.org
Cc: Akash Goel 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Cc: stable at vger.kernel.org
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/drm_cache.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 059f7c39c582..a7916e5f8864 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -136,6 +136,7 @@ drm_clflush_virt_range(void *addr, unsigned long length)
mb();
for (; addr < end; addr += size)
clflushopt(addr);
+   clflushopt(end - 1); /* force serialisation */
mb();
return;
}
-- 
2.8.1



[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #20 from Michel Dänzer  ---
Presumably it works with valgrind because it prevents the fatal effect of the
bad memory access which causes the problem. Note that valgrind stopped logging
errors after 1000 instances of the same (presumably harmless) issue in the
Awesomenauts code. Maybe there's some way to suppress those, so we can see the
problem?

-- 
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/20160707/db5b23b7/attachment.html>


[Bug 96835] "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96835

--- Comment #2 from raffarti at zoho.com ---
Created attachment 124940
  --> https://bugs.freedesktop.org/attachment.cgi?id=124940&action=edit
steam gdb backtrace

Steam crashes (it's 32 bit)

-- 
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/20160707/c6dac45b/attachment.html>


[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #19 from Quentin Quaadgras  ---
LIBGL_ALWAYS_SOFTWARE=y results in the game correctly launching.

-- 
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/20160707/410f40c4/attachment.html>


[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #18 from Nicolai Hähnle  ---
Sorry, I don't know what the difference could be in the Valgrind runs. For
completeness, could you try whether the game also crashes with
LIBGL_ALWAYS_SOFTWARE=y?

-- 
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/20160707/6aaa8ce0/attachment.html>


[Bug 96838] No console/display output on front/secondary VGA

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96838

Claudio Kuenzler  changed:

   What|Removed |Added

   Priority|medium  |lowest

-- 
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/20160707/430bacea/attachment.html>


[Bug 96838] No console/display output on front/secondary VGA

2016-07-07 Thread bugzilla-dae...@freedesktop.org
-3: new high-speed USB device number 2 using ehci-pci
[3.482857] clocksource: Switched to clocksource tsc
[3.482891] Console: switching to colour frame buffer device 128x48
[3.491157] radeon :09:0d.0: fb0: radeondrmfb frame buffer device
[3.500049] [drm] Initialized radeon 2.45.0 20080528 for :09:0d.0 on
minor 0



And when I switched the VGA connectors:

[ 6613.913005] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 92
[ 6613.913151] Raw EDID:
[ 6613.913183] 00 ff ff ff ff ff ff 00 10 ac 07 a0 4c 4b 34 30
[ 6613.913255] 04 0f 01 03 0e 29 1f ff ff ff ff ff ff ff ff ff
[ 6613.91] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 6613.913405] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 6613.913484] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 6613.913562] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 6613.913633] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 6613.913711] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 6613.914978] [drm:radeon_vga_detect [radeon]] *ERROR* VGA-2: probed a monitor
but no|invalid EDID



Let me know if you need more information.
Attached is the full dmesg output.

-- 
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/20160707/e1a9a9dc/attachment-0001.html>


[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #17 from Quentin Quaadgras  ---
Multithreading setting has no effect for me, @Nicolai is there any workaround
then? The game was running under Valgrind, I am not so familiar with the
software, is it doing anything differently in regards to the libraries it
loads?

-- 
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/20160707/0a0c0519/attachment-0001.html>


[Bug 96835] "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash

2016-07-07 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96835

Michel Dänzer  changed:

   What|Removed |Added

 CC||chuck.atkins at kitware.com

--- Comment #1 from Michel Dänzer  ---
Please attach a gdb backtrace of a crash.

-- 
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/20160707/580d7390/attachment.html>