Hi Jacopo,
On Fri, Mar 08, 2019 at 02:31:33PM +0100, Jacopo Mondi wrote:
> Hi Sakari,
>thanks for the review
>
> On Thu, Mar 07, 2019 at 05:19:29PM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > Thanks for writing the documentation for this!
> >
>
On Fri, Mar 08, 2019 at 02:19:03PM +0100, Jacopo Mondi wrote:
> Hi Sakari and Niklas,
>
> On Thu, Mar 07, 2019 at 11:47:26AM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Tue, Mar 05, 2019 at 07:51:19PM +0100, Jacopo Mondi wrote:
> > > Hello,
> >
TE_FL_ACTIVE
> + - 0
> + - The route is enabled. Set by applications.
> +* - V4L2_SUBDEV_ROUTE_FL_IMMUTABLE
> + - 1
> + - The route is immutable. Set by the driver.
> +
> +Return Value
> +
> +
> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> +appropriately. The generic error codes are described at the
> +:ref:`Generic Error Codes ` chapter.
> +
> +ENOSPC
> + The number of provided route entries is less than the available ones.
> +
> +EINVAL
> + The sink or source pad identifiers reference a non-existing pad, or
> refernce
> + pads of different types (ie. the sink_pad identifiers refers to a source
> pad)
> + The sink or source stream identifiers reference a non-existing stream
s/The/or the/
> + in the sink or source pad.
s/i/o/
> +
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
That'd
probably not be trivial to implement though.
> + }
> +
> + if (source_pad == pad1)
> + return true;
> + }
> +
> + return false;
> +}
> +
> static const struct media_entity_operations rcar_csi2_entity_ops = {
> + .has_route = rcar_csi2_has_route,
> .link_validate = v4l2_subdev_link_validate,
> };
>
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
; @@ -595,6 +619,8 @@ int adv748x_afe_init(struct adv748x_afe *afe)
>
> afe->pads[ADV748X_AFE_SOURCE].flags = MEDIA_PAD_FL_SOURCE;
>
> + afe->sd.entity.ops = &adv748x_afe_entity_ops;
> +
> ret = media_entity_pads_init(&afe->sd.entity, ADV748X_AFE_NR_PADS,
> afe->pads);
> if (ret)
> --
> 2.20.1
>
--
Sakari Ailus
sakari.ai...@linux.intel.com
On Thu, Mar 07, 2019 at 10:27:36AM +, Ian Arkver wrote:
> On 07/03/2019 10:09, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Tue, Mar 05, 2019 at 07:51:31PM +0100, Jacopo Mondi wrote:
> > > From: Sakari Ailus
> > >
> > > Add a helper macro fo
Hi Jacopo,
On Tue, Mar 05, 2019 at 07:51:31PM +0100, Jacopo Mondi wrote:
> From: Sakari Ailus
>
> Add a helper macro for iterating over pads that are connected through
> enabled routes. This can be used to find all the connected pads within an
> entity, for instance starting fro
/2 [ENABLED]
> 0/0 -> 1/3 []
> ---
>
> Below is reported the media graph of the system used for testing [1].
>
> v4l2-ctl patches to handle the newly introduced IOCTLs are available from
> Niklas' repository at:
> git://git.ragnatech.se/v4l-utils routing
Could you send the v4l2-ctl patches out as well, please?
--
Sakari Ailus
sakari.ai...@linux.intel.com
Hi Jacopo,
On Fri, Feb 22, 2019 at 12:17:47PM +0100, Jacopo Mondi wrote:
> Hi Sakari,
> thanks for your suggestions.
>
> On Fri, Feb 22, 2019 at 01:04:29PM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
>
> [snip]
>
> > > On the previous example, I thoug
Hi Jacopo,
On Fri, Feb 22, 2019 at 09:40:19AM +0100, Jacopo Mondi wrote:
> Hi Sakari,
>
> On Fri, Feb 22, 2019 at 12:31:32AM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Thu, Feb 21, 2019 at 03:39:40PM +0100, Jacopo Mondi wrote:
> > > Hi Sakari,
> &
; > handling.
> >
>
> Care to explain what makes this ioctl require a compat version? I
> don't see assumptions on the word length on the implementation. What
> am I missing?
The size of the "routes" pointer isn't constant, therefore affecting the
memor
for multiplexed links
> > > - Copy the argument back in case of an error. This is needed to let the
> > > caller know the number of routes.
> > >
> > > Signed-off-by: Sakari Ailus
> > > Reviewed-by: Niklas Söderlund
> > > ---
> >
-off-by: Michal Simek
> >
> > - Add sink and source streams for multiplexed links
> > - Copy the argument back in case of an error. This is needed to let the
> > caller know the number of routes.
> >
> > Signed-off-by: Sakari Ailus
> > Reviewed
On Tue, Jan 22, 2019 at 05:38:48PM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Tue, Jan 22, 2019 at 05:36:55PM +0200, Sakari Ailus wrote:
> > On Wed, Jan 16, 2019 at 01:24:05AM +0200, Laurent Pinchart wrote:
> > > On Fri, Nov 02, 2018 at 12:31:26AM +0100
On Tue, Jan 22, 2019 at 05:37:15PM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Tue, Jan 22, 2019 at 05:31:34PM +0200, Sakari Ailus wrote:
> > On Wed, Jan 16, 2019 at 12:54:20AM +0200, Laurent Pinchart wrote:
> > > On Fri, Nov 02, 2018 at 12:31:20AM +0100
ed-off-by: Michal Simek
> >
> > - Add sink and source streams for multiplexed links
> > - Copy the argument back in case of an error. This is needed to let the
> > caller know the number of routes.
> >
> > Signed-off-by: Sakari Ailus
> > Revie
On Wed, Jan 16, 2019 at 01:53:03AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:31AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > Implement compat IOCTL handlin
Hi Laurent,
On Wed, Jan 16, 2019 at 01:41:08AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:29AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > Two pads are considered having a
On Wed, Jan 16, 2019 at 01:35:14AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:28AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > Signed-off-by: Sakari Ailus
> > Reviewed-by:
Hi Laurent,
On Wed, Jan 16, 2019 at 01:24:05AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:26AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > Add a helper macro for iterating ove
Hi Laurent,
On Wed, Jan 16, 2019 at 12:54:20AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:20AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > The pipeline will be moved from the en
Hi Laurent,
On Wed, Jan 16, 2019 at 12:57:43AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:23AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > This way the pads are always passed to
Hi Laurent,
On Wed, Jan 16, 2019 at 01:28:22AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Wed, Jan 16, 2019 at 12:34:07AM +0200, Sakari Ailus wrote:
> > On Wed, Jan 16, 2019 at 12:21:36AM +0200, Laurent Pinchart wrote:
> > > On Fri, Nov 02, 2018 at 12:31:17AM
On Wed, Jan 16, 2019 at 12:38:42AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thanks you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:19AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > This moves the pipe and stream_count fields from
On Wed, Jan 16, 2019 at 12:24:32AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:18AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > With the addition of the recent has_route() media e
Hi Laurent,
On Wed, Jan 16, 2019 at 12:03:13AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Fri, Nov 02, 2018 at 12:31:16AM +0100, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > Change the media graph walk stack struc
Hu Kieran,
Apologies for the late reply.
On Wed, Nov 28, 2018 at 12:51:39PM +, Kieran Bingham wrote:
> Hi Sakari,
>
> Thank you for your review,
>
> On 20/11/2018 08:34, Sakari Ailus wrote:
> > Hi Kieran,
> >
> > On Fri, Nov 02, 2018 at 03:47:23PM +
them, but I still. X-)
I noticed that the new [GS]_ROUTING interface has no documentation
currently. Could you write it?
Also what I'd like to see is the media graph of a device that is driven by
these drivers. That'd help to better understand the use case also for those
who haven't worked with the patches.
Thanks.
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Hi Niklas,
On Fri, Nov 30, 2018 at 03:25:29AM +0100, Niklas Söderlund wrote:
> Hi Sakari, Steve,
>
> Thanks for your quick response.
>
> On 2018-11-29 22:37:53 +0200, Sakari Ailus wrote:
> > Hi Steve, Niklas,
> >
> > On Thu, Nov 29, 2018 at 11:41:3
example, no driver should be
> doing that. So removing the list_lock from v4l2_async_notifier_init() is
> probably safe. The notifier is not registered with v4l2-async at that point.
I agree, apart from "probably". It is safe.
Niklas: would you like to send a patch? :-)
--
Sakari Ailus
sakari.ai...@linux.intel.com
> +#else
> + /* Perform a software reset. */
> + ret = ov10635_write(dev, OV10635_SOFTWARE_RESET, 1);
> + if (ret < 0) {
> + dev_err(&dev->client->dev, "OV10635 reset failed (%d)\n", ret);
&g
Hi Dave,
Apologies for the delay.
On Fri, Sep 21, 2018 at 02:46:23PM +0100, Dave Stevenson wrote:
> Hi Sakari
>
> On Fri, 21 Sep 2018 at 13:03, Sakari Ailus wrote:
> >
> > Hi Laurent,
> >
> > On Fri, Sep 21, 2018 at 01:01:09PM +0300, Laurent Pinchart wrote:
en neither your answer :) ?
> >
> > Thanks
> > j
> >
> >>>
> >>> Isn't port 4 included?
> >>
> >> Hrm ... yes well I guess these are mandatory for port 4. I'll look at
> >> the wording here.
>
> Port 4 doe
On Fri, Nov 02, 2018 at 01:35:02PM +, Kieran Bingham wrote:
> Hi Sakari, Niklas,
>
> On 02/11/2018 13:15, Sakari Ailus wrote:
> > Hi Kieran,
> >
> > On Fri, Nov 02, 2018 at 12:27:11PM +, Kieran Bingham wrote:
> >> Hi Niklas, Sakari
> >>
>
Hi Kieran,
On Fri, Nov 02, 2018 at 12:27:11PM +, Kieran Bingham wrote:
> Hi Niklas, Sakari
>
> On 23/08/2018 14:25, Niklas Söderlund wrote:
> > From: Sakari Ailus
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > include/media/v4l2-subdev.h | 9
mera@53 {
> + compatible = "imi,rdacm20";
> + reg = <0x53 0x63>;
> + port {
> + rdacm20_out2: endpoint {
> + remote-endpoint =
> <&max9286_in2>;
> + };
> + };
> + };
> + };
> +
> + i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <3>;
> +
> + camera@54 {
> + compatible = "imi,rdacm20";
> + reg = <0x54 0x64>;
> + port {
> + rdacm20_out3: endpoint {
> + remote-endpoint =
> <&max9286_in3>;
> + };
> + };
> + };
> + };
> + };
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
* two VIN instances. The UDS can only be used by one VIN at a time,
> + * so the companion relationship needs to be described as well.
> + *
> + * There are at most two VINs sharing a UDS. For each UDS shared
> + * between two VINs there needs to be two instances of struct
> + * rvin_group_scaler describing each of the VINs individually. If
> + * a VIN do not share its UDS set companion to -1.
> + */
> +struct rvin_group_scaler {
> + int vin;
> + int companion;
> +};
> +
> /**
> * struct rvin_info - Information about the particular VIN implementation
> * @model: VIN model
> @@ -130,6 +152,7 @@ struct rvin_group_route {
> * @max_height: max input height the VIN supports
> * @routes: list of possible routes from the CSI-2 recivers to
> * all VINs. The list mush be NULL terminated.
> + * @scalers: List of available scalers, must be NULL terminated.
> */
> struct rvin_info {
> enum model_id model;
> @@ -138,6 +161,7 @@ struct rvin_info {
> unsigned int max_width;
> unsigned int max_height;
> const struct rvin_group_route *routes;
> + const struct rvin_group_scaler *scalers;
> };
>
> /**
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
>
> 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
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(&pdev->dev);
> > >
pm_runtime_enable(&pdev->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?
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().
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
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
Acked-by
L2_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 = &mt9t112_subdev_core_ops,
> + .video = &mt9t112_subdev_video_ops,
> + .pad= &mt9t112_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(&priv->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(&client->dev, "Product ID error %04x\n", chipid);
> + ret = -ENODEV;
> + goto done;
> + }
> +
> + dev_info(&client->dev, "%s chip ID %04x\n", devname, chipid);
> +
> +done:
> + mt9t112_s_power(&priv->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(&client->dev, "mt9t112: missing platform data!\n");
> + return -EINVAL;
> + }
> +
> + priv = devm_kzalloc(&client->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->info = ssdd->drv_priv;
> +
> + v4l2_i2c_subdev_init(&priv->subdev, client, &mt9t112_subdev_ops);
> +
> + priv->clk = v4l2_clk_get(&client->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, &rect, 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
> MT9V032 APTINA CAMERA SENSOR
> M: Laurent Pinchart
> L: linux-me...@vger.kernel.org
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
'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
> Signed-off-by: Niklas Söderlund
Acked-by: Sakari Ailus
> ---
> 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
>
> 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
*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
Acked-by: Sakari Ailus
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
he macro argument to 'media_entity'.
>
> Thanks!
> Given there also exists a "struct media_entity", using "_media_entity" seems
> safe to me.
That doesn't matter, does it? As long as the macro argument is used as a
field name of a struct. I.e. "__entity" would be fine, as well as "e". I'd
vote for __entity. :-)
In any case,
Acked-by: Sakari Ailus
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
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
definition is fine.
Acked-by: Sakari Ailus
>
> 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
ames = "default";
> + pinctrl-0 = <&vio_pins>;
> +
> + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <&ceu_in>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
d 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
A
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
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-
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 mov
; + 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
lwester Nawrocki
> Signed-off-by: Mauro Carvalho Chehab
I'm not sure this is needed but it doesn't break anything either.
Feel free to add:
Acked-by: Sakari Ailus
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
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 mo
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(&list_lock);
> >
> > INIT_LIST_HEAD(&sd->async_list);
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
y(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, &subdev_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(&list_lock);
>
> for (i = 0; i < notifier->num_subdevs; i++) {
> --
> 2.7.4
>
--
Sakari Ailus
sakari.ai...@linux.intel.com
2_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
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
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
node_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
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
; out:
> mutex_unlock(&priv->lock);
>
> @@ -919,7 +939,9 @@ static int rcar_csi2_probe(struct platform_device *pdev)
> priv->dev = &pdev->dev;
>
> mutex_init(&priv->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
l2_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(v
.pads, pipe))
> return -EPIPE;
>
> ret = v4l2_subdev_call(sd, video, s_stream, 1);
> if (ret == -ENOIOCTLCMD)
> ret = 0;
> if (ret)
> - media_pipeline_stop(&vin->vdev.entity);
> + media_pipeline_stop(vin->vdev.entity.pads);
>
> return ret;
> }
> --
> 2.15.1
>
--
Sakari Ailus
sakari.ai...@linux.intel.com
)(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
s. 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
kill the user space process using the device
instead? Naturally the wait will have to be interruptible.
...
> > > @@ -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?
>
> I'd love to, but refcount_t has no provision for refcounts that start at 0.
>
> void refcount_inc(refcount_t *r)
> {
> WARN_ONCE(!refcount_inc_not_zero(r), "refcount_t: increment on 0; use-
> after-free.\n");
> }
> EXPORT_SYMBOL(refcount_inc);
Ah. I wonder if you could simply initialise in probe and decrement it again
in remove?
You could use refcount_inc_not_zero directly, too.
>
> > > + spinlock_t unplug_lock;
> > > + wait_queue_head_t unplug_wait;
> > > +
> > > /* sysfs */
> > > struct device dev;
> > > struct cdev *cdev;
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Sakari Ailus
>
> ---
>
> 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 *jus
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
>
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 wro
;subdev.entity, NR_OF_RCAR_CSI2_PAD,
> > > + priv->pads);
> > > + if (ret)
> > > + goto error;
> > > +
> > > + ret = v4l2_async_register_subdev(&priv->subdev);
> > > + if (ret < 0)
> > > + goto error;
> > > +
> > > + pm_runtime_enable(&pdev->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
",
> + .data = &rcar_csi2_info_r8a7795,
> + },
> + {
> + .compatible = "renesas,r8a7796-csi2",
> + .data = &rcar_csi2_info_r8a7796,
> + },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, rcar_csi2_of_tabl
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
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(
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]
>
>
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,
> > >
to error_video_probe;
> +
> + return 0;
> +
> +error_video_probe:
> + if (priv->clk)
> + clk_put(priv->clk);
> +error_clk_enable:
> + v4l2_ctrl_handler_free(&priv->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(&priv->subdev);
> v4l2_ctrl_handler_free(&priv->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
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 th
video_device_unplug(&vin->vdev);
Does this depend on another patch?
>
> if (!vin->info->use_mc) {
> v4l2_async_notifier_unregister(&vin->notifier);
> --
> Regards,
>
> Laurent Pinchart
>
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
t; +/**
> + * 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
e) {
> + vbuf = &list_entry(buf_head, struct sh_mobile_ceu_buffer,
> +queue)->vb;
> + vb2_buffer_done(&vbuf->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(&pcdev->lock);
>
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
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 se
r 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
+ 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 = <&ceu_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
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
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 öve
tatic const struct of_device_id rcar_csi2_of_table[] = {
> + {
> + .compatible = "renesas,r8a7795-csi2",
> + .data = &rcar_csi2_info_r8a7795,
> + },
> + {
> + .compatible = "renesas,r8a7796-csi2",
> + .data = &rcar_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 = &rcar_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(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->info = of_device_get_match_data(&pdev->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 = &pdev->dev;
> +
> + mutex_init(&priv->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 = &pdev->dev;
> + v4l2_subdev_init(&priv->subdev, &rcar_csi2_subdev_ops);
> + v4l2_set_subdevdata(&priv->subdev, &pdev->dev);
> + snprintf(priv->subdev.name, V4L2_SUBDEV_NAME_SIZE, "%s %s",
> + KBUILD_MODNAME, dev_name(&pdev->dev));
> + priv->subdev.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
> +
> + priv->subdev.entity.function = MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;
> + priv->subdev.entity.ops = &rcar_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(&priv->subdev.entity, NR_OF_RCAR_CSI2_PAD,
> + priv->pads);
> + if (ret)
> + goto error;
> +
> + ret = v4l2_async_register_subdev(&priv->subdev);
> + if (ret < 0)
> + goto error;
> +
> + pm_runtime_enable(&pdev->dev);
> +
> + dev_info(priv->dev, "%d lanes found\n", priv->lanes);
> +
> + return 0;
> +
> +error:
> + v4l2_async_notifier_cleanup(&priv->notifier);
> +
> + return ret;
> +}
> +
> +static int rcar_csi2_remove(struct platform_device *pdev)
> +{
> + struct rcar_csi2 *priv = platform_get_drvdata(pdev);
> +
> + v4l2_async_notifier_cleanup(&priv->notifier);
> + v4l2_async_unregister_subdev(&priv->subdev);
> +
> + pm_runtime_disable(&pdev->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 ");
> +MODULE_DESCRIPTION("Renesas R-Car MIPI CSI-2 receiver");
> +MODULE_LICENSE("GPL v2");
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
};
> + csi20vin7: endpoint@7 {
> + reg = <7>;
> + remote-endpoint = <&vin7csi20>;
> + };
> + };
> + };
> + };
> 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
Hi Rob,
On Tue, Oct 03, 2017 at 08:40:10AM -0500, Rob Herring wrote:
> On Sun, Aug 27, 2017 at 5:40 PM, Sakari Ailus
> wrote:
> > 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öd
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 escreveu:
>
> > Hi Mauro,
> >
> > On Wed, Sep 27, 2017 at 06:46:56PM -0300, Mauro Carva
interface with that name, fwnode property API is just an API.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
interface with that name, fwnode property API is just an API.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
; >> > 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
> >> >
else
> - put_device(d);
> + dev[i++] = d;
> }
>
> mutex_unlock(&list_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
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:
> >>
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
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
1 - 100 of 191 matches
Mail list logo
