Re: [PATCH v16 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2

[Sakari Ailus]

On Tue, May 15, 2018 at 07:50:45AM +0300, Laurent Pinchart wrote:
> Hi Niklas,
> 
> On Tuesday, 15 May 2018 03:56:33 EEST Niklas Söderlund wrote:
> > Hi,
> > 
> > This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's
> > based on top of the media-tree and are tested on Renesas Salvator-X and
> > Salvator-XS together with adv7482 and the now in tree rcar-vin driver :-)
> > 
> > I hope this is the last incarnation of this patch-set, I do think it is
> > ready for upstream consumption :-)
> 
> So do I. Even though you dropped Hans' reviewed-by tag due to changes in the 
> hardware initialization code, I think the part that Hans cares about the most 
> is the V4L2 API implementation, so I believe his review still applies. In my 
> opinion the series has received the necessary review.
> 
> Hans, would you like to take this through your tree, or should we send a pull 
> request directly to Mauro ? I'd like the two patches to be merged in v4.18 if 
> possible.

I've applied the patches to my tree as discussed with Hans previously.

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hi Niklas,

On Sun, Apr 15, 2018 at 10:47:37PM +0200, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Thanks for your feedback.
> 
> On 2018-04-04 23:13:57 +0300, Sakari Ailus wrote:
> 
> [snip]
> 
> > > > +   pm_runtime_enable(>dev);
> > > 
> > > Is CONFIG_PM mandatory on Renesas SoCs? If not, you end up with the
> > > device uninitialised at probe, and pm_runtime_get_sync will not
> > > initialise it either if CONFIG_PM is not enabled. I guess you could
> > > call your runtime_resume function unconditionally, and mark the device
> > > as active in runtime_pm using pm_runtime_set_active.
> > 
> > There doesn't seem to be any runtime_resume function. Was there supposed
> > to be one?
> 
> No there is not suppose to be one.

Ok.

> 
> > 
> > Assuming runtime PM would actually do something here, you might add
> > pm_runtime_idle() to power the device off after probing.
> > 
> > I guess pm_runtime_set_active() should precede pm_runtime_enable().
> 
> The CSI-2 is in the always on power domain so the calls to 
> pm_runtime_get_sync() and pm_runtime_put() are there in the s_stream() 
> callback to enable and disable the module clock. I'm no expert on PM but 
> in my testing the pm_ calls in this driver seems to be correct.
> 
> 1. In probe I call pm_runtime_enable(). And rudimentary tests shows the 
>clock is off (but I might miss something) as I wish it to be until 
>stream on time.
> 2. In s_stream() I call pm_runtime_get_sync() before writing any 
>register when starting a stream. And likewise I call pm_runtime_put() 
>when stopping and I no longer need to write to a register.
> 3. In remove() I call pm_runtime_disable().
> 
> Am I missing something obvious here?

Looking at the code again, it seems fine in this respect.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] dt-bindings: media: rcar_vin: Use status "okay"

[Sakari Ailus]

On Fri, Mar 09, 2018 at 10:34:40AM +0100, Geert Uytterhoeven wrote:
> According to the Devicetree Specification, "ok" is not a valid status.
> 
> Fixes: 47c71bd61b772cd7 ("[media] rcar_vin: add devicetree support")
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

There are a few other matches, too, it'd be nice to fix them as well:

$ git grep 'status.*"ok"' -- Documentation/devicetree/bindings/
Documentation/devicetree/bindings/ata/apm-xgene.txt:- status: Shall 
be "ok" if enabled or "disabled" if disabled.
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt: status 
= "ok";
Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt:   status = "ok";
Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt:   status = "ok";
Documentation/devicetree/bindings/media/rcar_vin.txt:status = "ok";
Documentation/devicetree/bindings/media/rcar_vin.txt:status = "ok";
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:- status: Should be 
"ok" or "disabled" for enabled/disabled. Default is "ok".
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:   status 
= "ok";
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:status = "ok";
Documentation/devicetree/bindings/pci/hisilicon-pcie.txt:- status: Either "ok" 
or "disabled".
Documentation/devicetree/bindings/pci/xgene-pci.txt:- status: Either "ok" or 
"disabled".
Documentation/devicetree/bindings/pci/xgene-pci.txt:status = "ok";
Documentation/devicetree/bindings/phy/apm-xgene-phy.txt:- status
: Shall be "ok" if enabled or "disabled" if disabled.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver

[Sakari Ailus]

th;
> + mf->height  = priv->frame.height;
> + mf->colorspace  = priv->format->colorspace;
> + mf->code= priv->format->code;
> + mf->field   = V4L2_FIELD_NONE;
> +
> + return 0;
> +}
> +
> +static int mt9t112_s_fmt(struct v4l2_subdev *sd,
> +  struct v4l2_mbus_framefmt *mf)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct mt9t112_priv *priv = to_mt9t112(client);
> + struct v4l2_rect rect = {
> + .width = mf->width,
> + .height = mf->height,
> + .left = priv->frame.left,
> + .top = priv->frame.top,
> + };
> + int ret;
> +
> + ret = mt9t112_set_params(priv, , mf->code);
> +
> + if (!ret)
> + mf->colorspace = priv->format->colorspace;
> +
> + return ret;
> +}
> +
> +static int mt9t112_set_fmt(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *format)
> +{
> + struct v4l2_mbus_framefmt *mf = >format;
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct mt9t112_priv *priv = to_mt9t112(client);
> + unsigned int top, left;
> + int i;
> +
> + if (format->pad)
> + return -EINVAL;
> +
> + for (i = 0; i < priv->num_formats; i++)
> + if (mt9t112_cfmts[i].code == mf->code)
> + break;
> +
> + if (i == priv->num_formats) {
> + mf->code = MEDIA_BUS_FMT_UYVY8_2X8;
> + mf->colorspace = V4L2_COLORSPACE_JPEG;
> + } else {
> + mf->colorspace  = mt9t112_cfmts[i].colorspace;
> + }
> +
> + mt9t112_frame_check(>width, >height, , );
> +
> + mf->field = V4L2_FIELD_NONE;
> +
> + if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE)
> + return mt9t112_s_fmt(sd, mf);
> + cfg->try_fmt = *mf;
> + return 0;
> +}
> +
> +static int mt9t112_enum_mbus_code(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_mbus_code_enum *code)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct mt9t112_priv *priv = to_mt9t112(client);
> +
> + if (code->pad || code->index >= priv->num_formats)
> + return -EINVAL;
> +
> + code->code = mt9t112_cfmts[code->index].code;
> +
> + return 0;
> +}
> +
> +static int mt9t112_g_mbus_config(struct v4l2_subdev *sd,
> +  struct v4l2_mbus_config *cfg)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> +
> + cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_VSYNC_ACTIVE_HIGH |
> + V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_DATA_ACTIVE_HIGH |
> + V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_PCLK_SAMPLE_FALLING;
> + cfg->type = V4L2_MBUS_PARALLEL;
> + cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
> +
> + return 0;
> +}
> +
> +static int mt9t112_s_mbus_config(struct v4l2_subdev *sd,
> +  const struct v4l2_mbus_config *cfg)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> + struct mt9t112_priv *priv = to_mt9t112(client);
> +
> + if (soc_camera_apply_board_flags(ssdd, cfg) & 
> V4L2_MBUS_PCLK_SAMPLE_RISING)
> + priv->flags |= PCLK_RISING;
> +
> + return 0;
> +}

Do you have a DT based system where you use this? Then I think it'd be
rather easy to get rid of the mbus config stuff.

> +
> +static const struct v4l2_subdev_video_ops mt9t112_subdev_video_ops = {
> + .s_stream   = mt9t112_s_stream,
> + .g_mbus_config  = mt9t112_g_mbus_config,
> + .s_mbus_config  = mt9t112_s_mbus_config,
> +};
> +
> +static const struct v4l2_subdev_pad_ops mt9t112_subdev_pad_ops = {
> + .enum_mbus_code = mt9t112_enum_mbus_code,
> + .get_selection  = mt9t112_get_selection,
> + .set_selection  = mt9t112_set_selection,
> + .get_fmt= mt9t112_get_fmt,
> + .set_fmt= mt9t112_set_fmt,
> +};
> +
> +/
> + i2c driver
> +/
> +static const struct v4l2_subdev_ops mt9t112_subdev_ops = {
> + .core   = _subdev_core_ops,
> + .video  = _subdev_video_ops,
> + .pad= _subdev_pad_ops,
> +};
> +
> +static int mt9t112_camera_probe(struct i2c_client *client)
> +{
> + struct mt9t112_priv *priv = to_mt9t112(client);
> + const char  *devname;
> + int  chipid;
> + int  ret;
> +
> + ret = mt9t112_s_power(>subdev, 1);
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * check and show chip ID
> +  */
> + mt9t112_reg_read(chipid, client, 0x);
> +
> + switch (chipid) {
> + case 0x2680:
> + devname = "mt9t111";
> + priv->num_formats = 1;
> + break;
> + case 0x2682:
> + devname = "mt9t112";
> + priv->num_formats = ARRAY_SIZE(mt9t112_cfmts);
> + break;
> + default:
> + dev_err(>dev, "Product ID error %04x\n", chipid);
> + ret = -ENODEV;
> + goto done;
> + }
> +
> + dev_info(>dev, "%s chip ID %04x\n", devname, chipid);
> +
> +done:
> + mt9t112_s_power(>subdev, 0);
> + return ret;
> +}
> +
> +static int mt9t112_probe(struct i2c_client *client,
> +  const struct i2c_device_id *did)
> +{
> + struct mt9t112_priv *priv;
> + struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> + struct v4l2_rect rect = {
> + .width = VGA_WIDTH,
> + .height = VGA_HEIGHT,
> + .left = (MAX_WIDTH - VGA_WIDTH) / 2,
> + .top = (MAX_HEIGHT - VGA_HEIGHT) / 2,
> + };
> + int ret;
> +
> + if (!ssdd || !ssdd->drv_priv) {
> + dev_err(>dev, "mt9t112: missing platform data!\n");
> + return -EINVAL;
> + }
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->info = ssdd->drv_priv;
> +
> + v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
> +
> + priv->clk = v4l2_clk_get(>dev, "mclk");
> + if (IS_ERR(priv->clk))
> + return PTR_ERR(priv->clk);
> +
> + ret = mt9t112_camera_probe(client);
> +
> + /* Cannot fail: using the default supported pixel code */
> + if (!ret)
> + mt9t112_set_params(priv, , MEDIA_BUS_FMT_UYVY8_2X8);
> + else
> + v4l2_clk_put(priv->clk);
> +
> + return ret;
> +}
> +
> +static int mt9t112_remove(struct i2c_client *client)
> +{
> + struct mt9t112_priv *priv = to_mt9t112(client);
> +
> + v4l2_clk_put(priv->clk);
> + return 0;
> +}
> +
> +static const struct i2c_device_id mt9t112_id[] = {
> + { "mt9t112", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, mt9t112_id);
> +
> +static struct i2c_driver mt9t112_i2c_driver = {
> + .driver = {
> + .name = "mt9t112",
> + },
> + .probe= mt9t112_probe,

If you need to support OF based systems only, you could use probe_new and
drop the i2c ID table.

> + .remove   = mt9t112_remove,
> + .id_table = mt9t112_id,
> +};
> +
> +module_i2c_driver(mt9t112_i2c_driver);
> +
> +MODULE_DESCRIPTION("SoC Camera driver for mt9t112");
> +MODULE_AUTHOR("Kuninori Morimoto");
> +MODULE_LICENSE("GPL v2");

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 5/5] media: MAINTAINERS: Add entry for Aptina MT9T112

[Sakari Ailus]

Hi Jacopo,

On Fri, Mar 02, 2018 at 05:35:41PM +0100, Jacopo Mondi wrote:
> Add entry for Aptina/Micron MT9T112 camera sensor. The driver is
> currently orphaned.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 91ed6ad..1d8be25 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9385,6 +9385,13 @@ S: Maintained
>  F:   drivers/media/i2c/mt9t001.c
>  F:   include/media/i2c/mt9t001.h
>  
> +MT9T112 APTINA CAMERA SENSOR
> +L:   linux-me...@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Orphan

I don't like adding a driver which is in orphaned state to begin with.

Would you like to maintain it? :-)

> +F:   drivers/media/i2c/mt9t112.c
> +F:   include/media/i2c/mt9t112.h
> +
>  MT9V032 APTINA CAMERA SENSOR
>  M:   Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>  L:   linux-me...@vger.kernel.org

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Sakari Ailus]

Hi Laurent and Hans,

On Wed, Feb 21, 2018 at 10:16:25PM +0200, Laurent Pinchart wrote:
> No, I'm sorry, for MC-based drivers this isn't correct. The media entity that 
> symbolizes the DMA engine indeed has a sink pad, but it's a video node, not a 
> subdev. It thus has no media bus format configured for its sink pad. The 
> closest pad in the pipeline that has a media bus format is the source pad of 
> the subdev connected to the video node.
> 
> There's no communication within the kernel at G/S_FMT time between the video 
> node and its connected subdev. The only time we look at the pipeline as a 
> whole is when starting the stream to validate that the pipeline is correctly 
> configured. We thus have to implement G/S_FMT on the video node without any 
> knowledge about the connected subdev, and thus accept any colorspace.

A few more notes related to this --- there's no propagation of sub-device
format across the entities; there were several reasons for the design
choice. The V4L2 pixel format in the video node must be compatible with the
sub-device format when streaming is started. And... the streaming will
start in the pipeline defined by the enabled links to/from the video node.
In principle nothign prevents having multiple links there, and at the time
S_FMT IOCTL is called on the video node, none of those links could be
enabled. And that's perfectly valid use of the API.

A lot of the DMA engine drivers are simply devices that receive data and
write that to system memory, they really don't necessarily know anything
else. For the hardware this data is just pixels (or even bits, especially
in the case of CSI-2!).

So I agree with Laurent here that requiring correct colour space for
[GS]_FMT IOCTLs on video nodes in the general case is not feasible
(especially on MC-centric devices), due to the way the Media controller
pipeline and formats along that pipeline are configured and validated (i.e.
at streamon time).

But what to do here then? The colourspace field is not verified even in
link validation so there's no guarantee it's correctly set more or less
anywhere else than in the source of the stream. And if the stream has
multiple sources with different colour spaces, then what do you do? That's
perhaps a theoretical case but the current frameworks and APIs do in
principle support that.

Perhaps we should specify that the user should always set the same
colourspace on the sink end of a link that was there in the source? The
same should likely apply to the rest of the fields apart from width, height
and code, too. Before the user configures formats this doesn't work though,
and this does not address the matter with v4l2-compliance.

Granted that the drivers will themselves handle the colour space
information correctly, it'd still provide a way for the user to gain the
knowledge of the colour space which I believe is what matters.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Sakari Ailus]

On Wed, Feb 14, 2018 at 11:36:43AM +0100, Niklas Söderlund wrote:
> There is no way for drivers to validate a colorspace value, which could
> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
> validate that the colorspace value is part of enum v4l2_colorspace.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

> ---
>  include/uapi/linux/videodev2.h | 4 
>  1 file changed, 4 insertions(+)
> 
> Hi,
> 
> I hope this is the correct header to add this helper to. I think it's
> since if it's in uapi not only can v4l2 drivers use it but tools like
> v4l-compliance gets access to it and can be updated to use this instead
> of the hard-coded check of just < 0xff as it was last time I checked.
> 
> * Changes since v1
> - Cast colorspace to u32 as suggested by Sakari and only check the upper 
>   boundary to address a potential issue brought up by Laurent if the 
>   data type tested is u32 which is not uncommon:
> 
> enum.c:30:16: warning: comparison of unsigned expression >= 0 is always 
> true
> [-Wtype-limits]
>   return V4L2_COLORSPACE_IS_VALID(colorspace);
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9827189651801e12..1f27c0f4187cbded 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>   V4L2_COLORSPACE_DCI_P3= 12,
>  };
>  
> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
> +#define V4L2_COLORSPACE_IS_VALID(colorspace) \
> + ((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
> +
>  /*
>   * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
>   * This depends on whether this is a SDTV image (use SMPTE 170M), an
> -- 
> 2.16.1
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] videodev2.h: add helper to validate colorspace

[Sakari Ailus]

Hi Laurent and Niklas,

On Wed, Feb 14, 2018 at 12:23:05AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Wednesday, 14 February 2018 00:08:47 EET Niklas Söderlund wrote:
> > There is no way for drivers to validate a colorspace value, which could
> > be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
> > validate that the colorspace value is part of enum v4l2_colorspace.
> > 
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > ---
> >  include/uapi/linux/videodev2.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > Hi,
> > 
> > I hope this is the correct header to add this helper to. I think it's
> > since if it's in uapi not only can v4l2 drivers use it but tools like
> > v4l-compliance gets access to it and can be updated to use this instead
> > of the hard-coded check of just < 0xff as it was last time I checked.
> > 
> > // Niklas
> > 
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 9827189651801e12..843afd7c5b000553 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -238,6 +238,11 @@ enum v4l2_colorspace {
> > V4L2_COLORSPACE_DCI_P3= 12,
> >  };
> > 
> > +/* Determine if a colorspace is defined in enum v4l2_colorspace */
> > +#define V4L2_COLORSPACE_IS_VALID(colorspace)   \
> > +   (((colorspace) >= V4L2_COLORSPACE_DEFAULT) &&   \
> > +((colorspace) <= V4L2_COLORSPACE_DCI_P3))
> > +
> 
> This looks pretty good to me. I'd remove the parentheses around each test 
> though.

Agreed.

> 
> One potential issue is that if this macro operates on an unsigned value (for 
> instance an u32, which is the type used for the colorspace field in various 
> structures) the compiler will generate a warning:
> 
> enum.c: In function ‘test_4’: 
>   
>   
> enum.c:30:16: warning: comparison of unsigned expression >= 0 is always true 
> [-Wtype-limits]   
>
>   return V4L2_COLORSPACE_IS_VALID(colorspace);
> 
> Dropping the first check would fix that, but wouldn't catch invalid values 
> when operating on a signed type, such as int or enum v4l2_colorspace.

How about simply casting it to u32 first (and removing the first test)?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()

[Sakari Ailus]

On Thu, Jan 25, 2018 at 02:08:52PM +0100, Niklas Söderlund wrote:
> A recent change to the media_entity_to_video_device() macro breaks some
> use-cases for the macro due to a symbol collision. Before the change
> this worked:
> 
> vdev = media_entity_to_video_device(link->sink->entity);
> 
> While after the change it results in a compiler error "error: 'struct
> video_device' has no member named 'link'; did you mean 'lock'?". While
> the following still works after the change.
> 
> struct media_entity *entity = link->sink->entity;
> vdev = media_entity_to_video_device(entity);
> 
> Fix the collision by renaming the macro argument to '__entity'.
> 
> Fixes: 69b925c5fc36d8f1 ("media: v4l2-dev.h: add kernel-doc to two macros")
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

[Sakari Ailus]

Hi Hans,

On Fri, Jan 19, 2018 at 11:47:33AM +0100, Hans Verkuil wrote:
> On 01/19/18 11:24, Hans Verkuil wrote:
> > On 01/16/18 22:44, Jacopo Mondi wrote:
> >> Remove soc_camera framework dependencies from ov772x sensor driver.
> >> - Handle clock and gpios
> >> - Register async subdevice
> >> - Remove soc_camera specific g/s_mbus_config operations
> >> - Change image format colorspace from JPEG to SRGB as the two use the
> >>   same colorspace information but JPEG makes assumptions on color
> >>   components quantization that do not apply to the sensor
> >> - Remove sizes crop from get_selection as driver can't scale
> >> - Add kernel doc to driver interface header file
> >> - Adjust build system
> >>
> >> This commit does not remove the original soc_camera based driver as long
> >> as other platforms depends on soc_camera-based CEU driver.
> >>
> >> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> >> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> > 
> > Acked-by: Hans Verkuil <hans.verk...@cisco.com>
> 
> Un-acked.
> 
> I just noticed that this sensor driver has no enum_frame_interval and
> g/s_parm support. How would a driver ever know the frame rate of the
> sensor without that?

s/_parm/_frame_interval/ ?

We should have wrappers for this or rather to convert g/s_parm users to
g/s_frame_interval so drivers don't need to implement both.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v6 1/9] dt-bindings: media: Add Renesas CEU bindings

[Sakari Ailus]

On Wed, Jan 17, 2018 at 09:35:53AM +0100, jacopo mondi wrote:
> Hi Sakari,
> it's the second series this week where I fail to handle BT.656
> properly, sorry about this :)

No worries. I guess I forgot your reply. If the hardware doesn't support
Bt.656 then the current definition is fine.

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

> 
> On Wed, Jan 17, 2018 at 09:59:59AM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Tue, Jan 16, 2018 at 10:44:53PM +0100, Jacopo Mondi wrote:
> > > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > > Reviewed-by: Rob Herring <r...@kernel.org>
> > > Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> > > Acked-by: Hans Verkuil <hans.verk...@cisco.com>
> > > ---
> > >  .../devicetree/bindings/media/renesas,ceu.txt  | 81 
> > > ++
> > >  1 file changed, 81 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/media/renesas,ceu.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> > > b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > > new file mode 100644
> > > index 000..590ee27
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > > @@ -0,0 +1,81 @@
> > > +Renesas Capture Engine Unit (CEU)
> > > +--
> > > +
> > > +The Capture Engine Unit is the image capture interface found in the 
> > > Renesas
> > > +SH Mobile and RZ SoCs.
> > > +
> > > +The interface supports a single parallel input with data bus width of 8 
> > > or 16
> > > +bits.
> > > +
> > > +Required properties:
> > > +- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in 
> > > RZ/A1-H
> > > +  and RZ/A1-M SoCs.
> > > +- reg: Registers address base and size.
> > > +- interrupts: The interrupt specifier.
> > > +
> > > +The CEU supports a single parallel input and should contain a single 
> > > 'port'
> > > +subnode with a single 'endpoint'. Connection to input devices are modeled
> > > +according to the video interfaces OF bindings specified in:
> > > +Documentation/devicetree/bindings/media/video-interfaces.txt
> > > +
> > > +Optional endpoint properties applicable to parallel input bus described 
> > > in
> > > +the above mentioned "video-interfaces.txt" file are supported.
> > > +
> > > +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH 
> > > respectively.
> > > +  If property is not present, default is active high.
> > > +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH 
> > > respectively.
> > > +  If property is not present, default is active high.
> >
> > Does the hardware support Bt.656? If it does, you need to tell the
> > difference between the parallel interface with default sync polarity and
> > Bt.656 interfaces. With the above it's ambiguous.
> 
> No, it does not support BT.656.
> 
> I'm listing them as -required- endpoint properties. If they are not
> specified the drivers fails during probe:
> 
> renesas-ceu e821.ceu: Only parallel input supported.
> 
> Thanks
>j
> 
> >
> > > +
> > > +Example:
> > > +
> > > +The example describes the connection between the Capture Engine Unit and 
> > > an
> > > +OV7670 image sensor connected to i2c1 interface.
> > > +
> > > +ceu: ceu@e821 {
> > > + reg = <0xe821 0x209c>;
> > > + compatible = "renesas,r7s72100-ceu";
> > > + interrupts = ;
> > > +
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> > > +
> > > + status = "okay";
> > > +
> > > + port {
> > > + ceu_in: endpoint {
> > > + remote-endpoint = <_out>;
> > > +
> > > + hsync-active = <1>;
> > > + vsync-active = <0>;
> > > + };
> > > + };
> > > +};
> > > +
> > > +i2c1: i2c@fcfee400 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> > > +
> > > + status = "okay";
> > > +
> > > + clock-frequency = <10>;
> > > +
> > > + ov7670: camera@21 {
> > > + compatible = "ovti,ov7670";
> > > + reg = <0x21>;
> > > +
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> > > +
> > > + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> > > + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> > > +
> > > + port {
> > > + ov7670_out: endpoint {
> > > + remote-endpoint = <_in>;
> > > +
> > > + hsync-active = <1>;
> > > + vsync-active = <0>;
> > > + };
> > > + };
> > > + };
> > > +};
> > > --
> > > 2.7.4
> > >
> >
> > --
> > Sakari Ailus
> > e-mail: sakari.ai...@iki.fi

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v6 1/9] dt-bindings: media: Add Renesas CEU bindings

[Sakari Ailus]

Hi Jacopo,

On Tue, Jan 16, 2018 at 10:44:53PM +0100, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> Reviewed-by: Rob Herring <r...@kernel.org>
> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Acked-by: Hans Verkuil <hans.verk...@cisco.com>
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 81 
> ++
>  1 file changed, 81 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..590ee27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,81 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found in the Renesas
> +SH Mobile and RZ SoCs.
> +
> +The interface supports a single parallel input with data bus width of 8 or 16
> +bits.
> +
> +Required properties:
> +- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1-H
> +  and RZ/A1-M SoCs.
> +- reg: Registers address base and size.
> +- interrupts: The interrupt specifier.
> +
> +The CEU supports a single parallel input and should contain a single 'port'
> +subnode with a single 'endpoint'. Connection to input devices are modeled
> +according to the video interfaces OF bindings specified in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Optional endpoint properties applicable to parallel input bus described in
> +the above mentioned "video-interfaces.txt" file are supported.
> +
> +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH 
> respectively.
> +  If property is not present, default is active high.
> +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH 
> respectively.
> +  If property is not present, default is active high.

Does the hardware support Bt.656? If it does, you need to tell the
difference between the parallel interface with default sync polarity and
Bt.656 interfaces. With the above it's ambiguous.

> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and an
> +OV7670 image sensor connected to i2c1 interface.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,r7s72100-ceu";
> + interrupts = ;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <_out>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> +     reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <_in>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> + };
> +};
> -- 
> 2.7.4
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2] v4l: doc: Clarify v4l2_mbus_fmt height definition

[Sakari Ailus]

Hi Kieran,

Thanks for the update.

On Mon, Jan 08, 2018 at 05:55:24PM +, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
> 
> Clarify this using the same text as is provided for the v4l2_pix_format
> which is explicit on the matter, and by matching the terminology of
> 'image height' rather than the misleading 'frame height'.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] v4l: doc: clarify v4l2_mbus_fmt height definition

[Sakari Ailus]

Hi Kieran,

On Mon, Jan 08, 2018 at 02:45:49PM +, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
> 
> Clarify this by referencing the v4l2_pix_format which is explicit on the
> matter, and by matching the terminology of 'image height' rather than
> the misleading 'frame height'.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> ---
>  Documentation/media/uapi/v4l/subdev-formats.rst | 6 --
>  include/uapi/linux/v4l2-mediabus.h  | 4 ++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
> b/Documentation/media/uapi/v4l/subdev-formats.rst
> index b1eea44550e1..a2a00202b430 100644
> --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> @@ -16,10 +16,12 @@ Media Bus Formats
>  
>  * - __u32
>- ``width``
> -  - Image width, in pixels.
> +  - Image width in pixels. See struct
> + :c:type:`v4l2_pix_format`.
>  * - __u32
>- ``height``
> -  - Image height, in pixels.
> +  - Image height in pixels. See struct
> + :c:type:`v4l2_pix_format`.
>  * - __u32
>- ``code``
>- Format code, from enum
> diff --git a/include/uapi/linux/v4l2-mediabus.h 
> b/include/uapi/linux/v4l2-mediabus.h
> index 6e20de63ec59..6b34108d0338 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -18,8 +18,8 @@
>  
>  /**
>   * struct v4l2_mbus_framefmt - frame format on the media bus
> - * @width:   frame width
> - * @height:  frame height
> + * @width:   image width
> + * @height:  image height (see struct v4l2_pix_format)

Hmm. This is the media bus format and it has no direct relation to
v4l2_pix_format. So no, I can't see what would be the point in making such
a reference.

>   * @code:data format code (from enum v4l2_mbus_pixelcode)
>   * @field:   used interlacing type (from enum v4l2_field)
>   * @colorspace:  colorspace of the data (from enum v4l2_colorspace)

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH/RFC v2 05/15] rcar-csi2: count usage for each source pad

[Sakari Ailus]

Hejssan,

On Tue, Dec 19, 2017 at 12:38:51AM +0100, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Tack för dina kommentarer.
> 
> On 2017-12-15 14:25:27 +0200, Sakari Ailus wrote:
> > On Thu, Dec 14, 2017 at 08:08:25PM +0100, Niklas Söderlund wrote:
> > > The R-Car CSI-2 hardware can output the same virtual channel
> > > simultaneously to more then one R-Car VIN. For this reason we need to
> > > move the usage counting from the global device to each source pad.
> > > 
> > > If a source pads usage count go from 0 to 1 we need to signal that a new
> > > stream should start, likewise if it go from 1 to 0 we need to stop a
> > > stream. At the same time we only want to start or stop the R-Car
> > > CSI-2 device only on the first or last stream.
> > > 
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > ---
> > >  drivers/media/platform/rcar-vin/rcar-csi2.c | 38 
> > > +++--
> > >  1 file changed, 30 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> > > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > > index 8ce0bfeef1113f9c..e0f56cc3d25179a9 100644
> > > --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> > > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > > @@ -328,6 +328,14 @@ enum rcar_csi2_pads {
> > >   NR_OF_RCAR_CSI2_PAD,
> > >  };
> > >  
> > > +static int rcar_csi2_pad_to_vc(unsigned int pad)
> > > +{
> > > + if (pad < RCAR_CSI2_SOURCE_VC0 || pad > RCAR_CSI2_SOURCE_VC3)
> > > + return -EINVAL;
> > > +
> > > + return pad - RCAR_CSI2_SOURCE_VC0;
> > > +}
> > > +
> > >  struct rcar_csi2_info {
> > >   const struct phypll_hsfreqrange *hsfreqrange;
> > >   const struct phtw_testdin_data *testdin_data;
> > > @@ -350,7 +358,7 @@ struct rcar_csi2 {
> > >   struct v4l2_mbus_framefmt mf;
> > >  
> > >   struct mutex lock;
> > > - int stream_count;
> > > + int stream_count[4];
> > 
> > Why 4?
> 
> There are 4 source pads connected to up to 8 different remote sink pads.

Could you use a #define (macro) for these numbers?

> 
> > 
> > >  
> > >   unsigned short lanes;
> > >   unsigned char lane_swap[4];
> > > @@ -630,7 +638,13 @@ static int rcar_csi2_s_stream(struct v4l2_subdev 
> > > *sd, unsigned int pad,
> > >  {
> > >   struct rcar_csi2 *priv = sd_to_csi2(sd);
> > >   struct v4l2_subdev *nextsd;
> > > - int ret;
> > > + unsigned int i, count = 0;
> > > + int ret, vc;
> > > +
> > > + /* Only allow stream control on source pads and valid vc */
> > > + vc = rcar_csi2_pad_to_vc(pad);
> > > + if (vc < 0)
> > > + return vc;
> > >  
> > >   /* Only one stream on each source pad */
> > >   if (stream != 0)
> > > @@ -642,7 +656,10 @@ static int rcar_csi2_s_stream(struct v4l2_subdev 
> > > *sd, unsigned int pad,
> > >   if (ret)
> > >   goto out;
> > >  
> > > - if (enable && priv->stream_count == 0) {
> > > + for (i = 0; i < 4; i++)
> > > + count += priv->stream_count[i];
> > > +
> > > + if (enable && count == 0) {
> > >   pm_runtime_get_sync(priv->dev);
> > >  
> > >   ret = rcar_csi2_start(priv);
> > > @@ -650,20 +667,23 @@ static int rcar_csi2_s_stream(struct v4l2_subdev 
> > > *sd, unsigned int pad,
> > >   pm_runtime_put(priv->dev);
> > >   goto out;
> > >   }
> > > + } else if (!enable && count == 1) {
> > > + rcar_csi2_stop(priv);
> > > + pm_runtime_put(priv->dev);
> > > + }
> > >  
> > > + if (enable && priv->stream_count[vc] == 0) {
> > >   ret = v4l2_subdev_call(nextsd, video, s_stream, 1);
> > >   if (ret) {
> > >   rcar_csi2_stop(priv);
> > >   pm_runtime_put(priv->dev);
> > >   goto out;
> > >   }
> > > - } else if (!enable && priv->stream_count == 1) {
> > > - rcar_csi2_stop(priv);
> > > + } else if (!enable && priv->stream_count[vc] == 1) {
> > 
> > Do I understand correctly that you can start and streams here one by one,
> > inde

Re: [PATCH/RFC v2 02/15] rcar-vin: use pad as the starting point for a pipeline

[Sakari Ailus]

On Tue, Dec 19, 2017 at 12:08:56AM +0100, Niklas Söderlund wrote:
> Hej Sakari,
> 
> Tack för dina kommentarer.
> 
> On 2017-12-15 13:54:02 +0200, Sakari Ailus wrote:
> > On Thu, Dec 14, 2017 at 08:08:22PM +0100, Niklas Söderlund wrote:
> > > The pipeline will be moved from the entity to the pads; reflect this in
> > > the media pipeline function API.
> > 
> > I'll merge this to "media: entity: Use pad as the starting point for a
> > pipeline" if you're fine with that.
> 
> I'm fine with that, the issue is that the rcar-vin Gen3 driver is not 
> yet upstream :-( If it makes it upstream before the work in your vc 
> branch feel free to squash this in. Until then I fear I need to keep 
> carry this in this series.

Oops, I thought it already was there. Anyway, no changes then.

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[Sakari Ailus]

> > > +   base = devm_ioremap_resource(dev, res);
> > > 
> > > You can assign ceudev->base directly and remove the base local variable.
> > > 
> > > > +   if (IS_ERR(base))
> > > > +   return PTR_ERR(base);
> > > > +   ceudev->base = base;
> > > > +
> > > > +   ret = platform_get_irq(pdev, 0);
> > > > +   if (ret < 0) {
> > > > +   dev_err(dev, "failed to get irq: %d\n", ret);
> > > > +   return ret;
> > > > +   }
> > > > +   irq = ret;
> > > > +
> > > > +   ret = devm_request_irq(dev, irq, ceu_irq,
> > > > +  0, dev_name(dev), ceudev);
> > > > +   if (ret) {
> > > > +   dev_err(>dev, "Unable to register CEU 
> > > > interrupt.\n");
> > > > +   return ret;
> > > > +   }
> > > > +
> > > > +   pm_suspend_ignore_children(dev, true);
> > > > +   pm_runtime_enable(dev);
> > > > +
> > > > +   ret = v4l2_device_register(dev, >v4l2_dev);
> > > > +   if (ret)
> > > > +   goto error_pm_disable;
> > > > +
> > > > +   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> > > > +   num_sd = ceu_parse_dt(ceudev);
> > > > +   } else if (dev->platform_data) {
> > > > +   num_sd = ceu_parse_platform_data(ceudev, 
> > > > dev->platform_data);
> > > > +   } else {
> > > > +   dev_err(dev, "CEU platform data not set and no OF 
> > > > support\n");
> > > > +   ret = -EINVAL;
> > > > +   goto error_v4l2_unregister;
> > > > +   }
> > > > +
> > > > +   if (num_sd < 0) {
> > > > +   ret = num_sd;
> > > > +   goto error_v4l2_unregister;
> > > > +   } else if (num_sd == 0)
> > > > +   return 0;
> > > 
> > > You need braces around the second statement too.
> > 
> > Ok, actually parse_dt() and parse_platform_data() behaves differently.
> > The former returns error if no subdevices are connected to CEU, the
> > latter returns 0. That's wrong.
> > 
> > I wonder what's the correct behavior here. Other mainline drivers I
> > looked into (pxa_camera and atmel-isc) behaves differently from each
> > other, so I guess this is up to each platform to decide.
> 
> No, what it means is that we've failed to standardize it, not that it 
> shouldn't be standardized :-)
> 
> > Also, the CEU can accept one single input (and I made it clear
> > in DT bindings documentation saying it accepts a single endpoint,
> > while I'm parsing all the available ones in driver, I will fix this)
> > but as it happens on Migo-R, there could be HW hacks to share the input
> > lines between multiple subdevices. Should I accept it from dts as well?
> > 
> > So:
> > 1) Should we fail to probe if no subdevices are connected?
> 
> While the CEU itself would be fully functional without a subdev, in practice 
> it would be of no use. I would thus fail probing.
> 
> > 2) Should we accept more than 1 subdevice from dts as it happens right
> > now for platform data?
> 
> We need to support multiple connected devices, as some of the boards require 
> that. What I'm not sure about is whether the multiplexer on the Migo-R board 
> should be modeled as a subdevice. We could in theory connect multiple sensors 
> to the CEU input signals without any multiplexer as long as all but one are 
> in 
> reset with their outputs in a high impedance state. As that wouldn' require a 
> multiplexer we would need to support multiple endpoints in the CEU port. We 
> could then support Migo-R the same way, making the multiplexer transparent.
> 
> Sakari, what would you do here ?

We do have:

drivers/media/platform/video-mux.c

What is not addressed right now are the CSI-2 bus parameters, if the mux is
just a passive switch. This could be done using the frame descriptors.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

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

[Sakari Ailus]

On Mon, Dec 18, 2017 at 05:53:57PM -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>

I'm not sure this is needed but it doesn't break anything either.

Feel free to add:

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 5/5] v4l2: async: Add debug output to v4l2-async module

[Sakari Ailus]

Hi Jacopo,

On Sun, Dec 17, 2017 at 05:42:54PM +0100, jacopo mondi wrote:
> Hi Sakari,
> 
> On Fri, Dec 15, 2017 at 06:17:04PM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Wed, Dec 13, 2017 at 07:26:20PM +0100, Jacopo Mondi wrote:
> > > The v4l2-async module operations are quite complex to follow, due to the
> > > asynchronous nature of subdevices and notifiers registration and
> > > matching procedures. In order to help with debugging of failed or
> > > erroneous matching between a subdevice and the notifier collected
> > > async_subdevice it gets matched against, introduce a few dev_dbg() calls
> > > in v4l2_async core operations.
> > >
> > > Protect the debug operations with a Kconfig defined symbol, to make sure
> > > when debugging is disabled, no additional code or data is added to the
> > > module.
> > >
> > > Notifiers are identified by the name of the subdevice or v4l2_dev they are
> > > registered by, while subdevice matching which now happens on endpoints,
> > > need a longer description built walking the fwnode graph backwards
> > > collecting parent nodes names (otherwise we would have had printouts
> > > like: "Matching "endpoint" with "endpoint"" which are not that useful).
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > >
> > > ---
> > > For fwnodes backed by OF, I may have used the "%pOF" format modifier to
> > > get the full node name instead of parsing the fwnode graph by myself with
> > > "v4l2_async_fwnode_full_name()". Unfortunately I'm not aware of anything
> > > like "%pOF" for ACPI backed fwnodes. Also, walking the fwnode graph by
> > > myself allows me to reduce the depth, to reduce the debug messages output
> > > length which is anyway long enough to result disturbing on a 80columns
> > > terminal window.
> >
> > ACPI doesn't have such at the moment. I think printing the full path would
> > still be better. There isn't that much more to print after all.
> 
> So you suggest to just use the full node name for OF. What about ACPI?
> 
> From your other reply I got that I can print the single node name for
> "device ACPI nodes" but not for "non-device ACPI nodes". Should I build
> the full device name in drivers/acpi/properties.c for ACPI devices
> like I'm doing here for fwnodes?

What I think would be nice was that ACPI would receive similar way to print
node names (as well as other information) as OF has, through printk.

I don't demand that to get the patchset in though, I'm fine if this is
limited to OF right now. It's debug info, after all that I've at least
personally been fine without.

> 
> >
> > > ---
> > >
> > >  drivers/media/v4l2-core/Kconfig  |  8 
> > >  drivers/media/v4l2-core/v4l2-async.c | 81 
> > > 
> > >  2 files changed, 89 insertions(+)
> > >
> > > diff --git a/drivers/media/v4l2-core/Kconfig 
> > > b/drivers/media/v4l2-core/Kconfig
> > > index a35c336..8331736 100644
> > > --- a/drivers/media/v4l2-core/Kconfig
> > > +++ b/drivers/media/v4l2-core/Kconfig
> > > @@ -17,6 +17,14 @@ config VIDEO_ADV_DEBUG
> > > V4L devices.
> > > In doubt, say N.
> > >
> > > +config VIDEO_V4L2_ASYNC_DEBUG
> > > + bool "Enable debug functionalities for V4L2 async module"
> > > + depends on VIDEO_V4L2
> >
> > I'm not sure I'd add a Kconfig option. This is adding a fairly simple
> > function only to the kernel.
> 
> So I will use a symbol defined in the module to enable/disable debug
> (maybe the "DEBUG" symbol itself?)

Dynamic debug can be enabled via the user space interface or the kernel
command line, I think that should be enough.

> 
> >
> > > + default n
> > > + ---help---
> > > +   Say Y here to enable debug output in V4L2 async module.
> > > +   In doubt, say N.
> > > +
> > >  config VIDEO_FIXED_MINOR_RANGES
> > >   bool "Enable old-style fixed minor ranges on drivers/video devices"
> > >   default n
> > > diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> > > b/drivers/media/v4l2-core/v4l2-async.c
> > > index c13a781..307e1a5 100644
> > > --- a/drivers/media/v4l2-core/v4l2-async.c
> > > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > > @@ -8,6 +8,10 @@
> > >   * published by the Free Software Foundation.
> > >   */
> &g

Re: [PATCH 4/5] v4l2: async: Postpone subdev_notifier registration

[Sakari Ailus]

Hi Laurent,

On Sun, Dec 17, 2017 at 07:03:17PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
> 
> Thank you for the patch.
> 
> On Wednesday, 13 December 2017 20:26:19 EET Jacopo Mondi wrote:
> > Currently, subdevice notifiers are tested against all available
> > subdevices as soon as they get registered. It often happens anyway
> > that the subdevice they are connected to is not yet initialized, as
> > it usually gets registered later in drivers' code. This makes debug
> > of v4l2_async particularly painful, as identifying a notifier with
> > an unitialized subdevice is tricky as they don't have a valid
> > 'struct device *' or 'struct fwnode_handle *' to be identified with.
> > 
> > In order to make sure that the notifier's subdevices is initialized
> > when the notifier is tesed against available subdevices post-pone the
> > actual notifier registration at subdevice registration time.
> 
> Aren't you piling yet another hack on top of an already dirty framework ? How 
> about fixing the root cause of the issue and ensuring that subdevs are 
> properly initialized when the notifier is registered ?

The problem domain is quite complex --- there are multiple drivers working
with multiple objects each here, and things can happen in a different order
--- which needs to be supported but is sometimes missed in design.

In this case the problem is that the sub-device is only registered after
the related notifier is. If you did that the other way around, the V4L2
async framework could well find that everything is done and proceed to call
the complete callback, just before the async sub-device notifier is
registered.

Perhaps this is, once again, a sign that we should really ditch the
complete callback. I'd hope we could find consensus on that. It's a lot of
trouble to support this and I feel it's an entirely arfiticial construct
that does not really solve a problem it's intended to.

> 
> > It is worth noting that post-poning registration of a subdevice notifier
> > does not impact on the completion of the notifiers chain, as even if a
> > subdev notifier completes as soon as it gets registered, the complete()
> > call chain cannot be upscaled as long as the subdevice the notifiers
> > belongs to is not registered.
> > 
> > Also, it is now safe to access a notifier 'struct device *' as we're now
> > sure it is properly initialized when the notifier is actually
> > registered.
> > 
> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > ---
> >  drivers/media/v4l2-core/v4l2-async.c | 65 +---
> >  include/media/v4l2-async.h   |  2 ++
> >  2 files changed, 43 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > b/drivers/media/v4l2-core/v4l2-async.c index 0a1bf1d..c13a781 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> 
> [snip]
> 
> > @@ -548,6 +551,20 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
> > sd->fwnode = dev_fwnode(sd->dev);
> > }
> > 
> > +   /*
> > +* If the subdevice has an unregisterd notifier, it's now time
> > +* to register it.
> > +*/
> > +   subdev_notifier = sd->subdev_notifier;
> > +   if (subdev_notifier && !subdev_notifier->registered) {
> > +   ret = __v4l2_async_notifier_register(subdev_notifier);
> > +   if (ret) {
> > +   sd->fwnode = NULL;
> > +   subdev_notifier->owner = NULL;
> > +   return ret;
> > +   }
> > +   }
> 
> This is the part I like the least in this patch set. The 
> v4l2_subdev::subdev_notifier field should really disappear, there's no reason 
> to limit subdevs to a single notifier. Implicit registration of notifiers is 
> a 
> dirty hack in my opinion.
> 
> > mutex_lock(_lock);
> > 
> > INIT_LIST_HEAD(>async_list);
> 
> [snip]
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 5/5] v4l2: async: Add debug output to v4l2-async module

[Sakari Ailus]

node);
> +}
> +
> +#else /* CONFIG_VIDEO_V4L2_ASYNC_DEBUG */
> +#define V4L2_ASYNC_FWNODE_NAME_LEN   0
> +
> +static void v4l2_async_fwnode_full_name(char *name,
> + unsigned int len,
> + struct fwnode_handle *fwnode)
> +{
> +}
> +#endif /* CONFIG_VIDEO_V4L2_ASYNC_DEBUG */
> +
>  static struct device *v4l2_async_notifier_dev(
>   struct v4l2_async_notifier *notifier)
>  {
> @@ -54,9 +104,12 @@ static void v4l2_async_notifier_call_unbind(struct 
> v4l2_async_notifier *n,
> 
>  static int v4l2_async_notifier_call_complete(struct v4l2_async_notifier *n)
>  {
> + struct device *dev = v4l2_async_notifier_dev(n);
>   if (!n->ops || !n->ops->complete)
>   return 0;
> 
> + dev_dbg(dev, "Complete notifier \"%s\"\n", fwnode_get_name(n->owner));
> +
>   return n->ops->complete(n);
>  }
> 
> @@ -100,8 +153,17 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
>   struct v4l2_async_notifier *notifier, struct v4l2_subdev *sd)
>  {
>   bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
> + struct device *dev = v4l2_async_notifier_dev(notifier);
> + char asd_full_name[V4L2_ASYNC_FWNODE_NAME_LEN];
> + char sd_full_name[V4L2_ASYNC_FWNODE_NAME_LEN];
>   struct v4l2_async_subdev *asd;
> 
> + v4l2_async_fwnode_full_name(sd_full_name, V4L2_ASYNC_FWNODE_NAME_LEN,
> + sd->fwnode);
> +
> + dev_dbg(dev, "Match notifier \"%s\" with subdevice \"%s\"\n",
> + fwnode_get_name(notifier->owner), sd_full_name);
> +
>   list_for_each_entry(asd, >waiting, list) {
>   /* bus_type has been verified valid before */
>   switch (asd->match_type) {
> @@ -115,6 +177,11 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
>   match = match_i2c;
>   break;
>   case V4L2_ASYNC_MATCH_FWNODE:
> + v4l2_async_fwnode_full_name(asd_full_name,
> + V4L2_ASYNC_FWNODE_NAME_LEN,
> + asd->match.fwnode.fwnode);
> + dev_dbg(dev, "Test sd \"%s\" with async_sd \"%s\"\n",
> + sd_full_name, asd_full_name);
>   match = match_fwnode;
>   break;
>   default:
> @@ -198,9 +265,16 @@ static int v4l2_async_match_notify(struct 
> v4l2_async_notifier *notifier,
>  struct v4l2_subdev *sd,
>  struct v4l2_async_subdev *asd)
>  {
> + struct device *dev = v4l2_async_notifier_dev(notifier);
>   struct v4l2_async_notifier *subdev_notifier;
> + char sd_full_name[V4L2_ASYNC_FWNODE_NAME_LEN];
>   int ret;
> 
> + v4l2_async_fwnode_full_name(sd_full_name, V4L2_ASYNC_FWNODE_NAME_LEN,
> + sd->fwnode);
> + dev_dbg(dev, "Matched sd: \"%s\" with notifier \"%s\"\n",
> + sd_full_name, fwnode_get_name(notifier->owner));
> +
>   ret = v4l2_device_register_subdev(v4l2_dev, sd);
>   if (ret < 0)
>   return ret;
> @@ -240,6 +314,7 @@ static int v4l2_async_match_notify(struct 
> v4l2_async_notifier *notifier,
>  static int v4l2_async_notifier_try_all_subdevs(
>   struct v4l2_async_notifier *notifier)
>  {
> + struct device *dev = v4l2_async_notifier_dev(notifier);
>   struct v4l2_device *v4l2_dev =
>   v4l2_async_notifier_find_v4l2_dev(notifier);
>   struct v4l2_subdev *sd;
> @@ -247,6 +322,9 @@ static int v4l2_async_notifier_try_all_subdevs(
>   if (!v4l2_dev)
>   return 0;
> 
> + dev_dbg(dev, "Testing notifier \"%s\" against all subdevices\n",
> + fwnode_get_name(notifier->owner));
> +
>  again:
>   list_for_each_entry(sd, _list, async_list) {
>   struct v4l2_async_subdev *asd;
> @@ -378,6 +456,9 @@ static int __v4l2_async_notifier_register(struct 
> v4l2_async_notifier *notifier)
> 
>   notifier->owner = dev_fwnode(dev);
> 
> + dev_dbg(dev, "Registering notifier \"%s\"\n",
> + fwnode_get_name(notifier->owner));
> +
>   mutex_lock(_lock);
> 
>   for (i = 0; i < notifier->num_subdevs; i++) {
> --
> 2.7.4
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 4/5] v4l2: async: Postpone subdev_notifier registration

[Sakari Ailus]

  sd->subdev_notifier;
> 
>   if (subdev_notifier)
>   v4l2_async_notifier_unbind_all_subdevs(subdev_notifier);
> @@ -371,8 +365,7 @@ static bool v4l2_async_notifier_fwnode_has_async_subdev(
> 
>  static int __v4l2_async_notifier_register(struct v4l2_async_notifier 
> *notifier)
>  {
> - struct device *dev =
> - notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL;
> + struct device *dev = v4l2_async_notifier_dev(notifier);
>   struct v4l2_async_subdev *asd;
>   int ret;
>   int i;
> @@ -383,6 +376,8 @@ static int __v4l2_async_notifier_register(struct 
> v4l2_async_notifier *notifier)
>   INIT_LIST_HEAD(>waiting);
>   INIT_LIST_HEAD(>done);
> 
> + notifier->owner = dev_fwnode(dev);
> +
>   mutex_lock(_lock);
> 
>   for (i = 0; i < notifier->num_subdevs; i++) {
> @@ -421,6 +416,7 @@ static int __v4l2_async_notifier_register(struct 
> v4l2_async_notifier *notifier)
> 
>   /* Keep also completed notifiers on the list */
>   list_add(>list, _list);
> + notifier->registered = true;
> 
>   mutex_unlock(_lock);
> 
> @@ -447,7 +443,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   return -EINVAL;
> 
>   notifier->v4l2_dev = v4l2_dev;
> - notifier->owner = dev_fwnode(v4l2_dev->dev);
> + notifier->registered = false;
> 
>   ret = __v4l2_async_notifier_register(notifier);
>   if (ret)
> @@ -466,7 +462,11 @@ int v4l2_async_subdev_notifier_register(struct 
> v4l2_subdev *sd,
>   return -EINVAL;
> 
>   notifier->sd = sd;
> - notifier->owner = dev_fwnode(sd->dev);
> + sd->subdev_notifier = notifier;
> + notifier->registered = false;
> +
> + if (!sd->dev || !sd->fwnode)
> + return 0;
> 
>   ret = __v4l2_async_notifier_register(notifier);
>   if (ret)
> @@ -482,12 +482,15 @@ static void __v4l2_async_notifier_unregister(
>   if (!notifier || (!notifier->v4l2_dev && !notifier->sd))
>   return;
> 
> - v4l2_async_notifier_unbind_all_subdevs(notifier);
> + if (notifier->registered) {
> + v4l2_async_notifier_unbind_all_subdevs(notifier);
> + list_del(>list);
> + }
> 
>   notifier->sd = NULL;
>   notifier->v4l2_dev = NULL;
> -
> - list_del(>list);
> + notifier->owner = NULL;
> + notifier->registered = false;
>  }
> 
>  void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> @@ -548,6 +551,20 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>   sd->fwnode = dev_fwnode(sd->dev);
>   }
> 
> + /*
> +  * If the subdevice has an unregisterd notifier, it's now time
> +  * to register it.
> +  */
> + subdev_notifier = sd->subdev_notifier;
> + if (subdev_notifier && !subdev_notifier->registered) {
> + ret = __v4l2_async_notifier_register(subdev_notifier);
> + if (ret) {
> + sd->fwnode = NULL;
> + subdev_notifier->owner = NULL;
> + return ret;
> + }
> + }
> +
>   mutex_lock(_lock);
> 
>   INIT_LIST_HEAD(>async_list);
> @@ -589,7 +606,7 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>* Complete failed. Unbind the sub-devices bound through registering
>* this async sub-device.
>*/
> - subdev_notifier = v4l2_async_find_subdev_notifier(sd);
> + subdev_notifier = sd->subdev_notifier;
>   if (subdev_notifier)
>   v4l2_async_notifier_unbind_all_subdevs(subdev_notifier);
> 
> diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
> index a15c01d..6ab04ad 100644
> --- a/include/media/v4l2-async.h
> +++ b/include/media/v4l2-async.h
> @@ -110,6 +110,7 @@ struct v4l2_async_notifier_operations {
>   * @waiting: list of struct v4l2_async_subdev, waiting for their drivers
>   * @done:list of struct v4l2_subdev, already probed
>   * @list:member in a global list of notifiers
> + * @registered: notifier registered complete flag
>   */
>  struct v4l2_async_notifier {
>   const struct v4l2_async_notifier_operations *ops;
> @@ -123,6 +124,7 @@ struct v4l2_async_notifier {
>   struct list_head waiting;
>   struct list_head done;
>   struct list_head list;
> + bool registered;
>  };
> 
>  /**
> --
> 2.7.4
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 3/5] include: v4l2_async: Add 'owner' field to notifier

[Sakari Ailus]

Hi Jacopo,

On Wed, Dec 13, 2017 at 07:26:18PM +0100, Jacopo Mondi wrote:
> Notifiers can be registered as root notifiers (identified by a 'struct
> v4l2_device *') or subdevice notifiers (identified by a 'struct
> v4l2_subdev *'). In order to identify a notifier no matter if it is root
> or not, add a 'struct fwnode_handle *owner' field, whose name can be
> printed out for debug purposes.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>

You'll have struct device either through the v4l2_device or v4l2_subdev. Do
you need an additional field for this?

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 2/5] device property: Add fwnode_get_name() operation

[Sakari Ailus]

_array)(const struct fwnode_handle *fwnode_handle,
> const char *propname, const char **val,
> size_t nval);
> + const char *(*get_name)(const struct fwnode_handle *fwnode);
>   struct fwnode_handle *(*get_parent)(const struct fwnode_handle *fwnode);
>   struct fwnode_handle *
>   (*get_next_child_node)(const struct fwnode_handle *fwnode,
> diff --git a/include/linux/property.h b/include/linux/property.h
> index f6189a3..0fc464f 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -78,6 +78,7 @@ int fwnode_property_get_reference_args(const struct 
> fwnode_handle *fwnode,
>  unsigned int nargs, unsigned int index,
>  struct fwnode_reference_args *args);
>  
> +const char *fwnode_get_name(const struct fwnode_handle *fwnode);
>  struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle *fwnode);
>  struct fwnode_handle *fwnode_get_next_parent(
>   struct fwnode_handle *fwnode);

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 06/15] rcar-csi2: use frame description information when propagating .s_stream()

[Sakari Ailus]

nd stream for vc %u\n", vc);
> + return -EINVAL;
> + }
> +
> + /* Start or stop the requested stream */
> + mutex_lock(>lock);
>  
>   for (i = 0; i < 4; i++)
>   count += priv->stream_count[i];
> @@ -673,14 +697,14 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>   }
>  
>   if (enable && priv->stream_count[vc] == 0) {
> - ret = v4l2_subdev_call(nextsd, video, s_stream, 1);
> + ret = v4l2_subdev_call(nextsd, pad, s_stream, rpad, rstream, 1);
>       if (ret) {
>   rcar_csi2_stop(priv);
>   pm_runtime_put(priv->dev);
>   goto out;
>   }
>   } else if (!enable && priv->stream_count[vc] == 1) {
> - ret = v4l2_subdev_call(nextsd, video, s_stream, 0);
> + ret = v4l2_subdev_call(nextsd, pad, s_stream, rpad, rstream, 0);
>   }
>  
>   priv->stream_count[vc] += enable ? 1 : -1;
> -- 
> 2.15.1
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 05/15] rcar-csi2: count usage for each source pad

[Sakari Ailus]

On Thu, Dec 14, 2017 at 08:08:25PM +0100, Niklas Söderlund wrote:
> The R-Car CSI-2 hardware can output the same virtual channel
> simultaneously to more then one R-Car VIN. For this reason we need to
> move the usage counting from the global device to each source pad.
> 
> If a source pads usage count go from 0 to 1 we need to signal that a new
> stream should start, likewise if it go from 1 to 0 we need to stop a
> stream. At the same time we only want to start or stop the R-Car
> CSI-2 device only on the first or last stream.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 38 
> +++--
>  1 file changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index 8ce0bfeef1113f9c..e0f56cc3d25179a9 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -328,6 +328,14 @@ enum rcar_csi2_pads {
>   NR_OF_RCAR_CSI2_PAD,
>  };
>  
> +static int rcar_csi2_pad_to_vc(unsigned int pad)
> +{
> + if (pad < RCAR_CSI2_SOURCE_VC0 || pad > RCAR_CSI2_SOURCE_VC3)
> + return -EINVAL;
> +
> + return pad - RCAR_CSI2_SOURCE_VC0;
> +}
> +
>  struct rcar_csi2_info {
>   const struct phypll_hsfreqrange *hsfreqrange;
>   const struct phtw_testdin_data *testdin_data;
> @@ -350,7 +358,7 @@ struct rcar_csi2 {
>   struct v4l2_mbus_framefmt mf;
>  
>   struct mutex lock;
> - int stream_count;
> + int stream_count[4];

Why 4?

>  
>   unsigned short lanes;
>   unsigned char lane_swap[4];
> @@ -630,7 +638,13 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>  {
>   struct rcar_csi2 *priv = sd_to_csi2(sd);
>   struct v4l2_subdev *nextsd;
> - int ret;
> + unsigned int i, count = 0;
> + int ret, vc;
> +
> + /* Only allow stream control on source pads and valid vc */
> + vc = rcar_csi2_pad_to_vc(pad);
> + if (vc < 0)
> + return vc;
>  
>   /* Only one stream on each source pad */
>   if (stream != 0)
> @@ -642,7 +656,10 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>   if (ret)
>   goto out;
>  
> - if (enable && priv->stream_count == 0) {
> + for (i = 0; i < 4; i++)
> + count += priv->stream_count[i];
> +
> + if (enable && count == 0) {
>   pm_runtime_get_sync(priv->dev);
>  
>   ret = rcar_csi2_start(priv);
> @@ -650,20 +667,23 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>   pm_runtime_put(priv->dev);
>   goto out;
>   }
> + } else if (!enable && count == 1) {
> + rcar_csi2_stop(priv);
> + pm_runtime_put(priv->dev);
> + }
>  
> + if (enable && priv->stream_count[vc] == 0) {
>   ret = v4l2_subdev_call(nextsd, video, s_stream, 1);
>   if (ret) {
>   rcar_csi2_stop(priv);
>   pm_runtime_put(priv->dev);
>   goto out;
>   }
> - } else if (!enable && priv->stream_count == 1) {
> - rcar_csi2_stop(priv);
> + } else if (!enable && priv->stream_count[vc] == 1) {

Do I understand correctly that you can start and streams here one by one,
independently of each other?

Sometimes this might not be the case. I wonder if we should have a way to
tell that to the caller.

>   ret = v4l2_subdev_call(nextsd, video, s_stream, 0);
> - pm_runtime_put(priv->dev);
>   }
>  
> - priv->stream_count += enable ? 1 : -1;
> + priv->stream_count[vc] += enable ? 1 : -1;
>  out:
>   mutex_unlock(>lock);
>  
> @@ -919,7 +939,9 @@ static int rcar_csi2_probe(struct platform_device *pdev)
>   priv->dev = >dev;
>  
>   mutex_init(>lock);
> - priv->stream_count = 0;
> +
> + for (i = 0; i < 4; i++)
> + priv->stream_count[i] = 0;
>  
>   ret = rcar_csi2_probe_resources(priv, pdev);
>   if (ret) {
> -- 
> 2.15.1
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 03/15] rcar-vin: use the pad and stream aware s_stream

[Sakari Ailus]

Hej,

On Thu, Dec 14, 2017 at 08:08:23PM +0100, Niklas Söderlund wrote:
> To work with multiplexed streams the pad and stream aware s_stream
> operation needs to be used.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index cf30e5fceb1d493a..8435491535060eae 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1180,7 +1180,7 @@ static int rvin_set_stream(struct rvin_dev *vin, int on)
>  
>   if (!on) {
>   media_pipeline_stop(vin->vdev.entity.pads);
> - return v4l2_subdev_call(sd, video, s_stream, 0);
> + return v4l2_subdev_call(sd, pad, s_stream, pad->index, 0, 0);

Have you thought of adding a wrapper for the s_stream callback?

I think you should either change all s_stream callbacks from video to pad,
or add a wrapper which then calls the video op instead of the pad op if the
pad op does not exist. Otherwise we again have two non-interoperable
classes of drivers for no good reason.

Thinking about it, I'm not all that certain changing all instances would be
that much work in the end; it should be done anyway. Devices that have a
single stream (i.e. everything right now) just don't care about the pad
number.

>   }
>  
>   fmt.pad = pad->index;
> @@ -1239,12 +1239,14 @@ static int rvin_set_stream(struct rvin_dev *vin, int 
> on)
>   if (media_pipeline_start(vin->vdev.entity.pads, pipe))
>   return -EPIPE;
>  
> - ret = v4l2_subdev_call(sd, video, s_stream, 1);
> + ret = v4l2_subdev_call(sd, pad, s_stream, pad->index, 0, 1);
>   if (ret == -ENOIOCTLCMD)
>   ret = 0;
>   if (ret)
>   media_pipeline_stop(vin->vdev.entity.pads);
>  
> +     vin_dbg(vin, "pad: %u stream: 0 enable: %d\n", pad->index, on);
> +
>   return ret;
>  }
>  
> -- 
> 2.15.1
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 02/15] rcar-vin: use pad as the starting point for a pipeline

[Sakari Ailus]

On Thu, Dec 14, 2017 at 08:08:22PM +0100, Niklas Söderlund wrote:
> The pipeline will be moved from the entity to the pads; reflect this in
> the media pipeline function API.

I'll merge this to "media: entity: Use pad as the starting point for a
pipeline" if you're fine with that.

I haven't compiled everything for some time, and newly added drivers may be
lacking these changes. I'll re-check that soonish.

> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 03a914361a33125c..cf30e5fceb1d493a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1179,7 +1179,7 @@ static int rvin_set_stream(struct rvin_dev *vin, int on)
>   return -EPIPE;
>  
>   if (!on) {
> - media_pipeline_stop(>vdev.entity);
> + media_pipeline_stop(vin->vdev.entity.pads);
>   return v4l2_subdev_call(sd, video, s_stream, 0);
>   }
>  
> @@ -1235,15 +1235,15 @@ static int rvin_set_stream(struct rvin_dev *vin, int 
> on)
>   fmt.format.height != vin->format.height)
>   return -EPIPE;
>  
> - pipe = sd->entity.pipe ? sd->entity.pipe : >vdev.pipe;
> - if (media_pipeline_start(>vdev.entity, pipe))
> + pipe = sd->entity.pads->pipe ? sd->entity.pads->pipe : >vdev.pipe;
> + if (media_pipeline_start(vin->vdev.entity.pads, pipe))
>   return -EPIPE;
>  
>   ret = v4l2_subdev_call(sd, video, s_stream, 1);
>   if (ret == -ENOIOCTLCMD)
>   ret = 0;
>   if (ret)
> -     media_pipeline_stop(>vdev.entity);
> + media_pipeline_stop(vin->vdev.entity.pads);
>  
>   return ret;
>  }
> -- 
> 2.15.1
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 01/15] v4l2-subdev.h: add pad and stream aware s_stream

[Sakari Ailus]

Hejssan Niklas,

Tack för uppdaterade lappor!

On Thu, Dec 14, 2017 at 08:08:21PM +0100, Niklas Söderlund wrote:
> To be able to start and stop individual streams of a multiplexed pad the
> s_stream operation needs to be both pad and stream aware. Add a new
> operation to pad ops to facilitate this.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  include/media/v4l2-subdev.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index a30a94fad8dbacde..7288209338a48fda 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -669,6 +669,9 @@ struct v4l2_subdev_pad_config {
>   *
>   * @set_frame_desc: set the low level media bus frame parameters, @fd array
>   *  may be adjusted by the subdev driver to device 
> capabilities.
> + *
> + * @s_stream: used to notify the driver that a stream will start or has
> + *   stopped.

This is actually the callback which is used to control the stream state.
The above suggests that it's a notification of something that has happened
(or about to happen). How about:

Enable or disable streaming on a sub-device pad.

>   */
>  struct v4l2_subdev_pad_ops {
>   int (*init_cfg)(struct v4l2_subdev *sd,
> @@ -713,6 +716,8 @@ struct v4l2_subdev_pad_ops {
>  struct v4l2_subdev_routing *route);
>   int (*set_routing)(struct v4l2_subdev *sd,
>  struct v4l2_subdev_routing *route);
> + int (*s_stream)(struct v4l2_subdev *sd, unsigned int pad,
> +     unsigned int stream, int enable);

How about bool for enable?

>  };
>  
>  /**

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v9 07/28] rcar-vin: change name of video device

[Sakari Ailus]

On Fri, Dec 08, 2017 at 10:17:36AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> (CC'ing Sakari)
> 
> Thank you for the patch.
> 
> On Friday, 8 December 2017 03:08:21 EET Niklas Söderlund wrote:
> > The rcar-vin driver needs to be part of a media controller to support
> > Gen3. Give each VIN instance a unique name so it can be referenced from
> > userspace.
> > 
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > Reviewed-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
> > ---
> >  drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> > 59ec6d3d119590aa..19de99133f048960 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > @@ -876,7 +876,8 @@ int rvin_v4l2_register(struct rvin_dev *vin)
> > vdev->fops = _fops;
> > vdev->v4l2_dev = >v4l2_dev;
> > vdev->queue = >queue;
> > -   strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
> > +   snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
> > +dev_name(vin->dev));
> 
> Do we need the module name here ? How about calling them "%s output", 
> dev_name(vin->dev) to emphasize the fact that this is a video node and not a 
> VIN subdev ? This is what the omap3isp and vsp1 drivers do.
> 
> We're suffering a bit from the fact that V4L2 has never standardized a naming 
> scheme for the devices. It wouldn't be fair to ask you to fix that as a 
> prerequisite to get the VIN driver merged, but we clearly have to work on 
> that 
> at some point.

Agreed, this needs to be stable and I think aligning to what omap3isp or
vsp1 do would be a good fix here.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v5] v4l2-async: Match parent devices

[Sakari Ailus]

On Wed, Dec 06, 2017 at 02:58:39PM +, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> Devices supporting multiple endpoints on a single device node must set
> their subdevice fwnode to the endpoint to allow distinct comparisons.
> 
> Adapt the match_fwnode call to compare against the provided fwnodes
> first, but to also perform a cross reference comparison against the
> parent fwnodes of each other.
> 
> This allows notifiers to pass the endpoint for comparison and still
> support existing subdevices which store their default parent device
> node.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>
> 
> ---
> 
> Hi Sakari,
> 
> Since you signed-off on this patch - it has had to be reworked due to the
> changes on the of_node_full_name() functionality.
> 
> I believe it is correct now to *just* do the pointer matching, as that matches
> the current implementation, and converting to device_nodes will be just as
> equal as the fwnodes, as they are simply containers.
> 
> Let me know if you are happy to maintain your SOB on this patch - and if we 
> need
> to work towards getting this integrated upstream, especially in light of your 
> new
> endpoint matching work.

I'd really want to avoid resorting to matching opportunistically --- please
see my reply to Niklas on "[RFC 1/1] v4l: async: Use endpoint node, not
device node, for fwnode match".

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v12 1/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Sakari Ailus]

On Wed, Nov 29, 2017 at 08:32:34PM +0100, Niklas Söderlund wrote:
> Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> are located between the video sources (CSI-2 transmitters) and the video
> grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> 
> Each CSI-2 device is connected to more then one VIN device which
> simultaneously can receive video from the same CSI-2 device. Each VIN
> device can also be connected to more then one CSI-2 device. The routing
> of which link are used are controlled by the VIN devices. There are only
> a few possible routes which are set by hardware limitations, which are
> different for each SoC in the Gen3 family.
> 
> To work with the limitations of routing possibilities it is necessary
> for the DT bindings to describe which VIN device is connected to which
> CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> VIN device that be connected to it. To setup and to know which links are
> valid for each SoC is the responsibility of the VIN driver since the
> register to configure it belongs to the VIN hardware.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> Acked-by: Rob Herring <r...@kernel.org>

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v12 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hejssan!!

On Sat, Dec 02, 2017 at 03:50:21PM +0100, Niklas Söderlund wrote:
> Hej Sakari,
> 
> Thanks for your feedback.
> 
> On 2017-12-02 16:05:08 +0200, Sakari Ailus wrote:
> > Hejssan,
> > 
> > On Sat, Dec 02, 2017 at 12:08:21PM +0100, Niklas Söderlund wrote:
> > ...
> > > > > +static int rcar_csi2_parse_dt(struct rcar_csi2 *priv)
> > > > > +{
> > > > > + struct device_node *ep;
> > > > > + struct v4l2_fwnode_endpoint v4l2_ep;
> > > > > + int ret;
> > > > > +
> > > > > + ep = of_graph_get_endpoint_by_regs(priv->dev->of_node, 0, 0);
> > > > > + if (!ep) {
> > > > > + dev_err(priv->dev, "Not connected to subdevice\n");
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), 
> > > > > _ep);
> > > > > + if (ret) {
> > > > > + dev_err(priv->dev, "Could not parse v4l2 endpoint\n");
> > > > > + of_node_put(ep);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + ret = rcar_csi2_parse_v4l2(priv, _ep);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + priv->remote.match.fwnode.fwnode =
> > > > > + fwnode_graph_get_remote_endpoint(of_fwnode_handle(ep));
> > > > 
> > > > To continue the discussion from v10 --- how does this work? The V4L2 
> > > > async
> > > > framework does still matching for the node of the device, not the 
> > > > endpoint.
> > > > 
> > > > My suggestion is to handle this in match_fwnode until all drivers have 
> > > > been
> > > > converted. The V4L2 fwnode helper should be changed as well, then you 
> > > > could
> > > > use it here, too.
> > > 
> > > I agree that the V4L2 async framework should be changed to work with 
> > > endpoints and not the node of the device. I also agree on how this 
> > > change should be introduced.
> > > 
> > > But I don't feel that this change of the framework needs to block this 
> > > patch-set. Once the framework is updated to work with endpoints it 
> > > should be a trivial patch to change rcar-csi2 to use the new helper. Do 
> > > you agree whit this or do you feel that this patch-set should depend on 
> > > such change of the framework?
> > 
> > Without changes to the framework, I don't think this would work since the
> > async framework (or individual drivers) will assign the device's fwnode,
> > not that of the endpoint, to the fwnode against which to match the async
> > sub-device.
> > 
> > Therefore you'll need these changes for this driver to work. Or if you
> > introduce a sub-device driver that uses endpoints as well, then we have two
> > non-interoperable sets of ISP (or bridge) and sub-device drivers. That'd be
> > quite undesirable.
> 
> Such a driver is already upstream, the adv748x driver register its 
> subdevices using endpoints rather then the node of the device itself.
> 
> 
> int adv748x_csi2_init(...)
> {
> 
> ...
> 
> /* Ensure that matching is based upon the endpoint fwnodes */
> tx->sd.fwnode = of_fwnode_handle(ep);
> 
> ...
> }
> 
> 
> A related patch to when the adv748x driver was unstreamed where 
> 'v4l2-async: Match parent devices' by Kieran to make this change in
> behavior not to cause the non-interoperable sets your mention. It seems 
> however that that change have fallen thru the cracks.

Please see the other patch I just sent you (plus linux-media).

> 
> > 
> > Or, if you don't care whether it'd work with your use case right now, you
> > could use the helper function without changes. :-)
> 
> The adv748x is the primary use-case for the rcar-csi2 driver at the 
> moment. So I must either keep this workaround in the driver or make this 
> patch-set depend on future framework fixes. I would prefer to be able to 
> use the helper as it makes the driver less complex. At the same time I 
> don't want yet another framework change as a blocker for this patch-set 
> :-)
> 
> Once I'm back from my short vacation I will give the framework update a 
> try and if it turns out OK I will make this patch-set dependent on those 
> changes and squash in my patch which converts rcar-csi2 to use the 
> helper which is already done in preparation of future framework updates.
> 
> If it turns out the changes needed are complex or get stuck in review I 
> would prefer if it was possible to move forward with the workaround in 
> the driver for now and move it to the helper once it's available. Do 
> this sound like a agreeable plan to you?

Yes, but I think changing the framework should be fine.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v12 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

 priv->pads);
> > > + if (ret)
> > > + goto error;
> > > +
> > > + ret = v4l2_async_register_subdev(>subdev);
> > > + if (ret < 0)
> > > + goto error;
> > > +
> > > + pm_runtime_enable(>dev);
> > 
> > Is this enough for platform devices? Just wondering.
> 
> As far as I can tell from the documentation this should be enough. I'm 
> no expert on PM so if I'm wrong please let me know.
> 
> Geert: do I understand the documentation correctly?
> 
> > 
> > > +
> > > + dev_info(priv->dev, "%d lanes found\n", priv->lanes);
> > 
> > I'd use dev_dbg.
> 
> I'm thorn about this one. I agree that the information printed is not 
> critical. But I have found this useful when receiving logs from users 
> who have misconfigured there DTS with the wrong number of lines.
> 
> I'm open to changing this, but if it's a matter of taste I prefer to 
> keep it at a info level.

No objections. There are a bunch of stuff that can go wrong, this is just
one small piece of that. Thinking about it, it might be nice to add debug
prints for endpoint parsing so we'd have a generic way to print this
information.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v12 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

t; + priv->notifier.subdevs = devm_kzalloc(priv->dev,
> +   sizeof(*priv->notifier.subdevs),
> +   GFP_KERNEL);
> + if (priv->notifier.subdevs == NULL)
> + return -ENOMEM;
> +
> + priv->notifier.num_subdevs = 1;
> + priv->notifier.subdevs[0] = >remote;
> + priv->notifier.ops = _csi2_notify_ops;
> +
> + dev_dbg(priv->dev, "Found '%pOF'\n",
> + to_of_node(priv->remote.match.fwnode.fwnode));
> +
> + return v4l2_async_subdev_notifier_register(>subdev,
> +>notifier);
> +}
> +
> +/* 
> -
> + * Platform Device Driver
> + */
> +
> +static const struct media_entity_operations rcar_csi2_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate,
> +};
> +
> +static int rcar_csi2_probe_resources(struct rcar_csi2 *priv,
> +  struct platform_device *pdev)
> +{
> + struct resource *res;
> + int irq;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(priv->base))
> + return PTR_ERR(priv->base);
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + return 0;
> +}
> +
> +static const struct rcar_csi2_info rcar_csi2_info_r8a7795 = {
> + .hsfreqrange = hsfreqrange_h3_v3h_m3n,
> + .clear_ulps = true,
> + .init_phtw = true,
> + .csi0clkfreqrange = 0x20,
> +};
> +
> +static const struct rcar_csi2_info rcar_csi2_info_r8a7795es1 = {
> + .hsfreqrange = hsfreqrange_m3w_h3es1,
> +};
> +
> +static const struct rcar_csi2_info rcar_csi2_info_r8a7796 = {
> + .hsfreqrange = hsfreqrange_m3w_h3es1,
> +};
> +
> +static const struct of_device_id rcar_csi2_of_table[] = {
> + {
> + .compatible = "renesas,r8a7795-csi2",
> + .data = _csi2_info_r8a7795,
> + },
> + {
> + .compatible = "renesas,r8a7796-csi2",
> + .data = _csi2_info_r8a7796,
> + },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, rcar_csi2_of_table);
> +
> +static const struct soc_device_attribute r8a7795es1[] = {
> + {
> + .soc_id = "r8a7795", .revision = "ES1.*",
> + .data = _csi2_info_r8a7795es1,
> + },
> + { /* sentinel */}
> +};
> +
> +static int rcar_csi2_probe(struct platform_device *pdev)
> +{
> + const struct soc_device_attribute *attr;
> + struct rcar_csi2 *priv;
> + unsigned int i;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->info = of_device_get_match_data(>dev);
> +
> + /* r8a7795 ES1.x behaves different then ES2.0+ but no own compat */
> + attr = soc_device_match(r8a7795es1);
> + if (attr)
> + priv->info = attr->data;
> +
> + priv->dev = >dev;
> +
> + mutex_init(>lock);
> + priv->stream_count = 0;
> +
> + ret = rcar_csi2_probe_resources(priv, pdev);
> + if (ret) {
> + dev_err(priv->dev, "Failed to get resources\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + ret = rcar_csi2_parse_dt(priv);
> + if (ret)
> + return ret;
> +
> + priv->subdev.owner = THIS_MODULE;
> + priv->subdev.dev = >dev;
> + v4l2_subdev_init(>subdev, _csi2_subdev_ops);
> + v4l2_set_subdevdata(>subdev, >dev);
> + snprintf(priv->subdev.name, V4L2_SUBDEV_NAME_SIZE, "%s %s",
> +  KBUILD_MODNAME, dev_name(>dev));
> + priv->subdev.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
> +
> + priv->subdev.entity.function = MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;
> + priv->subdev.entity.ops = _csi2_entity_ops;
> +
> + priv->pads[RCAR_CSI2_SINK].flags = MEDIA_PAD_FL_SINK;
> + for (i = RCAR_CSI2_SOURCE_VC0; i < NR_OF_RCAR_CSI2_PAD; i++)
> + priv->pads[i].flags = MEDIA_PAD_FL_SOURCE;
> +
> + ret = media_entity_pads_init(>subdev.entity, NR_OF_RCAR_CSI2_PAD,
> +  priv->pads);
> + if (ret)
> + goto error;
> +
> + ret = v4l2_async_register_subdev(>subdev);
> + if (ret < 0)
> + goto error;
> +
> + pm_runtime_enable(>dev);

Is this enough for platform devices? Just wondering.

> +
> + dev_info(priv->dev, "%d lanes found\n", priv->lanes);

I'd use dev_dbg.

> +
> + return 0;
> +
> +error:
> + v4l2_async_notifier_unregister(>notifier);
> + v4l2_async_notifier_cleanup(>notifier);
> +
> + return ret;
> +}
> +
> +static int rcar_csi2_remove(struct platform_device *pdev)
> +{
> + struct rcar_csi2 *priv = platform_get_drvdata(pdev);
> +
> + v4l2_async_notifier_unregister(>notifier);
> + v4l2_async_notifier_cleanup(>notifier);
> + v4l2_async_unregister_subdev(>subdev);
> +
> + pm_runtime_disable(>dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver __refdata rcar_csi2_pdrv = {
> + .remove = rcar_csi2_remove,
> + .probe  = rcar_csi2_probe,
> + .driver = {
> + .name   = "rcar-csi2",
> + .of_match_table = of_match_ptr(rcar_csi2_of_table),
> + },
> +};
> +
> +module_platform_driver(rcar_csi2_pdrv);
> +
> +MODULE_AUTHOR("Niklas Söderlund <niklas.soderl...@ragnatech.se>");
> +MODULE_DESCRIPTION("Renesas R-Car MIPI CSI-2 receiver");
> +MODULE_LICENSE("GPL v2");

-- 
Hälsningar,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [RFC] v4l: i2c: ov7670: Implement mbus configuration

[Sakari Ailus]

On Wed, Nov 29, 2017 at 01:04:30PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
> 
> On Mon, Nov 27, 2017 at 11:26:53AM +0100, Jacopo Mondi wrote:
> > ov7670 currently supports configuration of a few parameters only through
> > platform data. Implement media bus configuration by parsing DT properties
> > at probe() time and opportunely configure REG_COM10 during s_format().
> > 
> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > 
> > ---
> > 
> > Hi linux-media,
> >I'm using this sensor to test the CEU driver I have submitted some time 
> > ago
> > and I would like to change synchronization signal polarities to test them in
> > combination with that driver.
> > 
> > So I added support for retrieving some properties listed in the device tree
> > bindings documentation from sensor's DT node and made a patch, BUT I'm
> > slightly confused about this (and that's why this is an RFC).
> > 
> > I did a grep for "sync-active" in drivers/media/i2c/ and no sensor driver
> > implements any property parsing, so I guess I'm doing something wrong here.
> 
> :-)
> 
> The standard properties are parsed in the V4L2 fwnode framework, and
> gathered to v4l2_fwnode_endpoint struct for drivers to use. Please see e.g.
> the smiapp driver how to do this.
> 
> You'll still need to parse device specific properties in the driver.
> 
> > 
> > I thought that maybe sensor media bus configuration should come from the
> > platform driver, through the s_mbus_config() operation in 
> > v4l2_subdev_video_ops,

It's specified in the sensor's local endpoint. The corresponding
configuration needs to be present in the remote endpoint. These are not
necessarily always the same due to e.g. wiring.

> > but that's said to be deprecated. So maybe is the framework providing 
> > support
> > for parsing those properties? Another grep there and I found only 
> > v4l2-fwnode.c
> > has support for parsing serial/parallel bus properties, but my 
> > understanding is
> > that those functions are meant to be used by the platform driver when
> > parsing the remote fw node.
> > 
> > So please help me out here: where should I implement media bus configuration
> > for sensor drivers?
> > 
> > Thanks
> >j
> > 
> > PS: being this just an RFC I have not updated dt bindings, and only
> > compile-tested the patch
> > 
> > ---
> >  drivers/media/i2c/ov7670.c | 108 
> > ++---
> >  1 file changed, 101 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> > index e88549f..7e2de7e 100644
> > --- a/drivers/media/i2c/ov7670.c
> > +++ b/drivers/media/i2c/ov7670.c
> > @@ -88,6 +88,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-1)");
> >  #define REG_COM10  0x15/* Control 10 */
> >  #define   COM10_HSYNC0x40/* HSYNC instead of HREF */
> >  #define   COM10_PCLK_HB  0x20/* Suppress PCLK on horiz blank */
> > +#define   COM10_PCLK_REV  0x10   /* Latch data on PCLK rising edge */
> >  #define   COM10_HREF_REV  0x08   /* Reverse HREF */
> >  #define   COM10_VS_LEAD  0x04/* VSYNC on clock leading edge */
> >  #define   COM10_VS_NEG   0x02/* VSYNC negative */
> > @@ -233,6 +234,7 @@ struct ov7670_info {
> > struct clk *clk;
> > struct gpio_desc *resetb_gpio;
> > struct gpio_desc *pwdn_gpio;
> > +   unsigned int mbus_config;   /* Media bus configuration flags */
> > int min_width;  /* Filter out smaller sizes */
> > int min_height; /* Filter out smaller sizes */
> > int clock_speed;/* External clock speed (MHz) */
> > @@ -985,7 +987,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> > struct ov7670_format_struct *ovfmt;
> > struct ov7670_win_size *wsize;
> > struct ov7670_info *info = to_state(sd);
> > -   unsigned char com7;
> > +   unsigned char com7, com10;
> > int ret;
> > 
> > if (format->pad)
> > @@ -1021,6 +1023,9 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> > ret = 0;
> > if (wsize->regs)
> > ret = ov7670_write_array(sd, wsize->regs);
> > +   if (ret)
> > +   return ret;
> > +
> > info->fmt = ovfmt;
> > 
> > /*
> > @@ -1033,8 +1038,26 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> >  * to write it unconditionally, and that will make the frame
> > 

Re: [RFC] v4l: i2c: ov7670: Implement mbus configuration

[Sakari Ailus]

e)
> + com10 |= COM10_PCLK_HB;
> +
> + if (com10)
> + ret = ov7670_write(sd, REG_COM10, com10);
> + if (ret)
> + return ret;
> +
>   return 0;
>  }
> 
> @@ -1572,6 +1595,29 @@ static int ov7670_init_gpio(struct i2c_client *client, 
> struct ov7670_info *info)
>   return 0;
>  }
> 
> +/**
> + * ov7670_parse_dt_prop() - parse property "prop_name" in OF node
> + *
> + * @return The property value or < 0 if property not present
> + *  or wrongly specified.
> + */
> +static int ov7670_parse_dt_prop(struct device *dev, char *prop_name)
> +{
> + struct device_node *np = dev->of_node;
> + u32 prop_val;
> + int ret;
> +
> + ret = of_property_read_u32(np, prop_name, _val);
> + if (ret) {
> + if (ret != -EINVAL)
> + dev_err(dev, "Unable to parse property %s: %d\n",
> + prop_name, ret);
> + return ret;
> + }
> +
> + return prop_val;
> +}
> +
>  static int ov7670_probe(struct i2c_client *client,
>   const struct i2c_device_id *id)
>  {
> @@ -1587,7 +1633,58 @@ static int ov7670_probe(struct i2c_client *client,
>   v4l2_i2c_subdev_init(sd, client, _ops);
> 
>   info->clock_speed = 30; /* default: a guess */
> - if (client->dev.platform_data) {
> +
> + if (IS_ENABLED(CONFIG_OF) && client->dev.of_node) {
> + /*
> +  * Parse OF properties to initialize media bus configuration.
> +  *
> +  * Use sensor's default configuration if a property is not
> +  * specified (ret == -EINVAL):
> +  */
> + info->mbus_config = 0;
> +
> + ret = ov7670_parse_dt_prop(>dev, "hsync-active");
> + if (ret < 0 && ret != -EINVAL)
> + return ret;
> + else if (ret == 0)
> + info->mbus_config |= V4L2_MBUS_HSYNC_ACTIVE_LOW;
> + else
> + info->mbus_config |= V4L2_MBUS_HSYNC_ACTIVE_HIGH;
> +
> + ret = ov7670_parse_dt_prop(>dev, "vsync-active");
> + if (ret < 0 && ret != -EINVAL)
> + return ret;
> + else if (ret == 0)
> + info->mbus_config |= V4L2_MBUS_VSYNC_ACTIVE_LOW;
> + else
> + info->mbus_config |= V4L2_MBUS_VSYNC_ACTIVE_HIGH;
> +
> + ret = ov7670_parse_dt_prop(>dev, "pclk-sample");
> + if (ret < 0 && ret != -EINVAL)
> + return ret;
> + else if (ret > 0)
> + info->mbus_config |= V4L2_MBUS_PCLK_SAMPLE_RISING;
> + else
> + info->mbus_config |= V4L2_MBUS_PCLK_SAMPLE_FALLING;
> +
> + ret = ov7670_parse_dt_prop(>dev,
> + "ov7670,pclk-hb-disable");
> + if (ret < 0 && ret != -EINVAL)
> + return ret;
> + else if (ret > 0)
> + info->pclk_hb_disable = true;
> + else
> + info->pclk_hb_disable = false;
> +
> + ret = ov7670_parse_dt_prop(>dev, "ov7670,pll-bypass");
> + if (ret < 0 && ret != -EINVAL)
> + return ret;
> + else if (ret > 0)
> + info->pll_bypass = true;
> + else
> + info->pll_bypass = false;
> +
> + } else if (client->dev.platform_data) {
>   struct ov7670_config *config = client->dev.platform_data;
> 
>   /*
> @@ -1649,9 +1746,6 @@ static int ov7670_probe(struct i2c_client *client,
>   tpf.denominator = 30;
>   info->devtype->set_framerate(sd, );
> 
> - if (info->pclk_hb_disable)
> - ov7670_write(sd, REG_COM10, COM10_PCLK_HB);
> -
>   v4l2_ctrl_handler_init(>hdl, 10);
>   v4l2_ctrl_new_std(>hdl, _ctrl_ops,
>   V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
> --
> 2.7.4
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies

[Sakari Ailus]

On Fri, Nov 17, 2017 at 10:14:51AM +0100, jacopo mondi wrote:
> Hi Sakari!
> 
> On Fri, Nov 17, 2017 at 02:43:15AM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Wed, Nov 15, 2017 at 11:56:01AM +0100, Jacopo Mondi wrote:
> > >
> 
> [snip]
> 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -25,8 +26,8 @@
> > >  #include 
> > >
> > >  #include 
> > > -#include 
> > > -#include 
> > > +
> > > +#include 
> >
> > Alphabetical order would be nice.
> 
> ups!
> 
> >
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -393,7 +394,7 @@ struct ov772x_win_size {
> > >  struct ov772x_priv {
> > >   struct v4l2_subdevsubdev;
> > >   struct v4l2_ctrl_handler  hdl;
> > > - struct v4l2_clk  *clk;
> > > + struct clk   *clk;
> > >   struct ov772x_camera_info*info;
> > >   const struct ov772x_color_format *cfmt;
> > >   const struct ov772x_win_size *win;
> > > @@ -550,7 +551,7 @@ static int ov772x_reset(struct i2c_client *client)
> > >  }
> > >
> > >  /*
> > > - * soc_camera_ops function
> > > + * subdev ops
> > >   */
> > >
> > >  static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
> > > @@ -650,13 +651,36 @@ static int ov772x_s_register(struct v4l2_subdev *sd,
> > >  }
> > >  #endif
> > >
> > > +static int ov772x_power_on(struct ov772x_priv *priv)
> > > +{
> > > + int ret;
> > > +
> > > + if (priv->info->platform_enable) {
> > > + ret = priv->info->platform_enable();
> > > + if (ret)
> > > + return ret;
> >
> > What does this do, enable the regulator?
> 
> Well, it depends on what function the platform code stores in
> 'platform_enable' pointer, doesn't it?
> 
> As you can see in [05/10] of this series, for Migo-R it's not about
> a regulator, but switching between the two available video inputs
> (OV7725 and TW9910) toggling their 'enable' pins.

Ok. That's not a very nice design.

Fair enough. I guess it's good to proceed one thing at a time.

If someone has this sensor on a board with DT support, we can use the
regulator framework and just ignore the platform callbacks.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[Sakari Ailus]

On Fri, Nov 17, 2017 at 10:33:55AM +0100, jacopo mondi wrote:
> Hi Sakari!
> 
> On Fri, Nov 17, 2017 at 02:36:51AM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Wed, Nov 15, 2017 at 03:25:11PM +0100, jacopo mondi wrote:
> > > Hi Sakari,
> > >thanks for review!
> >
> > You're welcome!
> >
> > > On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> > > > Hi Jacopo,
> > > >
> > > > Could you remove the original driver and send the patch using git
> > > > send-email -C ? That way a single patch would address converting it to a
> > > > proper V4L2 driver as well as move it to the correct location. The 
> > > > changes
> > > > would be easier to review that way since then, well, it'd be easier to 
> > > > see
> > > > the changes. :-)
> > >
> > > Actually I prefer not to remove the existing driver at the moment. See
> > > the cover letter for reasons why not to do so right now...
> >
> > So it's about testing mostly? Does someone (possibly you) have those boards
> > to test? I'd like to see this patchset to remove that last remaining SoC
> > camera bridge driver. :-)
> 
> Well, we agreed that for most of those platforms, compile testing it
> would be enough (let's believe in "if it compiles, it works"). I
> personally don't have access to those boards, and frankly I'm not even
> sure there are many of them around these days (I guess most of them
> are not even produced anymore).
> 
> >
> > >
> > > Also, there's not that much code from the old driver in here, surely
> > > less than the default 50% -C and -M options of 'git format-patch' use
> > > as a threshold for detecting copies iirc..
> >
> > Oh, if that's so, then makes sense to review it as a new driver.
> 
> thanks :)
> 
> >
> > >
> > > > The same goes for the two V4L2 SoC camera sensor / video decoder 
> > > > drivers at
> > > > the end of the set.
> > > >
> > >
> > > Also in this case I prefer not to remove existing code, as long as
> > > there are platforms using it..
> >
> > Couldn't they use this driver instead?
> 
> Oh, they will eventually, I hope :)
> 
> I would like to make sure we're all on the same page with this. My
> preference would be:
> 
> 1) Have renesas-ceu.c driver merged with Migo-R ported to use this new
> driver as an 'example'.
> 2) Do not remove any of the existing soc_camera code at this point
> 3) Port all other 4 SH users of sh_mobile_ceu_camera to use the now
> merged renesas-ceu driver
> 4) Remove sh_mobile_ceu_camera and soc_camera sensor drivers whose
> only users were those 4 SH boards
> 5) Remove soc_camera completely. For my understanding there are some
> PXA platforms still using soc_camera provided utilities somewhere.
> Hans knows better, but we can discuss this once we'll get there.

The first point here is basically done by this patchset and your intent
would be to proceed with the rest, right?

The above seems good; what I wanted to say was that I'd like to avoid
ending up in a permanent situation where some hardware works with the new
driver and some will continue to use the old one.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies

[Sakari Ailus]

struct v4l2_mbus_config *cfg)
>  {
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> -
>   cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
>   V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
>   V4L2_MBUS_DATA_ACTIVE_HIGH;
>   cfg->type = V4L2_MBUS_PARALLEL;
> - cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
> 
>   return 0;
>  }
> @@ -1038,12 +1058,11 @@ static int ov772x_probe(struct i2c_client *client,
>   const struct i2c_device_id *did)
>  {
>   struct ov772x_priv  *priv;
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> - struct i2c_adapter  *adapter = to_i2c_adapter(client->dev.parent);
> + struct i2c_adapter  *adapter = client->adapter;
>   int ret;
> 
> - if (!ssdd || !ssdd->drv_priv) {
> - dev_err(>dev, "OV772X: missing platform data!\n");
> + if (!client->dev.platform_data) {
> + dev_err(>dev, "Missing OV7725 platform data\n");
>   return -EINVAL;
>   }
> 
> @@ -1059,7 +1078,7 @@ static int ov772x_probe(struct i2c_client *client,
>   if (!priv)
>   return -ENOMEM;
> 
> - priv->info = ssdd->drv_priv;
> + priv->info = client->dev.platform_data;
> 
>   v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
>   v4l2_ctrl_handler_init(>hdl, 3);
> @@ -1073,21 +1092,33 @@ static int ov772x_probe(struct i2c_client *client,
>   if (priv->hdl.error)
>   return priv->hdl.error;
> 
> - priv->clk = v4l2_clk_get(>dev, "mclk");
> - if (IS_ERR(priv->clk)) {
> + priv->clk = clk_get(>dev, "mclk");
> + if (PTR_ERR(priv->clk) == -ENOENT) {
> + priv->clk = NULL;
> + } else if (IS_ERR(priv->clk)) {
> + dev_err(>dev, "Unable to get mclk clock\n");
>   ret = PTR_ERR(priv->clk);
> - goto eclkget;
> + goto error_clk_enable;
>   }
> 
>   ret = ov772x_video_probe(priv);
> - if (ret < 0) {
> - v4l2_clk_put(priv->clk);
> -eclkget:
> - v4l2_ctrl_handler_free(>hdl);
> - } else {
> - priv->cfmt = _cfmts[0];
> - priv->win = _win_sizes[0];
> - }
> + if (ret < 0)
> + goto error_video_probe;
> +
> + priv->cfmt = _cfmts[0];
> + priv->win = _win_sizes[0];
> +
> + ret = v4l2_async_register_subdev(>subdev);
> + if (ret)
> + goto error_video_probe;
> +
> + return 0;
> +
> +error_video_probe:
> + if (priv->clk)
> + clk_put(priv->clk);
> +error_clk_enable:
> +     v4l2_ctrl_handler_free(>hdl);
> 
>   return ret;
>  }
> @@ -1096,7 +1127,8 @@ static int ov772x_remove(struct i2c_client *client)
>  {
>   struct ov772x_priv *priv = to_ov772x(i2c_get_clientdata(client));
> 
> - v4l2_clk_put(priv->clk);
> + if (priv->clk)
> + clk_put(priv->clk);
>   v4l2_device_unregister_subdev(>subdev);
>   v4l2_ctrl_handler_free(>hdl);
>   return 0;
> diff --git a/include/media/i2c/ov772x.h b/include/media/i2c/ov772x.h
> index 00dbb7c..5896dff 100644
> --- a/include/media/i2c/ov772x.h
> +++ b/include/media/i2c/ov772x.h
> @@ -54,6 +54,9 @@ struct ov772x_edge_ctrl {
>  struct ov772x_camera_info {
>   unsigned long   flags;
>   struct ov772x_edge_ctrl edgectrl;
> +
> + int (*platform_enable)(void);
> + void (*platform_disable)(void);
>  };
> 
>  #endif /* __OV772X_H__ */
> --
> 2.7.4
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[Sakari Ailus]

Hi Jacopo,

On Wed, Nov 15, 2017 at 03:25:11PM +0100, jacopo mondi wrote:
> Hi Sakari,
>thanks for review!

You're welcome!

> On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > Could you remove the original driver and send the patch using git
> > send-email -C ? That way a single patch would address converting it to a
> > proper V4L2 driver as well as move it to the correct location. The changes
> > would be easier to review that way since then, well, it'd be easier to see
> > the changes. :-)
> 
> Actually I prefer not to remove the existing driver at the moment. See
> the cover letter for reasons why not to do so right now...

So it's about testing mostly? Does someone (possibly you) have those boards
to test? I'd like to see this patchset to remove that last remaining SoC
camera bridge driver. :-)

> 
> Also, there's not that much code from the old driver in here, surely
> less than the default 50% -C and -M options of 'git format-patch' use
> as a threshold for detecting copies iirc..

Oh, if that's so, then makes sense to review it as a new driver.

> 
> I would prefer this to be reviewed as new driver, I know it's a bit
> more painful, but irq handler and a couple of other routines apart,
> there's not that much code shared between the two...
> 
> >
> > The same goes for the two V4L2 SoC camera sensor / video decoder drivers at
> > the end of the set.
> >
> 
> Also in this case I prefer not to remove existing code, as long as
> there are platforms using it..

Couldn't they use this driver instead?

> 
> > On Wed, Nov 15, 2017 at 11:55:56AM +0100, Jacopo Mondi wrote:
> > > Add driver for Renesas Capture Engine Unit (CEU).
> > >
> > > The CEU interface supports capturing 'data' (YUV422) and 'images'
> > > (NV[12|21|16|61]).
> > >
> > > This driver aims to replace the soc_camera based sh_mobile_ceu one.
> > >
> > > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> > > platform GR-Peach.
> > >
> > > Tested with ov7725 camera sensor on SH4 platform Migo-R.
> >
> > Nice!
> >
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > > ---
> > > +#include 
> >
> > Do you need this header? There would seem some that I wouldn't expect to be
> > needed below, such as linux/init.h.
> 
> It's probably a leftover, I'll remove it...
> 
> [snip]
> >
> > > +#if IS_ENABLED(CONFIG_OF)
> > > +static const struct of_device_id ceu_of_match[] = {
> > > + { .compatible = "renesas,renesas-ceu" },
> >
> > Even if you add support for new hardware, shouldn't you maintain support
> > for renesas,sh-mobile-ceu?
> >
> 
> As you noticed already, the old driver did not support OF, so there
> are no compatibility issues here

Yeah, I realised that only after reviewing this patch.

It'd be Super-cool if someone did the DT conversion. Perhaps Laurent? ;-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH/RFC 2/2] v4l: rcar-vin: Wait for device access to complete before unplugging

[Sakari Ailus]

On Thu, Nov 16, 2017 at 02:33:49AM +0200, Laurent Pinchart wrote:
> To avoid races between device access and unplug, call the
> video_device_unplug() function in the platform driver remove handler.
> This will unsure that all device access completes before the remove
> handler proceeds to free resources.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index bd7976efa1fb..c5210f1d09ed 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1273,6 +1273,7 @@ static int rcar_vin_remove(struct platform_device *pdev)
>  
>   pm_runtime_disable(>dev);
>  
> + video_device_unplug(>vdev);

Does this depend on another patch?

>  
>   if (!vin->info->use_mc) {
>   v4l2_async_notifier_unregister(>notifier);
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Sakari Ailus]

vdev);
>   return ret;
>  }
>  
> @@ -841,6 +894,10 @@ int __video_register_device(struct video_device *vdev, 
> int type, int nr,
>   if (WARN_ON(!vdev->v4l2_dev))
>   return -EINVAL;
>  
> + /* unplug support */
> + spin_lock_init(>unplug_lock);
> + init_waitqueue_head(>unplug_wait);
> +
>   /* v4l2_fh support */
>   spin_lock_init(>fh_lock);
>   INIT_LIST_HEAD(>fh_list);
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index e657614521e3..365a94f91dc9 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -178,6 +179,12 @@ struct v4l2_file_operations {
>   * @pipe:  media_pipeline
>   * @fops: pointer to  v4l2_file_operations for the video device
>   * @device_caps: device capabilities as used in v4l2_capabilities
> + * @unplugged: when set the device has been unplugged and no device access
> + *   section can be entered
> + * @access_refcount: number of device access section currently running for 
> the
> + *   device
> + * @unplug_lock: protects unplugged and access_refcount
> + * @unplug_wait: wait queue to wait for device access sections to complete
>   * @dev:  device for the video device
>   * @cdev: character device
>   * @v4l2_dev: pointer to  v4l2_device parent
> @@ -221,6 +228,12 @@ struct video_device
>  
>   u32 device_caps;
>  
> + /* unplug handling */
> + bool unplugged;
> + int access_refcount;

Could you use refcount_t instead, to avoid integer overflow issues?

> + spinlock_t unplug_lock;
> + wait_queue_head_t unplug_wait;
> +
>   /* sysfs */
>   struct device dev;
>   struct cdev *cdev;
> @@ -506,4 +519,38 @@ static inline int video_is_registered(struct 
> video_device *vdev)
>   return test_bit(V4L2_FL_REGISTERED, >flags);
>  }
>  
> +/**
> + * video_device_enter - enter a device access section
> + * @vdev: the video device
> + *
> + * This function marks and protects the beginning of a section that should 
> not
> + * be entered after the device has been unplugged. The section end is marked
> + * with a call to video_device_exit(). Calls to this function can be nested.
> + *
> + * Returns:
> + * 0 on success or a negative error code if the device has been unplugged.
> + */
> +int video_device_enter(struct video_device *vdev);
> +
> +/**
> + * video_device_exit - exit a device access section
> + * @vdev: the video device
> + *
> + * This function marks the end of a section entered with 
> video_device_enter().
> + * It wakes up all tasks waiting on video_device_unplug() for device access
> + * sections to be exited.
> + */
> +void video_device_exit(struct video_device *vdev);
> +
> +/**
> + * video_device_unplug - mark a device as unplugged
> + * @vdev: the video device
> + *
> + * Mark a device as unplugged, causing all subsequent calls to
> + * video_device_enter() to return an error. If a device access section is
> + * currently being executed the function waits until the section is exited as
> + * marked by a call to video_device_exit().
> + */
> +void video_device_unplug(struct video_device *vdev);
> +
>  #endif /* _V4L2_DEV_H */
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] v4l: sh_mobile_ceu: Return buffers on streamoff()

[Sakari Ailus]

Hi Jacopo,

Thanks for the patch. I think you could add this to v2 of your related set;
that way it'll be easy to get the dependencies right. I don't think this is
urgent either...

On Wed, Nov 15, 2017 at 06:59:12PM +0100, Jacopo Mondi wrote:
> videobuf2 core reports an error when not all buffers have been returned
> to the framework:
> 
> drivers/media/v4l2-core/videobuf2-core.c:1651
> WARN_ON(atomic_read(>owned_by_drv_count))
> 
> Fix this returning all buffers currently in capture queue.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> 
> ---
> 
> I know I'm working to get rid of this driver, but while I was trying to have
> it working again on mainline, I found this had to be fixed.
> 
> Thanks
>   j
> 
> ---
>  drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c 
> b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
> index 36762ec..9180a1d 100644
> --- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
> +++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
> @@ -451,13 +451,18 @@ static void sh_mobile_ceu_stop_streaming(struct 
> vb2_queue *q)
>   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
>   struct sh_mobile_ceu_dev *pcdev = ici->priv;
>   struct list_head *buf_head, *tmp;
> + struct vb2_v4l2_buffer *vbuf;
> 
>   spin_lock_irq(>lock);
> 
>   pcdev->active = NULL;
> 
> - list_for_each_safe(buf_head, tmp, >capture)
> + list_for_each_safe(buf_head, tmp, >capture) {
> + vbuf = _entry(buf_head, struct sh_mobile_ceu_buffer,
> +queue)->vb;
> + vb2_buffer_done(>vb2_buf, VB2_BUF_STATE_DONE);

This should be VB2_BUF_STATE_ERROR, as the hardware hasn't actually
processed them, right?

>   list_del_init(buf_head);
> + }
> 
>   spin_unlock_irq(>lock);
> 

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[Sakari Ailus]

Hi Jacopo,

Could you remove the original driver and send the patch using git
send-email -C ? That way a single patch would address converting it to a
proper V4L2 driver as well as move it to the correct location. The changes
would be easier to review that way since then, well, it'd be easier to see
the changes. :-)

The same goes for the two V4L2 SoC camera sensor / video decoder drivers at
the end of the set.

On Wed, Nov 15, 2017 at 11:55:56AM +0100, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.

Nice!

> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/Kconfig   |9 +
>  drivers/media/platform/Makefile  |2 +
>  drivers/media/platform/renesas-ceu.c | 1768 
> ++
>  3 files changed, 1779 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3c4f7fa..401caea 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
> To compile this driver as a module, choose M here: the module
> will be called stm32-dcmi.
> 
> +config VIDEO_RENESAS_CEU
> + tristate "Renesas Capture Engine Unit (CEU) driver"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_FWNODE
> + ---help---
> +   This is a v4l2 driver for the Renesas CEU Interface
> +
>  source "drivers/media/platform/soc_camera/Kconfig"
>  source "drivers/media/platform/exynos4-is/Kconfig"
>  source "drivers/media/platform/am437x/Kconfig"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 327f80a..0d1f02b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)+= coda/
> 
>  obj-$(CONFIG_VIDEO_SH_VEU)   += sh_veu.o
> 
> +obj-$(CONFIG_VIDEO_RENESAS_CEU)  += renesas-ceu.o
> +
>  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)  += m2m-deinterlace.o
> 
>  obj-$(CONFIG_VIDEO_MUX)  += video-mux.o
> diff --git a/drivers/media/platform/renesas-ceu.c 
> b/drivers/media/platform/renesas-ceu.c
> new file mode 100644
> index 000..aaba3cd
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -0,0 +1,1768 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
> + *
> + * Copyright (C) 2017 Jacopo Mondi 
> + *
> + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
> + * Copyright (C) 2008 Magnus Damm
> + *
> + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
> + * Copyright (C) 2006, Sascha Hauer, Pengutronix
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 

Do you need this header? There would seem some that I wouldn't expect to be
needed below, such as linux/init.h.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define DRIVER_NAME  "renesas-ceu"
> +
> +/* 
> 
> + * CEU registers offsets and masks
> + */
> +#define CEU_CAPSR0x00 /* Capture start register  */
> +#define CEU_CAPCR0x04 /* Capture control register*/
> +#define CEU_CAMCR0x08 /* Capture interface control register  */
> +#define CEU_CAMOR0x10 /* Capture interface offset register   */
> +#define CEU_CAPWR0x14 /* Capture interface width register*/
> +#define CEU_CAIFR0x18 /* Capture interface input format register */
> +#define CEU_CRCNTR   0x28 /* CEU register control register   */
> +#define CEU_CRCMPR   0x2c /* CEU register forcible control register  */
> +#define CEU_CFLCR0x30 /* Capture filter control register */
> +#define CEU_CFSZR0x34 /* Capture filter size 

Re: [PATCH v1 02/10] include: media: Add Renesas CEU driver interface

[Sakari Ailus]

Hi Jacopo,

On Wed, Nov 15, 2017 at 11:55:55AM +0100, Jacopo Mondi wrote:
> Add renesas-ceu header file.
> 
> Do not remove the existing sh_mobile_ceu.h one as long as the original
> driver does not go away.

Hmm. This isn't really not about not removing a file but adding a new one.
Do you really need it outside the driver's own directory?

> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  include/media/drv-intf/renesas-ceu.h | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 include/media/drv-intf/renesas-ceu.h
> 
> diff --git a/include/media/drv-intf/renesas-ceu.h 
> b/include/media/drv-intf/renesas-ceu.h
> new file mode 100644
> index 000..f2da78c
> --- /dev/null
> +++ b/include/media/drv-intf/renesas-ceu.h
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +#ifndef __ASM_RENESAS_CEU_H__
> +#define __ASM_RENESAS_CEU_H__
> +
> +#include 
> +
> +#define CEU_FLAG_PRIMARY_SENSBIT(0)
> +#define CEU_MAX_SENS 2
> +
> +struct ceu_async_subdev {
> + unsigned long flags;
> + unsigned char bus_width;
> + unsigned char bus_shift;
> + unsigned int i2c_adapter_id;
> + unsigned int i2c_address;
> +};
> +
> +struct ceu_info {
> + unsigned int num_subdevs;
> + struct ceu_async_subdev subdevs[CEU_MAX_SENS];
> +};
> +
> +#endif /* __ASM_RENESAS_CEU_H__ */
> --
> 2.7.4
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

[Sakari Ailus]

Hi Jacopo,

Thanks for the patchset. Please see my comments below.

On Wed, Nov 15, 2017 at 11:55:54AM +0100, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.
> +
> +Required properties:
> +- compatible
> + Must be "renesas,renesas-ceu".
> +- reg
> + Physical address base and size.
> +- interrupts
> + The interrupt line number.
> +- pinctrl-names, pinctrl-0
> + phandle of pin controller sub-node configuring pins for CEU operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".

Could you list which ones they are? For someone not familiar with the
parallel bus this might not be obvious; also not all hardware can make use
of every one of these properties.

> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a
> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,renesas-ceu";
> + interrupts = ;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <_out>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + clocks = <>;
> + clock-names = "xclk";
> +
> + xclk: fixed_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2400>;
> + };

What's the purpose of the fixed_clk node here?

> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <_in>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> + };

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v10 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hi Laurent,

On Sat, Nov 11, 2017 at 08:17:59AM +0200, Laurent Pinchart wrote:
> > > +static int rcar_csi2_s_power(struct v4l2_subdev *sd, int on)
> > > +{
> > > + struct rcar_csi2 *priv = sd_to_csi2(sd);
> > > +
> > > + if (on)
> > > + pm_runtime_get_sync(priv->dev);
> > > + else
> > > + pm_runtime_put(priv->dev);
> > 
> > The pipeline you have is already rather complex. Would it be an option to
> > power the hardware on when streaming is started? The smiapp driver does
> > this, without even implementing the s_power callback. (You'd still need to
> > call it on the image source, as long as we have drivers that need it.)
> 
> We've briefly discussed this before, and I agree that pipeline power 
> management needs to be redesigned, but we still haven't agreed on a proper 
> architecture for that. Feel free to propose an RFC :-) In the meantime I 

Well, perhaps we should look at the use cases and see if there are gaps.
Runtime PM is essentially used everywhere else in the kernel.

> wouldn't try to enforce one specific model.

What I just wanted to point out that by switching to runtime PM you avoid
adding a new driver which is dependent on the s_power callback which I
don't think we'll want to keep in the long run. In this case there's no
benefit from s_power in any quantifiable way that I can see.

Actually the master driver manages calling the s_power callback so there's
hardly a need to do so here. It's just that the master drivers still need
that as long as there are sub-device drivers that depend on it.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v10 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hejssan, Niklas!

On Sat, Nov 11, 2017 at 01:11:13AM +0100, Niklas Söderlund wrote:
> Hej Sakari,
> 
> On 2017-11-11 00:32:27 +0200, Sakari Ailus wrote:
> > Hej Niklas,
> > 
> > Tack för uppdaterade lappar! Jag har några kommentar nedan... det ser bra
> > ut överallt.
> 
> Tack för din feedback!

Var så god!

...

> > > +static int rcar_csi2_calc_phypll(struct rcar_csi2 *priv,
> > > +  struct v4l2_subdev *source,
> > > +  struct v4l2_mbus_framefmt *mf,
> > > +  u32 *phypll)
> > > +{
> > > + const struct phypll_hsfreqrange *hsfreq;
> > > + const struct rcar_csi2_format *format;
> > > + struct v4l2_ctrl *ctrl;
> > > + u64 mbps;
> > > +
> > > + ctrl = v4l2_ctrl_find(source->ctrl_handler, V4L2_CID_PIXEL_RATE);
> > 
> > How about LINK_FREQ instead? It'd be more straightforward to calculate
> > this. Up to you.
> 
> I need to use PIXEL_RATE as my test setup uses the adv748x driver which 
> only implement that control. In the short term I would like to support 
> both, but I need a setup to test that before I can add support for it.  
> In the long term, maybe we should deprecate one of the controls?

Hmm. At least we musn't give the responsibility to calculate the pixel rate
to the end user: this depends on the bus and that is not visible to the
user space.

The link frequency is usually chosen from a few alternatives (or there's
just a single choice). And the pixel rate depends on the pixel code chosen
--- so you'd have a menu with menu entries changing based on format. That'd
be odd.

Perhaps just leave it as-is, as suggested by Laurent?

...

> > > +
> > > + dev_dbg(priv->dev, "Using source %s pad: %u\n", source->name,
> > > + source_pad->index);
> > > +
> > > + fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > > + fmt.pad = source_pad->index;
> > > + ret = v4l2_subdev_call(source, pad, get_fmt, NULL, );
> > > + if (ret)
> > > + return ret;
> > 
> > The link format has been validated already by this point this isn't
> > supposed to fail or produce different results than in link validation.
> > 
> > You could get the same format from the local pad, too.
> 
> Another good catch, I will use the format stored locally to make the 
> code simpler. As you state the formats are already validated so it's 
> safe to do so. I still need to get the remote subdevice to be able to 
> read the PIXEL_RATE control, but I can move that to 
> rcar_csi2_calc_phypll() where it's actually used.

Sounds good to me.
 
...

> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int rcar_csi2_set_pad_format(struct v4l2_subdev *sd,
> > > + struct v4l2_subdev_pad_config *cfg,
> > > + struct v4l2_subdev_format *format)
> > > +{
> > > + struct rcar_csi2 *priv = sd_to_csi2(sd);
> > > + struct v4l2_mbus_framefmt *framefmt;
> > > +
> > 
> > Is everything possible? For instance, are there limits regarding width or
> > height? Or the pixel code? They should be checked here.
> 
> Yes it do care about pixel code which was only validated at s_stream() 
> time, will move the check here thanks!
> 
> > 
> > Also the format on the source pad is, presumably, dependent on the format
> > on the sink pad.
> 
> Yes, but since this driver can't change the format in any way is there 
> any harm in mirror whatever is set on one pad on the other(s)? This will 
> change once multiple stream support is added in a later series.

If the hardware does not have functionality that may affect the size or the
pixel code, then the format on the source pad shouldn't be settable.

Yes, this will change when support for multiple streams is added. You'll
get more pads, and the sink pad no longer will have a format. But... it's a
good question how to prepare for this --- is it possible without changing
the user space API? I'm sure we'll have other such cases, such as the
smiapp driver with sensor embedded data.

...

> > > +static int rcar_csi2_parse_dt(struct rcar_csi2 *priv)
> > > +{
> > > + struct device_node *ep;
> > > + struct v4l2_fwnode_endpoint v4l2_ep;
> > > + int ret;
> > > +
> > > + ep = of_graph_get_endpoint_by_regs(priv->dev->of_node, 0, 0);
> > > + if (!ep) {
> > > + dev_err(priv->dev, "Not connected to subdevice\n");
> > > + return -EINVAL;
> > > + }
> > > +
&

Re: [PATCH v10 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

t; + }
> +
> + priv->lanes = vep->bus.mipi_csi2.num_data_lanes;
> + if (priv->lanes != 1 && priv->lanes != 2 && priv->lanes != 4) {
> + dev_err(priv->dev, "Unsupported number of data-lanes: %d\n",
> + priv->lanes);
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(priv->lane_swap); i++) {
> + priv->lane_swap[i] = i < priv->lanes ?
> + vep->bus.mipi_csi2.data_lanes[i] : i;
> +
> + /* Check for valid lane number */
> + if (priv->lane_swap[i] < 1 || priv->lane_swap[i] > 4) {
> + dev_err(priv->dev, "data-lanes must be in 1-4 range\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int rcar_csi2_parse_dt(struct rcar_csi2 *priv)
> +{
> + struct device_node *ep;
> + struct v4l2_fwnode_endpoint v4l2_ep;
> + int ret;
> +
> + ep = of_graph_get_endpoint_by_regs(priv->dev->of_node, 0, 0);
> + if (!ep) {
> + dev_err(priv->dev, "Not connected to subdevice\n");
> + return -EINVAL;
> + }
> +
> + ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), _ep);
> + if (ret) {
> + dev_err(priv->dev, "Could not parse v4l2 endpoint\n");
> + of_node_put(ep);
> + return -EINVAL;
> + }
> +
> + ret = rcar_csi2_parse_v4l2(priv, _ep);
> + if (ret)
> + return ret;
> +
> + priv->remote.match.fwnode.fwnode =
> + fwnode_graph_get_remote_endpoint(of_fwnode_handle(ep));
> + priv->remote.match_type = V4L2_ASYNC_MATCH_FWNODE;
> +
> + of_node_put(ep);
> +
> + priv->notifier.subdevs = devm_kzalloc(priv->dev,
> +   sizeof(*priv->notifier.subdevs),
> +   GFP_KERNEL);
> + if (priv->notifier.subdevs == NULL)
> + return -ENOMEM;
> +
> + priv->notifier.num_subdevs = 1;
> + priv->notifier.subdevs[0] = >remote;
> + priv->notifier.ops = _csi2_notify_ops;
> +
> + dev_dbg(priv->dev, "Found '%pOF'\n",
> + to_of_node(priv->remote.match.fwnode.fwnode));
> +
> + return v4l2_async_subdev_notifier_register(>subdev,
> +>notifier);

Could you use v4l2_async_notifier_parse_fwnode_endpoints_by_port() or does
something bad happen if you do? The intent with that was to avoid functions
like the above in drivers.

> +}
> +
> +/* 
> -
> + * Platform Device Driver
> + */
> +
> +static const struct media_entity_operations rcar_csi2_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate,
> +};
> +
> +static int rcar_csi2_probe_resources(struct rcar_csi2 *priv,
> +  struct platform_device *pdev)
> +{
> + struct resource *res;
> + int irq;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(priv->base))
> + return PTR_ERR(priv->base);
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + return 0;
> +}
> +
> +static const struct rcar_csi2_info rcar_csi2_info_r8a7795 = {
> + .hsfreqrange = hsfreqrange_h3_v3h_m3n,
> + .clear_ulps = true,
> + .have_phtw = true,
> + .csi0clkfreqrange = 0x20,
> +};
> +
> +static const struct rcar_csi2_info rcar_csi2_info_r8a7795es1 = {
> + .hsfreqrange = hsfreqrange_m3w_h3es1,
> +};
> +
> +static const struct rcar_csi2_info rcar_csi2_info_r8a7796 = {
> + .hsfreqrange = hsfreqrange_m3w_h3es1,
> +};
> +
> +static const struct of_device_id rcar_csi2_of_table[] = {
> + {
> +     .compatible = "renesas,r8a7795-csi2",
> + .data = _csi2_info_r8a7795,
> + },
> + {
> + .compatible = "renesas,r8a7796-csi2",
> + .data = _csi2_info_r8a7796,
> + },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, rcar_csi2_of_table);
> +
> +static const struct soc_device_attribute r8a7795es1[] = {
> + {
> + .soc_id = "r8a7795", .revision = "ES1.*",
> + .data = _csi2_info_r8a7795es1,
> + },
> + { /* sentinel */}
> +};
> +
> +static int rcar_csi2_probe(struct platform_device *pdev)
> +{
> + const struct soc_device_attribute *attr;
> + struct rcar_csi2 *priv;
> + unsigned int i;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->info = of_device_get_match_data(>dev);
> +
> + /* r8a7795 ES1.x behaves different then ES2.0+ but no own compat */
> + attr = soc_device_match(r8a7795es1);
> + if (attr)
> + priv->info = attr->data;
> +
> + priv->dev = >dev;
> +
> + mutex_init(>lock);
> + priv->stream_count = 0;
> +
> + ret = rcar_csi2_probe_resources(priv, pdev);
> + if (ret) {
> + dev_err(priv->dev, "Failed to get resources\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + ret = rcar_csi2_parse_dt(priv);
> + if (ret)
> + return ret;
> +
> + priv->subdev.owner = THIS_MODULE;
> + priv->subdev.dev = >dev;
> + v4l2_subdev_init(>subdev, _csi2_subdev_ops);
> + v4l2_set_subdevdata(>subdev, >dev);
> + snprintf(priv->subdev.name, V4L2_SUBDEV_NAME_SIZE, "%s %s",
> +  KBUILD_MODNAME, dev_name(>dev));
> + priv->subdev.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
> +
> + priv->subdev.entity.function = MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;
> + priv->subdev.entity.ops = _csi2_entity_ops;
> +
> + priv->pads[RCAR_CSI2_SINK].flags = MEDIA_PAD_FL_SINK;
> + for (i = RCAR_CSI2_SOURCE_VC0; i < NR_OF_RCAR_CSI2_PAD; i++)
> + priv->pads[i].flags = MEDIA_PAD_FL_SOURCE;
> +
> + ret = media_entity_pads_init(>subdev.entity, NR_OF_RCAR_CSI2_PAD,
> +  priv->pads);
> + if (ret)
> + goto error;
> +
> + ret = v4l2_async_register_subdev(>subdev);
> + if (ret < 0)
> + goto error;
> +
> + pm_runtime_enable(>dev);
> +
> + dev_info(priv->dev, "%d lanes found\n", priv->lanes);
> +
> + return 0;
> +
> +error:
> + v4l2_async_notifier_cleanup(>notifier);
> +
> + return ret;
> +}
> +
> +static int rcar_csi2_remove(struct platform_device *pdev)
> +{
> + struct rcar_csi2 *priv = platform_get_drvdata(pdev);
> +
> + v4l2_async_notifier_cleanup(>notifier);
> + v4l2_async_unregister_subdev(>subdev);
> +
> + pm_runtime_disable(>dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver __refdata rcar_csi2_pdrv = {
> + .remove = rcar_csi2_remove,
> + .probe  = rcar_csi2_probe,
> + .driver = {
> + .name   = "rcar-csi2",
> + .of_match_table = of_match_ptr(rcar_csi2_of_table),
> + },
> +};
> +
> +module_platform_driver(rcar_csi2_pdrv);
> +
> +MODULE_AUTHOR("Niklas Söderlund <niklas.soderl...@ragnatech.se>");
> +MODULE_DESCRIPTION("Renesas R-Car MIPI CSI-2 receiver");
> +MODULE_LICENSE("GPL v2");

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v10 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Sakari Ailus]

 };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <1>;
> +
> + csi20vin0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <>;
> + };
> + csi20vin1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <>;
> + };
> + csi20vin2: endpoint@2 {
> + reg = <2>;
> + remote-endpoint = <>;
> + };
> + csi20vin3: endpoint@3 {
> + reg = <3>;
> + remote-endpoint = <>;
> + };
> + csi20vin4: endpoint@4 {
> + reg = <4>;
> + remote-endpoint = <>;
> + };
> + csi20vin5: endpoint@5 {
> + reg = <5>;
> + remote-endpoint = <>;
> + };
> + csi20vin6: endpoint@6 {
> + reg = <6>;
> + remote-endpoint = <>;
> + };
> + csi20vin7: endpoint@7 {
> + reg = <7>;
> + remote-endpoint = <>;
> + };
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index adbf69306e9ee3d2..fa81ee6e80274646 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8565,6 +8565,7 @@ L:  linux-me...@vger.kernel.org
>  L:   linux-renesas-soc@vger.kernel.org
>  T:   git git://linuxtv.org/media_tree.git
>  S:   Supported
> +F:   Documentation/devicetree/bindings/media/rcar-csi2.txt
>  F:   Documentation/devicetree/bindings/media/rcar_vin.txt
>  F:   drivers/media/platform/rcar-vin/
>  

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2 13/17] media: v4l2-async: simplify v4l2_async_subdev structure

[Sakari Ailus]

Hi Mauro,

(Removing the non-list recipients.)

On Fri, Sep 29, 2017 at 06:27:13AM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 28 Sep 2017 15:09:21 +0300
> Sakari Ailus <sakari.ai...@iki.fi> escreveu:
> 
> > Hi Mauro,
> > 
> > On Wed, Sep 27, 2017 at 06:46:56PM -0300, 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.  
> > 
> > The idea is that in the union, there's a struct which is specific to the
> > match_type field. I wouldn't call it senseless.
> 
> Why a struct for each specific match_type is **needed**? It it is not
> needed, then it is senseless per definition :-) 
> 
> In the specific case of fwnode, there's already a named struct
> for fwnode_handle. The only thing is that it is declared outside
> enum v4l2_async_match_type. So, I don't see any reason to do things
> like:
> 
>   struct {
>   struct fwnode_handle *fwnode;
>   } fwnode;
> 
> If you're in doubt about that, think on how would you document
> both fwnode structs. Both fwnode structs specify the match
> criteria if %V4L2_ASYNC_MATCH_FWNODE.
> 
> The same applies to this:
> 
>   struct {
>   const char *name;
>   } device_name;
> 
> Both device_name and name specifies the match criteria if
> %V4L2_ASYNC_MATCH_DEVNAME.
> 
> > 
> > In the two cases there's just a single field in the containing struct. You
> > could remove the struct in that case as you do in this patch, and just use
> > the field. But I think the result is less clean and so I wouldn't make this
> > change.
> 
> It is actually cleaner without the stucts.
> 
> Without the useless struct, if one wants to match a firmware node, it
> should be doing:
> 
>   pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
>   pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);

This code should be and will be moved out of drivers. See:

<URL:http://www.spinics.net/lists/linux-media/msg122688.html>

So there are going to be quite a bit fewer instances of it, and none should
remain in drivers. I frankly don't have a strong opinion on this; there are
arguments for and against. I just don't see a reason to change it.

It'd be nice to have Hans's and Laurent's opinion though.

> 
> And that' it. For anyone that reads the above code, even not knowing
> all details of "match", is clear that the match criteria is whatever
> of_fwnode_handle() returns.
> 
> Now, on this:
> 
>   pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
>   pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
> 
> It sounds that something is missing, as only one field of match.fwnode
> was specified. Anyone not familiar with that non-conventional usage of
> a struct with just one struct field inside would need to seek for the
> header file declaring the struct. That would consume a lot of time for
> code reviewers for no good reason.
> 
> The same apply for devname search:
> 
> In this case:
>   asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
>   asd->match.device_name.name = imxsd->devname;
> 
> I would be expecting something else to be filled at device_name's
> struct, for example to specify a case sensitive or case insensitive
> match criteria, to allow seeking for a device's substring, or to
> allow using other struct device fields to narrow the seek.
> 
> With this:
> 
>   asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
>   asd->match.device_name = imxsd->devname;
> 
> It is clear that the match criteria is fully specified.
> 
> > The confusion comes possibly from the fact that the struct is named the
> > same as the field in the struct. These used to be called of and node, but
> > with the fwnode property framework the references to the fwnode are, well,
> > typically similarly called "fwnode". There's no underlying firmware
> > interface with that name, fwnode property API is just an API.
> 
> The duplicated "fwnode" name only made it more evident that we don't
> need to enclose a single match criteria field inside a struct.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [RESEND PATCH v2 13/17] media: v4l2-async: simplify v4l2_async_subdev structure

[Sakari Ailus]

Hi Mauro,

On Wed, Sep 27, 2017 at 06:46:56PM -0300, 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.

The idea is that in the union, there's a struct which is specific to the
match_type field. I wouldn't call it senseless.

In the two cases there's just a single field in the containing struct. You
could remove the struct in that case as you do in this patch, and just use
the field. But I think the result is less clean and so I wouldn't make this
change.

The confusion comes possibly from the fact that the struct is named the
same as the field in the struct. These used to be called of and node, but
with the fwnode property framework the references to the fwnode are, well,
typically similarly called "fwnode". There's no underlying firmware
interface with that name, fwnode property API is just an API.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2] device property: preserve usecount for node passed to of_fwnode_graph_get_port_parent()

[Sakari Ailus]

Hi Rob,

On Tue, Aug 22, 2017 at 02:42:10PM -0500, Rob Herring wrote:
> On Tue, Aug 22, 2017 at 10:00 AM, Niklas Söderlund
> <niklas.soderl...@ragnatech.se> wrote:
> > Hi Rob,
> >
> > On 2017-08-22 09:49:35 -0500, Rob Herring wrote:
> >> On Mon, Aug 21, 2017 at 7:19 PM, Niklas Söderlund
> >> <niklas.soderlund+rene...@ragnatech.se> wrote:
> >> > Using CONFIG_OF_DYNAMIC=y uncovered an imbalance in the usecount of the
> >> > node being passed to of_fwnode_graph_get_port_parent(). Preserve the
> >> > usecount by using of_get_parent() instead of of_get_next_parent() which
> >> > don't decrement the usecount of the node passed to it.
> >> >
> >> > Fixes: 3b27d00e7b6d7c88 ("device property: Move fwnode graph ops to 
> >> > firmware specific locations")
> >> > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> >> > Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>
> >> > ---
> >> >  drivers/of/property.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> Isn't this already fixed with this fix:
> >>
> >> commit c0a480d1acf7dc184f9f3e7cf724483b0d28dc2e
> >> Author: Tony Lindgren <t...@atomide.com>
> >> Date:   Fri Jul 28 01:23:15 2017 -0700
> >>
> >> device property: Fix usecount for of_graph_get_port_parent()
> >
> > No, that commit fixes it for of_graph_get_port_parent() while this
> > commit fixes it for of_fwnode_graph_get_port_parent(). But in essence it
> > is the same issue but needs two separate fixes.
> 
> Ah, because one takes the port node and one takes the endpoint node.
> That won't confuse anyone.

Yes, I think we've had this for some time in naming of a few graph
functions and increasingly so lately. It began with
of_graph_get_remote_port_parent(), which likely was named so to avoid the
name getting really long. The function itself gets a remove of the endpoint
given as an argument, then the port related to the entpoint and finally the
parent node of the port node (which is not the "ports" node). That's a lot
of work for a single interface function.

What comes to of_fwnode_graph_get_port_parent() --- it's the OF callback
function for the fwnode graph API that, as the name suggests, gets the
parent of the port node, no more, no less. The function is used in the
fwnode graph API implementation and is not available in the API as such.
The fwnode graph API itself only implements functionality already available
in the OF graph API under the corresponding name.

> 
> Can we please align this mess. I've tried to make the graph parsing
> not a free for all, open coded mess. There's no reason to have the
> port node handle and then need the parent device. Either you started
> with the parent device to parse local ports and endpoints or you got
> the remote endpoint with .graph_get_remote_endpoint(). Most of the
> time you don't even need the endpoint node handles. You really just
> need to know what is the remote device connected to port X, endpoint Y
> of my local device.

Perhaps most of the time, yes. V4L2 devices store bus (e.g. MIPI CSI-2)
specific information in the endpoint nodes.

The current OF graph API is geared towards providing convenience functions
to the extent that a single function performs actions a driver would
typically need. More recently functions implementing a single operation has
been added; the primitives that just perform a single operation would
likely be easier to manage.

The convenience functions have been, well, convenient as getting and
putting nodes could have been somewhat ignored in drivers. If the OF graph
API usage can be moved out of the drivers we'll likely have way fewer users
and thus there's no real need for convenience functions. That has other
benefits, too, such as parsing the graph correctly: most V4L2 drivers have
issues in this area.

The OF graph API (or the fwnode equivalent) is used effectively in all V4L2
drivers that support OF (there are about 20 of them); we're moving these to
the V4L2 framework but it'll take some time. That should make it easier for
cleaning things up. Based on a quick look V4L2 and V4L2 drivers together
represent a large proportion of all users in the kernel.

What do you think?

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 2/4] v4l: async: abort if memory allocation fails when unregistering notifiers

[Sakari Ailus]

Hi Niklas,

On Mon, Jul 31, 2017 at 12:31:56AM +0200, Niklas Söderlund wrote:
> Instead of trying to cope with the failed memory allocation and still
> leaving the kernel in a semi-broken state (the subdevices will be
> released but never re-probed) simply abort. The kernel have already
> printed a warning about allocation failure but keep the error printout
> to ease pinpointing the problem if it happens.
> 
> By doing this we can increase the readability of this complex function
> which puts it in a better state to separate the v4l2 housekeeping tasks
> from the re-probing of devices. It also serves to prepare for adding
> subnotifers.

By the time the notifier has been removed from the notifier list, we're the
sole user of the notifier done list. There is thus no need to acquire the
list lock to serialise access to that list.

Is there something that prevents re-probing the devices directly off the
notifier's done list without gathering the device pointers first? As the
notifier has been removed from the notifier list already, there will be no
matches found.

> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 0acf288d7227ba97..67852f0f2d3000c9 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -215,6 +215,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   if (!dev) {
>   dev_err(notifier->v4l2_dev->dev,
>   "Failed to allocate device cache!\n");
> + return;
>   }
>  
>   mutex_lock(_lock);
> @@ -234,23 +235,13 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   /* If we handled USB devices, we'd have to lock the parent too 
> */
>   device_release_driver(d);
>  
> - /*
> -  * Store device at the device cache, in order to call
> -  * put_device() on the final step
> -  */
> - if (dev)
> - dev[i++] = d;
> - else
> - put_device(d);
> + dev[i++] = d;
>   }
>  
>   mutex_unlock(_lock);
>  
>   /*
>* Call device_attach() to reprobe devices
> -  *
> -  * NOTE: If dev allocation fails, i is 0, and the whole loop won't be
> -  * executed.
>*/
>   while (i--) {
>   struct device *d = dev[i];
> -- 
> 2.13.3
> 

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 4/4] v4l: async: add comment about re-probing to v4l2_async_notifier_unregister()

[Sakari Ailus]

Hi Hans,

On Thu, Aug 24, 2017 at 09:59:41AM +0200, Hans Verkuil wrote:
> On 08/23/17 21:03, Niklas Söderlund wrote:
> > Hi,
> > 
> > On 2017-08-18 15:42:37 +0200, Niklas Söderlund wrote:
> >> Hi Sakari and Laurent,
> >>
> >> Thanks for your feedback.
> >>
> >> On 2017-08-18 14:20:08 +0300, Laurent Pinchart wrote:
> >>> Hello,
> >>>
> >>> On Tuesday 15 Aug 2017 19:09:33 Sakari Ailus wrote:
> >>>> On Mon, Jul 31, 2017 at 12:31:58AM +0200, Niklas Söderlund wrote:
> >>>>> The re-probing of subdevices when unregistering a notifier is tricky to
> >>>>> understand, and implemented somewhat as a hack. Add a comment trying to
> >>>>> explain why the re-probing is needed in the first place and why existing
> >>>>> helper functions can't be used in this situation.
> >>>>>
> >>>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> >>>>> ---
> >>>>>
> >>>>>  drivers/media/v4l2-core/v4l2-async.c | 17 +
> >>>>>  1 file changed, 17 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> >>>>> b/drivers/media/v4l2-core/v4l2-async.c index
> >>>>> d91ff0a33fd3eaff..a3c5a1f6d4d2ab03 100644
> >>>>> --- a/drivers/media/v4l2-core/v4l2-async.c
> >>>>> +++ b/drivers/media/v4l2-core/v4l2-async.c
> >>>>> @@ -234,6 +234,23 @@ void v4l2_async_notifier_unregister(struct
> >>>>> v4l2_async_notifier *notifier)> 
> >>>>> mutex_unlock(_lock);
> >>>>>
> >>>>> +   /*
> >>>>> +* Try to re-probe the subdevices which where part of the 
> >>>>> notifier.
> >>>>> +* This is done so subdevices which where part of the notifier 
> >>>>> will
> >>>>> +* be re-probed to a pristine state and put back on the global
> >>>>> +* list of subdevices so they can once more be found and 
> >>>>> associated
> >>>>> +* with a new notifier.
> >>>>
> >>>> Instead of tweaking the code trying to handle unhandleable error 
> >>>> conditions
> >>>> in notifier unregistration and adding lengthy stories on why this is done
> >>>> the way it is, could we simply get rid of the driver re-probing?
> >>>>
> >>>> I can't see why drivers shouldn't simply cope with the current interfaces
> >>>> without re-probing to which I've never seen any reasoned cause. When a
> >>>> sub-device driver is unbound, simply return the sub-device node to the 
> >>>> list
> >>>> of async sub-devices.
> >>>
> >>> I agree, this is a hack that we should get rid of. Reprobing has been 
> >>> there 
> >>> from the very beginning, it's now 4 years and a half old, let's allow it 
> >>> to 
> >>> retire :-)
> >>
> >> I would also be happy to see this code go away :-)
> >>
> >>>
> >>>> Or can someone come up with a valid reason why the re-probing code should
> >>>> stay? :-)
> >>
> >> Hans kindly dug out the original reason talking about why this code was 
> >> added in the first place at
> >>
> >> http://lkml.iu.edu/hypermail/linux/kernel/1210.2/00713.html
> >>
> >> I would also like record here what Laurent stated about this after 
> >> reading the above on #v4l 
> >>
> >> 13:53  pinchartl : what could happen is this
> >> 13:53  pinchartl : the master could export resources used by the subdev
> >> 13:53  pinchartl : the omap3 isp driver, for instance, is a clock source
> >> 13:54  pinchartl : and the clock can be used by sensors
> >> 13:54  pinchartl : so if you remove the omap3 isp, the clock won't be 
> >>there anymore
> >> 13:54  pinchartl : and that's bad for the subdev

Re-probing never helped anything with omap3isp driver as the clock is
removed *after* unregistering async notifier. This means that the
re-probing sub-device driver will get the same clock which is about to be
removed and continues with that happily, only to find the clock gone in a
brief moment.

This could be fixed in the omap3isp driver but it is telling that _no-one
ever complained_.

> >>
> >>
> &g

Re: [PATCH] device property: preserve usecount for node passed to of_fwnode_graph_get_port_parent()

[Sakari Ailus]

Hejssan Niklas,

Niklas Söderlund wrote:

Hi Sakari,

On 2017-08-21 22:03:02 +0300, Sakari Ailus wrote:

Hi Niklas,

Niklas Söderlund wrote:

Hi Sakari,

On 2017-08-21 16:30:17 +0300, Sakari Ailus wrote:

Hi Niklas,

Niklas Söderlund wrote:

Using CONFIG_OF_DYNAMIC=y uncovered an imbalance in the usecount of the
node being passed to of_fwnode_graph_get_port_parent(). Preserve the
usecount just like it is done in of_graph_get_port_parent().


The of_fwnode_graph_get_port_parent() is called by
fwnode_graph_get_port_parent() which obtains the port node through
fwnode_get_parent(). If you take a reference here, calling
fwnode_graph_get_port_parent() will end up incrementing the port node's use
count. In other words, my understanding is that dropping the reference to
the port node isn't a problem but intended behaviour here.


I'm not sure but I don't think the usecount will be incremented, without
this patch I think it's decremented by one instead. Lets look at the
code starting with fwnode_graph_get_port_parent().

struct fwnode_handle *
fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
{
struct fwnode_handle *port, *parent;

Increment usecount by 1

port = fwnode_get_parent(endpoint);
parent = fwnode_call_ptr_op(port, graph_get_port_parent);

Decrement usecount by 1

fwnode_handle_put(port); << Usecount -1


Here it is; this is the one I missed.

I spotted something else, too. Look at of_graph_get_port_parent(); it
appears to decrement the use count of the node passed to it, too:

struct device_node *of_graph_get_port_parent(struct device_node *node)
{
unsigned int depth;

/* Walk 3 levels up only if there is 'ports' node. */
for (depth = 3; depth && node; depth--) {
node = of_get_next_parent(node);
if (depth == 2 && of_node_cmp(node->name, "ports"))
break;
}
return node;
}
EXPORT_SYMBOL(of_graph_get_port_parent);

I think you'd need to of_node_get(node) first. I think it'd be good to
address this at the same time.


Your tree is old :-)

I did check of_graph_get_port_parent() when looking for how this was
handled elsewhere in the kernel. But I did not realise that the fix was
accepted after 4.13-rc1 so I did not mention that this was just a copy
of that fix in the patch description. For reference see

  c0a480d1acf7dc18 ("device property: Fix usecount for 
of_graph_get_port_parent()")


Ack, good. I didn't check new developments there, I have to admit.





One could claim the original design principle has truly been adopted in the
fwnode variant of the function. X-)


Yes and I adopted the same fix for the original :-)



On your original patch --- could you replace of_get_next_parent() by
of_get_parent()? In that case it won't drop the reference to the parent,
i.e. does what's required.


I do however think this is a much nicer solution. So I would still be
inclined to send a v2 whit this change instead. Which solution would you
prefer?


of_get_parent() is my preference; you can add to v2:

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

of_get_next_parent() is intended for cases where you expressly want to 
drop the reference AFAIK.


Thanks!







return parent;
}

Here it looks like the counting is correct and balanced. But without
this patch it's in this function 'fwnode_handle_put(port)' which
triggers the error which this patch aims to fix. Lets look at
of_fwnode_graph_get_port_parent() which in my case is what is called by
the fwnode_call_ptr_op().

static struct fwnode_handle *
of_fwnode_graph_get_port_parent(struct fwnode_handle *fwnode)
{
struct device_node *np;

Here in of_get_next_parent() the usecount is decremented by 1 and the
parents usecount is incremented by 1. So for our node node which passed
in from fwnode_graph_get_port_parent() (where it's named 'port') will be
decremented by 1.

/* Get the parent of the port */
np = of_get_next_parent(to_of_node(fwnode));
if (!np)
return NULL;

/* Is this the "ports" node? If not, it's the port parent. */
if (of_node_cmp(np->name, "ports"))
return of_fwnode_handle(np);

return of_fwnode_handle(of_get_next_parent(np));
}

So unless I miss something I do think this patch is needed to restore
balance to the usecount of the node being passed to
of_fwnode_graph_get_port_parent(). Or maybe I have misunderstood
something?



I wonder if I miss something.


I also wonder what I missed :-)





Fixes: 3b27d00e7b6d7c88 ("device property: Move fwnode graph ops to firmware 
specific locations")
Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
 drivers/of/property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 067f9fab7b77c794..637dcb4

Re: [PATCH] device property: preserve usecount for node passed to of_fwnode_graph_get_port_parent()

[Sakari Ailus]

Hi Niklas,

Niklas Söderlund wrote:

Hi Sakari,

On 2017-08-21 16:30:17 +0300, Sakari Ailus wrote:

Hi Niklas,

Niklas Söderlund wrote:

Using CONFIG_OF_DYNAMIC=y uncovered an imbalance in the usecount of the
node being passed to of_fwnode_graph_get_port_parent(). Preserve the
usecount just like it is done in of_graph_get_port_parent().


The of_fwnode_graph_get_port_parent() is called by
fwnode_graph_get_port_parent() which obtains the port node through
fwnode_get_parent(). If you take a reference here, calling
fwnode_graph_get_port_parent() will end up incrementing the port node's use
count. In other words, my understanding is that dropping the reference to
the port node isn't a problem but intended behaviour here.


I'm not sure but I don't think the usecount will be incremented, without
this patch I think it's decremented by one instead. Lets look at the
code starting with fwnode_graph_get_port_parent().

struct fwnode_handle *
fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
{
struct fwnode_handle *port, *parent;

Increment usecount by 1

port = fwnode_get_parent(endpoint);
parent = fwnode_call_ptr_op(port, graph_get_port_parent);

Decrement usecount by 1

fwnode_handle_put(port); << Usecount -1


Here it is; this is the one I missed.

I spotted something else, too. Look at of_graph_get_port_parent(); it 
appears to decrement the use count of the node passed to it, too:


struct device_node *of_graph_get_port_parent(struct device_node *node)
{
unsigned int depth;

/* Walk 3 levels up only if there is 'ports' node. */
for (depth = 3; depth && node; depth--) {
node = of_get_next_parent(node);
if (depth == 2 && of_node_cmp(node->name, "ports"))
break;
}
return node;
}
EXPORT_SYMBOL(of_graph_get_port_parent);

I think you'd need to of_node_get(node) first. I think it'd be good to 
address this at the same time.


One could claim the original design principle has truly been adopted in 
the fwnode variant of the function. X-)


On your original patch --- could you replace of_get_next_parent() by 
of_get_parent()? In that case it won't drop the reference to the parent, 
i.e. does what's required.




return parent;
}

Here it looks like the counting is correct and balanced. But without
this patch it's in this function 'fwnode_handle_put(port)' which
triggers the error which this patch aims to fix. Lets look at
of_fwnode_graph_get_port_parent() which in my case is what is called by
the fwnode_call_ptr_op().

static struct fwnode_handle *
of_fwnode_graph_get_port_parent(struct fwnode_handle *fwnode)
{
struct device_node *np;

Here in of_get_next_parent() the usecount is decremented by 1 and the
parents usecount is incremented by 1. So for our node node which passed
in from fwnode_graph_get_port_parent() (where it's named 'port') will be
decremented by 1.

/* Get the parent of the port */
np = of_get_next_parent(to_of_node(fwnode));
if (!np)
return NULL;

/* Is this the "ports" node? If not, it's the port parent. */
if (of_node_cmp(np->name, "ports"))
return of_fwnode_handle(np);

return of_fwnode_handle(of_get_next_parent(np));
}

So unless I miss something I do think this patch is needed to restore
balance to the usecount of the node being passed to
of_fwnode_graph_get_port_parent(). Or maybe I have misunderstood
something?



I wonder if I miss something.


I also wonder what I missed :-)





Fixes: 3b27d00e7b6d7c88 ("device property: Move fwnode graph ops to firmware 
specific locations")
Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
 drivers/of/property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 067f9fab7b77c794..637dcb4833e2af60 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -922,6 +922,12 @@ of_fwnode_graph_get_port_parent(struct fwnode_handle 
*fwnode)
 {
struct device_node *np;

+   /*
+* Preserve usecount for passed in node as of_get_next_parent()
+* will do of_node_put() on it.
+*/
+   of_node_get(to_of_node(fwnode));
+
/* Get the parent of the port */
    np = of_get_next_parent(to_of_node(fwnode));
    if (!np)




--
Sakari Ailus
sakari.ai...@linux.intel.com





--
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH] device property: preserve usecount for node passed to of_fwnode_graph_get_port_parent()

[Sakari Ailus]

Hi Niklas,

Niklas Söderlund wrote:

Using CONFIG_OF_DYNAMIC=y uncovered an imbalance in the usecount of the
node being passed to of_fwnode_graph_get_port_parent(). Preserve the
usecount just like it is done in of_graph_get_port_parent().


The of_fwnode_graph_get_port_parent() is called by 
fwnode_graph_get_port_parent() which obtains the port node through 
fwnode_get_parent(). If you take a reference here, calling 
fwnode_graph_get_port_parent() will end up incrementing the port node's 
use count. In other words, my understanding is that dropping the 
reference to the port node isn't a problem but intended behaviour here.


I wonder if I miss something.



Fixes: 3b27d00e7b6d7c88 ("device property: Move fwnode graph ops to firmware 
specific locations")
Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
 drivers/of/property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 067f9fab7b77c794..637dcb4833e2af60 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -922,6 +922,12 @@ of_fwnode_graph_get_port_parent(struct fwnode_handle 
*fwnode)
 {
struct device_node *np;

+   /*
+* Preserve usecount for passed in node as of_get_next_parent()
+* will do of_node_put() on it.
+*/
+   of_node_get(to_of_node(fwnode));
+
/* Get the parent of the port */
np = of_get_next_parent(to_of_node(fwnode));
if (!np)




--
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 1/4] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

[Sakari Ailus]

On Fri, Aug 18, 2017 at 03:42:07PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> On 2017-08-18 14:15:26 +0300, Laurent Pinchart wrote:
> > Hi Sakari,
> > 
> > On Tuesday 15 Aug 2017 19:16:14 Sakari Ailus wrote:
> > > On Mon, Jul 31, 2017 at 12:31:55AM +0200, Niklas Söderlund wrote:
> > > > The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it
> > > > to notifier->unbind() have no effect and leaves the notifier confused.
> > > > Call the unbind() callback prior to cleaning up the subdevice to avoid
> > > > this.
> > > > 
> > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > 
> > > This is a bugfix and worthy without any other patches and so should be
> > > applied separately.
> > > 
> > > I think it'd be safer to store sd->asd locally and call the notifier 
> > > unbind
> > > with that. Now you're making changes to the order in which things work, 
> > > and
> > > that's not necessary to achieve the objective of passing the async subdev
> > > pointer to the notifier.
> > 
> > But on the other hand I think the unbind notification should be called 
> > before 
> > the subdevice gets unbound, the same way the bound notification is called 
> > after it gets bound. One of the purposes of the unbind notification is to 
> > allow drivers to prepare for subdev about to be unbound, and they can't 
> > prepare if the unbind happened already.
> 
> I'm not opposed to move in the direction suggested by Sakari but I agree 
> with Laurent here. It makes more sens that the unbind callback is called 
> before the actual unbind happens. At the same time I agree that it dose 
> change the behavior, but I think it's for the better.

I agree with Laurent's reasoning. Feel free to add my ack.

> 
> > 
> > > With that changed,
> > > 
> > > Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>
> > > 
> > > > ---
> > > > 
> > > >  drivers/media/v4l2-core/v4l2-async.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > > > b/drivers/media/v4l2-core/v4l2-async.c index
> > > > 851f128eba2219ad..0acf288d7227ba97 100644
> > > > --- a/drivers/media/v4l2-core/v4l2-async.c
> > > > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > > > @@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct
> > > > v4l2_async_notifier *notifier)> 
> > > > d = get_device(sd->dev);
> > > > 
> > > > +   if (notifier->unbind)
> > > > +   notifier->unbind(notifier, sd, sd->asd);
> > > > +
> > > > 
> > > > v4l2_async_cleanup(sd);
> > > > 
> > > >     /* If we handled USB devices, we'd have to lock the 
> > > > parent too 
> > */
> > > > device_release_driver(d);
> > > > 
> > > > -   if (notifier->unbind)
> > > > -   notifier->unbind(notifier, sd, sd->asd);
> > > > -
> > > > 
> > > > /*
> > > > 
> > > >  * Store device at the device cache, in order to call
> > > >  * put_device() on the final step
> > 
> > -- 
> > Regards,
> > 
> > Laurent Pinchart
> > 
> 
> -- 
> Regards,
> Niklas Söderlund

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 1/4] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

[Sakari Ailus]

On Mon, Jul 31, 2017 at 12:31:55AM +0200, Niklas Söderlund wrote:
> The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it
> to notifier->unbind() have no effect and leaves the notifier confused.
> Call the unbind() callback prior to cleaning up the subdevice to avoid
> this.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

This is a bugfix and worthy without any other patches and so should be
applied separately.

I think it'd be safer to store sd->asd locally and call the notifier unbind
with that. Now you're making changes to the order in which things work, and
that's not necessary to achieve the objective of passing the async subdev
pointer to the notifier.

With that changed,

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

> ---
>  drivers/media/v4l2-core/v4l2-async.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 851f128eba2219ad..0acf288d7227ba97 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>  
>   d = get_device(sd->dev);
>  
> + if (notifier->unbind)
> + notifier->unbind(notifier, sd, sd->asd);
> +
>   v4l2_async_cleanup(sd);
>  
>   /* If we handled USB devices, we'd have to lock the parent too 
> */
>   device_release_driver(d);
>  
> - if (notifier->unbind)
> - notifier->unbind(notifier, sd, sd->asd);
> -
>   /*
>    * Store device at the device cache, in order to call
>* put_device() on the final step
> -- 
> 2.13.3
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 4/4] v4l: async: add comment about re-probing to v4l2_async_notifier_unregister()

[Sakari Ailus]

Hi Niklas,

Thanks for the patchset.

On Mon, Jul 31, 2017 at 12:31:58AM +0200, Niklas Söderlund wrote:
> The re-probing of subdevices when unregistering a notifier is tricky to
> understand, and implemented somewhat as a hack. Add a comment trying to
> explain why the re-probing is needed in the first place and why existing
> helper functions can't be used in this situation.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index d91ff0a33fd3eaff..a3c5a1f6d4d2ab03 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -234,6 +234,23 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>  
>   mutex_unlock(_lock);
>  
> + /*
> +  * Try to re-probe the subdevices which where part of the notifier.
> +  * This is done so subdevices which where part of the notifier will
> +  * be re-probed to a pristine state and put back on the global
> +  * list of subdevices so they can once more be found and associated
> +  * with a new notifier.

Instead of tweaking the code trying to handle unhandleable error conditions
in notifier unregistration and adding lengthy stories on why this is done
the way it is, could we simply get rid of the driver re-probing?

I can't see why drivers shouldn't simply cope with the current interfaces
without re-probing to which I've never seen any reasoned cause. When a
sub-device driver is unbound, simply return the sub-device node to the list
of async sub-devices.

Or can someone come up with a valid reason why the re-probing code should
stay? :-)

> +  *
> +  * One might be tempted to use device_reprobe() to handle the re-
> +  * probing. Unfortunately this is not possible since some video
> +  * device drivers call v4l2_async_notifier_unregister() from
> +  * there remove function leading to a dead lock situation on
> +  * device_lock(dev->parent). This lock is held when video device
> +  * drivers remove function is called and device_reprobe() also
> +  * tries to take the same lock, so using it here could lead to a
> +  * dead lock situation.
> +  */
> +
>   for (i = 0; i < count; i++) {
>   /* If we handled USB devices, we'd have to lock the parent too 
> */
>   device_release_driver(dev[i]);

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v7 2/3] media: i2c: adv748x: add adv748x driver

[Sakari Ailus]

Hi Kieran,

A few more minor matters that you might want to address on top of Hans's
pull request.

On Thu, Jul 06, 2017 at 12:01:16PM +0100, Kieran Bingham wrote:
...
> +static int adv748x_afe_g_input_status(struct v4l2_subdev *sd, u32 *status)
> +{
> + struct adv748x_afe *afe = adv748x_sd_to_afe(sd);
> + struct adv748x_state *state = adv748x_afe_to_state(afe);
> + int ret;
> +
> + mutex_lock(>mutex);
> +
> + ret = adv748x_afe_status(afe, status, NULL);
> +
> + mutex_unlock(>mutex);

A newline here would be nice.

> + return ret;
> +}

...

> +int adv748x_csi2_set_pixelrate(struct v4l2_subdev *sd, s64 rate)
> +{
> + struct v4l2_ctrl *ctrl;
> +
> + ctrl = v4l2_ctrl_find(sd->ctrl_handler, V4L2_CID_PIXEL_RATE);

It'd be much nicer to store the control pointer to your device's own struct
and use it. No need to look it up or check whether it was found.

> + if (!ctrl)
> + return -EINVAL;
> +
> + return v4l2_ctrl_s_ctrl_int64(ctrl, rate);
> +}

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v7 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

am wrong,
> > > then what did I miss?
> > 
> > I think that is what we want?
> > 
> >  From the VIN point of view all the subdevices it registered in it's
> > notifier have been found and bound right so I think it's correct to call
> > the complete callback for that notifier at this point?  If it really
> > cared about that all devices be present before it calls it complete
> > callback should it not also add all devices to its own notifier list?
> > 
> > But I do see your point that the VIN really have no way of telling if
> > all devices are present and we are ready to start to stream. This
> > however will be found out with a -EPIPE error if a stream is tried to be
> > started since the CSI-2 driver will fail to verify the pipeline since it
> > have no subdevice attached to its source pad. What do you think?
> 
> I think this is a bad idea. From the point of view of the application you
> expect that once the device nodes appear they will also *work*. In this
> case it might not work because one piece is still missing. So applications
> would have to know that if they get -EPIPE, then if they wait for a few
> seconds it might suddenly work because the last component was finally
> loaded. That's IMHO not acceptable and will drive application developers
> crazy.

Typically modules are loaded at system bootup, so there's not much chance
of this happening. The user can also detect this from the fact that there
are sub-devices that have pads without links. The MUST_CONNECT pad flag
should be set on such pads in any case: this is actually how the user could
detect the situation.

But then to why I replied to your e-mail, which is that there are other
problems as well. Such as the complete callback itself.

Imagine a system with a single ISP and multiple cameras. Or don't even
imagine one, just take an example from what we'll already have: even
omap3isp supports multiple cameras. The Intel CIO2 device will support
multiple cameras, too.

Each of the cameras can be used independently, but right now a fault in
probing any of the sensors (or other components in the system for that
matter, such as soon supposedly lens, flash or EEPROM devices) will render
all the cameras unusable. It'd be still quite importtant to be able to use
cameras that actually work, even if one of them does not. This is simply a
question of reliability.

The current implementation is that the initialisation of all the related
devices is required to be completed until any device nodes are registered.
This as itself is a part of the problem problem.

How that can be solved is by registering the device nodes of sub-devices
when the sub-devices are registered rather than at the time when all of
them are registered. This will have the effect of making partial device
states visible to the user space during driver probing.

I'd like to claim that it is not knowable whether a device the probing of
which has failed is going to come up in a fraction of a second or is not
going to come up during system uptime. -EPROBE_DEFER probably means that
the device will be around but there's no guarantee about it either, whereas
another error could be possibly fixed e.g. by the user.

Besides, the device nodes are even currently not created at the same
moment; they are rather created within a small window of time during which
the user will have access to the device nodes already created --- which do
not (yet) represent the complete device.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v7 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hejssan Niklas,

On Thu, Jun 15, 2017 at 10:48:20AM +0200, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Thanks for your comments.
> 
> On 2017-05-29 14:35:16 +0300, Sakari Ailus wrote:
> > Hi Niklas,
> > 
> > A few comments below.
> > 
> > On Wed, May 24, 2017 at 02:13:53AM +0200, Niklas Söderlund wrote:
> > > From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > 
> > > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> > > supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> > > hardware blocks are connected between the video sources and the video
> > > grabbers (VIN).
> > > 
> > > Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> > > 
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > ---
> > >  drivers/media/platform/rcar-vin/Kconfig |  12 +
> > >  drivers/media/platform/rcar-vin/Makefile|   1 +
> > >  drivers/media/platform/rcar-vin/rcar-csi2.c | 867 
> > > 
> > >  3 files changed, 880 insertions(+)
> > >  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> > > 
> > > diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> > > b/drivers/media/platform/rcar-vin/Kconfig
> > > index af4c98b44d2e22cb..6875f30c1ae42631 100644
> > > --- a/drivers/media/platform/rcar-vin/Kconfig
> > > +++ b/drivers/media/platform/rcar-vin/Kconfig
> > > @@ -1,3 +1,15 @@
> > > +config VIDEO_RCAR_CSI2
> > > + tristate "R-Car MIPI CSI-2 Receiver"
> > > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> > > + depends on ARCH_RENESAS || COMPILE_TEST
> > > + select V4L2_FWNODE
> > > + ---help---
> > > +   Support for Renesas R-Car MIPI CSI-2 receiver.
> > > +   Supports R-Car Gen3 SoCs.
> > > +
> > > +   To compile this driver as a module, choose M here: the
> > > +   module will be called rcar-csi2.
> > > +
> > >  config VIDEO_RCAR_VIN
> > >   tristate "R-Car Video Input (VIN) Driver"
> > >   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> > > MEDIA_CONTROLLER
> > > diff --git a/drivers/media/platform/rcar-vin/Makefile 
> > > b/drivers/media/platform/rcar-vin/Makefile
> > > index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> > > --- a/drivers/media/platform/rcar-vin/Makefile
> > > +++ b/drivers/media/platform/rcar-vin/Makefile
> > > @@ -1,3 +1,4 @@
> > >  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
> > >  
> > > +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
> > >  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> > > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > > new file mode 100644
> > > index ..1175f1fe4b139a13
> > > --- /dev/null
> > > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > > @@ -0,0 +1,867 @@
> > > +/*
> > > + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> > > + *
> > > + * Copyright (C) 2017 Renesas Electronics Corp.
> > > + *
> > > + * This program is free software; you can redistribute  it and/or modify 
> > > it
> > > + * under  the terms of  the GNU General  Public License as published by 
> > > the
> > > + * Free Software Foundation;  either version 2 of the  License, or (at 
> > > your
> > > + * option) any later version.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +/* Register offsets and bits */
> > > +
> > > +/* Control Timing Select */
> > > +#define TREF_REG 0x00
> > > +#define TREF_TREF(1 << 0)
> > > +
> > > +/* Software Reset */
> > > +#define SRST_REG 0x04
> > > +#define SRST_SRST(1 << 0)
> > > +
> > > +/* PHY Operation Control */
> > > +#define PHYCNT_REG   0x08
> > > +#define PHYCNT_SHU

Re: [PATCH v7 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Sakari Ailus]

Hi Niklas,

On Tue, Jun 13, 2017 at 06:50:14PM +0200, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Thanks for your feedback.
> 
> On 2017-05-29 14:16:25 +0300, Sakari Ailus wrote:
> > Hi Niklas,
> > 
> > On Wed, May 24, 2017 at 02:13:52AM +0200, Niklas Söderlund wrote:
> > > From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > 
> > > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> > > are located between the video sources (CSI-2 transmitters) and the video
> > > grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> > > 
> > > Each CSI-2 device is connected to more then one VIN device which
> > > simultaneously can receive video from the same CSI-2 device. Each VIN
> > > device can also be connected to more then one CSI-2 device. The routing
> > > of which link are used are controlled by the VIN devices. There are only
> > > a few possible routes which are set by hardware limitations, which are
> > > different for each SoC in the Gen3 family.
> > > 
> > > To work with the limitations of routing possibilities it is necessary
> > > for the DT bindings to describe which VIN device is connected to which
> > > CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> > > VIN device that be connected to it. To setup and to know which links are
> > > valid for each SoC is the responsibility of the VIN driver since the
> > > register to configure it belongs to the VIN hardware.
> > > 
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > ---
> > >  .../devicetree/bindings/media/rcar-csi2.txt| 116 
> > > +
> > >  1 file changed, 116 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt 
> > > b/Documentation/devicetree/bindings/media/rcar-csi2.txt
> > > new file mode 100644
> > > index ..f6e2027ee92b171a
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt
> > > @@ -0,0 +1,116 @@
> > > +Renesas R-Car MIPI CSI-2
> > > +
> > > +
> > > +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas 
> > > R-Car
> > > +family of devices. It is to be used in conjunction with the R-Car VIN 
> > > module,
> > > +which provides the video capture capabilities.
> > > +
> > > + - compatible: Must be one or more of the following
> > > +   - "renesas,r8a7795-csi2" for the R8A7795 device.
> > > +   - "renesas,r8a7796-csi2" for the R8A7796 device.
> > > +   - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device.
> > > +
> > > +   When compatible with a generic version nodes must list the
> > > +   SoC-specific version corresponding to the platform first
> > > +   followed by the generic version.
> > > +
> > > + - reg: the register base and size for the device registers
> > > + - interrupts: the interrupt for the device
> > > + - clocks: Reference to the parent clock
> > > +
> > > +The device node should contain two 'port' child nodes according to the
> > > +bindings defined in Documentation/devicetree/bindings/media/
> > > +video-interfaces.txt. Port 0 should connect the node that is the video
> > > +source for to the CSI-2. Port 1 should connect all the R-Car VIN
> > > +modules, which can make use of the CSI-2 module.
> > 
> > Should or shall?
> > 
> > I guess you could add that it is possible to leave them unconnected, too.
> 
> Which ports/endpoints are you talking about? In my mind it's not allowed 
> to leave them unconnected.
> 
> If there ever is a system with only 4 VIN instances (I'm not aware of 
> any such system) then yes the endpoints for those VIN not present in the 
> system in port 1 should be left unconnected but other then that they 
> should all be mandatory right? Or am I missing something?

I think so, yes. Then "shall" is right, isn't it?

> 
> > 
> > > +
> > > +- Port 0 - Video source
> > > + - Reg 0 - sub-node describing the endpoint that is the video source
> > 
> > Which endpoint properties are mandatory for the receiver? Which ones are
> > optional? (I.e. it shouldn't be necessary to read driver code to write board
> > description.)
> 
> I will add a note that all endpoints in port 0 are mandatory and that 
> all endpoints that represents a connection to a VIN instance in the 
> system is mandatory for next version. Thanks I did not think about this 
> possibility.

Please list the mandatory and optional properties, too. Not just the
endpoints.

-- 
Hälsningar,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 2/2] media: entity: Add media_entity_get_fwnode_pad() function

[Sakari Ailus]

Hi Niklas,

Thanks for the update!

On Tue, Jun 13, 2017 at 04:31:26PM +0200, Niklas Söderlund wrote:
> This is a wrapper around the media entity get_fwnode_pad operation.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/media-entity.c | 35 +++
>  include/media/media-entity.h | 23 +++
>  2 files changed, 58 insertions(+)
> 
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index bc44193efa4798b4..35a15263793f71e1 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -18,6 +18,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -386,6 +387,40 @@ struct media_entity *media_graph_walk_next(struct 
> media_graph *graph)
>  }
>  EXPORT_SYMBOL_GPL(media_graph_walk_next);
>  
> +int media_entity_get_fwnode_pad(struct media_entity *entity,
> + struct fwnode_handle *fwnode,
> + unsigned int direction)

media entity pad flags has unsigned long type. I think you should call this
e.g. direction_flags or pad_direction_flags. It'd be clear that it's about
pad flags and only the direction matters.

> +{
> + struct fwnode_endpoint endpoint;
> + int i, ret;

media entity num_pads field is u16. I guess unsigned int is fine, but it
should be unsigned at least.

With these,

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

> +
> + if (!entity->ops || !entity->ops->get_fwnode_pad) {
> + for (i = 0; i < entity->num_pads; i++) {
> + if (entity->pads[i].flags & direction)
> + return i;
> + }
> +
> + return -ENXIO;
> + }
> +
> + ret = fwnode_graph_parse_endpoint(fwnode, );
> + if (ret)
> + return ret;
> +
> + ret = entity->ops->get_fwnode_pad();
> + if (ret < 0)
> + return ret;
> +
> + if (ret >= entity->num_pads)
> + return -ENXIO;
> +
> + if (!(entity->pads[ret].flags & direction))
> + return -ENXIO;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(media_entity_get_fwnode_pad);
> +
>  /* 
> -
>   * Pipeline management
>   */
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 46eeb036aa330534..4114e06964824ec9 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -821,6 +821,29 @@ struct media_pad *media_entity_remote_pad(struct 
> media_pad *pad);
>  struct media_entity *media_entity_get(struct media_entity *entity);
>  
>  /**
> + * media_entity_get_fwnode_pad - Get pad number from fwnode
> + *
> + * @entity: The entity
> + * @fwnode: Pointer to the fwnode_handle which should be used to find the pad
> + * @direction: Expected direction of the pad, as defined in
> + *  :ref:`include/uapi/linux/media.h `
> + *  (seek for ``MEDIA_PAD_FL_*``)
> + *
> + * This function can be used to resolve the media pad number from
> + * a fwnode. This is useful for devices which use more complex
> + * mappings of media pads.
> + *
> + * If the entity dose not implement the get_fwnode_pad() operation
> + * then this function searches the entity for the first pad that
> + * matches the @direction.
> + *
> + * Return: returns the pad number on success or a negative error code.
> + */
> +int media_entity_get_fwnode_pad(struct media_entity *entity,
> + struct fwnode_handle *fwnode,
> + unsigned int direction);
> +
> +/**
>   * media_graph_walk_init - Allocate resources used by graph walk.
>   *
>   * @graph: Media graph structure that will be used to walk the graph

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 1/2] media: entity: Add get_fwnode_pad entity operation

[Sakari Ailus]

On Tue, Jun 13, 2017 at 04:31:25PM +0200, Niklas Söderlund wrote:
> The optional operation can be used by entities to report how it maps its
> fwnode endpoints to media pad numbers. This is useful for devices which
> require advanced mappings of pads.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Thanks!

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v4] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

[Sakari Ailus]

Hi Mauro,

On Thu, Jun 08, 2017 at 03:00:22PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed,  7 Jun 2017 10:52:07 +0100
> Kieran Bingham <kbing...@kernel.org> escreveu:
> 
> > From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > 
> > Return NULL, if a null entity is parsed for it's v4l2_subdev
> > 
> > Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> Could you please improve this patch description?
> 
> I'm unsure if this is a bug fix, or some sort of feature...
> 
> On what situations would a null entity be passed to this function?

I actually proposed this patch. This change is simply for convenience ---
the caller doesn't need to make sure the subdev is non-NULL, possibly
obtained from e.g. media_entity_remote_pad() which returns NULL all links to
the pad are disabled. This is a recurring pattern, and making this change
avoids an additional check.

Having something along these lines in the patch description wouldn't hurt.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v4] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

[Sakari Ailus]

On Wed, Jun 07, 2017 at 10:52:07AM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> Return NULL, if a null entity is parsed for it's v4l2_subdev
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>

Reviewed-by: Sakari Ailus <sakari.ai...@linux.intel.com>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v7 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

 of_node_full_name(ep));
> + return -EINVAL;
> + }
> +
> + priv->lanes = v4l2_ep.bus.mipi_csi2.num_data_lanes;
> + if (priv->lanes != 1 && priv->lanes != 2 && priv->lanes != 4) {
> + dev_err(priv->dev, "Unsupported number of data-lanes: %d\n",
> + priv->lanes);
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(priv->lane_swap); i++) {
> + priv->lane_swap[i] = i < priv->lanes ?
> + v4l2_ep.bus.mipi_csi2.data_lanes[i] : i;
> +
> + /* Check for valid lane number */
> + if (priv->lane_swap[i] < 1 || priv->lane_swap[i] > 4) {

Do you also support for three lanes? Based on the code elsewhere, it doesn't
seem like that.

> + dev_err(priv->dev, "data-lanes must be in 1-4 range\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int rcar_csi2_probe_resources(struct rcar_csi2 *priv,
> +  struct platform_device *pdev)
> +{
> + struct resource *mem;
> + int irq;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem)
> + return -ENODEV;
> +
> + priv->base = devm_ioremap_resource(>dev, mem);
> + if (IS_ERR(priv->base))
> + return PTR_ERR(priv->base);
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + return 0;
> +}
> +
> +static int rcar_csi2_probe(struct platform_device *pdev)
> +{
> + struct rcar_csi2 *priv;
> + unsigned int i;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = >dev;
> +
> + mutex_init(>lock);
> + priv->stream_count = 0;
> +
> + ret = rcar_csi2_parse_dt_settings(priv);
> + if (ret)
> + return ret;
> +
> + ret = rcar_csi2_parse_dt_subdevice(priv);
> + if (ret)
> + return ret;
> +
> + ret = rcar_csi2_probe_resources(priv, pdev);
> + if (ret) {
> + dev_err(priv->dev, "Failed to get resources\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->subdev.owner = THIS_MODULE;
> + priv->subdev.dev = >dev;
> + v4l2_subdev_init(>subdev, _csi2_subdev_ops);
> + v4l2_set_subdevdata(>subdev, >dev);
> + snprintf(priv->subdev.name, V4L2_SUBDEV_NAME_SIZE, "%s %s",
> +  KBUILD_MODNAME, dev_name(>dev));
> + priv->subdev.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
> + priv->subdev.internal_ops = _csi2_internal_ops;
> +
> + priv->subdev.entity.function = MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;
> + priv->subdev.entity.ops = _csi2_entity_ops;
> +
> + priv->pads[RCAR_CSI2_SINK].flags = MEDIA_PAD_FL_SINK;
> + for (i = RCAR_CSI2_SOURCE_VC0; i < NR_OF_RCAR_CSI2_PAD; i++)
> + priv->pads[i].flags = MEDIA_PAD_FL_SOURCE;
> +
> + ret = media_entity_pads_init(>subdev.entity, NR_OF_RCAR_CSI2_PAD,
> +  priv->pads);
> + if (ret)
> + return ret;
> +
> + ret = v4l2_async_register_subdev(>subdev);
> + if (ret < 0)
> + return ret;
> +
> + pm_runtime_enable(>dev);
> +
> + dev_info(priv->dev, "%d lanes found\n", priv->lanes);
> +
> + return 0;
> +}
> +
> +static int rcar_csi2_remove(struct platform_device *pdev)
> +{
> + struct rcar_csi2 *priv = platform_get_drvdata(pdev);
> +
> + v4l2_async_unregister_subdev(>subdev);
> +
> + pm_runtime_disable(>dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver __refdata rcar_csi2_pdrv = {
> + .remove = rcar_csi2_remove,
> + .probe  = rcar_csi2_probe,
> + .driver = {
> + .name   = "rcar-csi2",
> + .of_match_table = of_match_ptr(rcar_csi2_of_table),
> + },
> +};
> +
> +module_platform_driver(rcar_csi2_pdrv);
> +
> +MODULE_AUTHOR("Niklas Söderlund <niklas.soderl...@ragnatech.se>");
> +MODULE_DESCRIPTION("Renesas R-Car MIPI CSI-2 receiver");
> +MODULE_LICENSE("GPL v2");

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v7 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Sakari Ailus]

reg = <1>;
> +
> +  csi20vin0: endpoint@0 {
> +  reg = <0>;
> +  remote-endpoint = <>;
> +  };
> +  csi20vin1: endpoint@1 {
> +  reg = <1>;
> +  remote-endpoint = <>;
> +  };
> +  csi20vin2: endpoint@2 {
> +  reg = <2>;
> +  remote-endpoint = <>;
> +  };
> +  csi20vin3: endpoint@3 {
> +  reg = <3>;
> +  remote-endpoint = <>;
> +  };
> +  csi20vin4: endpoint@4 {
> +  reg = <4>;
> +  remote-endpoint = <>;
> +  };
> +  csi20vin5: endpoint@5 {
> +  reg = <5>;
> +  remote-endpoint = <>;
> +  };
> +  csi20vin6: endpoint@6 {
> +  reg = <6>;
> +  remote-endpoint = <>;
> +  };
> +  csi20vin7: endpoint@7 {
> +  reg = <7>;
> +  remote-endpoint = <>;
> +  };
> +  };
> +  };
> +  };
> +
> +/* Board properties */
> +
> +  {
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + csi20_in: endpoint@0 {
> + clock-lanes = <0>;
> + data-lanes = <1>;
> + remote-endpoint = <_txb>;
> + };
> + };
> + };
> + };

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 2/2] v4l: async: add subnotifier registration for subdevices

[Sakari Ailus]

Hi Niklas,

On Wed, May 24, 2017 at 02:07:27AM +0200, Niklas Söderlund wrote:
...
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index c16200c88417b151..e1e181db90f789c0 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -141,11 +141,13 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
>   sd->dev = NULL;
>  }
>  
> -int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> -  struct v4l2_async_notifier *notifier)
> +static int v4l2_async_do_notifier_register(struct v4l2_device *v4l2_dev,
> +struct v4l2_async_notifier *notifier,
> +bool subnotifier)
>  {
>   struct v4l2_subdev *sd, *tmp;
>   struct v4l2_async_subdev *asd;
> + bool found;
>   int i;
>  
>   if (!v4l2_dev || !notifier->num_subdevs ||
> @@ -174,32 +176,65 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   list_add_tail(>list, >waiting);
>   }
>  
> - mutex_lock(_lock);
> + if (subnotifier)
> + lockdep_assert_held(_lock);
> + else
> + mutex_lock(_lock);
> +
> + /*
> +  * This function can be called recursively so the list
> +  * might be modified in a recursive call. Start from the
> +  * top of the list each iteration.
> +  */
> + found = true;
> + while (found) {

That looks a bit cumbersome. You can do:

do {
found = false;
...;
} while (found);

And remove the assignment above. Or even

for (found = true; found; found = false) {
...;
}

> + found = false;
>  
> - list_for_each_entry_safe(sd, tmp, _list, async_list) {
> - int ret;
> + list_for_each_entry_safe(sd, tmp, _list, async_list) {
> + int ret;
>  
> - asd = v4l2_async_belongs(notifier, sd);
> - if (!asd)
> - continue;
> + asd = v4l2_async_belongs(notifier, sd);
> + if (!asd)
> + continue;
>  
> - ret = v4l2_async_test_notify(notifier, sd, asd);
> - if (ret < 0) {
> - mutex_unlock(_lock);
> - return ret;
> + ret = v4l2_async_test_notify(notifier, sd, asd);
> + if (ret < 0) {
> + if (!subnotifier)
> + mutex_unlock(_lock);
> + return ret;
> + }
> +
> + found = true;

Alternatively you could use goto and a label to restart the matching. That
would be quite clean, you'd remove one variable which is just serving as a
condition to restart the loop:

again:
list_for_each_entry_safe() {
ret = test_notify();
if (ret < 0)
return ret;
goto again;
}

I think I like this better. This considered,

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

> + break;
>   }
>   }
>  
>   /* Keep also completed notifiers on the list */
>   list_add(>list, _list);
>  
> - mutex_unlock(_lock);
> + if (!subnotifier)
> + mutex_unlock(_lock);
>  
>   return 0;
>  }
> +
> +int v4l2_async_subnotifier_register(struct v4l2_subdev *sd,
> + struct v4l2_async_notifier *notifier)
> +{
> + return v4l2_async_do_notifier_register(sd->v4l2_dev, notifier, true);
> +}
> +EXPORT_SYMBOL(v4l2_async_subnotifier_register);
> +
> +int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> +  struct v4l2_async_notifier *notifier)
> +{
> + return v4l2_async_do_notifier_register(v4l2_dev, notifier, false);
> +}
>  EXPORT_SYMBOL(v4l2_async_notifier_register);
>  
> -void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> +static void
> +v4l2_async_do_notifier_unregister(struct v4l2_async_notifier *notifier,
> +   bool subnotifier)
>  {
>   struct v4l2_subdev *sd, *tmp;
>   unsigned int notif_n_subdev = notifier->num_subdevs;
> @@ -216,7 +251,10 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   "Failed to allocate device cache!\n");
>   }
>  
> - mutex_lock(_lock);
> + if (subnotifier)
> + lockdep_assert_held(_lock);
> + else
> +

Re: [PATCH v2 1/2] media: entity: Add pad_from_fwnode entity operation

[Sakari Ailus]

Hejssan,

On Wed, May 24, 2017 at 04:07:36PM +0200, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Thanks for your feedback.
> 
> On 2017-05-24 16:21:37 +0300, Sakari Ailus wrote:
> > Hi Niklas,
> > 
> > On Wed, May 24, 2017 at 02:09:06AM +0200, Niklas Söderlund wrote:
> > > From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > 
> > > The optional operation can be used by entities to report how it maps its
> > > fwnode endpoints to media pad numbers. This is useful for devices which
> > > require advanced mappings of pads.
> > > 
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > ---
> > >  include/media/media-entity.h | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > > index c7c254c5bca1761b..2aea22b0409d1070 100644
> > > --- a/include/media/media-entity.h
> > > +++ b/include/media/media-entity.h
> > > @@ -21,6 +21,7 @@
> > >  
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -171,6 +172,9 @@ struct media_pad {
> > >  
> > >  /**
> > >   * struct media_entity_operations - Media entity operations
> > > + * @pad_from_fwnode: Return the pad number based on a fwnode 
> > > endpoint.
> > > + *   This operation can be used to map a fwnode to a
> > > + *   media pad number. Optional.
> > >   * @link_setup:  Notify the entity of link changes. The 
> > > operation can
> > >   *   return an error, in which case link setup will 
> > > be
> > >   *   cancelled. Optional.
> > > @@ -184,6 +188,8 @@ struct media_pad {
> > >   *mutex held.
> > >   */
> > >  struct media_entity_operations {
> > > + int (*pad_from_fwnode)(struct fwnode_endpoint *endpoint,
> > > +unsigned int *pad);
> > 
> > Hmm. How about calling this get_fwnode_pad for instance? I wonder what
> > others think.
> 
> I'm OK with this name change, will update for next version.
> 
> > 
> > You could just return the pad number still, and a negative value on error. I
> > think we won't have more than INT_MAX pads. :-)
> 
> I did that at first but then I remembered all the review comments I have 
> gotten earlier about using int as the type for pads :-) If you and 
> others agree in this case returning the pad as int or a negative value 
> as error I have no problem chaining this for the next version.

unsigned int was proposed for there was no need for negative values. In this
case there is.

I don't really have a strong opinion either way. I wonder what Hans or
Laurent thinks.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v5 3/7] media: i2c: max2175: Add MAX2175 support

[Sakari Ailus]

On Fri, May 26, 2017 at 02:47:32PM +, Ramesh Shanmugasundaram wrote:
> Hi Sakari,
> 
> Thanks for the review comments on the patches. Sorry for the late response
> as I was caught up with another work.

No worries.

> 
> I will incorporate your comments and rebase it on top of your branch. I
> see it is not there in media-tree master yet. Please let me know if there
> is a change in plan.

I've sent a pull request to Mauro here and my expectation is it'll reach
media tree master in not too distant future:

<URL:http://www.spinics.net/lists/linux-media/msg115707.html>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 1/2] v4l: async: check for v4l2_dev in v4l2_async_notifier_register()

[Sakari Ailus]

On Wed, May 24, 2017 at 02:07:26AM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> 
> Add a check for v4l2_dev to v4l2_async_notifier_register() as to fail as
> early as possible since this will fail later in v4l2_async_test_notify().
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 2/2] media: entity: Add media_entity_pad_from_fwnode() function

[Sakari Ailus]

Hi Niklas,

On Wed, May 24, 2017 at 02:09:07AM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> 
> This is a wrapper around the media entity pad_from_fwnode operation.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/media-entity.c | 39 +++
>  include/media/media-entity.h | 22 ++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index bc44193efa4798b4..c124754f739a8b94 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -18,6 +18,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -386,6 +387,44 @@ struct media_entity *media_graph_walk_next(struct 
> media_graph *graph)
>  }
>  EXPORT_SYMBOL_GPL(media_graph_walk_next);
>  
> +int media_entity_pad_from_fwnode(struct media_entity *entity,
> +  struct fwnode_handle *fwnode,
> +  int direction, unsigned int *pad)
> +{
> + struct fwnode_endpoint endpoint;
> + int i, tmp, ret;
> +
> + if (!entity->ops || !entity->ops->pad_from_fwnode) {
> + for (i = 0; i < entity->num_pads; i++) {
> + if (entity->pads[i].flags & direction) {
> + *pad = i;
> + return 0;
> + }
> + }
> +
> + return -ENXIO;
> + }
> +
> + ret = fwnode_graph_parse_endpoint(fwnode, );
> + if (ret)
> + return ret;
> +
> + ret = entity->ops->pad_from_fwnode(, );
> + if (ret)
> + return ret;
> +
> + if (tmp >= entity->num_pads)
> + return -ENXIO;
> +
> + if (!(entity->pads[tmp].flags & direction))
> + return -ENXIO;
> +
> + *pad = tmp;
> +
> + return 0;

I'd just return the pad number to the caller.

> +}
> +EXPORT_SYMBOL_GPL(media_entity_pad_from_fwnode);
> +
>  /* 
> -
>   * Pipeline management
>   */
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 2aea22b0409d1070..7507181609bec43c 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -822,6 +822,28 @@ struct media_pad *media_entity_remote_pad(struct 
> media_pad *pad);
>  struct media_entity *media_entity_get(struct media_entity *entity);
>  
>  /**
> + * media_entity_pad_from_fwnode - Get pad number from fwnode
> + *
> + * @entity: The entity
> + * @fwnode: Pointer to fwnode_handle which should be used to find pad
> + * @direction: Expected direction of the pad

You should document the possible values for this. What would you think about
using a bool called e.g. is_sink? I don't have a strong opinion either way
though.

> + * @pad: Pointer to pad which will should be filled in
> + *
> + * This function can be used to resolve the media pad number from
> + * a fwnode. This is useful for devices which uses more complex
> + * mappings of media pads.
> + *
> + * If the entity do not implement the pad_from_fwnode() operation
> + * this function searches the entity for the first pad that matches
> + * the @direction.
> + *
> + * Return: return 0 on success.
> + */
> +int media_entity_pad_from_fwnode(struct media_entity *entity,
> +  struct fwnode_handle *fwnode,
> +  int direction, unsigned int *pad);
> +
> +/**
>   * media_graph_walk_init - Allocate resources used by graph walk.
>   *
>   * @graph: Media graph structure that will be used to walk the graph

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 1/2] media: entity: Add pad_from_fwnode entity operation

[Sakari Ailus]

Hi Niklas,

On Wed, May 24, 2017 at 02:09:06AM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> 
> The optional operation can be used by entities to report how it maps its
> fwnode endpoints to media pad numbers. This is useful for devices which
> require advanced mappings of pads.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  include/media/media-entity.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index c7c254c5bca1761b..2aea22b0409d1070 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -171,6 +172,9 @@ struct media_pad {
>  
>  /**
>   * struct media_entity_operations - Media entity operations
> + * @pad_from_fwnode: Return the pad number based on a fwnode endpoint.
> + *   This operation can be used to map a fwnode to a
> + *   media pad number. Optional.
>   * @link_setup:  Notify the entity of link changes. The 
> operation can
>   *   return an error, in which case link setup will be
>   *   cancelled. Optional.
> @@ -184,6 +188,8 @@ struct media_pad {
>   *mutex held.
>   */
>  struct media_entity_operations {
> + int (*pad_from_fwnode)(struct fwnode_endpoint *endpoint,
> +unsigned int *pad);

Hmm. How about calling this get_fwnode_pad for instance? I wonder what
others think.

You could just return the pad number still, and a negative value on error. I
think we won't have more than INT_MAX pads. :-)

>   int (*link_setup)(struct media_entity *entity,
>         const struct media_pad *local,
> const struct media_pad *remote, u32 flags);

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

On Tue, May 23, 2017 at 10:47:58PM +0100, Kieran Bingham wrote:
> On 23/05/17 22:43, Sakari Ailus wrote:
> > On Wed, May 24, 2017 at 12:40:19AM +0300, Sakari Ailus wrote:
> >>>  * When all devices use endpoint matching, this code can be simplified, 
> >>> and the
> >>>  * parent comparisons can be removed.
> > 
> > Oh, and this I'm not so sure about --- we'll need to match lens controllers
> > and flash drivers. There are no endpoints in those devices. Let's see how it
> > goes when we get there...
> > 
> 
> Sure, would you like me to post a v4 of just this patch?

Please.

> 
> The parent checks should always be safe, so this feels like less of a 
> workaround
> now, and if it provides support for other use cases perhaps it could survive
> longer term.

Indeed. If you end up getting the second parent of a device node, the end
result will be that you simply won't have a match.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

On Wed, May 24, 2017 at 12:40:19AM +0300, Sakari Ailus wrote:
> >  * When all devices use endpoint matching, this code can be simplified, and 
> > the
> >  * parent comparisons can be removed.

Oh, and this I'm not so sure about --- we'll need to match lens controllers
and flash drivers. There are no endpoints in those devices. Let's see how it
goes when we get there...

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

Hi Kieran,

On Tue, May 23, 2017 at 06:40:08PM +0100, Kieran Bingham wrote:
> On 23/05/17 14:02, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > On Mon, May 22, 2017 at 06:36:38PM +0100, Kieran Bingham wrote:
> >> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> >>
> >> Devices supporting multiple endpoints on a single device node must set
> >> their subdevice fwnode to the endpoint to allow distinct comparisons.
> >>
> >> Adapt the match_fwnode call to compare against the provided fwnodes
> >> first, but also to search for a comparison against the parent fwnode.
> >>
> >> This allows notifiers to pass the endpoint for comparison and still
> >> support existing subdevices which store their default parent device
> >> node.
> >>
> >> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> >>
> >> ---
> >> v2:
> >>  - Added documentation comments
> >>  - simplified the OF match by adding match_fwnode_of()
> >>
> >> v3:
> >>  - Fix comments
> >>  - Fix sd_parent, and asd_parent usage
> >>
> >>  drivers/media/v4l2-core/v4l2-async.c | 36 -
> >>  1 file changed, 31 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> >> b/drivers/media/v4l2-core/v4l2-async.c
> >> index cbd919d4edd2..12c0707851fd 100644
> >> --- a/drivers/media/v4l2-core/v4l2-async.c
> >> +++ b/drivers/media/v4l2-core/v4l2-async.c
> >> @@ -41,14 +41,40 @@ static bool match_devname(struct v4l2_subdev *sd,
> >>return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
> >>  }
> >>  
> >> +/*
> >> + * Check whether the two device_node pointers refer to the same OF node. 
> >> We
> >> + * can't compare pointers directly as they can differ if overlays have 
> >> been
> >> + * applied.
> >> + */
> >> +static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle 
> >> *b)
> >> +{
> >> +  return !of_node_cmp(of_node_full_name(to_of_node(a)),
> >> +  of_node_full_name(to_of_node(b)));
> >> +}
> >> +
> >> +/*
> >> + * As a measure to support drivers which have not been converted to use
> >> + * endpoint matching, we also find the parent devices for cross-matching.
> >> + *
> >> + * When all devices use endpoint matching, this code can be simplified, 
> >> and the
> >> + * parent comparisons can be removed.
> >> + */
> >>  static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> >> *asd)
> >>  {
> >> -  if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
> >> -  return sd->fwnode == asd->match.fwnode.fwnode;
> >> +  struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
> >> +  struct fwnode_handle *sd_parent, *asd_parent;
> >> +
> >> +  sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
> >> +  asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
> >> +
> >> +  if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
> >> +  return sd->fwnode == asd_fwnode ||
> >> + sd_parent == asd_fwnode ||
> >> + sd->fwnode == asd_parent;
> >>  
> >> -  return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
> >> -  of_node_full_name(
> >> -  to_of_node(asd->match.fwnode.fwnode)));
> >> +  return match_fwnode_of(sd->fwnode, asd_fwnode) ||
> >> + match_fwnode_of(sd_parent, asd_fwnode) ||
> >> + match_fwnode_of(sd->fwnode, asd_parent);
> >>  }
> >>  
> >>  static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> >> *asd)
> > 
> > Would this become easier to read if you handled all matching in what is
> > called match_fwnode_of() above, also for non-OF fwnodes? Essentially you'd
> > have what used to be match_fwnode() there, and new match_fwnode() would call
> > that function with all the three combinations.
> > 
> 
> 
> > I'd call the other function __match_fwnode() for instance.
> > 
> 
> 
> Yes - Took me a moment to understand what you meant here - but yes it's 
> leaner +
> cleaner:

Looks quite nice! Thanks! :)

> 
> 
> /*
>  * As a measure to support dr

Re: [PATCH v3 1/2] device property: Add fwnode_graph_get_port_parent

[Sakari Ailus]

Hi Kieran,

On Tue, May 23, 2017 at 06:15:42PM +0100, Kieran Bingham wrote:
> 
> 
> On 23/05/17 13:58, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > On Mon, May 22, 2017 at 06:36:37PM +0100, Kieran Bingham wrote:
> >> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> >>
> >> Provide a helper to obtain the parent device fwnode without first
> >> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
> >>
> >> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> >>
> >> ---
> >> v2:
> >>  - Rebase on top of Sakari's acpi-graph-clean branch and simplify
> >>
> >> v3:
> >>  - Fix up kerneldoc
> >>  - Get the 'port' of the endpoint to find the parent of the port
> >>
> >>  drivers/base/property.c  | 15 +++
> >>  include/linux/property.h |  2 ++
> >>  2 files changed, 17 insertions(+)
> >>
> >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> >> index b311a6fa7d0c..fdbc644fd743 100644
> >> --- a/drivers/base/property.c
> >> +++ b/drivers/base/property.c
> >> @@ -1169,6 +1169,21 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle 
> >> *fwnode,
> >>  EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
> >>  
> >>  /**
> >> + * fwnode_graph_get_port_parent - Return the device fwnode of a port 
> >> endpoint
> >> + * @endpoint: Endpoint firmware node of the port
> >> + *
> >> + * Return: the firmware node of the device the @endpoint belongs to.
> >> + */
> >> +struct fwnode_handle *
> >> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> >> +{
> >> +  struct fwnode_handle *port = fwnode_get_next_parent(endpoint);
> >> +
> >> +  return fwnode_call_ptr_op(port, graph_get_port_parent);
> > 
> > I missed one thing: the reference to port obtained in
> > fwnode_get_next_parent() needs to be released.
> > 
> > I can do the change while applying the patch on top of the set if you're ok
> > with that.
> 
> Yes, that would be great thanks.

Thanks! The patch actually came out in this form:

<URL:https://git.linuxtv.org/sailus/media_tree.git/commit/?h=acpi-graph-cleaned=6c9e58006e73de03441337f3ca6247afed28cf0a>

I'll post it to list once I've rebased the set again, I hope you're ok with
that. :-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

Hi Kieran,

On Mon, May 22, 2017 at 06:36:38PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> Devices supporting multiple endpoints on a single device node must set
> their subdevice fwnode to the endpoint to allow distinct comparisons.
> 
> Adapt the match_fwnode call to compare against the provided fwnodes
> first, but also to search for a comparison against the parent fwnode.
> 
> This allows notifiers to pass the endpoint for comparison and still
> support existing subdevices which store their default parent device
> node.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> ---
> v2:
>  - Added documentation comments
>  - simplified the OF match by adding match_fwnode_of()
> 
> v3:
>  - Fix comments
>  - Fix sd_parent, and asd_parent usage
> 
>  drivers/media/v4l2-core/v4l2-async.c | 36 -
>  1 file changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index cbd919d4edd2..12c0707851fd 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -41,14 +41,40 @@ static bool match_devname(struct v4l2_subdev *sd,
>   return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
>  }
>  
> +/*
> + * Check whether the two device_node pointers refer to the same OF node. We
> + * can't compare pointers directly as they can differ if overlays have been
> + * applied.
> + */
> +static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle *b)
> +{
> + return !of_node_cmp(of_node_full_name(to_of_node(a)),
> + of_node_full_name(to_of_node(b)));
> +}
> +
> +/*
> + * As a measure to support drivers which have not been converted to use
> + * endpoint matching, we also find the parent devices for cross-matching.
> + *
> + * When all devices use endpoint matching, this code can be simplified, and 
> the
> + * parent comparisons can be removed.
> + */
>  static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> *asd)
>  {
> - if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
> - return sd->fwnode == asd->match.fwnode.fwnode;
> + struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
> + struct fwnode_handle *sd_parent, *asd_parent;
> +
> + sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
> + asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
> +
> + if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
> + return sd->fwnode == asd_fwnode ||
> +sd_parent == asd_fwnode ||
> +sd->fwnode == asd_parent;
>  
> - return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
> - of_node_full_name(
> - to_of_node(asd->match.fwnode.fwnode)));
> + return match_fwnode_of(sd->fwnode, asd_fwnode) ||
> +match_fwnode_of(sd_parent, asd_fwnode) ||
> +match_fwnode_of(sd->fwnode, asd_parent);
>  }
>  
>  static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> *asd)

Would this become easier to read if you handled all matching in what is
called match_fwnode_of() above, also for non-OF fwnodes? Essentially you'd
have what used to be match_fwnode() there, and new match_fwnode() would call
that function with all the three combinations.

I'd call the other function __match_fwnode() for instance.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 1/2] device property: Add fwnode_graph_get_port_parent

[Sakari Ailus]

Hi Kieran,

On Mon, May 22, 2017 at 06:36:37PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> Provide a helper to obtain the parent device fwnode without first
> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> ---
> v2:
>  - Rebase on top of Sakari's acpi-graph-clean branch and simplify
> 
> v3:
>  - Fix up kerneldoc
>  - Get the 'port' of the endpoint to find the parent of the port
> 
>  drivers/base/property.c  | 15 +++
>  include/linux/property.h |  2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index b311a6fa7d0c..fdbc644fd743 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -1169,6 +1169,21 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle 
> *fwnode,
>  EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
>  
>  /**
> + * fwnode_graph_get_port_parent - Return the device fwnode of a port endpoint
> + * @endpoint: Endpoint firmware node of the port
> + *
> + * Return: the firmware node of the device the @endpoint belongs to.
> + */
> +struct fwnode_handle *
> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> +{
> + struct fwnode_handle *port = fwnode_get_next_parent(endpoint);
> +
> + return fwnode_call_ptr_op(port, graph_get_port_parent);

I missed one thing: the reference to port obtained in
fwnode_get_next_parent() needs to be released.

I can do the change while applying the patch on top of the set if you're ok
with that.

> +}
> +EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
> +
> +/**
>   * fwnode_graph_get_remote_port_parent - Return fwnode of a remote device
>   * @fwnode: Endpoint firmware node pointing to the remote endpoint
>   *
> diff --git a/include/linux/property.h b/include/linux/property.h
> index b9f4838d9882..af95d5d84192 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -275,6 +275,8 @@ void *device_get_mac_address(struct device *dev, char 
> *addr, int alen);
>  
>  struct fwnode_handle *fwnode_graph_get_next_endpoint(
>   struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> +struct fwnode_handle *fwnode_graph_get_port_parent(
> + struct fwnode_handle *fwnode);
>  struct fwnode_handle *fwnode_graph_get_remote_port_parent(
>   struct fwnode_handle *fwnode);
>  struct fwnode_handle *fwnode_graph_get_remote_port(

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent

[Sakari Ailus]

Hi Laurent and Kieran,

On Fri, May 19, 2017 at 05:42:07PM +0300, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Friday 19 May 2017 14:34:33 Kieran Bingham wrote:
> > On 18/05/17 14:36, Laurent Pinchart wrote:
> > > On Wednesday 17 May 2017 16:03:38 Kieran Bingham wrote:
> > >> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > >> 
> > >> V4L2 async notifiers can pass the endpoint fwnode rather than the device
> > >> fwnode.
> > > 
> > > I'm not sure I would mention V4L2 in the commit message, as this is
> > > generic.
> >
> > Good point
> > 
> > >> Provide a helper to obtain the parent device fwnode without first
> > >> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
> > >> 
> > >> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > >> ---
> > >> 
> > >>  drivers/base/property.c  | 25 +
> > >>  include/linux/property.h |  2 ++
> > >>  2 files changed, 27 insertions(+)
> > >> 
> > >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> > >> index 627ebc9b570d..caf4316fe565 100644
> > >> --- a/drivers/base/property.c
> > >> +++ b/drivers/base/property.c
> > >> @@ -1245,6 +1245,31 @@ fwnode_graph_get_next_endpoint(struct
> > >> fwnode_handle
> > >> *fwnode, EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
> > >> 
> > >>  /**
> > >> 
> > >> + * fwnode_graph_get_port_parent - Return device node of a port endpoint
> > >> + * @fwnode: Endpoint firmware node pointing of the port
> > >> + *
> > >> + * Extracts firmware node of the device the @fwnode belongs to.
> > > 
> > > I'm not too familiar with the fwnode API, but I know it's written in C,
> > > where functions don't extract something but return a value :-) How about
> > > 
> > > Return: the firmware node of the device the @endpoint belongs to.
> > 
> > I'm not averse to the reword - but it is different to the other functions in
> > the same context:
> > 
> > fwnode_graph_get_remote_endpoint(struct fwnode_handle *fwnode)
> >  * Extracts firmware node of a remote endpoint the @fwnode points to.
> > 
> > struct fwnode_handle *fwnode_graph_get_remote_port(struct fwnode_handle
> > *fwnode)
> >  * Extracts firmware node of a remote port the @fwnode points to.
> > 
> > fwnode_graph_get_remote_port_parent(struct fwnode_handle *fwnode)
> >  * Extracts firmware node of a remote device the @fwnode points to.
> > 
> > Then with this function becoming:
> > 
> > fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> >  * Returns firmware node of the device the @endpoint belongs to.
> > 
> > 
> > I guess those could be changed too ...
> 
> My point is that the kerneldoc format documents return values with a 
> "Return:" 
> tag. The documentation for the function can still provide extra information.

Yeah, let's do this right and then fix the rest. I've already submitted the
pull request on this one --- the origin of that text is actually the V4L2 OF
framework. Feel free to submit a patch that fixes it, I can do it as well.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 1/2] device property: Add fwnode_graph_get_port_parent

[Sakari Ailus]

Hi Kieran,

On Fri, May 19, 2017 at 05:16:02PM +0100, Kieran Bingham wrote:
> +struct fwnode_handle *
> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> +{
> + return fwnode_call_ptr_op(endpoint, graph_get_port_parent);

graph_get_port_parent op will actually get the parent of the port. But it
expects a port node, not an endpoint node. This is implemented so in order
to center the ops around primitives rather than end user APIs that may
change over time.

I think you'll need:

return fwnode_call_ptr_op(fwnode_graph_get_next_parent(endpoint),
  graph_get_port_parent);

Or something like that.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

[Sakari Ailus]

Hi Laurent,

On Fri, May 19, 2017 at 12:59:12AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Friday 19 May 2017 00:05:17 Sakari Ailus wrote:
> > On Thu, May 18, 2017 at 11:54:46PM +0300, Laurent Pinchart wrote:
> > > On Thursday 18 May 2017 23:50:34 Sakari Ailus wrote:
> > >> On Thu, May 18, 2017 at 07:08:00PM +0300, Laurent Pinchart wrote:
> > >>> On Wednesday 17 May 2017 22:20:57 Sakari Ailus wrote:
> > >>>> On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote:
> > >>>>> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > >>>>> 
> > >>>>> Return NULL, if a null entity is parsed for it's v4l2_subdev
> > >>>>> 
> > >>>>> Signed-off-by: Kieran Bingham
> > >>>>> <kieran.bingham+rene...@ideasonboard.com>
> > >>>>> ---
> > >>>>> 
> > >>>>>  include/media/v4l2-subdev.h | 2 +-
> > >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>>> 
> > >>>>> diff --git a/include/media/v4l2-subdev.h
> > >>>>> b/include/media/v4l2-subdev.h
> > >>>>> index 5f1669c45642..72d7f28f38dc 100644
> > >>>>> --- a/include/media/v4l2-subdev.h
> > >>>>> +++ b/include/media/v4l2-subdev.h
> > >>>>> @@ -829,7 +829,7 @@ struct v4l2_subdev {
> > >>>>>  };
> > >>>>>  
> > >>>>>  #define media_entity_to_v4l2_subdev(ent) \
> > >>>>> - container_of(ent, struct v4l2_subdev, entity)
> > >>>>> + (ent ? container_of(ent, struct v4l2_subdev, entity) : NULL)
> > >>>>>  #define vdev_to_v4l2_subdev(vdev) \
> > >>>>>   ((struct v4l2_subdev *)video_get_drvdata(vdev))
> > >>>> 
> > >>>> The problem with this is that ent is now referenced twice. If the ent
> > >>>> macro argument has side effect, this would introduce bugs. It's
> > >>>> unlikely, but worth avoiding. Either use a macro or a function.
> > >>>> 
> > >>>> I think I'd use function for there's little use for supporting for
> > >>>> const and non-const arguments presumably. A simple static inline
> > >>>> function should do.
> > >>> 
> > >>> Note that, if we want to keep using a macro, this could be written as
> > >>> 
> > >>> #define media_entity_to_v4l2_subdev(ent) ({ \
> > >>> typeof(ent) __ent = ent; \
> > > 
> > > I just realized that this should be written
> > > 
> > >   typeof(ent) __ent = (ent);
> > 
> > I don't think that really makes much of a difference. It's a little bit
> > safer still perhaps. I don't remember having seen a case where the function
> > argument would have required parentheses there though.
> > 
> > >>> __ent ? container_of(__ent, struct v4l2_subdev, entity) : NULL; 
> > >>> \
> > >>> 
> > >>> })
> > >>> 
> > >>> Bonus point if you can come up with a way to return a const struct
> > >>> v4l2_subdev pointer when then ent argument is const.
> > >> 
> > >> I can't think of a use case for that. I've never seen a const struct
> > >> v4l2_subdev anywhere. I could be just oblivious though. :-)
> > > 
> > > I agree with you, it's overkill, at least for now. Although I'd like to
> > > see how it could be done, for other similar constructs where both const
> > > and non- const versions are useful.
> > 
> > Yes, that approach is fine. Another example here (not merged yet):
> > 
> > <URL:https://git.linuxtv.org/sailus/media_tree.git/commit/?h=of=1461f5172
> > d40c1c4632bcb457e5f580836922879>
> 
> The problem here is that the container_of() macro ends up casting the 
> argument 
> to a struct v4l2_subdev *, regardless of whether the original pointer was 
> const or not.

Uh, good point. Hmm.

> 
> > > > Better give a __ent a name that someone will not accidentally come up
> > > > with. That can lead to problems that are difficult to debug --- for the
> > > > code compiles, it just doesn't do what's expected.
> > > 
> > > Won't it generate a compilation error as the variable would be redefined
> > > by the macro ?
> > 
> > It's perfectly fine redefine local 

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

[Sakari Ailus]

Hi Kieran,

On Thu, May 18, 2017 at 01:04:55PM +0100, Kieran Bingham wrote:
> Hi Sakari,
> 
> >>> In omap3isp/isp.c: isp_fwnodes_parse() the async notifier is registered 
> >>> looking
> >>> at the endpoints parent fwnode:
> >>>
> >>>   isd->asd.match.fwnode.fwnode =
> >>>   fwnode_graph_get_remote_port_parent(fwnode);
> >>>
> >>> This would therefore not support ADV748x ... (it wouldn't know which 
> >>> TX/CSI
> >>> entity to match against)
> >>>
> >>> So the way I see it is that all devices which currently register an async
> >>> notifier should now register the match against the endpoint instead of the
> >>> parent device:
> >>>
> >>>  - isd->asd.match.fwnode.fwnode = 
> >>> fwnode_graph_get_remote_port_parent(fwnode);
> >>>  + isd->asd.match.fwnode.fwnode = fwnode;
> >>>
> >>> And then if we adapt the match to check against:
> >>>fwnode == fwnode || fwnode == 
> >>> fwnode_graph_get_remote_port_parent(fwnode);
> >>
> >> That's not enough as a master driver may use device node whereas the
> >> sub-device driver uses endpoint node. You need to do it both ways.
> >>
> 
> I've worked through this and I'm convinced that it should not be both ways...
> 
> We are matching a Subdevice (SD) to an Async Subdevice Notifier (ASD)
> 
> Bringing in 'endpoints' gives us the following match combinations
> 
> 
>   SD   ASD   : Result
>   ep   ep: Match ... Subdevices can specify their endpoint node.
> Notifiers can be updated to also specify the (remote) 
> endpoint.
> 
>   dev  ep: Match  - We should take the parent of the ASD to match SD,
> to support subdevices which default to their device node.
> 
>   dev  dev   : Match - This is the current case for all other drivers
> but Notifier ASDs can be converted to EP's
> 
>   ep   dev   : No Match - We should *not* take the parent of the SD
> If a subdevice has specified it's endpoint, (ADV748x)
> Matching against the parent device is invalid.

Is it? You could argue that all CSI-2 receiver drivers that the ADV748x is
used need to be converted, but I suppose that other sub-device drivers will
gradually get converted as well whilst not all CSI-2 receiver drivers could
be converted yet.

I guess it would be also possible to perform a mass conversion but the
problem in those is always that you can't test all the affected hardware
anyway.

> 
> Finding and matching the parent of the SD would allow a driver to register a
> notifier ASD with a dev node, and expect to match a subdevice that has
> registered it's subdev with an EP node. This would erroneously allow drivers 
> to
> register a notifier that would match against *both* of the ADV748x CSI2 
> entities.

You'd first have to have a board that has the two devices, and then ignore
what the drivers are doing. :-) I guess an error would be encountered at
some point in driver initialisation.

Anyway, I don't think this situation should be a lasting one, and that
endpoint matching is the way to go.

> 
> I have posted an implementation of this as:
>  [PATCH v1 3/3] v4l: async: Match parent devices [0]
> 
> I believe this to be correct - but I'm aware that I'm only really considering
> the OF side here... Please let me know if there's something I'm not taking 
> into
> account.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

[Sakari Ailus]

Hi Laurent,

On Thu, May 18, 2017 at 11:54:46PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Thursday 18 May 2017 23:50:34 Sakari Ailus wrote:
> > On Thu, May 18, 2017 at 07:08:00PM +0300, Laurent Pinchart wrote:
> > > On Wednesday 17 May 2017 22:20:57 Sakari Ailus wrote:
> > >> On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote:
> > >>> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > >>> 
> > >>> Return NULL, if a null entity is parsed for it's v4l2_subdev
> > >>> 
> > >>> Signed-off-by: Kieran Bingham
> > >>> <kieran.bingham+rene...@ideasonboard.com>
> > >>> ---
> > >>> 
> > >>>  include/media/v4l2-subdev.h | 2 +-
> > >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>> 
> > >>> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > >>> index 5f1669c45642..72d7f28f38dc 100644
> > >>> --- a/include/media/v4l2-subdev.h
> > >>> +++ b/include/media/v4l2-subdev.h
> > >>> @@ -829,7 +829,7 @@ struct v4l2_subdev {
> > >>>  };
> > >>>  
> > >>>  #define media_entity_to_v4l2_subdev(ent) \
> > >>> -   container_of(ent, struct v4l2_subdev, entity)
> > >>> +   (ent ? container_of(ent, struct v4l2_subdev, entity) : NULL)
> > >>>  #define vdev_to_v4l2_subdev(vdev) \
> > >>> ((struct v4l2_subdev *)video_get_drvdata(vdev))
> > >> 
> > >> The problem with this is that ent is now referenced twice. If the ent
> > >> macro argument has side effect, this would introduce bugs. It's
> > >> unlikely, but worth avoiding. Either use a macro or a function.
> > >> 
> > >> I think I'd use function for there's little use for supporting for const
> > >> and non-const arguments presumably. A simple static inline function
> > >> should do.
> > >
> > > Note that, if we want to keep using a macro, this could be written as
> > > 
> > > #define media_entity_to_v4l2_subdev(ent) ({ \
> > > 
> > >   typeof(ent) __ent = ent; \
> 
> I just realized that this should be written
> 
>   typeof(ent) __ent = (ent);

I don't think that really makes much of a difference. It's a little bit
safer still perhaps. I don't remember having seen a case where the function
argument would have required parentheses there though.

> 
> > >   __ent ? container_of(__ent, struct v4l2_subdev, entity) : NULL; \
> > > 
> > > })
> > > 
> > > Bonus point if you can come up with a way to return a const struct
> > > v4l2_subdev pointer when then ent argument is const.
> > 
> > I can't think of a use case for that. I've never seen a const struct
> > v4l2_subdev anywhere. I could be just oblivious though. :-)
> 
> I agree with you, it's overkill, at least for now. Although I'd like to see 
> how it could be done, for other similar constructs where both const and non-
> const versions are useful.

Yes, that approach is fine. Another example here (not merged yet):

<URL:https://git.linuxtv.org/sailus/media_tree.git/commit/?h=of=1461f5172d40c1c4632bcb457e5f580836922879>

> 
> > Better give a __ent a name that someone will not accidentally come up with.
> > That can lead to problems that are difficult to debug --- for the code
> > compiles, it just doesn't do what's expected.
> 
> Won't it generate a compilation error as the variable would be redefined by 
> the macro ?

It's perfectly fine redefine local variables. The compiler could just
generate a warning and not an error.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

[Sakari Ailus]

Hi Laurent,

On Thu, May 18, 2017 at 07:08:00PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Wednesday 17 May 2017 22:20:57 Sakari Ailus wrote:
> > On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote:
> > > From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > > 
> > > Return NULL, if a null entity is parsed for it's v4l2_subdev
> > > 
> > > Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > > ---
> > > 
> > >  include/media/v4l2-subdev.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > > index 5f1669c45642..72d7f28f38dc 100644
> > > --- a/include/media/v4l2-subdev.h
> > > +++ b/include/media/v4l2-subdev.h
> > > @@ -829,7 +829,7 @@ struct v4l2_subdev {
> > > 
> > >  };
> > >  
> > >  #define media_entity_to_v4l2_subdev(ent) \
> > > - container_of(ent, struct v4l2_subdev, entity)
> > > + (ent ? container_of(ent, struct v4l2_subdev, entity) : NULL)
> > > 
> > >  #define vdev_to_v4l2_subdev(vdev) \
> > >   ((struct v4l2_subdev *)video_get_drvdata(vdev))
> > 
> > The problem with this is that ent is now referenced twice. If the ent macro
> > argument has side effect, this would introduce bugs. It's unlikely, but
> > worth avoiding. Either use a macro or a function.
> > 
> > I think I'd use function for there's little use for supporting for const and
> > non-const arguments presumably. A simple static inline function should do.
> 
> Note that, if we want to keep using a macro, this could be written as
> 
> #define media_entity_to_v4l2_subdev(ent) ({ \
>   typeof(ent) __ent = ent; \
>   __ent ? container_of(__ent, struct v4l2_subdev, entity) : NULL; \
> })
> 
> Bonus point if you can come up with a way to return a const struct 
> v4l2_subdev 
> pointer when then ent argument is const.

I can't think of a use case for that. I've never seen a const struct
v4l2_subdev anywhere. I could be just oblivious though. :-)

Better give a __ent a name that someone will not accidentally come up with.
That can lead to problems that are difficult to debug --- for the code
compiles, it just doesn't do what's expected.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent

[Sakari Ailus]

Hi Kieran,

On Wed, May 17, 2017 at 04:03:38PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> V4L2 async notifiers can pass the endpoint fwnode rather than the device
> fwnode.
> 
> Provide a helper to obtain the parent device fwnode without first
> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>

Could you rebase this on my fwnode cleanup patchset here, please? I'd be
happy to apply it on top of the set.

<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=acpi-graph-cleaned>

This function becomes quite simple, see
fwnode_graph_get_remote_port_parent().

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

[Sakari Ailus]

Hi Kieran,

On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> Return NULL, if a null entity is parsed for it's v4l2_subdev
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> ---
>  include/media/v4l2-subdev.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 5f1669c45642..72d7f28f38dc 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -829,7 +829,7 @@ struct v4l2_subdev {
>  };
>  
>  #define media_entity_to_v4l2_subdev(ent) \
> - container_of(ent, struct v4l2_subdev, entity)
> + (ent ? container_of(ent, struct v4l2_subdev, entity) : NULL)
>  #define vdev_to_v4l2_subdev(vdev) \
>   ((struct v4l2_subdev *)video_get_drvdata(vdev))
>  

The problem with this is that ent is now referenced twice. If the ent macro
argument has side effect, this would introduce bugs. It's unlikely, but
worth avoiding. Either use a macro or a function.

I think I'd use function for there's little use for supporting for const and
non-const arguments presumably. A simple static inline function should do.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

[Sakari Ailus]

ep.port);
> >>>> +
> >>>> +if (ep.port > ADV748X_PORT_MAX) {
> >>>> +adv_err(state, "Invalid endpoint %s on 
> >>>> port %d",
> >>>> +
> >>>> of_node_full_name(ep.local_node),
> >>>> +ep.port);
> >>>> +
> >>>> +continue;
> >>>> +}
> >>>> +
> >>>> +state->endpoints[ep.port] = ep_np;
> >>>> +found++;
> >>>> +}
> >>>> +}
> >>>> +
> >>>> +return found ? 0 : -ENODEV;
> >>>> +}
> >>>> +
> > 
> > ...
> > 
> >>>> diff --git a/drivers/media/i2c/adv748x/adv748x-csi2.c 
> >>>> b/drivers/media/i2c/adv748x/adv748x-csi2.c
> >>>> new file mode 100644
> >>>> index ..d0a0fcfeae2e
> >>>> --- /dev/null
> >>>> +++ b/drivers/media/i2c/adv748x/adv748x-csi2.c

...

> >>>> +/* 
> >>>> -
> >>>> + * v4l2_subdev_internal_ops
> >>>> + *
> >>>> + * We use the internal registered operation to be able to ensure that 
> >>>> our
> >>>> + * incremental subdevices (not connected in the forward path) can be 
> >>>> registered
> >>>> + * against the resulting video path and media device.
> >>>> + */
> >>>> +
> >>>> +static int adv748x_csi2_notify_complete(struct v4l2_async_notifier 
> >>>> *notifier)
> >>>> +{
> >>>> +struct adv748x_csi2 *tx = notifier_to_csi2(notifier);
> >>>> +struct adv748x_state *state = tx->state;
> >>>> +int ret;
> >>>> +
> >>>> +ret = v4l2_device_register_subdev_nodes(tx->sd.v4l2_dev);
> >>>> +if (ret) {
> >>>> +adv_err(state, "Failed to register subdev nodes\n");
> >>>> +return ret;
> >>>> +}
> >>>> +
> >>>> +/* Return early until we register TXB */
> >>>> +if (is_txa(tx))
> >>>> +return ret;
> >>>> +
> >>>> +ret = adv748x_setup_links(state);
> >>>
> >>> Could you set up links first? It'd be really annoying to clean up the mess
> >>> after the sub-device nodes have been registered. Actually --- it's not 
> >>> even
> >>> doable at the moment.
> >>
> >> No - I don't think I can set up links until the devices are registered so 
> >> that I
> >> have access to the media-dev.
> >>
> >> I think I've already tried that :)
> > 
> > You still don't need to register the sub-device nodes, do you? The
> > sub-devices are already registered before
> > v4l2_device_register_subdev_nodes(), right?
> > 
> 
> Don't worry about the code above - It's all been deleted.
> 
> I realised I was using the async notifiers to register the AFE/HDMI entities 
> but
> it was completely overkill.

Ack. Good. Sometimes you figure out how best do something while explaining
it to others... :-) (I was happy to listen.)

...

> >>>> diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c 
> >>>> b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> >>>> new file mode 100644
> >>>> index ..19c1bd41cc6c
> >>>> --- /dev/null
> >>>> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> >>>> @@ -0,0 +1,671 @@
> > 
> > ...
> > 
> >>>> +static const struct v4l2_dv_timings_cap adv748x_hdmi_timings_cap = {
> >>>> +.type = V4L2_DV_BT_656_1120,
> >>>> +/* keep this initialization for compatibility with GCC < 4.4.6 
> >>>> */
> >>>> +.reserved = { 0 },
> >>>
> >>> Is this necessary? Aren't the uninitialised fields zeroed if any field in 
> >>> a
> >>> struct is initialised, also on those versions of GCC? (Of course there 
> >>> have
> >>> been bugs, but nothing rings a bell.)
> >>
> >> Looks like it is necessary:
> >>  https://patchwork.kernel.org/patch/2851851/
> > 
> > This is related to the anonymous union. What I'm saying appears unrelated
> > --- if any struct field is initialised, then the rest of the fields of the
> > struct are initialised to zero by the compiler (unless explicitly
> > initialised to something else).
> > 
> > I.e. you can drop ".reserved = { 0 }," line.
> 
> In that patch I referenced, (several of the drivers were all updated in a
> similar fashion) Gianluca mentioned the following:
> 
> > 
> > Please note that I have also to init the reserved space as otherwise GCC 
> > fails with this error:
> > 
> >  CC [M]  adv7842.o
> >  adv7842.c:549: error: field name not in record or union initializer
> >  adv7842.c:549: error: (near initialization for  
> > 'adv7842_timings_cap_analog.reserved')
> >  adv7842.c:549: warning: braces around  scalar initializer
> >  adv7842.c:549: warning: (near initialization for  
> > 'adv7842_timings_cap_analog.reserved[0]')

I had to test that here. :-) Ouch. And I'm left wondering how does the
initialisation of the reserved field get things working again...

Anyway, please ignore the original comment.

> 
> Therefore my understanding was that it was necessary.
> 
> If not - then we can remove from the following drivers too:
> 
> git grep ".reserved = { 0 }"
> drivers/media/i2c/ad9389b.c:.reserved = { 0 },
> drivers/media/i2c/adv7511.c:.reserved = { 0 },
> drivers/media/i2c/adv7604.c:.reserved = { 0 },
> drivers/media/i2c/adv7604.c:.reserved = { 0 },
> drivers/media/i2c/adv7842.c:.reserved = { 0 },
> drivers/media/i2c/adv7842.c:.reserved = { 0 },
> drivers/media/i2c/tc358743.c:   .reserved = { 0 },
> drivers/media/i2c/ths8200.c:.reserved = { 0 },
> drivers/media/platform/vivid/vivid-vid-common.c:.reserved = { 0 },
> drivers/media/spi/gs1662.c: .reserved = { 0 },
> samples/v4l/v4l2-pci-skeleton.c:.reserved = { 0 },
> 
> But maybe we should test with an older compiler to verify this...
> 
> Is there a cut-off point where we would stop supporting older compilers?

I guess when people stop submitting patches to support them? :-)

Documentation/admin-guide/README.rst says that at least GCC 3.2 should be
used. That's very, very old. I wonder if anyone has recently used such an
old version...

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

[Sakari Ailus]

Hi Kieran,

On Mon, May 15, 2017 at 01:32:41PM +0100, Kieran Bingham wrote:
> Hi Sakari
> 
> On 12/05/17 17:46, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > Thanks for the patches!
> 
> Thankyou for the review!

You're welcome! :-)

> 
> > Would you have a media-ctl -p && media-ctl --print-dot (or the PS file) to
> > see how this looks like in practice?
> 
> The file I linked to on Friday showed the immutable links version (I have that
> in as a temporary workaround until the links are correctly ignored by rvin /
> handled by core correctly)
> 
> So again, here is the posted 'immutable' version, which represents this patch
> version:
> 
> http://janet.linuxembedded.co.uk/adv748x-immutable.png
> 
> But the end goal of this patchset will be the following configuration:
> 
> http://janet.linuxembedded.co.uk/adv748x-non-immutable.png

What does media-ctl -p say?

...

> >> +static int adv748x_afe_g_input_status(struct v4l2_subdev *sd, u32 *status)
> >> +{
> >> +  struct adv748x_state *state = adv748x_afe_to_state(sd);
> >> +  int ret;
> >> +
> >> +  ret = mutex_lock_interruptible(>mutex);
> > 
> > I wonder if this is necessary. Do you expect the mutex to be taken for
> > extended periods of time?
> 
> It looks like the only other adv* driver to take a lock here is the 7180.
> Perhaps that is where the heritage of this code derived from.
> 
> I don't think the locking should be held for a long time anywhere, but I will
> try to go through and consider all the locking throughout the code base.
> 
> At the moment I think anything that calls adv748x_afe_status() should be 
> locked
> to ensure serialisation through adv748x_afe_read_ro_map().

I meant whether you need the "_interruptible" part. It's quite a bit of
repeating error handling that looks mostly unnecessary.

> 
> 
> >> +  if (ret)
> >> +  return ret;
> >> +
> >> +  ret = adv748x_afe_status(state, status, NULL);
> >> +
> >> +  mutex_unlock(>mutex);
> >> +  return ret;
> >> +}

...

> >> +static int adv748x_afe_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> >> +{
> >> +  struct adv748x_state *state =
> >> +  container_of(ctrl->handler, struct adv748x_state, afe.ctrl_hdl);
> >> +  unsigned int width, height, fps;
> >> +  v4l2_std_id std;
> >> +
> >> +  switch (ctrl->id) {
> >> +  case V4L2_CID_PIXEL_RATE:
> > 
> > I presume you will know when PIXEL_RATE changes? 
> 
> No interrupt handling in here yet to handle input changes - but I'm working on
> that. At the least it could be set on format configurations.

Ack. Then I guess this is good.

> 
> 
> > You can use
> > v4l2_ctrl_s_ctrl_int64() to change it. That way control events will be
> > emitted correctly, too.
> 
> Thanks - I didn't know about those helpers. I'll try to add where applicable.
> 
> These controls are indirectly read through the CSI2 'pass-through' entity.
> 
> Do I need to add some event handling in there to update it's control value to
> propagate the events?

As long as you allow subscribing the control event I guess nothing special
is needed.

..

> >> +int adv748x_afe_probe(struct adv748x_state *state, struct device_node *ep)
> >> +{
> >> +  int ret;
> >> +  unsigned int i;
> >> +
> >> +  state->afe.streaming = false;
> >> +  state->afe.curr_norm = V4L2_STD_ALL;
> >> +
> >> +  adv748x_subdev_init(>afe.sd, state, _afe_ops, "afe");
> >> +
> >> +  /* Ensure that matching is based upon the endpoint fwnodes */
> >> +  state->afe.sd.fwnode = >fwnode;
> > 
> > I wonder if you really need to convert all users of async matching to use
> > endpoints --- could you opportunistically peek if the device node matches,
> > just in case? You can't have an accidental positive match anyway.
> > 
> > So, the match is now for plain fwnode pointers, and it would be:
> > 
> > return async->fwnode == fwnode ||
> > port_parent(parent(async->fwnode)) == fwnode ||
> > async->fwnode == port_parent(parent(fwnode));
> 
> 
> If we adapt the core to match against endpoint comparisons and device node
> comparisons then yes we wouldn't have to adapt everything, I.e. we wouldn't 
> have
> to change all the async devices - but we would have to adapt all the 
> bus/bridge
> drivers (those who perform the v4l2_async_notifier_register() call) as they 
> must
> register their notifier against an endpoint if they are to ever be able t

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sakari Ailus]

ase
> > >>> simply return NULL and let the master's probe
> > >>> continue rather than deferring.
> > >>> 
> > >>> Signed-off-by: Sricharan R <sricha...@codeaurora.org>
> > >>> ---
> > >>> 
> > >>>  drivers/iommu/of_iommu.c | 1 +
> > >>>  1 file changed, 1 insertion(+)
> > >>> 
> > >>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > >>> index 9f44ee8..e6e9bec 100644
> > >>> --- a/drivers/iommu/of_iommu.c
> > >>> +++ b/drivers/iommu/of_iommu.c
> > >>> @@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct
> > >>> device_node *np)
> > >>> 
> > >>> ops = iommu_ops_from_fwnode(fwnode);
> > >>> if ((ops && !ops->of_xlate) ||
> > >>> +   !of_device_is_available(iommu_spec->np) ||
> > >>> (!ops && !of_iommu_driver_present(iommu_spec->np)))
> > >>> return NULL;
> > >> 
> > >> This looks good to me, but won't be enough. The ipmmu-vmsa driver in
> > >> v4.12-rc1 doesn't call iommu_device_register() and thus won't be found
> > >> by iommu_ops_from_fwnode(). Furthermore, it doesn't IOMMU_OF_DECLARE(),
> > >> and thus will always be considered as absent.
> > >> 
> > >> I agree that the ipmmu-vmsa driver needs to be fixed, but it would
> > >> have been nice to check existing IOMMU drivers before merging this patch
> > >> series...
> > > 
> > > Please pardon the question, but has this patch series been tested on
> > > ARM32 ?
> > > 
> > > When the device is probed the arch_setup_dma_ops() function is called.
> > > It sets the device's dma_ops and the mapping (in
> > > __arm_iommu_attach_device()). If probe is deferred,
> > > arch_teardown_dma_ops() is called which in turn calls
> > > arch_teardown_dma_ops(). This removes the mapping but doesn't touch the
> > > dma_ops. The next time the device is probed, arch_setup_dma_ops() bails
> > > out immediately as the dma_ops are already set, leaving us with a device
> > > bound to IOMMU operations but with no mapping. This oopses later as soon
> > > as the kernel tries to map memory for the device through the IOMMU.
> > 
> > Resetting the dma_ops for arm32 was added in this patch [1], which I
> > missed to send in the original series, but now have added to Russell's patch
> > tracking system.
> 
> Thank you. I fear that won't be enough though.
> 
> > [1] https://patchwork.kernel.org/patch/9434105/
> 
> Quoting the patch:
> 
> > arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
> > ,dma_ops should be cleared in the teardown path. Otherwise
> > this causes problem when the probe of device is retried after
> > being deferred. The device's iommu structures are cleared
> > after EPROBEDEFER error, but on the next try dma_ops will still
> > be set to old value, which is not right.
> >
> > Signed-off-by: Sricharan R <sricha...@codeaurora.org>
> > Reviewed-by: Robin Murphy <robin.mur...@arm.com>
> > ---
> >   arch/arm/mm/dma-mapping.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > index ab4f745..a40f03e 100644
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -2358,6 +2358,7 @@ static void arm_teardown_iommu_dma_ops(struct device 
> *dev)
> > __arm_iommu_detach_device(dev);
> > arm_iommu_release_mapping(mapping);
> > +   set_dma_ops(dev, NULL);
> >   }
> >   #else
> 
> The subject mentions arch_teardown_dma_ops(), which I think is correct, but 
> the patch adds the set_dma_ops() call to arm_teardown_iommu_dma_ops().
> 
> However, the situation is perhaps more complex. Note the check at the 
> beginning of arch_setup_dma_ops():
> 
>   /*
>* Don't override the dma_ops if they have already been set. Ideally
>* this should be the only location where dma_ops are set, remove this
>* check when all other callers of set_dma_ops will have disappeared.
>*/
>   if (dev->dma_ops)
>   return;
> 
> If you set the dma_ops to NULL in arm_teardown_iommu_dma_ops() or 
> arch_teardown_dma_ops(), the next call to arch_setup_dma_ops() will override 
> them. To be safe you should only set them to NULL if they have been set by 
> arch_setup_dma_ops(). More than that, arch_teardown_dma_ops() should probably 
> not call arm_teardown_iommu_dma_ops() at all if the dma_ops were set by 
> arm_iommu_attach_device() and not arch_teardown_dma_ops(). One option would 
> be 
> to add a field to struct dev_archdata to store that information. To avoid 
> growing the structure, which is embedded in every struct device, you could 
> possibly turn the dma_coherent bool into a bitfield.
> 
> @@ -19,7 +19,8 @@ struct dev_archdata {
>  #ifdef CONFIG_XEN
>   const struct dma_map_ops *dev_dma_ops;
>  #endif
> - bool dma_coherent;
> + bool dma_coherent:1;
> + bool dma_ops_setup:1;
>  };
>  
>  struct omap_device;
> 
> I haven't checked, however, whether the dma_coherent field would need to be 
> accessed atomically, so this might be a bad idea.

A bool bit field? :-)

I think I'd just use bool for both. I wouldn't expect dma_coherent change
once it has been set before device driver probe though.

If you like a bit field, then I'd propose making it unsigned int.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

[Sakari Ailus]

Hi Kieran,

Thanks for the patches!

Would you have a media-ctl -p && media-ctl --print-dot (or the PS file) to
see how this looks like in practice?

Please see my comments below.

On Thu, May 11, 2017 at 06:21:20PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Provide basic support for the ADV7481 and ADV7482.
> 
> The driver is modelled with 2 subdevices to allow simultaneous streaming
> from the AFE (Analog front end) and HDMI inputs.
> 
> Presently the HDMI is hardcoded to link to the TXA CSI bus, whilst the
> AFE is linked to the TXB CSI bus.
> 
> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
> and an earlier rework by Niklas Söderlund.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> 
> v2:
>  - Implement DT parsing
>  - adv748x: Add CSI2 entity
>  - adv748x: Rework pad allocations and fmts
>  - Give AFE 8 input pads and move pad defines
>  - Use the enums to ensure pads are referenced correctly.
>  - adv748x: Rename AFE/HDMI entities
>Now they are 'just afe' and 'just hdmi'
>  - Reorder the entity enum and structures
>  - Added pad-format for the CSI2 entities
>  - CSI2 s_stream pass through
>  - CSI2 control pass through (with link following)
> ---
>  Documentation/devicetree/bindings/media/i2c/adv748x.txt |  63 +-
>  MAINTAINERS |   6 +-
>  drivers/media/i2c/Kconfig   |  10 +-
>  drivers/media/i2c/Makefile  |   1 +-
>  drivers/media/i2c/adv748x/Makefile  |   7 +-
>  drivers/media/i2c/adv748x/adv748x-afe.c | 599 -
>  drivers/media/i2c/adv748x/adv748x-core.c| 698 +-
>  drivers/media/i2c/adv748x/adv748x-csi2.c| 373 +-
>  drivers/media/i2c/adv748x/adv748x-hdmi.c| 671 +-
>  drivers/media/i2c/adv748x/adv748x.h | 201 +++-
>  10 files changed, 2629 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt
>  create mode 100644 drivers/media/i2c/adv748x/Makefile
>  create mode 100644 drivers/media/i2c/adv748x/adv748x-afe.c
>  create mode 100644 drivers/media/i2c/adv748x/adv748x-core.c
>  create mode 100644 drivers/media/i2c/adv748x/adv748x-csi2.c
>  create mode 100644 drivers/media/i2c/adv748x/adv748x-hdmi.c
>  create mode 100644 drivers/media/i2c/adv748x/adv748x.h
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.txt 
> b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
> new file mode 100644
> index ..04d9ebc674a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
> @@ -0,0 +1,63 @@
> +* Analog Devices ADV748X video decoder with HDMI receiver
> +
> +The ADV7481, and ADV7482 are multi format video decoders with an integrated
> +HDMI receiver. It can output CSI-2 on two independent outputs TXA and TXB 
> from
> +three input sources HDMI, analog and TTL.
> +
> +Required Properties:
> +
> +  - compatible: Must contain one of the following
> +- "adi,adv7481" for the ADV7481
> +- "adi,adv7482" for the ADV7482
> +
> +  - reg: I2C slave address
> +
> +The device node must contain one 'port' child node per device input and 
> output
> +port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
> +are numbered as follows.
> +
> +  Name  TypePort
> +
> +  HDMI  sink0
> +  AIN1  sink1
> +  AIN2  sink2
> +  AIN3  sink3
> +  AIN4  sink4
> +  AIN5  sink5
> +  AIN6  sink6
> +  AIN7  sink7
> +  AIN8  sink8
> +  TTL   sink9
> +  TXA   source  10
> +  TXB   source  11
> +
> +The digital output port node must contain at least one source endpoint.
> +
> +Example:
> +
> +video_receiver@70 {
> +compatible = "adi,adv7482";
> +reg = <0x70>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@10 {
> +reg = <10>;
> +adv7482_txa: endpoint@1 {
> +clock-lanes = <0>;
> +data-lanes = <1 2 3 4>;
> +remote-endpoint = <_in>;
> +};
> +};
> +
> +port@11 {
> +reg = <11>;
> +adv7482_txb: endpoint@1 {
> +clock-lanes = <0>;
> +data-lanes = <1>;
> + 

Re: [PATCH] v4l2-subdev: Remove of_node

[Sakari Ailus]

Hi Kieran,

Thanks for the patch.

On Wed, May 10, 2017 at 05:45:54PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> 
> With the fwnode implementation, of_node is no longer used.
> 
> Remove it.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> ---
>  include/media/v4l2-subdev.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 5f1669c45642..a40760174797 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -787,7 +787,6 @@ struct v4l2_subdev_platform_data {
>   *   is attached.
>   * @devnode: subdev device node
>   * @dev: pointer to the physical device, if any
> - * @of_node: The device_node of the subdev, usually the same as dev->of_node.
>   * @fwnode: The fwnode_handle of the subdev, usually the same as
>   *   either dev->of_node->fwnode or dev->fwnode (whichever is non-NULL).
>   * @async_list: Links this subdev to a global subdev_list or @notifier->done
> @@ -820,7 +819,6 @@ struct v4l2_subdev {
>   void *host_priv;
>   struct video_device *devnode;
>   struct device *dev;
> - struct device_node *of_node;
>   struct fwnode_handle *fwnode;
>   struct list_head async_list;
>   struct v4l2_async_subdev *asd;

This is actually the difference my local v4l2-acpi branch and what I have in
my git.linuxtv.org tree. :-) So the change is there, embedded in the same
patch that converts the users.

I'll upload it later tonight.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v5 3/7] media: i2c: max2175: Add MAX2175 support

[Sakari Ailus]

Hi Ramesh,

On Tue, May 09, 2017 at 02:37:34PM +0100, Ramesh Shanmugasundaram wrote:
...
> +#include 
> +#include 
> +#include 

Could you rebase this on the V4L2 fwnode patchset here, please?

<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi>

It depends on other patches which will reach media-tree master in next rc1,
for now I've merged them here:

<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge>

I'll send a pull request for media-tree once we have 4.12rc1 in media-tree
master.

Thanks.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v5 3/7] media: i2c: max2175: Add MAX2175 support

[Sakari Ailus]

Hi Ramesh,

On Tue, May 09, 2017 at 02:37:34PM +0100, Ramesh Shanmugasundaram wrote:
> This patch adds driver support for the MAX2175 chip. This is Maxim
> Integrated's RF to Bits tuner front end chip designed for software-defined
> radio solutions. This driver exposes the tuner as a sub-device instance
> with standard and custom controls to configure the device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
> v5:
>  - sck -> Sample clock is clarified in driver documentation (Hans)
>  - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
> ---
>  Documentation/media/v4l-drivers/index.rst   |1 +
>  Documentation/media/v4l-drivers/max2175.rst |   60 ++
>  drivers/media/i2c/Kconfig   |4 +
>  drivers/media/i2c/Makefile  |2 +
>  drivers/media/i2c/max2175/Kconfig   |8 +
>  drivers/media/i2c/max2175/Makefile  |4 +
>  drivers/media/i2c/max2175/max2175.c | 1437 
> +++
>  drivers/media/i2c/max2175/max2175.h |  108 ++

If the driver consists of two files, I think it'd be reasonable to have it
directly under drivers/media/i2c rather than in its own directory.

>  8 files changed, 1624 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/max2175.rst
>  create mode 100644 drivers/media/i2c/max2175/Kconfig
>  create mode 100644 drivers/media/i2c/max2175/Makefile
>  create mode 100644 drivers/media/i2c/max2175/max2175.c
>  create mode 100644 drivers/media/i2c/max2175/max2175.h
> 
> diff --git a/Documentation/media/v4l-drivers/index.rst 
> b/Documentation/media/v4l-drivers/index.rst
> index a606d1cdac13..d8cade53d496 100644
> --- a/Documentation/media/v4l-drivers/index.rst
> +++ b/Documentation/media/v4l-drivers/index.rst
> @@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
> distribution of Linux.
>   davinci-vpbe
>   fimc
>   ivtv
> +max2175

Tabs, please!

>   meye
>   omap3isp
>   omap4_camera
> diff --git a/Documentation/media/v4l-drivers/max2175.rst 
> b/Documentation/media/v4l-drivers/max2175.rst
> new file mode 100644
> index ..94fb815f043b
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/max2175.rst
> @@ -0,0 +1,60 @@
> +Maxim Integrated MAX2175 RF to bits tuner driver
> +
> +
> +The MAX2175 driver implements the following driver-specific controls:
> +
> +``V4L2_CID_MAX2175_I2S_ENABLE``

You're documenting driver specific controls. Should you provide a header
under include/uapi/linux to make these usable for the user space?

> +---
> +Enable/Disable I2S output of the tuner.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``(0)``
> +  - I2S output is disabled.
> +* - ``(1)``
> +  - I2S output is enabled.
> +
> +``V4L2_CID_MAX2175_HSLS``
> +-
> +The high-side/low-side (HSLS) control of the tuner for a given band.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``(0)``
> +  - The LO frequency position is below the desired frequency.
> +* - ``(1)``
> +  - The LO frequency position is above the desired frequency.
> +
> +``V4L2_CID_MAX2175_RX_MODE (menu)``
> +---
> +The Rx mode controls a number of preset parameters of the tuner like
> +sample clock (sck), sampling rate etc. These multiple settings are
> +provided under one single label called Rx mode in the datasheet. The
> +list below shows the supported modes with a brief description.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``"Europe modes"``
> +* - ``"FM 1.2" (0)``
> +  - This configures FM band with a sample rate of 0.512 million
> +samples/sec with a 10.24 MHz sck.
> +* - ``"DAB 1.2" (1)``
> +  - This configures VHF band with a sample rate of 2.048 million
> +samples/sec with a 32.768 MHz sck.
> +
> +* - ``"North America modes"``
> +* - ``"FM 1.0" (0)``
> +  - This configures FM band with a sample rate of 0.7441875 million
> +samples/sec with a 14.88375 MHz sck.
> +* - ``"DAB 1.2" (1)``
> +  - This configures FM band with a sample rate of 0.372 million
> +samples/sec with a 7.441875 MHz sck.
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index b358d1a40688..d9fc1311794f 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -785,6 +785,10 @@ config VIDEO_SAA6752HS
> To compile this driver as a module, choose M here: the
> module will be called saa6752hs.
>  
> +comment "SDR tuner chips"
> +
> +source "drivers/media/i2c/max2175/Kconfig"
> +
>  comment "Miscellaneous helper chips"
>  
>  config 

Re: [PATCH v5 2/7] dt-bindings: media: Add MAX2175 binding description

[Sakari Ailus]

Hi Ramesh,

On Tue, May 09, 2017 at 02:37:33PM +0100, Ramesh Shanmugasundaram wrote:
> Add device tree binding documentation for MAX2175 RF to bits tuner
> device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> <ramesh.shanmugasunda...@bp.renesas.com>
> Acked-by: Rob Herring <r...@kernel.org>
> ---
> v5:
>  - pF in property-units.txt is renamed to pico-farads (Geert)
>  - "maxim,refout-load-pF" is renamed to "maxim,refout-load".
> ---
>  .../devicetree/bindings/media/i2c/max2175.txt  | 61 
> ++
>  .../devicetree/bindings/property-units.txt |  1 +
>  2 files changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
> b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> new file mode 100644
> index ..dce421857efe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> @@ -0,0 +1,61 @@
> +Maxim Integrated MAX2175 RF to Bits tuner
> +-
> +
> +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
> +RF to Bits® front-end designed for software-defined radio solutions.
> +
> +Required properties:
> +
> +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> +- clocks: phandle to the fixed xtal clock.

How about "clock specifier"

> +- clock-names: name of the fixed xtal clock, shall be "xtal".

If you have a single clock you could drop clock-names. You can obtain it
in the driver using  clk_get(dev, NULL) . Up to you.

> +- port: child port node corresponding to the I2S output, in accordance with
> + the video interface bindings defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The port
> + node must contain at least one endpoint.
> +
> +Optional properties:
> +
> +- maxim,master : phandle to the master tuner if it is a slave. 
> This
> + is used to define two tuners in diversity mode
> + (1 master, 1 slave). By default each tuner is an
> + individual master.
> +- maxim,refout-load   : load capacitance value (in pico-farads) on reference
> + output drive level. The possible load values are:
> +  0 (default - refout disabled)
> + 10
> + 20
> + 30
> + 40
> + 60
> + 70
> +- maxim,am-hiz-filter : empty property indicates the AM Hi-Z filter is used
> + in this hardware for AM antenna input.
> +
> +Example:
> +
> +
> +Board specific DTS file
> +
> +/* Fixed XTAL clock node */
> +maxim_xtal: clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <36864000>;
> +};
> +
> +/* A tuner device instance under i2c bus */
> +max2175_0: tuner@60 {
> + compatible = "maxim,max2175";
> + reg = <0x60>;
> + clocks = <_xtal>;
> + clock-names = "xtal";
> + maxim,refout-load = <10>;
> +
> + port {
> + max2175_0_ep: endpoint {
> + remote-endpoint = <_rx_device>;
> + };
> + };
> +
> +};
> diff --git a/Documentation/devicetree/bindings/property-units.txt 
> b/Documentation/devicetree/bindings/property-units.txt
> index 0849618a9df0..2d1d28843c96 100644
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -30,6 +30,7 @@ Electricity
>  -micro-ohms  : micro Ohms
>  -microwatt-hours: micro Watt-hours
>  -microvolt   : micro volts
> +-pico-farads : picofarads

Why pico-farads and not picofarads? Most of the existing definitions have
no dash. (Just wondering.)

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com