Re: [PATCH 5/5] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Liviu Dudau]

On Tue, Jan 23, 2018 at 07:08:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
> 
> v2: Convert armada, rcar, and sun4i as well
> 
> Cc: Liviu Dudau <liviu.du...@arm.com>
> Cc: Brian Starkey <brian.star...@arm.com>
> Cc: Mali DP Maintainers <mal...@foss.arm.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Gustavo Padovan <gust...@padovan.org>
> Cc: Sean Paul <seanp...@chromium.org>
> Cc: Philipp Zabel <p.za...@pengutronix.de>
> Cc: CK Hu <ck...@mediatek.com>
> Cc: Neil Armstrong <narmstr...@baylibre.com>
> Cc: Rob Clark <robdcl...@gmail.com>
> Cc: Ben Skeggs <bske...@redhat.com>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: Sandy Huang <h...@rock-chips.com>
> Cc: "Heiko Stübner" <he...@sntech.de>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Cc: VMware Graphics <linux-graphics-maintai...@vmware.com>
> Cc: Sinclair Yeh <s...@vmware.com>
> Cc: Thomas Hellstrom <thellst...@vmware.com>
> Cc: Shawn Guo <shawn...@kernel.org>
> Cc: Archit Taneja <arch...@codeaurora.org>
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: Russell King <rmk+ker...@armlinux.org.uk>
> Suggested-by: Daniel Vetter <dan...@ffwll.ch>
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> Reviewed-by: Thierry Reding <tred...@nvidia.com>
> Reviewed-by: Archit Taneja <arch...@codeaurora.org> #msm
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  7 +--
>  drivers/gpu/drm/arm/malidp_planes.c |  7 +--
>  drivers/gpu/drm/armada/armada_crtc.c|  8 ++--
>  drivers/gpu/drm/armada/armada_overlay.c |  8 ++--
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  drivers/gpu/drm/drm_plane_helper.c  | 11 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  6 --
>  drivers/gpu/drm/i915/intel_display.c| 12 
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  7 +--
>  drivers/gpu/drm/meson/meson_plane.c |  7 +--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
>  drivers/gpu/drm/nouveau/nv50_display.c  | 12 
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  7 +--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 +--
>  drivers/gpu/drm/sun4i/sun8i_ui_layer.c  |  7 +--
>  drivers/gpu/drm/sun4i/sun8i_vi_layer.c  |  7 +--
>  drivers/gpu/drm/tegra/plane.c   |  7 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  7 +--
>  drivers/gpu/drm/zte/zx_plane.c  | 13 +
>  include/drm/drm_atomic_helper.h |  1 -
>  include/drm/drm_plane_helper.h  |  1 -
>  22 files changed, 28 insertions(+), 147 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 877647ef35a9..cf5cbd63ecdf 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs 
> hdlcd_crtc_helper_funcs = {
>  static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
> - struct drm_rect clip = { 0 };
>   struct drm_crtc_state *crtc_state;
>   u32 src_h = state->src_h >> 16;
>  
> @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
> *plane,
>   return -EINVAL;
>   }
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - return drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + return drm_atomic_helper_check_plane_state(state, crtc_state,
>  DRM_PLANE_HELPER_NO_SCALING,
>  DRM_PLANE_HELPER_NO_SCALING,
>  false, true);
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> 

Re: [PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

[Liviu Dudau]

On Tue, Nov 14, 2017 at 05:34:14AM +0200, Laurent Pinchart wrote:
> Hi Liviu,

Hi Laurent,

> 
> On Monday, 13 November 2017 13:53:14 EET Liviu Dudau wrote:
> > On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote:
> > > When the DU sources its frames from a VSP, it performs no memory access
> > > and thus has no requirements on imported dma-buf memory types. In
> > > particular the DU could import a physically non-contiguous buffer that
> > > would later be mapped contiguously through the VSP IOMMU.
> > > 
> > > This use case isn't supported at the moment as the GEM CMA helpers will
> > > reject any non-contiguous buffer, and the DU isn't connected to an IOMMU
> > > that can make the buffer contiguous for DMA. Fix this by implementing a
> > > custom .gem_prime_import_sg_table() operation that accepts all imported
> > > dma-buf regardless of the number of scatterlist entries.
> > 
> > This patch raises the question of why use CMA at all if you can accept
> > any kind of buffers.
> 
> Both the DU and VSP require DMA contiguous memory. On R-Car Gen2 the DU 
> performs DMA, and thus uses the GEM CMA helpers. On Gen3 it delegates DMA to 
> the external VSP composer, and still uses the GEM CMA helpers to ensure that 
> memory will be DMA contiguous for the VSP. The problem arises when physically 
> non-contiguous dma-buf buffers are imported, they can be mapped contiguously 
> to the VSP (assuming an IOMMU is present) but not to the DU (as there's no 
> IOMMU).
> 
> The situation is particularly messy due to the fact that I have one VSP 
> instance per CRTC, each connected to its own IOMMU channel. The driver thus 
> doesn't know when allocating GEM objects to which struct device they need to 
> be mapped. The DRM helpers don't support delayed mapping of memory. I'd like 
> to know whether that's something I should fix properly (which would likely 
> involve major reworking of the helpers) or hack around it in the DU driver.

I understand. Looks like you have your hands full with an "interesting"
architecture.

> 
> > > Signed-off-by: Laurent Pinchart
> > > <laurent.pinchart+rene...@ideasonboard.com>
> > > ---
> > > 
> > >  drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
> > >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 ++
> > >  drivers/gpu/drm/rcar-du/rcar_du_kms.h |  7 +++
> > >  3 files changed, 47 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 48c166f925a3..d999231f98c7
> > > 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > @@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = {
> > >   .gem_prime_import   = drm_gem_prime_import,
> > >   .gem_prime_export   = drm_gem_prime_export,
> > >   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> > > - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> > > + .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table,
> > >   .gem_prime_vmap = drm_gem_cma_prime_vmap,
> > >   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> > >   .gem_prime_mmap = drm_gem_cma_prime_mmap,
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 566d1a948c8f..2dd0c2ba047d
> > > 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> 
> [snip]
> 
> > > +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct
> > > drm_device *dev,
> > > + struct dma_buf_attachment *attach,
> > > + struct sg_table *sgt)
> > > +{
> > > + struct rcar_du_device *rcdu = dev->dev_private;
> > > + struct drm_gem_cma_object *cma_obj;
> > > + struct drm_gem_object *gem_obj;
> > > + int ret;
> > > +
> > > + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
> > > + return drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
> > > +
> > > + /* Create a CMA GEM buffer. */
> > > + cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> > > + if (!cma_obj)
> > > + return ERR_PTR(-ENOMEM);
> > > + gem_obj = _obj->base;
> > > +
> > > + ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size);
> > > + if (ret)
> > > + got

Re: [PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

[Liviu Dudau]

On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote:
> When the DU sources its frames from a VSP, it performs no memory access
> and thus has no requirements on imported dma-buf memory types. In
> particular the DU could import a physically non-contiguous buffer that
> would later be mapped contiguously through the VSP IOMMU.
> 
> This use case isn't supported at the moment as the GEM CMA helpers will
> reject any non-contiguous buffer, and the DU isn't connected to an IOMMU
> that can make the buffer contiguous for DMA. Fix this by implementing a
> custom .gem_prime_import_sg_table() operation that accepts all imported
> dma-buf regardless of the number of scatterlist entries.

This patch raises the question of why use CMA at all if you can accept
any kind of buffers.

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 
> +++
>  drivers/gpu/drm/rcar-du/rcar_du_kms.h |  7 +++
>  3 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 48c166f925a3..d999231f98c7 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = {
>   .gem_prime_import   = drm_gem_prime_import,
>   .gem_prime_export   = drm_gem_prime_export,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> + .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
>   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
>   .gem_prime_mmap = drm_gem_cma_prime_mmap,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 566d1a948c8f..2dd0c2ba047d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -148,6 +149,44 @@ const struct rcar_du_format_info 
> *rcar_du_format_info(u32 fourcc)
>   * Frame buffer
>   */
>  
> +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device 
> *dev,
> + struct dma_buf_attachment *attach,
> + struct sg_table *sgt)
> +{
> + struct rcar_du_device *rcdu = dev->dev_private;
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *gem_obj;
> + int ret;
> +
> + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
> + return drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
> +
> + /* Create a CMA GEM buffer. */
> + cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> + if (!cma_obj)
> + return ERR_PTR(-ENOMEM);
> + gem_obj = _obj->base;
> +
> + ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size);
> + if (ret)
> + goto error;
> +
> + ret = drm_gem_create_mmap_offset(gem_obj);
> + if (ret) {
> + drm_gem_object_release(gem_obj);
> + goto error;
> + }
> +
> + cma_obj->paddr = 0;

This is going to break drm_gem_cma_describe() if you are using it plus
the rcar_du_plane_setup_scanout() unless I'm missing something besides
familiarity with the RCAR driver code :)

This function looks very similar to what I tried to do for mali-dp to
allow the import of contiguous DMA buffers that have more than 1 sgt
entries. In the end I gave up as I kept finding issues and went for the
drm_gem_cma_prime_import_sg_table() changes. Maybe you need to do a
similar change in the function to bypass some requirements if the driver
signals that it can accept relaxed requirements?

Best regards,
Liviu

> + cma_obj->sgt = sgt;
> +
> + return gem_obj;
> +
> +error:
> + kfree(cma_obj);
> + return ERR_PTR(ret);
> +}
> +
>  int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
>   struct drm_mode_create_dumb *args)
>  {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
> index 07951d5fe38b..10b2bb0f0df9 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
> @@ -16,10 +16,13 @@
>  
>  #include 
>  
> +struct dma_buf_attachment;
>  struct drm_file;
>  struct drm_device;
> +struct drm_gem_object;
>  struct drm_mode_create_dumb;
>  struct rcar_du_device;
> +struct sg_table;
>  
>  struct rcar_du_format_info {
>   u32 fourcc;
> @@ -36,4 +39,8 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu);
>  int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
>   struct drm_mode_create_dumb *args);
>  
> +struct 

Re: [PATCH/RFC 1/2] drm: rcar-du: Set the DMA coherent mask for the DU device

[Liviu Dudau]

On Mon, Nov 13, 2017 at 12:32:27PM +0200, Laurent Pinchart wrote:
> The DU DMA address space is limited to 32 bits, so the DMA coherent mask
> should be set accordingly. The DMA mapping implementation will
> transparently map high memory buffers to 32-bit addresses through an
> IOMMU when present (or through bounce buffers otherwise, which isn't a
> supported use case as performances would be terrible).
> 
> However, when sourcing frames from a VSP, the situation is more
> complicated. The DU delegates all memory accesses to the VSP and doesn't
> perform any DMA access by itself. Due to how the GEM CMA helpers are
> structured buffers are still mapped to the DU device. They are later
> mapped to the VSP as well to perform DMA access, through the IOMMU
> connected to the VSP.
> 
> Setting the DMA coherent mask to 32 bits for the DU when using a VSP can
> cause issues when importing a dma_buf. If the buffer is located above
> the 32-bit address space, the DMA mapping implementation will try to map
> it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer
> will be allocated, which in the best case will waste memory and in the
> worst case will just fail.
> 
> To work around this issue, set the DMA coherent mask to the full 40-bit
> address space for the DU. All dma-buf instances will be imported without
> any restriction, and will be mapped to the VSP when preparing the
> associated framebuffer.

This does indeed look like a work around, but I can't see anything wrong
with it.

Reviewed-by: Liviu Dudau <liviu.du...@arm.com>

> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 6e02c762a557..48c166f925a3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -370,6 +370,7 @@ static int rcar_du_probe(struct platform_device *pdev)
>   struct rcar_du_device *rcdu;
>   struct drm_device *ddev;
>   struct resource *mem;
> + unsigned int mask;
>   int ret;
>  
>   /* Allocate and initialize the R-Car device structure. */
> @@ -388,6 +389,16 @@ static int rcar_du_probe(struct platform_device *pdev)
>   if (IS_ERR(rcdu->mmio))
>   return PTR_ERR(rcdu->mmio);
>  
> + /*
> +  * Set the DMA coherent mask to reflect the DU 32-bit DMA address space
> +  * limitations. When sourcing frames from a VSP the DU doesn't perform
> +  * any memory access so set the mask to 40 bits to accept all buffers.
> +  */
> + mask = rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE) ? 40 : 32;
> + ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(mask));
> + if (ret)
> + return ret;
> +
>   /* DRM/KMS objects */
>   ddev = drm_dev_alloc(_du_driver, >dev);
>   if (IS_ERR(ddev))
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

Re: [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

[Liviu Dudau]

On Tue, Jul 25, 2017 at 10:01:19AM +0200, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
> 
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Liviu Dudau <liviu.du...@arm.com>
> Cc: Brian Starkey <brian.star...@arm.com>
> Cc: Mali DP Maintainers <mal...@foss.arm.com>
> Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Sean Paul <seanp...@chromium.org>
> Cc: David Airlie <airl...@linux.ie>
> Cc: Inki Dae <inki@samsung.com>
> Cc: Joonyoung Shim <jy0922.s...@samsung.com>
> Cc: Seung-Woo Kim <sw0312@samsung.com>
> Cc: Kyungmin Park <kyungmin.p...@samsung.com>
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: Krzysztof Kozlowski <k...@kernel.org>
> Cc: Ben Skeggs <bske...@redhat.com>
> Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org>
> Cc: Vincent Abriou <vincent.abr...@st.com>
> Cc: Yannick Fertre <yannick.fer...@st.com>
> Cc: Philippe Cornu <philippe.co...@st.com>
> Cc: Jyri Sarha <jsa...@ti.com>
> Cc: "Ville Syrjälä" <ville.syrj...@linux.intel.com>
> Cc: Rongrong Zou <zourongr...@gmail.com>
> Cc: Shawn Guo <shawn@linaro.org>
> Cc: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Eric Engestrom <e...@engestrom.ch>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Rob Clark <robdcl...@gmail.com>
> Cc: Archit Taneja <arch...@codeaurora.org>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: Thomas Hellstrom <thellst...@vmware.com>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> ---
>  drivers/gpu/drm/arm/malidp_planes.c |  1 -
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  1 -
>  drivers/gpu/drm/drm_atomic.c|  3 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 55 
> -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c   |  1 -
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 -
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
>  drivers/gpu/drm/i915/intel_display.c|  2 -
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  2 -
>  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
>  drivers/gpu/drm/omapdrm/omap_plane.c|  1 -
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  1 -
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  1 -
>  drivers/gpu/drm/sti/sti_cursor.c|  1 -
>  drivers/gpu/drm/sti/sti_gdp.c   |  1 -
>  drivers/gpu/drm/sti/sti_hqvdp.c |  1 -
>  drivers/gpu/drm/stm/ltdc.c  |  1 -
>  drivers/gpu/drm/tilcdc/tilcdc_plane.c   |  1 -
>  include/drm/drm_atomic.h|  3 --
>  include/drm/drm_atomic_helper.h |  3 --
>  20 files changed, 1 insertion(+), 81 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 600fa7bd7f52..0f0f8234fe21 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -128,7 +128,6 @@ static void malidp_plane_atomic_print_state(struct 
> drm_printer *p,
>  static const struct drm_plane_funcs malidp_de_plane_funcs = {
>   .update_plane = drm_atomic_helper_update_plane,
>   .disable_plane = drm_atomic_helper_disable_plane,
> - .set_property = drm_atomic_helper_plane_set_property,
>   .destroy = malidp_de_plane_destroy,
>   .reset = malidp_plane_reset,
>   .atomic_duplicate_state = malidp_duplicate_plane_state,

For mali-dp changes:
Acked-by: Liviu Dudau <liviu.du...@arm.com>

I'm assuming the series goes through drm-next tree.

Thanks,
Liviu

> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index b5bd9b005225..9cd9e23e75c6 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -1052,7 +1052,6 @@ static void 
> atmel_hlcdc_plane_atomic_destroy_state(struct drm_plane *p,
>  static struct drm_plane_funcs layer_plane_funcs = {
>   .update_plane = drm_atomic_helper_update_plane,
>   .disable_plane = drm_atomic_helper_disable_plane

Re: [PATCH 4/6] ARM: vexpress_defconfig: Cleanup from non-existing options

[Liviu Dudau]

On Mon, Jul 17, 2017 at 07:49:54AM +0200, Krzysztof Kozlowski wrote:
> ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30 ("ARM: vexpress:
> Remove non-DT code").
> 
> Signed-off-by: Krzysztof Kozlowski <k...@kernel.org>

Acked-by: Liviu Dudau <liviu.du...@arm.com>

Thanks for the cleanup!

Best regards,
Liviu

> ---
>  arch/arm/configs/vexpress_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/vexpress_defconfig 
> b/arch/arm/configs/vexpress_defconfig
> index 0fa0ed577b15..edae1c58fe80 100644
> --- a/arch/arm/configs/vexpress_defconfig
> +++ b/arch/arm/configs/vexpress_defconfig
> @@ -19,7 +19,6 @@ CONFIG_MODULE_UNLOAD=y
>  # CONFIG_IOSCHED_DEADLINE is not set
>  # CONFIG_IOSCHED_CFQ is not set
>  CONFIG_ARCH_VEXPRESS=y
> -CONFIG_ARCH_VEXPRESS_CA9X4=y
>  CONFIG_ARCH_VEXPRESS_DCSCB=y
>  CONFIG_ARCH_VEXPRESS_TC2_PM=y
>  # CONFIG_SWP_EMULATE is not set
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

Re: [PATCH 5/7] bus: vexpress-config: add missing of_node_put after calling of_parse_phandle

[Liviu Dudau]

On Fri, Jul 01, 2016 at 05:41:59PM +0800, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
> 
> Cc: Liviu Dudau <liviu.du...@arm.com>
> Cc: Sudeep Holla <sudeep.ho...@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Signed-off-by: Peter Chen <peter.c...@nxp.com>

Acked-by: Liviu Dudau <liviu.du...@arm.com>

> ---
>  drivers/bus/vexpress-config.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c
> index c3cb76b..9efdf1d 100644
> --- a/drivers/bus/vexpress-config.c
> +++ b/drivers/bus/vexpress-config.c
> @@ -178,6 +178,7 @@ static int vexpress_config_populate(struct device_node 
> *node)
>  
>   parent = class_find_device(vexpress_config_class, NULL, bridge,
>   vexpress_config_node_match);
> + of_node_put(bridge);
>   if (WARN_ON(!parent))
>   return -ENODEV;
>  
> -- 
> 1.9.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯