Re: [PATCH 4/8] clk: renesas: cpg-mssr: Add support for reset control

[Philipp Zabel]

Hi Geert,

On Fri, 2017-01-20 at 15:08 +0100, Geert Uytterhoeven wrote:
> Add optional support for the Reset Control feature of the Renesas Clock
> Pulse Generator / Module Standby and Software Reset module on R-Car
> Gen2, R-Car Gen3, and RZ/G1 SoCs.

Is there a reason to make this optional?

> This allows to reset SoC devices using the Reset Controller API.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Looks good to me,

Acked-by: Philipp Zabel <p.za...@pengutronix.de>

Just a small issue below,

> ---
>  drivers/clk/renesas/renesas-cpg-mssr.c | 122 
> +
>  1 file changed, 122 insertions(+)
> 
> diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c 
> b/drivers/clk/renesas/renesas-cpg-mssr.c
> index f1161a585c57e433..ea4af714ac14603a 100644
> --- a/drivers/clk/renesas/renesas-cpg-mssr.c
> +++ b/drivers/clk/renesas/renesas-cpg-mssr.c
[...]
> +static int cpg_mssr_reset(struct reset_controller_dev *rcdev,
> +   unsigned long id)
> +{
> + struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
> + unsigned int reg = id / 32;
> + unsigned int bit = id % 32;
> + u32 bitmask = BIT(bit);

Here you have a bitmask = BIT(bit) variable.

> + unsigned long flags;
> + u32 value;
> +
> + dev_dbg(priv->dev, "reset %u%02u\n", reg, bit);
> +
> + /* Reset module */
> + spin_lock_irqsave(>rmw_lock, flags);
> + value = readl(priv->base + SRCR(reg));
> + value |= bitmask;

Here you use it.

> + writel(value, priv->base + SRCR(reg));
> + spin_unlock_irqrestore(>rmw_lock, flags);
> +
> + /* Wait for at least one cycle of the RCLK clock (@ ca. 32 kHz) */
> + udelay(35);
> +
> + /* Release module from reset state */
> + writel(bitmask, priv->base + SRSTCLR(reg));
> +
> + return 0;
> +}
> +
> +static int cpg_mssr_assert(struct reset_controller_dev *rcdev, unsigned long 
> id)
> +{
> + struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
> + unsigned int reg = id / 32;
> + unsigned int bit = id % 32;

Here you haven't.

> + unsigned long flags;
> + u32 value;
> +
> + dev_dbg(priv->dev, "assert %u%02u\n", reg, bit);
> +
> + spin_lock_irqsave(>rmw_lock, flags);
> + value = readl(priv->base + SRCR(reg));
> + writel(value | BIT(bit), priv->base + SRCR(reg));

Here you don't.

> + spin_unlock_irqrestore(>rmw_lock, flags);
> + return 0;
> +}
> +
> +static int cpg_mssr_deassert(struct reset_controller_dev *rcdev,
> +  unsigned long id)
> +{
> + struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
> + unsigned int reg = id / 32;
> + unsigned int bit = id % 32;
> +
> + dev_dbg(priv->dev, "deassert %u%02u\n", reg, bit);
> +
> + writel(BIT(bit), priv->base + SRSTCLR(reg));

And here ...

> + return 0;
> +}
> +
> +static int cpg_mssr_status(struct reset_controller_dev *rcdev,
> +unsigned long id)
> +{
> + struct cpg_mssr_priv *priv = rcdev_to_priv(rcdev);
> + unsigned int reg = id / 32;
> + unsigned int bit = id % 32;
> +
> + return !!(readl(priv->base + SRCR(reg)) & BIT(bit));

And here neither.

I'd choose one variant over the other for consistency.

regards
Philipp

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

 A. Hi Geert,

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Hi Philipp, Mike, Stephen, Simon, Magnus,
>   (see questions *** below!)
> 
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
> 
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
> 
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().

I think you should add a binding doc even though the DT bindings are
still trivial.

> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> 
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>  driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>  files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>  RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>  from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
> 
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
> Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
> code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
> in Part C,
>   - The block driver cleanups in part E depend on the board code
> cleanups in part D.
> 
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
> 
> ***
> 
>   - Philip: While this is a driver for a reset-controller, currently it
> doesn't provide any reset-controller functionality. Hence I added it
> to drivers/soc/renesas/. Is that OK for you?

Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.

regards
Philipp

Re: [PATCH] backlight: pwm_bl: Fix GPIO out for unimplemented .get_direction()

[Philipp Zabel]

On Wed, 2017-03-22 at 18:21 +0100, Geert Uytterhoeven wrote:
> Commit 7613c922315e308a ("backlight: pwm_bl: Move the checks for initial
> power state to a separate function") not just moved some code, but made
> slight changes in semantics.
> 
> If a gpiochip doesn't implement the optional .get_direction() callback,
> gpiod_get_direction always returns -EINVAL, which is never equal to
> GPIOF_DIR_IN, leading to the GPIO not being configured for output.
>
> To avoid this, invert the test and check for not GPIOF_DIR_OUT instead,
> like the original code did.
> 
> This restores the display on r8a7740/armadillo.
> 
> Fixes: 7613c922315e308a ("backlight: pwm_bl: Move the checks for initial 
> power state to a separate function")
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Acked-by: Philipp Zabel <p.za...@pengutronix.de>

regards
Philipp

> ---
>  drivers/video/backlight/pwm_bl.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index d7efcb632f7d9dde..002f1ce22bd02032 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -297,14 +297,15 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
>   }
>  
>   /*
> -  * If the GPIO is configured as input, change the direction to output
> -  * and set the GPIO as active.
> +  * If the GPIO is not known to be already configured as output, that
> +  * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
> +  * change the direction to output and set the GPIO as active.
>* Do not force the GPIO to active when it was already output as it
>* could cause backlight flickering or we would enable the backlight too
>* early. Leave the decision of the initial backlight state for later.
>*/
>   if (pb->enable_gpio &&
> - gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN)
> + gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
>   gpiod_direction_output(pb->enable_gpio, 1);
>  
>   pb->power_supply = devm_regulator_get(>dev, "power");

Re: [PATCH] gpu: Convert to using %pOF instead of full_name

[Philipp Zabel]

On Tue, 2017-07-18 at 16:43 -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring <r...@kernel.org>
> Cc: Russell King <li...@armlinux.org.uk>
> Cc: David Airlie <airl...@linux.ie>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Sean Paul <seanp...@chromium.org>
> 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: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Xinliang Liu <z.liuxinli...@hisilicon.com>
> Cc: Rongrong Zou <zourongr...@gmail.com>
> Cc: Xinwei Kong <kong.kongxin...@hisilicon.com>
> Cc: Chen Feng <puck.c...@hisilicon.com>
> Cc: CK Hu <ck...@mediatek.com>
> Cc: Philipp Zabel <p.za...@pengutronix.de>
> Cc: Matthias Brugger <matthias@gmail.com>
> Cc: Neil Armstrong <narmstr...@baylibre.com>
> Cc: Carlo Caione <ca...@caione.org>
> Cc: Kevin Hilman <khil...@baylibre.com>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: Mark Yao <mark@rock-chips.com>
> Cc: Heiko Stuebner <he...@sntech.de>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Jyri Sarha <jsa...@ti.com>
> Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> ---

Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>

regards
Philipp

Re: [PATCH v2 5/8] media: v4l2-mediabus: convert flags to enums and document them

[Philipp Zabel]

On Tue, 2017-12-19 at 09:18 -0200, Mauro Carvalho Chehab wrote:
> There is a mess with media bus flags: there are two sets of
> flags, one used by parallel and ITU-R BT.656 outputs,
> and another one for CSI2.
> 
> Depending on the type, the same bit has different meanings.
> 
> That's very confusing, and counter-intuitive. So, split them
> into two sets of flags, inside an enum.
> 
> This way, it becomes clearer that there are two separate sets
> of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
> need a different set of flags.
> 
> As a side effect, enums can be documented via kernel-docs,
> so there will be an improvement at flags documentation.
> 
> Unfortunately, soc_camera and pxa_camera do a mess with
> the flags, using either one set of flags without proper
> checks about the type. That could be fixed, but, as both drivers
> are obsolete and in the process of cleanings, I opted to just
> keep the behavior, using an unsigned int inside those two
> drivers.
> 
> Acked-by: Hans Verkuil <hans.verk...@cisco.com>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

For imx-media,
Acked-by: Philipp Zabel <p.za...@pengutronix.de>

thanks
Philipp

Re: [PATCH 3/8] media: v4l2-async: simplify v4l2_async_subdev structure

[Philipp Zabel]

On Mon, 2017-12-18 at 17:53 -0200, Mauro Carvalho Chehab wrote:
> The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> match criteria requires just a device name.
> 
> So, it doesn't make sense to enclose those into structs,
> as the criteria can go directly into the union.
> 
> That makes easier to document it, as we don't need to document
> weird senseless structs.
> 
> At drivers, this makes even clearer about the match criteria.
> 
> Acked-by: Sylwester Nawrocki <s.nawro...@samsung.com>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Thanks, this does improve readability in the drivers. For imx-media,

Acked-by: Philipp Zabel <p.za...@pengutronix.de>

regards
Philipp

> ---
>  drivers/media/platform/am437x/am437x-vpfe.c|  6 +++---
>  drivers/media/platform/atmel/atmel-isc.c   |  2 +-
>  drivers/media/platform/atmel/atmel-isi.c   |  2 +-
>  drivers/media/platform/davinci/vpif_capture.c  |  4 ++--
>  drivers/media/platform/exynos4-is/media-dev.c  |  4 ++--
>  drivers/media/platform/pxa_camera.c|  2 +-
>  drivers/media/platform/qcom/camss-8x16/camss.c |  2 +-
>  drivers/media/platform/rcar-vin/rcar-core.c|  2 +-
>  drivers/media/platform/rcar_drif.c |  4 ++--
>  drivers/media/platform/soc_camera/soc_camera.c |  2 +-
>  drivers/media/platform/stm32/stm32-dcmi.c  |  2 +-
>  drivers/media/platform/ti-vpe/cal.c|  2 +-
>  drivers/media/platform/xilinx/xilinx-vipp.c|  2 +-
>  drivers/media/v4l2-core/v4l2-async.c   | 16 
>  drivers/media/v4l2-core/v4l2-fwnode.c  | 10 +-
>  drivers/staging/media/imx/imx-media-dev.c  |  4 ++--
>  include/media/v4l2-async.h |  8 ++--
>  17 files changed, 35 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index 0997c640191d..601ae6487617 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2304,8 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier *notifier,
>   vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
>  
>   for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
> - if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
> - asd[i].match.fwnode.fwnode) {
> + if (vpfe->cfg->asd[i]->match.fwnode ==
> + asd[i].match.fwnode) {
>   sdinfo = >cfg->sub_devs[i];
>   vpfe->sd[i] = subdev;
>   vpfe->sd[i]->grp_id = sdinfo->grp_id;
> @@ -2510,7 +2510,7 @@ vpfe_get_pdata(struct platform_device *pdev)
>   }
>  
>   pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
> + pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
>   of_node_put(rem);
>   }
>  
> diff --git a/drivers/media/platform/atmel/atmel-isc.c 
> b/drivers/media/platform/atmel/atmel-isc.c
> index 0c2635647f69..34676409ca08 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -2088,7 +2088,7 @@ static int isc_parse_dt(struct device *dev, struct 
> isc_device *isc)
>   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
>  
>   subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - subdev_entity->asd->match.fwnode.fwnode =
> + subdev_entity->asd->match.fwnode =
>   of_fwnode_handle(rem);
>   list_add_tail(_entity->list, >subdev_entities);
>   }
> diff --git a/drivers/media/platform/atmel/atmel-isi.c 
> b/drivers/media/platform/atmel/atmel-isi.c
> index e900995143a3..9958918e2449 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -1128,7 +1128,7 @@ static int isi_graph_parse(struct atmel_isi *isi, 
> struct device_node *node)
>   /* Remote node to connect */
>   isi->entity.node = remote;
>   isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - isi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
>   return 0;
>   }
>  }
> diff --git a/drivers/media/platform/davinci/vpif_capture.c 
> b/drivers/media/platform/davinci/vpif_capture.c
> index e45916f69de

Re: [PATCH 5/8] media: v4l2-mediabus: convert flags to enums and document them

[Philipp Zabel]

Hi Mauro,

On Mon, 2017-12-18 at 17:53 -0200, Mauro Carvalho Chehab wrote:
> There is a mess with media bus flags: there are two sets of
> flags, one used by parallel and ITU-R BT.656 outputs,
> and another one for CSI2.
> 
> Depending on the type, the same bit has different meanings.
> 
> That's very confusing, and counter-intuitive. So, split them
> into two sets of flags, inside an enum.
> 
> This way, it becomes clearer that there are two separate sets
> of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
> need a different set of flags.
> 
> As a side effect, enums can be documented via kernel-docs,
> so there will be an improvement at flags documentation.
> 
> Unfortunately, soc_camera and pxa_camera do a mess with
> the flags, using either one set of flags without proper
> checks about the type. That could be fixed, but, as both drivers
> are obsolete and in the process of cleanings, I opted to just
> keep the behavior, using an unsigned int inside those two
> drivers.
> 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

If I am not mistaken this is missing a conversion of
drivers/staging/media/imx/imx-media-csi.c:

8<
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index eb7be5093a9d5..b1daac3a537d9 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -636,9 +636,10 @@ static int csi_setup(struct csi_priv *priv)
 
    /* compose mbus_config from the upstream endpoint */
    mbus_cfg.type = priv->upstream_ep.bus_type;
-   mbus_cfg.flags = (priv->upstream_ep.bus_type == V4L2_MBUS_CSI2) ?
-   priv->upstream_ep.bus.mipi_csi2.flags :
-   priv->upstream_ep.bus.parallel.flags;
+   if (priv->upstream_ep.bus_type == V4L2_MBUS_CSI2)
+   mbus_cfg.csi2_flags = priv->upstream_ep.bus.mipi_csi2.flags;
+   else
+   mbus_cfg.pb_flags = priv->upstream_ep.bus.parallel.flags;
 
/*
 * we need to pass input frame to CSI interface, but
>8

regards
Philipp

> ---
>  drivers/media/i2c/adv7180.c|  10 +-
>  drivers/media/i2c/ml86v7667.c  |   5 +-
>  drivers/media/i2c/mt9m111.c|   8 +-
>  drivers/media/i2c/ov6650.c |  19 +--
>  drivers/media/i2c/soc_camera/imx074.c  |   6 +-
>  drivers/media/i2c/soc_camera/mt9m001.c |  10 +-
>  drivers/media/i2c/soc_camera/mt9t031.c |  11 +-
>  drivers/media/i2c/soc_camera/mt9t112.c |  11 +-
>  drivers/media/i2c/soc_camera/mt9v022.c |  16 ++-
>  drivers/media/i2c/soc_camera/ov5642.c  |   5 +-
>  drivers/media/i2c/soc_camera/ov772x.c  |  10 +-
>  drivers/media/i2c/soc_camera/ov9640.c  |  10 +-
>  drivers/media/i2c/soc_camera/ov9740.c  |  10 +-
>  drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  12 +-
>  drivers/media/i2c/soc_camera/tw9910.c  |  13 +-
>  drivers/media/i2c/tc358743.c   |  10 +-
>  drivers/media/i2c/tvp5150.c|   6 +-
>  drivers/media/platform/pxa_camera.c|   8 +-
>  drivers/media/platform/rcar-vin/rcar-core.c|   4 +-
>  drivers/media/platform/rcar-vin/rcar-dma.c |   4 +-
>  .../platform/soc_camera/sh_mobile_ceu_camera.c |   2 +-
>  drivers/media/platform/soc_camera/soc_camera.c |   3 +-
>  .../platform/soc_camera/soc_camera_platform.c  |   2 +-
>  drivers/media/platform/soc_camera/soc_mediabus.c   |   2 +-
>  drivers/media/v4l2-core/v4l2-fwnode.c  |   5 +-
>  include/media/v4l2-fwnode.h|   4 +-
>  include/media/v4l2-mediabus.h  | 145 
> ++---
>  27 files changed, 218 insertions(+), 133 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 25d24a3f10a7..4bf25a72ef4f 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -743,16 +743,16 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
>  
>   if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
>   cfg->type = V4L2_MBUS_CSI2;
> - cfg->flags = V4L2_MBUS_CSI2_1_LANE |
> - V4L2_MBUS_CSI2_CHANNEL_0 |
> - V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
> + cfg->csi2_flags = V4L2_MBUS_CSI2_1_LANE
> +   | V4L2_MBUS_CSI2_CHANNEL_0
> +   | V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
>   } else {
>   /*
>* The ADV7180 sensor supports BT.601/656 output modes.
>* The BT.656 is default and not yet configurable by s/w.
>*/
> - cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
> - 

Re: [PATCH 2/2] vfio: platform: Add generic DT reset support

[Philipp Zabel]

Hi Geert,

On Thu, 2018-02-22 at 09:50 +0100, Geert Uytterhoeven wrote:
[...]
> > > @@ -127,8 +134,15 @@ static int vfio_platform_get_reset(struct 
> > > vfio_platform_device *vdev)
> > >   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
> > >   
> > > >reset_module);
> > >   }
> > > + if (vdev->of_reset)
> > > + return 0;
> > > +
> > > + vdev->reset_control = __of_reset_control_get(vdev->device->of_node,
> > > +  NULL, 0, false, false);
> > > + if (!IS_ERR(vdev->reset_control))
> > > + return 0;
> > 
> > if you assign to a local variable first here:
> > 
> > struct reset_control *rstc;
> > 
> >  ...
> > 
> > rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
> > if (!IS_ERR(rstc)) {
> > vdev->reset_control = rstc;
> > return 0;
> > }
> > 
> > Also, please don't use __of_reset_control_get directly.
> 
> OK, apparently I didn't read  beyond the first #else...

I don't blame you, this is missing some documentation.

> > > @@ -217,6 +233,9 @@ static int vfio_platform_call_reset(struct 
> > > vfio_platform_device *vdev,
> > >   } else if (vdev->of_reset) {
> > >   dev_info(vdev->device, "reset\n");
> > >   return vdev->of_reset(vdev);
> > > + } else if (!IS_ERR_OR_NULL(vdev->reset_control)) {
> > > + dev_info(vdev->device, "reset\n");
> > > + return reset_control_reset(vdev->reset_control);
> > 
> > } else {
> > if (vdev->reset_control)
> > dev_info(vdev->device, "reset\n");
> > return reset_control_reset(vdev->reset_control);
> > 
> > >   }
> 
> I'd like to keep the "else if", as that's the pattern used by the blocks 
> above.

my bad, there's more code after this.

} else if (vdev->reset_control) {
dev_info(vdev->device, "reset\n");
return reset_control_reset(vdev->reset_control);
}

is better as it doesn't lose the warning if vdev->reset_control == NULL.
It seems I've focused too much on getting rid of the IS_ERR_OR_NULL
macro.

regards
Philipp

Re: [PATCH 2/2] vfio: platform: Add generic DT reset support

[Philipp Zabel]

Hi Geert,

I have a suggestion to avoid having to use the IS_ERR_OR_NULL macro, see
below:

On Tue, 2018-02-13 at 17:36 +0100, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
> 
> On many SoCs, devices are connected to an SoC-internal reset controller,
> and can be reset in a generic way.  Hence add support to reset such
> devices using the reset controller subsystem, provided the reset
> hierarchy is described correctly in DT using the "resets" property.
> 
> Devices that require a more complex reset procedure can still
> provide a device-specific reset driver, as that takes precedence.
> 
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op if reset controller support is disabled.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/vfio/platform/vfio_platform_common.c  | 23 +--
>  drivers/vfio/platform/vfio_platform_private.h |  1 +
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..5d1e48f96e423508 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -112,7 +113,13 @@ static bool vfio_platform_has_reset(struct 
> vfio_platform_device *vdev)
>   if (VFIO_PLATFORM_IS_ACPI(vdev))
>   return vfio_platform_acpi_has_reset(vdev);
>  
> - return vdev->of_reset ? true : false;
> + if (vdev->of_reset)
> + return true;
> +
> + if (!IS_ERR_OR_NULL(vdev->reset_control))
> + return true;

I'd avoid storing error values in vdev->reset_control at all, so this
could be:

if (vdev->reset_control)
return true;

> +
> + return false;
>  }
>  
>  static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
> @@ -127,8 +134,15 @@ static int vfio_platform_get_reset(struct 
> vfio_platform_device *vdev)
>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>   >reset_module);
>   }
> + if (vdev->of_reset)
> + return 0;
> +
> + vdev->reset_control = __of_reset_control_get(vdev->device->of_node,
> +  NULL, 0, false, false);
> + if (!IS_ERR(vdev->reset_control))
> + return 0;

if you assign to a local variable first here:

struct reset_control *rstc;

 ...

rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
if (!IS_ERR(rstc)) {
vdev->reset_control = rstc;
return 0;
}

Also, please don't use __of_reset_control_get directly.

>  
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(vdev->reset_control);

return PTR_ERR(rstc);

>  }
>  
>  static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> @@ -138,6 +152,8 @@ static void vfio_platform_put_reset(struct 
> vfio_platform_device *vdev)
>  
>   if (vdev->of_reset)
>   module_put(vdev->reset_module);
> +
> + reset_control_put(vdev->reset_control);
>  }
>  
>  static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
> @@ -217,6 +233,9 @@ static int vfio_platform_call_reset(struct 
> vfio_platform_device *vdev,
>   } else if (vdev->of_reset) {
>   dev_info(vdev->device, "reset\n");
>   return vdev->of_reset(vdev);
> + } else if (!IS_ERR_OR_NULL(vdev->reset_control)) {
> + dev_info(vdev->device, "reset\n");
> + return reset_control_reset(vdev->reset_control);

} else {
if (vdev->reset_control)
dev_info(vdev->device, "reset\n");
return reset_control_reset(vdev->reset_control);

>   }
>  
>   dev_warn(vdev->device, "no reset function found!\n");
> diff --git a/drivers/vfio/platform/vfio_platform_private.h 
> b/drivers/vfio/platform/vfio_platform_private.h
> index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -60,6 +60,7 @@ struct vfio_platform_device {
>   const char  *compat;
>   const char  *acpihid;
>   struct module   *reset_module;
> + struct reset_control*reset_control;
>   struct device   *device;
>  
>   /*

regards
Philipp

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

[Philipp Zabel]

On Tue, 2018-01-23 at 19:08 +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/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ab4032167094..9fb96f9cc36e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -699,7 +699,6 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
>   * drm_atomic_helper_check_plane_state() - Check plane state for validity
>   * @plane_state: plane state to check
>   * @crtc_state: crtc state to check
> - * @clip: integer clipping coordinates
>   * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
>   * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
>   * @can_position: is it legal to position the plane such that it
> @@ -719,7 +718,6 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
>   */
>  int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
>   const struct drm_crtc_state *crtc_state,
> - const struct drm_rect *clip,
>   int min_scale,
>   int max_scale,
>   bool can_position,
> @@ -729,6 +727,7 @@ int drm_atomic_helper_check_plane_state(struct 
> drm_plane_state *plane_state,
>   struct drm_rect *src = _state->src;
>   

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

[Philipp Zabel]

On Tue, 2018-04-10 at 17:53 +0200, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
> 
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem.  Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
> 
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
> 
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>

> ---
> v2:
>   - Don't store error values in vdev->reset_control,
>   - Use of_reset_control_get_exclusive() instead of
> __of_reset_control_get(),
>   - Improve description.
> ---
>  drivers/vfio/platform/vfio_platform_common.c  | 26 --
>  drivers/vfio/platform/vfio_platform_private.h |  1 +
>  2 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..3c13327b2777f8ec 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
[...]
> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct 
> vfio_platform_device *vdev)
>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>   >reset_module);
>   }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);

If vdev->device->of_node == NULL, this will return -EINVAL ...

> + if (!IS_ERR(rstc)) {
> + vdev->reset_control = rstc;
> + return 0;
> + }
>  
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(rstc);

... instead of -ENOENT, if that makes any difference.

regards
Philipp

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Philipp Zabel]

On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
> Hi Sinan,
> 
> On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya <ok...@codeaurora.org> wrote:
> > On 4/12/2018 7:49 AM, Auger Eric wrote:
> > > On 12/04/18 13:32, Geert Uytterhoeven wrote:
> > > > On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric <eric.au...@redhat.com> 
> > > > wrote:
> > > > > On 11/04/18 11:15, Geert Uytterhoeven wrote:
> > > > > > Vfio-platform requires reset support, provided either by ACPI, or, 
> > > > > > on DT
> > > > > > platforms, by a device-specific reset driver matching against the
> > > > > > device's compatible value.
> > > > > > 
> > > > > > On many SoCs, devices are connected to an SoC-internal reset 
> > > > > > controller.
> > > > > > If the reset hierarchy is described in DT using "resets" properties,
> > > > > > such devices can be reset in a generic way through the reset 
> > > > > > controller
> > > > > > subsystem.  Hence add support for this, avoiding the need to write
> > > > > > device-specific reset drivers for each single device on affected 
> > > > > > SoCs.
> > > > > > 
> > > > > > Devices that do require a more complex reset procedure can still 
> > > > > > provide
> > > > > > a device-specific reset driver, as that takes precedence.
> > > > > > 
> > > > > > Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, 
> > > > > > and
> > > > > > becomes a no-op (as in: "No reset function found for device") if 
> > > > > > reset
> > > > > > controller support is disabled.
> > > > > > 
> > > > > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> > > > > > Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>
> > > > > > --- a/drivers/vfio/platform/vfio_platform_common.c
> > > > > > +++ b/drivers/vfio/platform/vfio_platform_common.c
> > > > > > @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
> > > > > > vfio_platform_device *vdev)
> > > > > >   vdev->of_reset = 
> > > > > > vfio_platform_lookup_reset(vdev->compat,
> > > > > >   
> > > > > > >reset_module);
> > > > > >   }
> > > > > > + if (vdev->of_reset)
> > > > > > + return 0;
> > > > > > +
> > > > > > + rstc = of_reset_control_get_exclusive(vdev->device->of_node, 
> > > > > > NULL);
> > > > > 
> > > > > Shouldn't we prefer the top level reset_control_get_exclusive()?
> > > > 
> > > > I guess that should work, too.
> > > > 
> > > > > To make sure about the exclusive/shared terminology, does
> > > > > get_reset_control_get_exclusive() check we have an exclusive wire
> > > > > between this device and the reset controller?
> > > > 
> > > > AFAIU, the "exclusive" means that only a single user can obtain access 
> > > > to
> > > > the reset, and it does not guarantee that we have an exclusive wire 
> > > > between
> > > > the device and the reset controller.
> > > > 
> > > > The latter depends on the SoC's reset topology. If a reset wire is 
> > > > shared
> > > > by multiple devices (e.g. resets shared by PWM or Display Unit devices 
> > > > on
> > > > R-Car SoCs), exporting a subset of these devices to a guest is a bad 
> > > > idea,
> > > > indeed.
> > > 
> > > So who's going to check this assigned device will not trigger a reset of
> > > other non assigned devices sharing the same reset controller?

If the reset control is requested as exclusive, any other driver
requesting the same reset control will fail (or this reset_control_get
will fail, whichever comes last).

> > I like the direction in general. I was hoping that you'd call it 
> > of_reset_control
> > rather than reset_control.
> 
> You mean vfio_platform_device.of_reset_control?
> If we switch to reset_control_get_exclusive(), that doesn't make much sense...
> 
> > Is there anything in the OF spec about

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Philipp Zabel]

Hi Geert,

On Thu, 2018-04-12 at 18:02 +0200, Geert Uytterhoeven wrote:
> Hi Philipp,
> 
> On Thu, Apr 12, 2018 at 4:10 PM, Philipp Zabel <p.za...@pengutronix.de> wrote:
> > On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
> > > On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya <ok...@codeaurora.org> wrote:
> > > > On 4/12/2018 7:49 AM, Auger Eric wrote:
> > > > > On 12/04/18 13:32, Geert Uytterhoeven wrote:
> > > > > > On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric 
> > > > > > <eric.au...@redhat.com> wrote:
> > > > > > > On 11/04/18 11:15, Geert Uytterhoeven wrote:
> > > > > > > > Vfio-platform requires reset support, provided either by ACPI, 
> > > > > > > > or, on DT
> > > > > > > > platforms, by a device-specific reset driver matching against 
> > > > > > > > the
> > > > > > > > device's compatible value.
> > > > > > > > 
> > > > > > > > On many SoCs, devices are connected to an SoC-internal reset 
> > > > > > > > controller.
> > > > > > > > If the reset hierarchy is described in DT using "resets" 
> > > > > > > > properties,
> > > > > > > > such devices can be reset in a generic way through the reset 
> > > > > > > > controller
> > > > > > > > subsystem.  Hence add support for this, avoiding the need to 
> > > > > > > > write
> > > > > > > > device-specific reset drivers for each single device on 
> > > > > > > > affected SoCs.
> > > > > > > > 
> > > > > > > > Devices that do require a more complex reset procedure can 
> > > > > > > > still provide
> > > > > > > > a device-specific reset driver, as that takes precedence.
> > > > > > > > 
> > > > > > > > Note that this functionality depends on 
> > > > > > > > CONFIG_RESET_CONTROLLER=y, and
> > > > > > > > becomes a no-op (as in: "No reset function found for device") 
> > > > > > > > if reset
> > > > > > > > controller support is disabled.
> > > > > > > > 
> > > > > > > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> > > > > > > > Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>
> > > > > > > > --- a/drivers/vfio/platform/vfio_platform_common.c
> > > > > > > > +++ b/drivers/vfio/platform/vfio_platform_common.c
> > > > > > > > @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
> > > > > > > > vfio_platform_device *vdev)
> > > > > > > >   vdev->of_reset = 
> > > > > > > > vfio_platform_lookup_reset(vdev->compat,
> > > > > > > >   
> > > > > > > > >reset_module);
> > > > > > > >   }
> > > > > > > > + if (vdev->of_reset)
> > > > > > > > + return 0;
> > > > > > > > +
> > > > > > > > + rstc = 
> > > > > > > > of_reset_control_get_exclusive(vdev->device->of_node, NULL);
> > > > > > > 
> > > > > > > Shouldn't we prefer the top level reset_control_get_exclusive()?
> > > > > > 
> > > > > > I guess that should work, too.
> > > > > > 
> > > > > > > To make sure about the exclusive/shared terminology, does
> > > > > > > get_reset_control_get_exclusive() check we have an exclusive wire
> > > > > > > between this device and the reset controller?
> > > > > > 
> > > > > > AFAIU, the "exclusive" means that only a single user can obtain 
> > > > > > access to
> > > > > > the reset, and it does not guarantee that we have an exclusive wire 
> > > > > > between
> > > > > > the device and the reset controller.
> > > > > > 
> > > > > > The latter depends on the SoC's reset topology. If a reset wire is 
> > > > > > shared
> > > &g

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Philipp Zabel]

On Tue, 2018-02-27 at 14:56 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
> 
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
> 
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes().
>
> For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().

[...]
>  drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
>  drivers/gpu/drm/imx/parallel-display.c |   2 +-

For imx-drm,
Acked-by: Philipp Zabel <p.za...@pengutronix.de>

regards
Philipp

Re: [PATCH 1/2] dt-bindings: reset: rcar-rst: Document r8a774c0 rst

[Philipp Zabel]

On Mon, 2018-09-10 at 16:09 +0100, Fabrizio Castro wrote:
> Document bindings for the RZ/G2E (a.k.a. R8A774C0) reset
> module.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
>  Documentation/devicetree/bindings/reset/renesas,rst.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt 
> b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> index e4fe0ab..25e6db5 100644
> --- a/Documentation/devicetree/bindings/reset/renesas,rst.txt
> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> @@ -19,6 +19,7 @@ Required properties:
> - "renesas,r8a7745-rst" (RZ/G1E)
> - "renesas,r8a77470-rst" (RZ/G1C)
> - "renesas,r8a774a1-rst" (RZ/G2M)
> +   - "renesas,r8a774c0-rst" (RZ/G2E)
> - "renesas,r8a7778-reset-wdt" (R-Car M1A)
>     - "renesas,r8a7779-reset-wdt" (R-Car H1)
> - "renesas,r8a7790-rst" (R-Car H2)

Acked-by: Philipp Zabel 

regards
Philipp