* [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-07-07 20:37 ` Sakari Ailus
2021-06-24 19:21 ` [PATCH v3 02/11] media: cadence: csi2rx: Unregister v4l2 async notifier Pratyush Yadav
` (10 subsequent siblings)
11 siblings, 1 reply; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Dongchun Zhu, Jacopo Mondi,
Kieran Bingham, Martina Krasteva, Paul Kocialkowski, Raag Jadav,
Sakari Ailus, Steve Longerbeam, Tianshu Qiu, linux-kernel,
linux-media
Calling s_power subdev callback is discouraged. Instead, the subdevs
should use runtime PM to control its power. Use runtime PM callbacks to
control sensor power. The pm counter is incremented when the stream is
started and decremented when the stream is stopped.
Refactor s_stream() a bit to make this new control flow easier. Add a
helper to choose whether mipi or dvp set_stream needs to be called. The
logic flow is also changed to make it a bit clearer.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
Changes in v3:
- Clean up the logic in ov5640_s_stream() a bit.
- Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().
- Rename the label error_pm to disable_pm.
Changes in v2:
- New in v2.
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/ov5640.c | 127 +++++++++++++++++++++++--------------
2 files changed, 79 insertions(+), 50 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 588f8eb95984..8f43a4d7bcc1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -929,7 +929,7 @@ config VIDEO_OV2740
config VIDEO_OV5640
tristate "OmniVision OV5640 sensor support"
- depends on OF
+ depends on OF && PM
depends on GPIOLIB && VIDEO_V4L2 && I2C
select MEDIA_CONTROLLER
select VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index f6e1e51e0375..2b7fd8631ad1 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -15,6 +15,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/of_device.h>
+#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/types.h>
@@ -238,8 +239,6 @@ struct ov5640_dev {
/* lock to protect all members below */
struct mutex lock;
- int power_count;
-
struct v4l2_mbus_framefmt fmt;
bool pending_fmt_change;
@@ -1277,6 +1276,14 @@ static int ov5640_set_stream_mipi(struct ov5640_dev *sensor, bool on)
on ? 0x00 : 0x0f);
}
+static int ov5640_set_stream(struct ov5640_dev *sensor, bool on)
+{
+ if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
+ return ov5640_set_stream_mipi(sensor, on);
+ else
+ return ov5640_set_stream_dvp(sensor, on);
+}
+
static int ov5640_get_sysclk(struct ov5640_dev *sensor)
{
/* calculate sysclk */
@@ -2155,37 +2162,6 @@ static int ov5640_set_power(struct ov5640_dev *sensor, bool on)
/* --------------- Subdev Operations --------------- */
-static int ov5640_s_power(struct v4l2_subdev *sd, int on)
-{
- struct ov5640_dev *sensor = to_ov5640_dev(sd);
- int ret = 0;
-
- mutex_lock(&sensor->lock);
-
- /*
- * If the power count is modified from 0 to != 0 or from != 0 to 0,
- * update the power state.
- */
- if (sensor->power_count == !on) {
- ret = ov5640_set_power(sensor, !!on);
- if (ret)
- goto out;
- }
-
- /* Update the power count. */
- sensor->power_count += on ? 1 : -1;
- WARN_ON(sensor->power_count < 0);
-out:
- mutex_unlock(&sensor->lock);
-
- if (on && !ret && sensor->power_count == 1) {
- /* restore controls */
- ret = v4l2_ctrl_handler_setup(&sensor->ctrls.handler);
- }
-
- return ret;
-}
-
static int ov5640_try_frame_interval(struct ov5640_dev *sensor,
struct v4l2_fract *fi,
u32 width, u32 height)
@@ -2681,6 +2657,7 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
struct ov5640_dev *sensor = to_ov5640_dev(sd);
+ struct device *dev = &sensor->i2c_client->dev;
int ret;
/* v4l2_ctrl_lock() locks our own mutex */
@@ -2690,7 +2667,7 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
* not apply any controls to H/W at this time. Instead
* the controls will be restored right after power-up.
*/
- if (sensor->power_count == 0)
+ if (pm_runtime_suspended(dev))
return 0;
switch (ctrl->id) {
@@ -2939,39 +2916,57 @@ static int ov5640_enum_mbus_code(struct v4l2_subdev *sd,
static int ov5640_s_stream(struct v4l2_subdev *sd, int enable)
{
struct ov5640_dev *sensor = to_ov5640_dev(sd);
+ struct device *dev = &sensor->i2c_client->dev;
int ret = 0;
mutex_lock(&sensor->lock);
- if (sensor->streaming == !enable) {
- if (enable && sensor->pending_mode_change) {
+ if (sensor->streaming == enable) {
+ mutex_unlock(&sensor->lock);
+ return 0;
+ }
+
+ if (enable) {
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret < 0)
+ goto err;
+
+ if (sensor->pending_mode_change) {
ret = ov5640_set_mode(sensor);
if (ret)
- goto out;
+ goto put_pm;
}
- if (enable && sensor->pending_fmt_change) {
+ if (sensor->pending_fmt_change) {
ret = ov5640_set_framefmt(sensor, &sensor->fmt);
if (ret)
- goto out;
+ goto put_pm;
sensor->pending_fmt_change = false;
}
- if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
- ret = ov5640_set_stream_mipi(sensor, enable);
- else
- ret = ov5640_set_stream_dvp(sensor, enable);
+ ret = ov5640_set_stream(sensor, true);
+ if (ret)
+ goto put_pm;
+ } else {
+ ret = ov5640_set_stream(sensor, false);
+ if (ret)
+ goto err;
- if (!ret)
- sensor->streaming = enable;
+ pm_runtime_put(dev);
}
-out:
+
+ sensor->streaming = enable;
+ mutex_unlock(&sensor->lock);
+ return 0;
+
+put_pm:
+ pm_runtime_put(dev);
+err:
mutex_unlock(&sensor->lock);
return ret;
}
static const struct v4l2_subdev_core_ops ov5640_core_ops = {
- .s_power = ov5640_s_power,
.log_status = v4l2_ctrl_subdev_log_status,
.subscribe_event = v4l2_ctrl_subdev_subscribe_event,
.unsubscribe_event = v4l2_event_subdev_unsubscribe,
@@ -3037,6 +3032,29 @@ static int ov5640_check_chip_id(struct ov5640_dev *sensor)
return ret;
}
+static int ov5640_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *subdev = i2c_get_clientdata(client);
+ struct ov5640_dev *sensor = to_ov5640_dev(subdev);
+
+ return ov5640_set_power(sensor, false);
+}
+
+static int ov5640_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *subdev = i2c_get_clientdata(client);
+ struct ov5640_dev *sensor = to_ov5640_dev(subdev);
+ int ret = 0;
+
+ ret = ov5640_set_power(sensor, true);
+ if (ret)
+ return ret;
+
+ return __v4l2_ctrl_handler_setup(&sensor->ctrls.handler);
+}
+
static int ov5640_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
@@ -3162,13 +3180,17 @@ static int ov5640_probe(struct i2c_client *client)
if (ret)
goto entity_cleanup;
+ pm_runtime_enable(dev);
+ pm_runtime_set_suspended(dev);
+
ret = v4l2_async_register_subdev_sensor(&sensor->sd);
if (ret)
- goto free_ctrls;
+ goto pm_disable;
return 0;
-free_ctrls:
+pm_disable:
+ pm_runtime_disable(dev);
v4l2_ctrl_handler_free(&sensor->ctrls.handler);
entity_cleanup:
media_entity_cleanup(&sensor->sd.entity);
@@ -3178,17 +3200,23 @@ static int ov5640_probe(struct i2c_client *client)
static int ov5640_remove(struct i2c_client *client)
{
+ struct device *dev = &client->dev;
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct ov5640_dev *sensor = to_ov5640_dev(sd);
v4l2_async_unregister_subdev(&sensor->sd);
media_entity_cleanup(&sensor->sd.entity);
+ pm_runtime_disable(dev);
v4l2_ctrl_handler_free(&sensor->ctrls.handler);
mutex_destroy(&sensor->lock);
return 0;
}
+static const struct dev_pm_ops ov5640_pm_ops = {
+ SET_RUNTIME_PM_OPS(ov5640_suspend, ov5640_resume, NULL)
+};
+
static const struct i2c_device_id ov5640_id[] = {
{"ov5640", 0},
{},
@@ -3205,6 +3233,7 @@ static struct i2c_driver ov5640_i2c_driver = {
.driver = {
.name = "ov5640",
.of_match_table = ov5640_dt_ids,
+ .pm = &ov5640_pm_ops,
},
.id_table = ov5640_id,
.probe_new = ov5640_probe,
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power
2021-06-24 19:21 ` [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power Pratyush Yadav
@ 2021-07-07 20:37 ` Sakari Ailus
2021-07-07 21:00 ` Laurent Pinchart
0 siblings, 1 reply; 26+ messages in thread
From: Sakari Ailus @ 2021-07-07 20:37 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Vignesh Raghavendra,
Tomi Valkeinen, Nikhil Devshatwar, Dongchun Zhu, Jacopo Mondi,
Kieran Bingham, Martina Krasteva, Paul Kocialkowski, Raag Jadav,
Steve Longerbeam, Tianshu Qiu, linux-kernel, linux-media
Hi Pratyush,
Thanks for the patch.
On Fri, Jun 25, 2021 at 12:51:50AM +0530, Pratyush Yadav wrote:
> Calling s_power subdev callback is discouraged. Instead, the subdevs
> should use runtime PM to control its power. Use runtime PM callbacks to
> control sensor power. The pm counter is incremented when the stream is
> started and decremented when the stream is stopped.
>
> Refactor s_stream() a bit to make this new control flow easier. Add a
> helper to choose whether mipi or dvp set_stream needs to be called. The
> logic flow is also changed to make it a bit clearer.
>
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
>
> ---
>
> Changes in v3:
> - Clean up the logic in ov5640_s_stream() a bit.
> - Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().
> - Rename the label error_pm to disable_pm.
>
> Changes in v2:
> - New in v2.
>
> drivers/media/i2c/Kconfig | 2 +-
> drivers/media/i2c/ov5640.c | 127 +++++++++++++++++++++++--------------
> 2 files changed, 79 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 588f8eb95984..8f43a4d7bcc1 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -929,7 +929,7 @@ config VIDEO_OV2740
>
> config VIDEO_OV5640
> tristate "OmniVision OV5640 sensor support"
> - depends on OF
> + depends on OF && PM
Could you add support for runtime PM without requiring CONFIG_PM?
Essentially you'll need to power on the device in probe and power it off in
probe, and make sure the runtime PM nop variant functions return the value
you'd expect.
The ov5640_check_chip_id() function also calls ov5640_set_power() directly.
That needs to be changed, too.
> depends on GPIOLIB && VIDEO_V4L2 && I2C
> select MEDIA_CONTROLLER
> select VIDEO_V4L2_SUBDEV_API
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index f6e1e51e0375..2b7fd8631ad1 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -15,6 +15,7 @@
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/of_device.h>
> +#include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
> #include <linux/types.h>
> @@ -238,8 +239,6 @@ struct ov5640_dev {
> /* lock to protect all members below */
> struct mutex lock;
>
> - int power_count;
> -
> struct v4l2_mbus_framefmt fmt;
> bool pending_fmt_change;
>
> @@ -1277,6 +1276,14 @@ static int ov5640_set_stream_mipi(struct ov5640_dev *sensor, bool on)
> on ? 0x00 : 0x0f);
> }
>
> +static int ov5640_set_stream(struct ov5640_dev *sensor, bool on)
> +{
> + if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
> + return ov5640_set_stream_mipi(sensor, on);
> + else
> + return ov5640_set_stream_dvp(sensor, on);
> +}
> +
> static int ov5640_get_sysclk(struct ov5640_dev *sensor)
> {
> /* calculate sysclk */
> @@ -2155,37 +2162,6 @@ static int ov5640_set_power(struct ov5640_dev *sensor, bool on)
>
> /* --------------- Subdev Operations --------------- */
>
> -static int ov5640_s_power(struct v4l2_subdev *sd, int on)
> -{
> - struct ov5640_dev *sensor = to_ov5640_dev(sd);
> - int ret = 0;
> -
> - mutex_lock(&sensor->lock);
> -
> - /*
> - * If the power count is modified from 0 to != 0 or from != 0 to 0,
> - * update the power state.
> - */
> - if (sensor->power_count == !on) {
> - ret = ov5640_set_power(sensor, !!on);
> - if (ret)
> - goto out;
> - }
> -
> - /* Update the power count. */
> - sensor->power_count += on ? 1 : -1;
> - WARN_ON(sensor->power_count < 0);
> -out:
> - mutex_unlock(&sensor->lock);
> -
> - if (on && !ret && sensor->power_count == 1) {
> - /* restore controls */
> - ret = v4l2_ctrl_handler_setup(&sensor->ctrls.handler);
> - }
> -
> - return ret;
> -}
> -
> static int ov5640_try_frame_interval(struct ov5640_dev *sensor,
> struct v4l2_fract *fi,
> u32 width, u32 height)
> @@ -2681,6 +2657,7 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
> {
> struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
> struct ov5640_dev *sensor = to_ov5640_dev(sd);
> + struct device *dev = &sensor->i2c_client->dev;
> int ret;
>
> /* v4l2_ctrl_lock() locks our own mutex */
> @@ -2690,7 +2667,7 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
> * not apply any controls to H/W at this time. Instead
> * the controls will be restored right after power-up.
> */
> - if (sensor->power_count == 0)
> + if (pm_runtime_suspended(dev))
The problem with this is that it does not prevent powering the device off
while you're here. Please use pm_runtime_get_if_active() instead (see other
drivers for examples).
> return 0;
>
> switch (ctrl->id) {
> @@ -2939,39 +2916,57 @@ static int ov5640_enum_mbus_code(struct v4l2_subdev *sd,
> static int ov5640_s_stream(struct v4l2_subdev *sd, int enable)
> {
> struct ov5640_dev *sensor = to_ov5640_dev(sd);
> + struct device *dev = &sensor->i2c_client->dev;
> int ret = 0;
>
> mutex_lock(&sensor->lock);
>
> - if (sensor->streaming == !enable) {
> - if (enable && sensor->pending_mode_change) {
> + if (sensor->streaming == enable) {
> + mutex_unlock(&sensor->lock);
> + return 0;
> + }
> +
> + if (enable) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret < 0)
> + goto err;
> +
> + if (sensor->pending_mode_change) {
> ret = ov5640_set_mode(sensor);
> if (ret)
> - goto out;
> + goto put_pm;
> }
>
> - if (enable && sensor->pending_fmt_change) {
> + if (sensor->pending_fmt_change) {
> ret = ov5640_set_framefmt(sensor, &sensor->fmt);
> if (ret)
> - goto out;
> + goto put_pm;
> sensor->pending_fmt_change = false;
> }
>
> - if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
> - ret = ov5640_set_stream_mipi(sensor, enable);
> - else
> - ret = ov5640_set_stream_dvp(sensor, enable);
> + ret = ov5640_set_stream(sensor, true);
> + if (ret)
> + goto put_pm;
> + } else {
> + ret = ov5640_set_stream(sensor, false);
> + if (ret)
> + goto err;
>
> - if (!ret)
> - sensor->streaming = enable;
> + pm_runtime_put(dev);
> }
> -out:
> +
> + sensor->streaming = enable;
> + mutex_unlock(&sensor->lock);
> + return 0;
> +
> +put_pm:
> + pm_runtime_put(dev);
> +err:
> mutex_unlock(&sensor->lock);
> return ret;
> }
>
> static const struct v4l2_subdev_core_ops ov5640_core_ops = {
> - .s_power = ov5640_s_power,
Nice!
> .log_status = v4l2_ctrl_subdev_log_status,
> .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
> .unsubscribe_event = v4l2_event_subdev_unsubscribe,
> @@ -3037,6 +3032,29 @@ static int ov5640_check_chip_id(struct ov5640_dev *sensor)
> return ret;
> }
>
> +static int ov5640_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *subdev = i2c_get_clientdata(client);
> + struct ov5640_dev *sensor = to_ov5640_dev(subdev);
> +
> + return ov5640_set_power(sensor, false);
> +}
> +
> +static int ov5640_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *subdev = i2c_get_clientdata(client);
> + struct ov5640_dev *sensor = to_ov5640_dev(subdev);
> + int ret = 0;
> +
> + ret = ov5640_set_power(sensor, true);
> + if (ret)
> + return ret;
> +
> + return __v4l2_ctrl_handler_setup(&sensor->ctrls.handler);
This should be done by the ov5640_set_power() function --- there's no
guarantee the sensor will be powered off after probe before someone tries
to use it.
In fact, it would be nicer to split ov5640_set_power() in two. There's
little need for the convoluted calling of power management functions in
this driver. (Almost all sensor drivers have one to power the sensor off
and another to power it on.)
> +}
> +
> static int ov5640_probe(struct i2c_client *client)
> {
> struct device *dev = &client->dev;
> @@ -3162,13 +3180,17 @@ static int ov5640_probe(struct i2c_client *client)
> if (ret)
> goto entity_cleanup;
>
> + pm_runtime_enable(dev);
> + pm_runtime_set_suspended(dev);
You could also do this after registering the subdev below --- less error
handling that way.
See e.g. the imx355 driver for an example in what to do at the end of
probe. The idea is runtime PM is used to turn the sensor off if it's
enabled while the driver turns it on independently of runtime PM.
> +
> ret = v4l2_async_register_subdev_sensor(&sensor->sd);
> if (ret)
> - goto free_ctrls;
> + goto pm_disable;
>
> return 0;
>
> -free_ctrls:
> +pm_disable:
> + pm_runtime_disable(dev);
> v4l2_ctrl_handler_free(&sensor->ctrls.handler);
> entity_cleanup:
> media_entity_cleanup(&sensor->sd.entity);
> @@ -3178,17 +3200,23 @@ static int ov5640_probe(struct i2c_client *client)
>
> static int ov5640_remove(struct i2c_client *client)
> {
> + struct device *dev = &client->dev;
> struct v4l2_subdev *sd = i2c_get_clientdata(client);
> struct ov5640_dev *sensor = to_ov5640_dev(sd);
>
> v4l2_async_unregister_subdev(&sensor->sd);
> media_entity_cleanup(&sensor->sd.entity);
> + pm_runtime_disable(dev);
> v4l2_ctrl_handler_free(&sensor->ctrls.handler);
> mutex_destroy(&sensor->lock);
>
> return 0;
> }
>
> +static const struct dev_pm_ops ov5640_pm_ops = {
> + SET_RUNTIME_PM_OPS(ov5640_suspend, ov5640_resume, NULL)
> +};
> +
> static const struct i2c_device_id ov5640_id[] = {
> {"ov5640", 0},
> {},
> @@ -3205,6 +3233,7 @@ static struct i2c_driver ov5640_i2c_driver = {
> .driver = {
> .name = "ov5640",
> .of_match_table = ov5640_dt_ids,
> + .pm = &ov5640_pm_ops,
> },
> .id_table = ov5640_id,
> .probe_new = ov5640_probe,
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power
2021-07-07 20:37 ` Sakari Ailus
@ 2021-07-07 21:00 ` Laurent Pinchart
2021-07-07 21:44 ` Sakari Ailus
0 siblings, 1 reply; 26+ messages in thread
From: Laurent Pinchart @ 2021-07-07 21:00 UTC (permalink / raw)
To: Sakari Ailus
Cc: Pratyush Yadav, Mauro Carvalho Chehab, Vignesh Raghavendra,
Tomi Valkeinen, Nikhil Devshatwar, Dongchun Zhu, Jacopo Mondi,
Kieran Bingham, Martina Krasteva, Paul Kocialkowski, Raag Jadav,
Steve Longerbeam, Tianshu Qiu, linux-kernel, linux-media
Hi Sakari,
On Wed, Jul 07, 2021 at 11:37:18PM +0300, Sakari Ailus wrote:
> On Fri, Jun 25, 2021 at 12:51:50AM +0530, Pratyush Yadav wrote:
> > Calling s_power subdev callback is discouraged. Instead, the subdevs
> > should use runtime PM to control its power. Use runtime PM callbacks to
> > control sensor power. The pm counter is incremented when the stream is
> > started and decremented when the stream is stopped.
> >
> > Refactor s_stream() a bit to make this new control flow easier. Add a
> > helper to choose whether mipi or dvp set_stream needs to be called. The
> > logic flow is also changed to make it a bit clearer.
> >
> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> >
> > ---
> >
> > Changes in v3:
> > - Clean up the logic in ov5640_s_stream() a bit.
> > - Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().
> > - Rename the label error_pm to disable_pm.
> >
> > Changes in v2:
> > - New in v2.
> >
> > drivers/media/i2c/Kconfig | 2 +-
> > drivers/media/i2c/ov5640.c | 127 +++++++++++++++++++++++--------------
> > 2 files changed, 79 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index 588f8eb95984..8f43a4d7bcc1 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -929,7 +929,7 @@ config VIDEO_OV2740
> >
> > config VIDEO_OV5640
> > tristate "OmniVision OV5640 sensor support"
> > - depends on OF
> > + depends on OF && PM
>
> Could you add support for runtime PM without requiring CONFIG_PM?
>
> Essentially you'll need to power on the device in probe and power it off in
> probe, and make sure the runtime PM nop variant functions return the value
> you'd expect.
I've gone through that in several sensor drivers, and it really
increases the complexity to get it right, to a point where I'm not
comfortable asking someone to do the same (not to mention the very, very
high chance that it won't be done correctly). What's the practical
drawback in requiring CONFIG_PM ?
> The ov5640_check_chip_id() function also calls ov5640_set_power() directly.
> That needs to be changed, too.
>
> > depends on GPIOLIB && VIDEO_V4L2 && I2C
> > select MEDIA_CONTROLLER
> > select VIDEO_V4L2_SUBDEV_API
> > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > index f6e1e51e0375..2b7fd8631ad1 100644
> > --- a/drivers/media/i2c/ov5640.c
> > +++ b/drivers/media/i2c/ov5640.c
> > @@ -15,6 +15,7 @@
> > #include <linux/init.h>
> > #include <linux/module.h>
> > #include <linux/of_device.h>
> > +#include <linux/pm_runtime.h>
> > #include <linux/regulator/consumer.h>
> > #include <linux/slab.h>
> > #include <linux/types.h>
> > @@ -238,8 +239,6 @@ struct ov5640_dev {
> > /* lock to protect all members below */
> > struct mutex lock;
> >
> > - int power_count;
> > -
> > struct v4l2_mbus_framefmt fmt;
> > bool pending_fmt_change;
> >
> > @@ -1277,6 +1276,14 @@ static int ov5640_set_stream_mipi(struct ov5640_dev *sensor, bool on)
> > on ? 0x00 : 0x0f);
> > }
> >
> > +static int ov5640_set_stream(struct ov5640_dev *sensor, bool on)
> > +{
> > + if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
> > + return ov5640_set_stream_mipi(sensor, on);
> > + else
> > + return ov5640_set_stream_dvp(sensor, on);
> > +}
> > +
> > static int ov5640_get_sysclk(struct ov5640_dev *sensor)
> > {
> > /* calculate sysclk */
> > @@ -2155,37 +2162,6 @@ static int ov5640_set_power(struct ov5640_dev *sensor, bool on)
> >
> > /* --------------- Subdev Operations --------------- */
> >
> > -static int ov5640_s_power(struct v4l2_subdev *sd, int on)
> > -{
> > - struct ov5640_dev *sensor = to_ov5640_dev(sd);
> > - int ret = 0;
> > -
> > - mutex_lock(&sensor->lock);
> > -
> > - /*
> > - * If the power count is modified from 0 to != 0 or from != 0 to 0,
> > - * update the power state.
> > - */
> > - if (sensor->power_count == !on) {
> > - ret = ov5640_set_power(sensor, !!on);
> > - if (ret)
> > - goto out;
> > - }
> > -
> > - /* Update the power count. */
> > - sensor->power_count += on ? 1 : -1;
> > - WARN_ON(sensor->power_count < 0);
> > -out:
> > - mutex_unlock(&sensor->lock);
> > -
> > - if (on && !ret && sensor->power_count == 1) {
> > - /* restore controls */
> > - ret = v4l2_ctrl_handler_setup(&sensor->ctrls.handler);
> > - }
> > -
> > - return ret;
> > -}
> > -
> > static int ov5640_try_frame_interval(struct ov5640_dev *sensor,
> > struct v4l2_fract *fi,
> > u32 width, u32 height)
> > @@ -2681,6 +2657,7 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
> > {
> > struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
> > struct ov5640_dev *sensor = to_ov5640_dev(sd);
> > + struct device *dev = &sensor->i2c_client->dev;
> > int ret;
> >
> > /* v4l2_ctrl_lock() locks our own mutex */
> > @@ -2690,7 +2667,7 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
> > * not apply any controls to H/W at this time. Instead
> > * the controls will be restored right after power-up.
> > */
> > - if (sensor->power_count == 0)
> > + if (pm_runtime_suspended(dev))
>
> The problem with this is that it does not prevent powering the device off
> while you're here. Please use pm_runtime_get_if_active() instead (see other
> drivers for examples).
>
> > return 0;
> >
> > switch (ctrl->id) {
> > @@ -2939,39 +2916,57 @@ static int ov5640_enum_mbus_code(struct v4l2_subdev *sd,
> > static int ov5640_s_stream(struct v4l2_subdev *sd, int enable)
> > {
> > struct ov5640_dev *sensor = to_ov5640_dev(sd);
> > + struct device *dev = &sensor->i2c_client->dev;
> > int ret = 0;
> >
> > mutex_lock(&sensor->lock);
> >
> > - if (sensor->streaming == !enable) {
> > - if (enable && sensor->pending_mode_change) {
> > + if (sensor->streaming == enable) {
> > + mutex_unlock(&sensor->lock);
> > + return 0;
> > + }
> > +
> > + if (enable) {
> > + ret = pm_runtime_resume_and_get(dev);
> > + if (ret < 0)
> > + goto err;
> > +
> > + if (sensor->pending_mode_change) {
> > ret = ov5640_set_mode(sensor);
> > if (ret)
> > - goto out;
> > + goto put_pm;
> > }
> >
> > - if (enable && sensor->pending_fmt_change) {
> > + if (sensor->pending_fmt_change) {
> > ret = ov5640_set_framefmt(sensor, &sensor->fmt);
> > if (ret)
> > - goto out;
> > + goto put_pm;
> > sensor->pending_fmt_change = false;
> > }
> >
> > - if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
> > - ret = ov5640_set_stream_mipi(sensor, enable);
> > - else
> > - ret = ov5640_set_stream_dvp(sensor, enable);
> > + ret = ov5640_set_stream(sensor, true);
> > + if (ret)
> > + goto put_pm;
> > + } else {
> > + ret = ov5640_set_stream(sensor, false);
> > + if (ret)
> > + goto err;
> >
> > - if (!ret)
> > - sensor->streaming = enable;
> > + pm_runtime_put(dev);
> > }
> > -out:
> > +
> > + sensor->streaming = enable;
> > + mutex_unlock(&sensor->lock);
> > + return 0;
> > +
> > +put_pm:
> > + pm_runtime_put(dev);
> > +err:
> > mutex_unlock(&sensor->lock);
> > return ret;
> > }
> >
> > static const struct v4l2_subdev_core_ops ov5640_core_ops = {
> > - .s_power = ov5640_s_power,
>
> Nice!
>
> > .log_status = v4l2_ctrl_subdev_log_status,
> > .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
> > .unsubscribe_event = v4l2_event_subdev_unsubscribe,
> > @@ -3037,6 +3032,29 @@ static int ov5640_check_chip_id(struct ov5640_dev *sensor)
> > return ret;
> > }
> >
> > +static int ov5640_suspend(struct device *dev)
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct v4l2_subdev *subdev = i2c_get_clientdata(client);
> > + struct ov5640_dev *sensor = to_ov5640_dev(subdev);
> > +
> > + return ov5640_set_power(sensor, false);
> > +}
> > +
> > +static int ov5640_resume(struct device *dev)
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct v4l2_subdev *subdev = i2c_get_clientdata(client);
> > + struct ov5640_dev *sensor = to_ov5640_dev(subdev);
> > + int ret = 0;
> > +
> > + ret = ov5640_set_power(sensor, true);
> > + if (ret)
> > + return ret;
> > +
> > + return __v4l2_ctrl_handler_setup(&sensor->ctrls.handler);
>
> This should be done by the ov5640_set_power() function --- there's no
> guarantee the sensor will be powered off after probe before someone tries
> to use it.
>
> In fact, it would be nicer to split ov5640_set_power() in two. There's
> little need for the convoluted calling of power management functions in
> this driver. (Almost all sensor drivers have one to power the sensor off
> and another to power it on.)
>
> > +}
> > +
> > static int ov5640_probe(struct i2c_client *client)
> > {
> > struct device *dev = &client->dev;
> > @@ -3162,13 +3180,17 @@ static int ov5640_probe(struct i2c_client *client)
> > if (ret)
> > goto entity_cleanup;
> >
> > + pm_runtime_enable(dev);
> > + pm_runtime_set_suspended(dev);
>
> You could also do this after registering the subdev below --- less error
> handling that way.
>
> See e.g. the imx355 driver for an example in what to do at the end of
> probe. The idea is runtime PM is used to turn the sensor off if it's
> enabled while the driver turns it on independently of runtime PM.
>
> > +
> > ret = v4l2_async_register_subdev_sensor(&sensor->sd);
> > if (ret)
> > - goto free_ctrls;
> > + goto pm_disable;
> >
> > return 0;
> >
> > -free_ctrls:
> > +pm_disable:
> > + pm_runtime_disable(dev);
> > v4l2_ctrl_handler_free(&sensor->ctrls.handler);
> > entity_cleanup:
> > media_entity_cleanup(&sensor->sd.entity);
> > @@ -3178,17 +3200,23 @@ static int ov5640_probe(struct i2c_client *client)
> >
> > static int ov5640_remove(struct i2c_client *client)
> > {
> > + struct device *dev = &client->dev;
> > struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > struct ov5640_dev *sensor = to_ov5640_dev(sd);
> >
> > v4l2_async_unregister_subdev(&sensor->sd);
> > media_entity_cleanup(&sensor->sd.entity);
> > + pm_runtime_disable(dev);
> > v4l2_ctrl_handler_free(&sensor->ctrls.handler);
> > mutex_destroy(&sensor->lock);
> >
> > return 0;
> > }
> >
> > +static const struct dev_pm_ops ov5640_pm_ops = {
> > + SET_RUNTIME_PM_OPS(ov5640_suspend, ov5640_resume, NULL)
> > +};
> > +
> > static const struct i2c_device_id ov5640_id[] = {
> > {"ov5640", 0},
> > {},
> > @@ -3205,6 +3233,7 @@ static struct i2c_driver ov5640_i2c_driver = {
> > .driver = {
> > .name = "ov5640",
> > .of_match_table = ov5640_dt_ids,
> > + .pm = &ov5640_pm_ops,
> > },
> > .id_table = ov5640_id,
> > .probe_new = ov5640_probe,
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power
2021-07-07 21:00 ` Laurent Pinchart
@ 2021-07-07 21:44 ` Sakari Ailus
2021-07-07 21:51 ` Laurent Pinchart
0 siblings, 1 reply; 26+ messages in thread
From: Sakari Ailus @ 2021-07-07 21:44 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Pratyush Yadav, Mauro Carvalho Chehab, Vignesh Raghavendra,
Tomi Valkeinen, Nikhil Devshatwar, Dongchun Zhu, Jacopo Mondi,
Kieran Bingham, Martina Krasteva, Paul Kocialkowski, Raag Jadav,
Steve Longerbeam, Tianshu Qiu, linux-kernel, linux-media
Hi Laurent,
On Thu, Jul 08, 2021 at 12:00:57AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Wed, Jul 07, 2021 at 11:37:18PM +0300, Sakari Ailus wrote:
> > On Fri, Jun 25, 2021 at 12:51:50AM +0530, Pratyush Yadav wrote:
> > > Calling s_power subdev callback is discouraged. Instead, the subdevs
> > > should use runtime PM to control its power. Use runtime PM callbacks to
> > > control sensor power. The pm counter is incremented when the stream is
> > > started and decremented when the stream is stopped.
> > >
> > > Refactor s_stream() a bit to make this new control flow easier. Add a
> > > helper to choose whether mipi or dvp set_stream needs to be called. The
> > > logic flow is also changed to make it a bit clearer.
> > >
> > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > >
> > > ---
> > >
> > > Changes in v3:
> > > - Clean up the logic in ov5640_s_stream() a bit.
> > > - Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().
> > > - Rename the label error_pm to disable_pm.
> > >
> > > Changes in v2:
> > > - New in v2.
> > >
> > > drivers/media/i2c/Kconfig | 2 +-
> > > drivers/media/i2c/ov5640.c | 127 +++++++++++++++++++++++--------------
> > > 2 files changed, 79 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > index 588f8eb95984..8f43a4d7bcc1 100644
> > > --- a/drivers/media/i2c/Kconfig
> > > +++ b/drivers/media/i2c/Kconfig
> > > @@ -929,7 +929,7 @@ config VIDEO_OV2740
> > >
> > > config VIDEO_OV5640
> > > tristate "OmniVision OV5640 sensor support"
> > > - depends on OF
> > > + depends on OF && PM
> >
> > Could you add support for runtime PM without requiring CONFIG_PM?
> >
> > Essentially you'll need to power on the device in probe and power it off in
> > probe, and make sure the runtime PM nop variant functions return the value
> > you'd expect.
>
> I've gone through that in several sensor drivers, and it really
> increases the complexity to get it right, to a point where I'm not
> comfortable asking someone to do the same (not to mention the very, very
I don't think it's very complicated, really. Looking at examples of other
drivers (e.g. imx334) doing exactly the same helps as you don't need to
check for individual functions.
The complexity of the power management in this driver is mostly because of
evolutionary development done over time, it's an old driver.
> high chance that it won't be done correctly). What's the practical
> drawback in requiring CONFIG_PM ?
Good question. CONFIG_PM is something you can disable (for a reason I can't
think of though). Why should a driver depend on it when it could perfectly
work without it as well?
Although this might not amount to a practical drawback. :-)
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power
2021-07-07 21:44 ` Sakari Ailus
@ 2021-07-07 21:51 ` Laurent Pinchart
2021-07-08 10:28 ` Sakari Ailus
0 siblings, 1 reply; 26+ messages in thread
From: Laurent Pinchart @ 2021-07-07 21:51 UTC (permalink / raw)
To: Sakari Ailus
Cc: Pratyush Yadav, Mauro Carvalho Chehab, Vignesh Raghavendra,
Tomi Valkeinen, Nikhil Devshatwar, Dongchun Zhu, Jacopo Mondi,
Kieran Bingham, Martina Krasteva, Paul Kocialkowski, Raag Jadav,
Steve Longerbeam, Tianshu Qiu, linux-kernel, linux-media
Hi Sakari,
On Thu, Jul 08, 2021 at 12:44:15AM +0300, Sakari Ailus wrote:
> On Thu, Jul 08, 2021 at 12:00:57AM +0300, Laurent Pinchart wrote:
> > On Wed, Jul 07, 2021 at 11:37:18PM +0300, Sakari Ailus wrote:
> > > On Fri, Jun 25, 2021 at 12:51:50AM +0530, Pratyush Yadav wrote:
> > > > Calling s_power subdev callback is discouraged. Instead, the subdevs
> > > > should use runtime PM to control its power. Use runtime PM callbacks to
> > > > control sensor power. The pm counter is incremented when the stream is
> > > > started and decremented when the stream is stopped.
> > > >
> > > > Refactor s_stream() a bit to make this new control flow easier. Add a
> > > > helper to choose whether mipi or dvp set_stream needs to be called. The
> > > > logic flow is also changed to make it a bit clearer.
> > > >
> > > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > > >
> > > > ---
> > > >
> > > > Changes in v3:
> > > > - Clean up the logic in ov5640_s_stream() a bit.
> > > > - Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().
> > > > - Rename the label error_pm to disable_pm.
> > > >
> > > > Changes in v2:
> > > > - New in v2.
> > > >
> > > > drivers/media/i2c/Kconfig | 2 +-
> > > > drivers/media/i2c/ov5640.c | 127 +++++++++++++++++++++++--------------
> > > > 2 files changed, 79 insertions(+), 50 deletions(-)
> > > >
> > > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > > index 588f8eb95984..8f43a4d7bcc1 100644
> > > > --- a/drivers/media/i2c/Kconfig
> > > > +++ b/drivers/media/i2c/Kconfig
> > > > @@ -929,7 +929,7 @@ config VIDEO_OV2740
> > > >
> > > > config VIDEO_OV5640
> > > > tristate "OmniVision OV5640 sensor support"
> > > > - depends on OF
> > > > + depends on OF && PM
> > >
> > > Could you add support for runtime PM without requiring CONFIG_PM?
> > >
> > > Essentially you'll need to power on the device in probe and power it off in
> > > probe, and make sure the runtime PM nop variant functions return the value
> > > you'd expect.
> >
> > I've gone through that in several sensor drivers, and it really
> > increases the complexity to get it right, to a point where I'm not
> > comfortable asking someone to do the same (not to mention the very, very
>
> I don't think it's very complicated, really. Looking at examples of other
> drivers (e.g. imx334) doing exactly the same helps as you don't need to
> check for individual functions.
>
> The complexity of the power management in this driver is mostly because of
> evolutionary development done over time, it's an old driver.
https://git.linuxtv.org/pinchartl/media.git/commit/?h=sensors/ar0330/driver&id=e72ca23c4c6b1ab6b06ac48280726e09d63cc818
Look at the changes to ar0330_probe(). As far as I understand, anything
less than that would be incorrect, and it's way too easy to get it
wrong.
> > high chance that it won't be done correctly). What's the practical
> > drawback in requiring CONFIG_PM ?
>
> Good question. CONFIG_PM is something you can disable (for a reason I can't
> think of though). Why should a driver depend on it when it could perfectly
> work without it as well?
Because it requires additional complexity in the driver, times the
number of sensor drivers we have in the kernel. Not even mentioning test
coverage, I'm pretty sure very few people would test the sensor drivers
without CONFIG_PM.
> Although this might not amount to a practical drawback. :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power
2021-07-07 21:51 ` Laurent Pinchart
@ 2021-07-08 10:28 ` Sakari Ailus
0 siblings, 0 replies; 26+ messages in thread
From: Sakari Ailus @ 2021-07-08 10:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Pratyush Yadav, Mauro Carvalho Chehab, Vignesh Raghavendra,
Tomi Valkeinen, Nikhil Devshatwar, Dongchun Zhu, Jacopo Mondi,
Kieran Bingham, Martina Krasteva, Paul Kocialkowski, Raag Jadav,
Steve Longerbeam, Tianshu Qiu, linux-kernel, linux-media
Hi Laurent,
On Thu, Jul 08, 2021 at 12:51:16AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Thu, Jul 08, 2021 at 12:44:15AM +0300, Sakari Ailus wrote:
> > On Thu, Jul 08, 2021 at 12:00:57AM +0300, Laurent Pinchart wrote:
> > > On Wed, Jul 07, 2021 at 11:37:18PM +0300, Sakari Ailus wrote:
> > > > On Fri, Jun 25, 2021 at 12:51:50AM +0530, Pratyush Yadav wrote:
> > > > > Calling s_power subdev callback is discouraged. Instead, the subdevs
> > > > > should use runtime PM to control its power. Use runtime PM callbacks to
> > > > > control sensor power. The pm counter is incremented when the stream is
> > > > > started and decremented when the stream is stopped.
> > > > >
> > > > > Refactor s_stream() a bit to make this new control flow easier. Add a
> > > > > helper to choose whether mipi or dvp set_stream needs to be called. The
> > > > > logic flow is also changed to make it a bit clearer.
> > > > >
> > > > > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes in v3:
> > > > > - Clean up the logic in ov5640_s_stream() a bit.
> > > > > - Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().
> > > > > - Rename the label error_pm to disable_pm.
> > > > >
> > > > > Changes in v2:
> > > > > - New in v2.
> > > > >
> > > > > drivers/media/i2c/Kconfig | 2 +-
> > > > > drivers/media/i2c/ov5640.c | 127 +++++++++++++++++++++++--------------
> > > > > 2 files changed, 79 insertions(+), 50 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > > > index 588f8eb95984..8f43a4d7bcc1 100644
> > > > > --- a/drivers/media/i2c/Kconfig
> > > > > +++ b/drivers/media/i2c/Kconfig
> > > > > @@ -929,7 +929,7 @@ config VIDEO_OV2740
> > > > >
> > > > > config VIDEO_OV5640
> > > > > tristate "OmniVision OV5640 sensor support"
> > > > > - depends on OF
> > > > > + depends on OF && PM
> > > >
> > > > Could you add support for runtime PM without requiring CONFIG_PM?
> > > >
> > > > Essentially you'll need to power on the device in probe and power it off in
> > > > probe, and make sure the runtime PM nop variant functions return the value
> > > > you'd expect.
> > >
> > > I've gone through that in several sensor drivers, and it really
> > > increases the complexity to get it right, to a point where I'm not
> > > comfortable asking someone to do the same (not to mention the very, very
> >
> > I don't think it's very complicated, really. Looking at examples of other
> > drivers (e.g. imx334) doing exactly the same helps as you don't need to
> > check for individual functions.
> >
> > The complexity of the power management in this driver is mostly because of
> > evolutionary development done over time, it's an old driver.
>
> https://git.linuxtv.org/pinchartl/media.git/commit/?h=sensors/ar0330/driver&id=e72ca23c4c6b1ab6b06ac48280726e09d63cc818
>
> Look at the changes to ar0330_probe(). As far as I understand, anything
> less than that would be incorrect, and it's way too easy to get it
> wrong.
The driver uses autosuspend that requires quite a few extra calls to
runtime PM framework. The only other driver doing this may be the CCS
driver.
>
> > > high chance that it won't be done correctly). What's the practical
> > > drawback in requiring CONFIG_PM ?
> >
> > Good question. CONFIG_PM is something you can disable (for a reason I can't
> > think of though). Why should a driver depend on it when it could perfectly
> > work without it as well?
>
> Because it requires additional complexity in the driver, times the
> number of sensor drivers we have in the kernel. Not even mentioning test
How much of additional complexity?
You need to call the function powering on the sensor in probe, and call
another one to power the sensor off in remove, and make sure the use of
runtime PM functions is correct. Good examples exist of this.
Even if you fully relied on runtime PM and do not call the aforementioned
functions directly, you need to power on the sensor in probe using runtime
PM on DT based systems which is not the case on ACPI based systems. These
differences need to be taken into account in that case.
> coverage, I'm pretty sure very few people would test the sensor drivers
> without CONFIG_PM.
That is probably true.
--
Regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v3 02/11] media: cadence: csi2rx: Unregister v4l2 async notifier
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 03/11] media: cadence: csi2rx: Add external DPHY support Pratyush Yadav
` (9 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Benoit Parrot, Maxime Ripard,
Niklas Söderlund, Sakari Ailus, linux-kernel, linux-media
The notifier is added to the global notifier list when registered. When
the module is removed, the struct csi2rx_priv in which the notifier is
embedded, is destroyed. As a result the notifier list has a reference to
a notifier that no longer exists. This causes invalid memory accesses
when the list is iterated over. Similar for when the probe fails.
Unregister and clean up the notifier to avoid this.
Fixes: 1fc3b37f34f6 ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver")
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
Changes in v3:
- New in v3.
drivers/media/platform/cadence/cdns-csi2rx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
index f2b4ddd31177..bf2e024d73c5 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -471,6 +471,7 @@ static int csi2rx_probe(struct platform_device *pdev)
return 0;
err_cleanup:
+ v4l2_async_notifier_unregister(&csi2rx->notifier);
v4l2_async_notifier_cleanup(&csi2rx->notifier);
err_free_priv:
kfree(csi2rx);
@@ -481,6 +482,8 @@ static int csi2rx_remove(struct platform_device *pdev)
{
struct csi2rx_priv *csi2rx = platform_get_drvdata(pdev);
+ v4l2_async_notifier_unregister(&csi2rx->notifier);
+ v4l2_async_notifier_cleanup(&csi2rx->notifier);
v4l2_async_unregister_subdev(&csi2rx->subdev);
kfree(csi2rx);
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 03/11] media: cadence: csi2rx: Add external DPHY support
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 01/11] media: ov5640: Use runtime PM to control sensor power Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 02/11] media: cadence: csi2rx: Unregister v4l2 async notifier Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 04/11] media: cadence: csi2rx: Soft reset the streams before starting capture Pratyush Yadav
` (8 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Maxime Ripard, linux-kernel,
linux-media
Some platforms like TI's J721E can have the CSI2RX paired with an
external DPHY. Add support to enable and configure the DPHY using the
generic PHY framework.
Get the pixel rate and bpp from the subdev and pass them on to the DPHY
along with the number of lanes. All other settings are left to their
default values.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
Changes in v3:
- Use v4l2_get_link_freq() to calculate pixel clock.
Changes in v2:
- Use phy_pm_runtime_get_sync() and phy_pm_runtime_put() before making
calls to set PHY mode, etc. to make sure it is ready.
drivers/media/platform/cadence/cdns-csi2rx.c | 148 +++++++++++++++++--
1 file changed, 138 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
index bf2e024d73c5..d86be917135b 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -30,6 +30,12 @@
#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane) ((plane) << (16 + (llane) * 4))
#define CSI2RX_STATIC_CFG_LANES_MASK GENMASK(11, 8)
+#define CSI2RX_DPHY_LANE_CTRL_REG 0x40
+#define CSI2RX_DPHY_CL_RST BIT(16)
+#define CSI2RX_DPHY_DL_RST(i) BIT((i) + 12)
+#define CSI2RX_DPHY_CL_EN BIT(4)
+#define CSI2RX_DPHY_DL_EN(i) BIT(i)
+
#define CSI2RX_STREAM_BASE(n) (((n) + 1) * 0x100)
#define CSI2RX_STREAM_CTRL_REG(n) (CSI2RX_STREAM_BASE(n) + 0x000)
@@ -54,6 +60,11 @@ enum csi2rx_pads {
CSI2RX_PAD_MAX,
};
+struct csi2rx_fmt {
+ u32 code;
+ u8 bpp;
+};
+
struct csi2rx_priv {
struct device *dev;
unsigned int count;
@@ -85,6 +96,37 @@ struct csi2rx_priv {
int source_pad;
};
+static const struct csi2rx_fmt formats[] = {
+ {
+ .code = MEDIA_BUS_FMT_YUYV8_2X8,
+ .bpp = 16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_UYVY8_2X8,
+ .bpp = 16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_YVYU8_2X8,
+ .bpp = 16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_VYUY8_2X8,
+ .bpp = 16,
+ },
+};
+
+static u8 csi2rx_get_bpp(u32 code)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(formats); i++) {
+ if (formats[i].code == code)
+ return formats[i].bpp;
+ }
+
+ return 0;
+}
+
static inline
struct csi2rx_priv *v4l2_subdev_to_csi2rx(struct v4l2_subdev *subdev)
{
@@ -101,6 +143,71 @@ static void csi2rx_reset(struct csi2rx_priv *csi2rx)
writel(0, csi2rx->base + CSI2RX_SOFT_RESET_REG);
}
+static int csi2rx_configure_external_dphy(struct csi2rx_priv *csi2rx)
+{
+ union phy_configure_opts opts = { };
+ struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
+ struct v4l2_subdev_format sd_fmt;
+ s64 pixel_clock;
+ int ret;
+ u8 bpp;
+ bool got_pm = true;
+
+ sd_fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ sd_fmt.pad = 0;
+
+ ret = v4l2_subdev_call(csi2rx->source_subdev, pad, get_fmt, NULL,
+ &sd_fmt);
+ if (ret)
+ return ret;
+
+ bpp = csi2rx_get_bpp(sd_fmt.format.code);
+ if (!bpp)
+ return -EINVAL;
+
+ /*
+ * Do not divide by the number of lanes here. That will be done by
+ * phy_mipi_dphy_get_default_config().
+ */
+ pixel_clock = v4l2_get_link_freq(csi2rx->source_subdev->ctrl_handler,
+ 1, 2);
+ if (pixel_clock < 0)
+ return pixel_clock;
+
+ ret = phy_mipi_dphy_get_default_config(pixel_clock, bpp,
+ csi2rx->num_lanes, cfg);
+ if (ret)
+ return ret;
+
+ ret = phy_pm_runtime_get_sync(csi2rx->dphy);
+ if (ret == -ENOTSUPP)
+ got_pm = false;
+ else if (ret)
+ return ret;
+
+ ret = phy_set_mode_ext(csi2rx->dphy, PHY_MODE_MIPI_DPHY,
+ PHY_MIPI_DPHY_SUBMODE_RX);
+ if (ret)
+ goto out;
+
+ ret = phy_power_on(csi2rx->dphy);
+ if (ret)
+ goto out;
+
+ ret = phy_configure(csi2rx->dphy, &opts);
+ if (ret) {
+ /* Can't do anything if it fails. Ignore the return value. */
+ phy_power_off(csi2rx->dphy);
+ goto out;
+ }
+
+out:
+ if (got_pm)
+ phy_pm_runtime_put(csi2rx->dphy);
+
+ return ret;
+}
+
static int csi2rx_start(struct csi2rx_priv *csi2rx)
{
unsigned int i;
@@ -139,6 +246,17 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
if (ret)
goto err_disable_pclk;
+ /* Enable DPHY clk and data lanes. */
+ if (csi2rx->dphy) {
+ reg = CSI2RX_DPHY_CL_EN | CSI2RX_DPHY_CL_RST;
+ for (i = 0; i < csi2rx->num_lanes; i++) {
+ reg |= CSI2RX_DPHY_DL_EN(csi2rx->lanes[i] - 1);
+ reg |= CSI2RX_DPHY_DL_RST(csi2rx->lanes[i] - 1);
+ }
+
+ writel(reg, csi2rx->base + CSI2RX_DPHY_LANE_CTRL_REG);
+ }
+
/*
* Create a static mapping between the CSI virtual channels
* and the output stream.
@@ -169,10 +287,21 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
if (ret)
goto err_disable_pixclk;
+ if (csi2rx->dphy) {
+ ret = csi2rx_configure_external_dphy(csi2rx);
+ if (ret) {
+ dev_err(csi2rx->dev,
+ "Failed to configure external DPHY: %d\n", ret);
+ goto err_disable_sysclk;
+ }
+ }
+
clk_disable_unprepare(csi2rx->p_clk);
return 0;
+err_disable_sysclk:
+ clk_disable_unprepare(csi2rx->sys_clk);
err_disable_pixclk:
for (; i > 0; i--)
clk_disable_unprepare(csi2rx->pixel_clk[i - 1]);
@@ -200,6 +329,13 @@ static void csi2rx_stop(struct csi2rx_priv *csi2rx)
if (v4l2_subdev_call(csi2rx->source_subdev, video, s_stream, false))
dev_warn(csi2rx->dev, "Couldn't disable our subdev\n");
+
+ if (csi2rx->dphy) {
+ writel(0, csi2rx->base + CSI2RX_DPHY_LANE_CTRL_REG);
+
+ if (phy_power_off(csi2rx->dphy))
+ dev_warn(csi2rx->dev, "Couldn't power off DPHY\n");
+ }
}
static int csi2rx_s_stream(struct v4l2_subdev *subdev, int enable)
@@ -307,15 +443,6 @@ static int csi2rx_get_resources(struct csi2rx_priv *csi2rx,
return PTR_ERR(csi2rx->dphy);
}
- /*
- * FIXME: Once we'll have external D-PHY support, the check
- * will need to be removed.
- */
- if (csi2rx->dphy) {
- dev_err(&pdev->dev, "External D-PHY not supported yet\n");
- return -EINVAL;
- }
-
ret = clk_prepare_enable(csi2rx->p_clk);
if (ret) {
dev_err(&pdev->dev, "Couldn't prepare and enable P clock\n");
@@ -345,7 +472,7 @@ static int csi2rx_get_resources(struct csi2rx_priv *csi2rx,
* FIXME: Once we'll have internal D-PHY support, the check
* will need to be removed.
*/
- if (csi2rx->has_internal_dphy) {
+ if (!csi2rx->dphy && csi2rx->has_internal_dphy) {
dev_err(&pdev->dev, "Internal D-PHY not supported yet\n");
return -EINVAL;
}
@@ -466,6 +593,7 @@ static int csi2rx_probe(struct platform_device *pdev)
dev_info(&pdev->dev,
"Probed CSI2RX with %u/%u lanes, %u streams, %s D-PHY\n",
csi2rx->num_lanes, csi2rx->max_lanes, csi2rx->max_streams,
+ csi2rx->dphy ? "external" :
csi2rx->has_internal_dphy ? "internal" : "no");
return 0;
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 04/11] media: cadence: csi2rx: Soft reset the streams before starting capture
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (2 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 03/11] media: cadence: csi2rx: Add external DPHY support Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 05/11] media: cadence: csi2rx: Set the STOP bit when stopping a stream Pratyush Yadav
` (7 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Maxime Ripard, linux-kernel,
linux-media
This resets the stream state machines and FIFOs, giving them a clean
slate. On J721E if the streams are not reset before starting the
capture, the captured frame gets wrapped around vertically on every run
after the first.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
(no changes since v1)
drivers/media/platform/cadence/cdns-csi2rx.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
index d86be917135b..379bc163d4c1 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -39,6 +39,7 @@
#define CSI2RX_STREAM_BASE(n) (((n) + 1) * 0x100)
#define CSI2RX_STREAM_CTRL_REG(n) (CSI2RX_STREAM_BASE(n) + 0x000)
+#define CSI2RX_STREAM_CTRL_SOFT_RST BIT(4)
#define CSI2RX_STREAM_CTRL_START BIT(0)
#define CSI2RX_STREAM_DATA_CFG_REG(n) (CSI2RX_STREAM_BASE(n) + 0x008)
@@ -135,12 +136,22 @@ struct csi2rx_priv *v4l2_subdev_to_csi2rx(struct v4l2_subdev *subdev)
static void csi2rx_reset(struct csi2rx_priv *csi2rx)
{
+ int i;
+
writel(CSI2RX_SOFT_RESET_PROTOCOL | CSI2RX_SOFT_RESET_FRONT,
csi2rx->base + CSI2RX_SOFT_RESET_REG);
udelay(10);
writel(0, csi2rx->base + CSI2RX_SOFT_RESET_REG);
+
+ /* Reset individual streams. */
+ for (i = 0; i < csi2rx->max_streams; i++) {
+ writel(CSI2RX_STREAM_CTRL_SOFT_RST,
+ csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+ usleep_range(10, 20);
+ writel(0, csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+ }
}
static int csi2rx_configure_external_dphy(struct csi2rx_priv *csi2rx)
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 05/11] media: cadence: csi2rx: Set the STOP bit when stopping a stream
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (3 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 04/11] media: cadence: csi2rx: Soft reset the streams before starting capture Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 06/11] media: cadence: csi2rx: Fix stream data configuration Pratyush Yadav
` (6 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Maxime Ripard, linux-kernel,
linux-media
The stream stop procedure says that the STOP bit should be set when the
stream is to be stopped, and then the ready bit in stream status
register polled to make sure the STOP operation is finished.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
(no changes since v1)
drivers/media/platform/cadence/cdns-csi2rx.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
index 379bc163d4c1..34d4829a0d87 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -8,6 +8,7 @@
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_graph.h>
@@ -40,8 +41,12 @@
#define CSI2RX_STREAM_CTRL_REG(n) (CSI2RX_STREAM_BASE(n) + 0x000)
#define CSI2RX_STREAM_CTRL_SOFT_RST BIT(4)
+#define CSI2RX_STREAM_CTRL_STOP BIT(1)
#define CSI2RX_STREAM_CTRL_START BIT(0)
+#define CSI2RX_STREAM_STATUS_REG(n) (CSI2RX_STREAM_BASE(n) + 0x004)
+#define CSI2RX_STREAM_STATUS_RDY BIT(31)
+
#define CSI2RX_STREAM_DATA_CFG_REG(n) (CSI2RX_STREAM_BASE(n) + 0x008)
#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECT BIT(31)
#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n) BIT((n) + 16)
@@ -326,12 +331,23 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
static void csi2rx_stop(struct csi2rx_priv *csi2rx)
{
unsigned int i;
+ u32 val;
+ int ret;
clk_prepare_enable(csi2rx->p_clk);
clk_disable_unprepare(csi2rx->sys_clk);
for (i = 0; i < csi2rx->max_streams; i++) {
- writel(0, csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+ writel(CSI2RX_STREAM_CTRL_STOP,
+ csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+
+ ret = readl_relaxed_poll_timeout(csi2rx->base +
+ CSI2RX_STREAM_STATUS_REG(i),
+ val,
+ (val & CSI2RX_STREAM_STATUS_RDY),
+ 10, 10000);
+ if (ret)
+ dev_warn(csi2rx->dev, "Failed to stop stream%d\n", i);
clk_disable_unprepare(csi2rx->pixel_clk[i]);
}
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 06/11] media: cadence: csi2rx: Fix stream data configuration
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (4 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 05/11] media: cadence: csi2rx: Set the STOP bit when stopping a stream Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 07/11] media: cadence: csi2rx: Populate subdev devnode Pratyush Yadav
` (5 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Maxime Ripard, linux-kernel,
linux-media
Firstly, there is no VC_EN bit present in the STREAM_DATA_CFG register.
Bit 31 is part of the VL_SELECT field. Remove it completely.
Secondly, it makes little sense to enable ith virtual channel for ith
stream. Sure, there might be a use-case that demands it. But there might
also be a use case that demands all streams to use the 0th virtual
channel. Prefer this case over the former because it is less arbitrary
and also makes it very clear what the limitations of the current driver
is instead of giving a false impression that multiple virtual channels
are supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
(no changes since v1)
drivers/media/platform/cadence/cdns-csi2rx.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
index 34d4829a0d87..780b42df757a 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -48,7 +48,6 @@
#define CSI2RX_STREAM_STATUS_RDY BIT(31)
#define CSI2RX_STREAM_DATA_CFG_REG(n) (CSI2RX_STREAM_BASE(n) + 0x008)
-#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECT BIT(31)
#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n) BIT((n) + 16)
#define CSI2RX_STREAM_CFG_REG(n) (CSI2RX_STREAM_BASE(n) + 0x00c)
@@ -291,8 +290,11 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
writel(CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF,
csi2rx->base + CSI2RX_STREAM_CFG_REG(i));
- writel(CSI2RX_STREAM_DATA_CFG_EN_VC_SELECT |
- CSI2RX_STREAM_DATA_CFG_VC_SELECT(i),
+ /*
+ * Enable one virtual channel. When multiple virtual channels
+ * are supported this will have to be changed.
+ */
+ writel(CSI2RX_STREAM_DATA_CFG_VC_SELECT(0),
csi2rx->base + CSI2RX_STREAM_DATA_CFG_REG(i));
writel(CSI2RX_STREAM_CTRL_START,
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 07/11] media: cadence: csi2rx: Populate subdev devnode
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (5 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 06/11] media: cadence: csi2rx: Fix stream data configuration Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 08/11] media: Re-structure TI platform drivers Pratyush Yadav
` (4 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Maxime Ripard, linux-kernel,
linux-media
The devnode can be used by media-ctl and other userspace tools to
perform configurations on the subdev. Without it, media-ctl returns
ENOENT when setting format on the sensor subdev.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
(no changes since v2)
Changes in v2:
- New in v2.
drivers/media/platform/cadence/cdns-csi2rx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
index 780b42df757a..ff893a29ea54 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -609,6 +609,7 @@ static int csi2rx_probe(struct platform_device *pdev)
csi2rx->pads[CSI2RX_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
for (i = CSI2RX_PAD_SOURCE_STREAM0; i < CSI2RX_PAD_MAX; i++)
csi2rx->pads[i].flags = MEDIA_PAD_FL_SOURCE;
+ csi2rx->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
ret = media_entity_pads_init(&csi2rx->subdev.entity, CSI2RX_PAD_MAX,
csi2rx->pads);
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 08/11] media: Re-structure TI platform drivers
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (6 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 07/11] media: cadence: csi2rx: Populate subdev devnode Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 09/11] media: ti: Add CSI2RX support for J721E Pratyush Yadav
` (3 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Benoit Parrot, Bert Vermeulen,
Eugen Hristev, Ezequiel Garcia, Hans Verkuil, Helen Koike,
Jiapeng Chong, Kieran Bingham, Michael Tretter, Mirela Rabulea,
Neil Armstrong, Qiushi Wu, Ricardo Ribalda, Thomas Bogendoerfer,
Yang Yingliang, Zou Wei, linux-kernel, linux-media
The ti-vpe/ sub-directory does not only contain the VPE-specific things.
It also contains the CAL driver, which is a completely different
subsystem. This is also not a good place to add new drivers for other TI
platforms since they will all get mixed up.
Separate the VPE and CAL parts into different sub-directories and rename
the ti-vpe/ sub-directory to ti/. This is now the place where new TI
platform drivers can be added.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Compile tested only. There should be no functional change.
Changes in v3:
- Add Tomi's R-by.
Changes in v2:
- New in v2.
MAINTAINERS | 3 ++-
drivers/media/platform/Makefile | 2 +-
drivers/media/platform/ti/Makefile | 3 +++
drivers/media/platform/ti/cal/Makefile | 3 +++
drivers/media/platform/{ti-vpe => ti/cal}/cal-camerarx.c | 0
drivers/media/platform/{ti-vpe => ti/cal}/cal-video.c | 0
drivers/media/platform/{ti-vpe => ti/cal}/cal.c | 0
drivers/media/platform/{ti-vpe => ti/cal}/cal.h | 0
drivers/media/platform/{ti-vpe => ti/cal}/cal_regs.h | 0
drivers/media/platform/{ti-vpe => ti/vpe}/Makefile | 4 ----
drivers/media/platform/{ti-vpe => ti/vpe}/csc.c | 0
drivers/media/platform/{ti-vpe => ti/vpe}/csc.h | 0
drivers/media/platform/{ti-vpe => ti/vpe}/sc.c | 0
drivers/media/platform/{ti-vpe => ti/vpe}/sc.h | 0
drivers/media/platform/{ti-vpe => ti/vpe}/sc_coeff.h | 0
drivers/media/platform/{ti-vpe => ti/vpe}/vpdma.c | 0
drivers/media/platform/{ti-vpe => ti/vpe}/vpdma.h | 0
drivers/media/platform/{ti-vpe => ti/vpe}/vpdma_priv.h | 0
drivers/media/platform/{ti-vpe => ti/vpe}/vpe.c | 0
drivers/media/platform/{ti-vpe => ti/vpe}/vpe_regs.h | 0
20 files changed, 9 insertions(+), 6 deletions(-)
create mode 100644 drivers/media/platform/ti/Makefile
create mode 100644 drivers/media/platform/ti/cal/Makefile
rename drivers/media/platform/{ti-vpe => ti/cal}/cal-camerarx.c (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal-video.c (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal.c (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal.h (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal_regs.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/Makefile (78%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/csc.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/csc.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/sc.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/sc.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/sc_coeff.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpdma.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpdma.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpdma_priv.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpe.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpe_regs.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ae47618c857..5dad98f69683 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18584,7 +18584,8 @@ W: http://linuxtv.org/
Q: http://patchwork.linuxtv.org/project/linux-media/list/
F: Documentation/devicetree/bindings/media/ti,cal.yaml
F: Documentation/devicetree/bindings/media/ti,vpe.yaml
-F: drivers/media/platform/ti-vpe/
+F: drivers/media/platform/ti/cal/
+F: drivers/media/platform/ti/vpe/
TI WILINK WIRELESS DRIVERS
L: linux-wireless@vger.kernel.org
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 73ce083c2fc6..26d15b377a79 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
-obj-y += ti-vpe/
+obj-y += ti/
obj-$(CONFIG_VIDEO_MX2_EMMAPRP) += mx2_emmaprp.o
obj-$(CONFIG_VIDEO_CODA) += coda/
diff --git a/drivers/media/platform/ti/Makefile b/drivers/media/platform/ti/Makefile
new file mode 100644
index 000000000000..bbc737ccbbea
--- /dev/null
+++ b/drivers/media/platform/ti/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += cal/
+obj-y += vpe/
diff --git a/drivers/media/platform/ti/cal/Makefile b/drivers/media/platform/ti/cal/Makefile
new file mode 100644
index 000000000000..45ac35585f0b
--- /dev/null
+++ b/drivers/media/platform/ti/cal/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-cal.o
+ti-cal-y := cal.o cal-camerarx.o cal-video.o
diff --git a/drivers/media/platform/ti-vpe/cal-camerarx.c b/drivers/media/platform/ti/cal/cal-camerarx.c
similarity index 100%
rename from drivers/media/platform/ti-vpe/cal-camerarx.c
rename to drivers/media/platform/ti/cal/cal-camerarx.c
diff --git a/drivers/media/platform/ti-vpe/cal-video.c b/drivers/media/platform/ti/cal/cal-video.c
similarity index 100%
rename from drivers/media/platform/ti-vpe/cal-video.c
rename to drivers/media/platform/ti/cal/cal-video.c
diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti/cal/cal.c
similarity index 100%
rename from drivers/media/platform/ti-vpe/cal.c
rename to drivers/media/platform/ti/cal/cal.c
diff --git a/drivers/media/platform/ti-vpe/cal.h b/drivers/media/platform/ti/cal/cal.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/cal.h
rename to drivers/media/platform/ti/cal/cal.h
diff --git a/drivers/media/platform/ti-vpe/cal_regs.h b/drivers/media/platform/ti/cal/cal_regs.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/cal_regs.h
rename to drivers/media/platform/ti/cal/cal_regs.h
diff --git a/drivers/media/platform/ti-vpe/Makefile b/drivers/media/platform/ti/vpe/Makefile
similarity index 78%
rename from drivers/media/platform/ti-vpe/Makefile
rename to drivers/media/platform/ti/vpe/Makefile
index ad624056e039..3fadfe084f87 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti/vpe/Makefile
@@ -10,7 +10,3 @@ ti-sc-y := sc.o
ti-csc-y := csc.o
ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
-
-obj-$(CONFIG_VIDEO_TI_CAL) += ti-cal.o
-
-ti-cal-y := cal.o cal-camerarx.o cal-video.o
diff --git a/drivers/media/platform/ti-vpe/csc.c b/drivers/media/platform/ti/vpe/csc.c
similarity index 100%
rename from drivers/media/platform/ti-vpe/csc.c
rename to drivers/media/platform/ti/vpe/csc.c
diff --git a/drivers/media/platform/ti-vpe/csc.h b/drivers/media/platform/ti/vpe/csc.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/csc.h
rename to drivers/media/platform/ti/vpe/csc.h
diff --git a/drivers/media/platform/ti-vpe/sc.c b/drivers/media/platform/ti/vpe/sc.c
similarity index 100%
rename from drivers/media/platform/ti-vpe/sc.c
rename to drivers/media/platform/ti/vpe/sc.c
diff --git a/drivers/media/platform/ti-vpe/sc.h b/drivers/media/platform/ti/vpe/sc.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/sc.h
rename to drivers/media/platform/ti/vpe/sc.h
diff --git a/drivers/media/platform/ti-vpe/sc_coeff.h b/drivers/media/platform/ti/vpe/sc_coeff.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/sc_coeff.h
rename to drivers/media/platform/ti/vpe/sc_coeff.h
diff --git a/drivers/media/platform/ti-vpe/vpdma.c b/drivers/media/platform/ti/vpe/vpdma.c
similarity index 100%
rename from drivers/media/platform/ti-vpe/vpdma.c
rename to drivers/media/platform/ti/vpe/vpdma.c
diff --git a/drivers/media/platform/ti-vpe/vpdma.h b/drivers/media/platform/ti/vpe/vpdma.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/vpdma.h
rename to drivers/media/platform/ti/vpe/vpdma.h
diff --git a/drivers/media/platform/ti-vpe/vpdma_priv.h b/drivers/media/platform/ti/vpe/vpdma_priv.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/vpdma_priv.h
rename to drivers/media/platform/ti/vpe/vpdma_priv.h
diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti/vpe/vpe.c
similarity index 100%
rename from drivers/media/platform/ti-vpe/vpe.c
rename to drivers/media/platform/ti/vpe/vpe.c
diff --git a/drivers/media/platform/ti-vpe/vpe_regs.h b/drivers/media/platform/ti/vpe/vpe_regs.h
similarity index 100%
rename from drivers/media/platform/ti-vpe/vpe_regs.h
rename to drivers/media/platform/ti/vpe/vpe_regs.h
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 09/11] media: ti: Add CSI2RX support for J721E
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (7 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 08/11] media: Re-structure TI platform drivers Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-06-24 19:21 ` [PATCH v3 10/11] media: dt-bindings: Add DT bindings for TI J721E CSI2RX driver Pratyush Yadav
` (2 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Alexandre Courbot,
Arnd Bergmann, Bert Vermeulen, Dikshita Agarwal, Fabio Estevam,
Georgi Djakov, Hans Verkuil, Helen Koike, Lad Prabhakar,
Michael Tretter, Mirela Rabulea, Neil Armstrong,
Stanimir Varbanov, Thomas Bogendoerfer, linux-kernel,
linux-media
TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
capture over a CSI-2 bus.
The Cadence CSI2RX IP acts as a bridge between the TI specific parts and
the CSI-2 protocol parts. TI then has a wrapper on top of this bridge
called the SHIM layer. It takes in data from stream 0, repacks it, and
sends it to memory over PSI-L DMA.
This driver acts as the "front end" to V4L2 client applications. It
implements the required ioctls and buffer operations, passes the
necessary calls on to the bridge, programs the SHIM layer, and performs
DMA via the dmaengine API to finally return the data to a buffer
supplied by the application.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
Changes in v3:
- Move DMA related fields in struct ti_csi2rx_dma.
- Protect DMA buffer queue with a spinlock to make sure the queue buffer
and DMA callback don't race on it.
- Track the current DMA state. It might go idle because of a lack of
buffers. This state can be used to restart it if needed.
- Do not include the current buffer in the pending queue. It is slightly
better modelling than leaving it at the head of the pending queue.
- Use the buffer as the callback argument, and add a reference to csi in it.
- If queueing a buffer to DMA fails, the buffer gets leaked and DMA gets
stalled with. Instead, report the error to vb2 and queue the next
buffer in the pending queue.
- DMA gets stalled if we run out of buffers since the callback is the
only one that fires subsequent transfers and it is no longer being
called. Check for that when queueing buffers and restart DMA if
needed.
- Do not put of node until we are done using the fwnode.
- Set inital format to UYVY 640x480.
Changes in v2:
- Use dmaengine_get_dma_device() instead of directly accessing
dma->device->dev.
- Do not set dst_addr_width when configuring slave DMA.
- Move to a separate subdir and rename to j721e-csi2rx.c
- Convert compatible to ti,j721e-csi2rx.
- Move to use Media Controller centric APIs.
- Improve cleanup in probe when one of the steps fails.
- Add colorspace to formats database.
- Set hw_revision on media_device.
- Move video device initialization to probe time instead of register time.
MAINTAINERS | 6 +
drivers/media/platform/Kconfig | 12 +
drivers/media/platform/ti/Makefile | 1 +
.../media/platform/ti/j721e-csi2rx/Makefile | 2 +
.../platform/ti/j721e-csi2rx/j721e-csi2rx.c | 978 ++++++++++++++++++
5 files changed, 999 insertions(+)
create mode 100644 drivers/media/platform/ti/j721e-csi2rx/Makefile
create mode 100644 drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5dad98f69683..96f002b9046d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18467,6 +18467,12 @@ S: Odd Fixes
F: drivers/clk/ti/
F: include/linux/clk/ti.h
+TI J721E CSI2RX DRIVER
+M: Pratyush Yadav <p.yadav@ti.com>
+L: linux-media@vger.kernel.org
+S: Supported
+F: drivers/media/platform/ti/j721e-csi2rx/
+
TI DAVINCI MACHINE SUPPORT
M: Sekhar Nori <nsekhar@ti.com>
R: Bartosz Golaszewski <bgolaszewski@baylibre.com>
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 157c924686e4..732a942b3b29 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -200,6 +200,18 @@ config VIDEO_TI_CAL_MC
endif # VIDEO_TI_CAL
+config VIDEO_TI_J721E_CSI2RX
+ tristate "TI J721E CSI2RX wrapper layer driver"
+ depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_SUPPORT && MEDIA_CONTROLLER
+ depends on PHY_CADENCE_DPHY && VIDEO_CADENCE_CSI2RX
+ depends on ARCH_K3 || COMPILE_TEST
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
+ help
+ Support for TI CSI2RX wrapper layer. This just enables the wrapper driver.
+ The Cadence CSI2RX bridge driver needs to be enabled separately.
+
endif # V4L_PLATFORM_DRIVERS
menuconfig V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/platform/ti/Makefile b/drivers/media/platform/ti/Makefile
index bbc737ccbbea..17c9cfb74f66 100644
--- a/drivers/media/platform/ti/Makefile
+++ b/drivers/media/platform/ti/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += cal/
obj-y += vpe/
+obj-y += j721e-csi2rx/
diff --git a/drivers/media/platform/ti/j721e-csi2rx/Makefile b/drivers/media/platform/ti/j721e-csi2rx/Makefile
new file mode 100644
index 000000000000..377afc1d6280
--- /dev/null
+++ b/drivers/media/platform/ti/j721e-csi2rx/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VIDEO_TI_J721E_CSI2RX) += j721e-csi2rx.o
diff --git a/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c b/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c
new file mode 100644
index 000000000000..0e2ce9aa4196
--- /dev/null
+++ b/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c
@@ -0,0 +1,978 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI CSI2 RX driver.
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ * Author: Pratyush Yadav <p.yadav@ti.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/dmaengine.h>
+#include <linux/of_platform.h>
+
+#include <media/v4l2-device.h>
+#include <media/v4l2-ioctl.h>
+#include <media/videobuf2-dma-contig.h>
+
+#define TI_CSI2RX_MODULE_NAME "j721e-csi2rx"
+
+#define SHIM_CNTL 0x10
+#define SHIM_CNTL_PIX_RST BIT(0)
+
+#define SHIM_DMACNTX 0x20
+#define SHIM_DMACNTX_EN BIT(31)
+#define SHIM_DMACNTX_YUV422 GENMASK(27, 26)
+#define SHIM_DMACNTX_FMT GENMASK(5, 0)
+#define SHIM_DMACNTX_UYVY 0
+#define SHIM_DMACNTX_VYUY 1
+#define SHIM_DMACNTX_YUYV 2
+#define SHIM_DMACNTX_YVYU 3
+
+#define SHIM_PSI_CFG0 0x24
+#define SHIM_PSI_CFG0_SRC_TAG GENMASK(15, 0)
+#define SHIM_PSI_CFG0_DST_TAG GENMASK(31, 15)
+
+#define CSI_DF_YUV420 0x18
+#define CSI_DF_YUV422 0x1e
+#define CSI_DF_RGB444 0x20
+#define CSI_DF_RGB888 0x24
+
+#define PSIL_WORD_SIZE_BYTES 16
+
+struct ti_csi2rx_fmt {
+ u32 fourcc; /* Four character code. */
+ u32 code; /* Mbus code. */
+ enum v4l2_colorspace colorspace;
+ u32 csi_df; /* CSI Data format. */
+ u8 bpp; /* Bits per pixel. */
+};
+
+struct ti_csi2rx_buffer {
+ /* Common v4l2 buffer. Must be first. */
+ struct vb2_v4l2_buffer vb;
+ struct list_head list;
+ struct ti_csi2rx_dev *csi;
+};
+
+enum ti_csi2rx_dma_state {
+ TI_CSI2RX_DMA_STOPPED, /* Streaming not started yet. */
+ TI_CSI2RX_DMA_IDLE, /* Streaming but no pending DMA operation. */
+ TI_CSI2RX_DMA_ACTIVE, /* Streaming and pending DMA operation. */
+};
+
+struct ti_csi2rx_dma {
+ /* Protects all fields in this struct. */
+ spinlock_t lock;
+ struct dma_chan *chan;
+ /* Buffers queued to the driver, waiting to be processed by DMA. */
+ struct list_head queue;
+ enum ti_csi2rx_dma_state state;
+ /*
+ * Current buffer being processed by DMA. NULL if no buffer is being
+ * processed.
+ */
+ struct ti_csi2rx_buffer *curr;
+};
+
+struct ti_csi2rx_dev {
+ struct device *dev;
+ void __iomem *shim;
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct media_device mdev;
+ struct media_pipeline pipe;
+ struct media_pad pad;
+ struct v4l2_async_notifier notifier;
+ struct v4l2_subdev *subdev;
+ struct vb2_queue vidq;
+ struct mutex mutex; /* To serialize ioctls. */
+ struct v4l2_format v_fmt;
+ struct ti_csi2rx_dma dma;
+ u32 sequence;
+};
+
+static const struct ti_csi2rx_fmt formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .code = MEDIA_BUS_FMT_YUYV8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .csi_df = CSI_DF_YUV422,
+ .bpp = 16,
+ }, {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .code = MEDIA_BUS_FMT_UYVY8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .csi_df = CSI_DF_YUV422,
+ .bpp = 16,
+ }, {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .code = MEDIA_BUS_FMT_YVYU8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .csi_df = CSI_DF_YUV422,
+ .bpp = 16,
+ }, {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .code = MEDIA_BUS_FMT_VYUY8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .csi_df = CSI_DF_YUV422,
+ .bpp = 16,
+ },
+
+ /* More formats can be supported but they are not listed for now. */
+};
+
+static const unsigned int num_formats = ARRAY_SIZE(formats);
+
+/* Forward declaration needed by ti_csi2rx_dma_callback. */
+static int ti_csi2rx_start_dma(struct ti_csi2rx_dev *csi,
+ struct ti_csi2rx_buffer *buf);
+
+static const struct ti_csi2rx_fmt *find_format_by_pix(u32 pixelformat)
+{
+ unsigned int i;
+
+ for (i = 0; i < num_formats; i++) {
+ if (formats[i].fourcc == pixelformat)
+ return &formats[i];
+ }
+
+ return NULL;
+}
+
+static void ti_csi2rx_fill_fmt(const struct ti_csi2rx_fmt *csi_fmt,
+ struct v4l2_format *v4l2_fmt)
+{
+ struct v4l2_pix_format *pix = &v4l2_fmt->fmt.pix;
+ u32 bpl;
+
+ v4l2_fmt->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ pix->pixelformat = csi_fmt->fourcc;
+ pix->colorspace = csi_fmt->colorspace;
+ pix->sizeimage = pix->height * pix->width * (csi_fmt->bpp / 8);
+
+ bpl = (pix->width * ALIGN(csi_fmt->bpp, 8)) >> 3;
+ pix->bytesperline = ALIGN(bpl, 16);
+}
+
+static int ti_csi2rx_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
+{
+ struct ti_csi2rx_dev *csi = video_drvdata(file);
+
+ strscpy(cap->driver, TI_CSI2RX_MODULE_NAME, sizeof(cap->driver));
+ strscpy(cap->card, TI_CSI2RX_MODULE_NAME, sizeof(cap->card));
+
+ snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
+ dev_name(csi->dev));
+
+ return 0;
+}
+
+static int ti_csi2rx_enum_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if (f->index >= num_formats)
+ return -EINVAL;
+
+ memset(f->reserved, 0, sizeof(f->reserved));
+ f->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ f->pixelformat = formats[f->index].fourcc;
+
+ return 0;
+}
+
+static int ti_csi2rx_g_fmt_vid_cap(struct file *file, void *prov,
+ struct v4l2_format *f)
+{
+ struct ti_csi2rx_dev *csi = video_drvdata(file);
+
+ *f = csi->v_fmt;
+
+ return 0;
+}
+
+static int ti_csi2rx_try_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+ const struct ti_csi2rx_fmt *fmt;
+
+ /*
+ * Default to the first format if the requested pixel format code isn't
+ * supported.
+ */
+ fmt = find_format_by_pix(f->fmt.pix.pixelformat);
+ if (!fmt)
+ fmt = &formats[0];
+
+ if (f->fmt.pix.field == V4L2_FIELD_ANY)
+ f->fmt.pix.field = V4L2_FIELD_NONE;
+
+ if (f->fmt.pix.field != V4L2_FIELD_NONE)
+ return -EINVAL;
+
+ ti_csi2rx_fill_fmt(fmt, f);
+
+ return 0;
+}
+
+static int ti_csi2rx_s_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+ struct ti_csi2rx_dev *csi = video_drvdata(file);
+ struct vb2_queue *q = &csi->vidq;
+ int ret;
+
+ if (vb2_is_busy(q))
+ return -EBUSY;
+
+ ret = ti_csi2rx_try_fmt_vid_cap(file, priv, f);
+ if (ret < 0)
+ return ret;
+
+ csi->v_fmt = *f;
+
+ return 0;
+}
+
+static int ti_csi2rx_enum_framesizes(struct file *file, void *fh,
+ struct v4l2_frmsizeenum *fsize)
+{
+ const struct ti_csi2rx_fmt *fmt;
+ u8 bpp;
+
+ fmt = find_format_by_pix(fsize->pixel_format);
+ if (!fmt)
+ return -EINVAL;
+
+ bpp = ALIGN(fmt->bpp, 8);
+
+ fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
+ fsize->stepwise.min_width = PSIL_WORD_SIZE_BYTES * 8 / bpp;
+ fsize->stepwise.max_width = UINT_MAX;
+ fsize->stepwise.step_width = PSIL_WORD_SIZE_BYTES * 8 / bpp;
+ fsize->stepwise.min_height = 1;
+ fsize->stepwise.max_height = UINT_MAX;
+ fsize->stepwise.step_height = 1;
+
+ return 0;
+}
+
+static const struct v4l2_ioctl_ops csi_ioctl_ops = {
+ .vidioc_querycap = ti_csi2rx_querycap,
+ .vidioc_enum_fmt_vid_cap = ti_csi2rx_enum_fmt_vid_cap,
+ .vidioc_try_fmt_vid_cap = ti_csi2rx_try_fmt_vid_cap,
+ .vidioc_g_fmt_vid_cap = ti_csi2rx_g_fmt_vid_cap,
+ .vidioc_s_fmt_vid_cap = ti_csi2rx_s_fmt_vid_cap,
+ .vidioc_enum_framesizes = ti_csi2rx_enum_framesizes,
+ .vidioc_reqbufs = vb2_ioctl_reqbufs,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
+ .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
+ .vidioc_querybuf = vb2_ioctl_querybuf,
+ .vidioc_qbuf = vb2_ioctl_qbuf,
+ .vidioc_dqbuf = vb2_ioctl_dqbuf,
+ .vidioc_expbuf = vb2_ioctl_expbuf,
+ .vidioc_streamon = vb2_ioctl_streamon,
+ .vidioc_streamoff = vb2_ioctl_streamoff,
+};
+
+static const struct v4l2_file_operations csi_fops = {
+ .owner = THIS_MODULE,
+ .open = v4l2_fh_open,
+ .release = vb2_fop_release,
+ .read = vb2_fop_read,
+ .poll = vb2_fop_poll,
+ .unlocked_ioctl = video_ioctl2,
+ .mmap = vb2_fop_mmap,
+};
+
+static int ti_csi2rx_video_register(struct ti_csi2rx_dev *csi)
+{
+ struct video_device *vdev = &csi->vdev;
+ int ret, src_pad;
+
+ ret = video_register_device(vdev, VFL_TYPE_VIDEO, -1);
+ if (ret)
+ return ret;
+
+ src_pad = media_entity_get_fwnode_pad(&csi->subdev->entity,
+ csi->subdev->fwnode,
+ MEDIA_PAD_FL_SOURCE);
+ if (src_pad < 0) {
+ dev_err(csi->dev, "Couldn't find source pad for subdev\n");
+ return src_pad;
+ }
+
+ ret = media_create_pad_link(&csi->subdev->entity, src_pad,
+ &vdev->entity, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret) {
+ video_unregister_device(vdev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int csi_async_notifier_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *subdev,
+ struct v4l2_async_subdev *asd)
+{
+ struct ti_csi2rx_dev *csi = dev_get_drvdata(notifier->v4l2_dev->dev);
+
+ csi->subdev = subdev;
+
+ return 0;
+}
+
+static int csi_async_notifier_complete(struct v4l2_async_notifier *notifier)
+{
+ struct ti_csi2rx_dev *csi = dev_get_drvdata(notifier->v4l2_dev->dev);
+ int ret;
+
+ ret = ti_csi2rx_video_register(csi);
+ if (ret)
+ return ret;
+
+ return v4l2_device_register_subdev_nodes(&csi->v4l2_dev);
+}
+
+static const struct v4l2_async_notifier_operations csi_async_notifier_ops = {
+ .bound = csi_async_notifier_bound,
+ .complete = csi_async_notifier_complete,
+};
+
+static int ti_csi2rx_init_subdev(struct ti_csi2rx_dev *csi)
+{
+ struct fwnode_handle *fwnode;
+ struct v4l2_async_subdev *asd;
+ struct device_node *node;
+ int ret;
+
+ node = of_get_child_by_name(csi->dev->of_node, "csi-bridge");
+ if (!node)
+ return -EINVAL;
+
+ fwnode = of_fwnode_handle(node);
+ if (!fwnode) {
+ of_node_put(node);
+ return -EINVAL;
+ }
+
+ v4l2_async_notifier_init(&csi->notifier);
+ csi->notifier.ops = &csi_async_notifier_ops;
+
+ asd = v4l2_async_notifier_add_fwnode_subdev(&csi->notifier, fwnode,
+ struct v4l2_async_subdev);
+ of_node_put(node);
+ if (IS_ERR(asd)) {
+ v4l2_async_notifier_cleanup(&csi->notifier);
+ return PTR_ERR(asd);
+ }
+
+ ret = v4l2_async_notifier_register(&csi->v4l2_dev, &csi->notifier);
+ if (ret) {
+ v4l2_async_notifier_cleanup(&csi->notifier);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void ti_csi2rx_setup_shim(struct ti_csi2rx_dev *csi)
+{
+ const struct ti_csi2rx_fmt *fmt;
+ unsigned int reg;
+
+ fmt = find_format_by_pix(csi->v_fmt.fmt.pix.pixelformat);
+ if (!fmt) {
+ dev_err(csi->dev, "Unknown format\n");
+ return;
+ }
+
+ /* De-assert the pixel interface reset. */
+ reg = SHIM_CNTL_PIX_RST;
+ writel(reg, csi->shim + SHIM_CNTL);
+
+ reg = SHIM_DMACNTX_EN;
+ reg |= FIELD_PREP(SHIM_DMACNTX_FMT, fmt->csi_df);
+
+ /*
+ * Using the values from the documentation gives incorrect ordering for
+ * the luma and chroma components. In practice, the "reverse" format
+ * gives the correct image. So for example, if the image is in UYVY, the
+ * reverse would be YVYU.
+ */
+ switch (fmt->fourcc) {
+ case V4L2_PIX_FMT_UYVY:
+ reg |= FIELD_PREP(SHIM_DMACNTX_YUV422,
+ SHIM_DMACNTX_YVYU);
+ break;
+ case V4L2_PIX_FMT_VYUY:
+ reg |= FIELD_PREP(SHIM_DMACNTX_YUV422,
+ SHIM_DMACNTX_YUYV);
+ break;
+ case V4L2_PIX_FMT_YUYV:
+ reg |= FIELD_PREP(SHIM_DMACNTX_YUV422,
+ SHIM_DMACNTX_VYUY);
+ break;
+ case V4L2_PIX_FMT_YVYU:
+ reg |= FIELD_PREP(SHIM_DMACNTX_YUV422,
+ SHIM_DMACNTX_UYVY);
+ break;
+ default:
+ /* Ignore if not YUV 4:2:2 */
+ break;
+ }
+
+ writel(reg, csi->shim + SHIM_DMACNTX);
+
+ reg = FIELD_PREP(SHIM_PSI_CFG0_SRC_TAG, 0) |
+ FIELD_PREP(SHIM_PSI_CFG0_DST_TAG, 1);
+ writel(reg, csi->shim + SHIM_PSI_CFG0);
+}
+
+static void ti_csi2rx_dma_callback(void *param)
+{
+ struct ti_csi2rx_buffer *buf = param;
+ struct ti_csi2rx_dev *csi = buf->csi;
+ struct ti_csi2rx_dma *dma = &csi->dma;
+ unsigned long flags = 0;
+
+ buf->vb.vb2_buf.timestamp = ktime_get_ns();
+ buf->vb.sequence = csi->sequence++;
+
+ spin_lock_irqsave(&dma->lock, flags);
+
+ WARN_ON(dma->curr != buf);
+ vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_DONE);
+
+ /* If there are more buffers to process then start their transfer. */
+ dma->curr = NULL;
+ while (!list_empty(&dma->queue)) {
+ buf = list_entry(dma->queue.next, struct ti_csi2rx_buffer, list);
+ list_del(&buf->list);
+
+ if (ti_csi2rx_start_dma(csi, buf)) {
+ dev_err(csi->dev, "Failed to queue the next buffer for DMA\n");
+ vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+ } else {
+ dma->curr = buf;
+ break;
+ }
+ }
+
+ if (!dma->curr)
+ dma->state = TI_CSI2RX_DMA_IDLE;
+
+ spin_unlock_irqrestore(&dma->lock, flags);
+}
+
+static int ti_csi2rx_start_dma(struct ti_csi2rx_dev *csi,
+ struct ti_csi2rx_buffer *buf)
+{
+ unsigned long addr;
+ struct dma_async_tx_descriptor *desc;
+ size_t len = csi->v_fmt.fmt.pix.sizeimage;
+ dma_cookie_t cookie;
+ int ret = 0;
+
+ addr = vb2_dma_contig_plane_dma_addr(&buf->vb.vb2_buf, 0);
+ desc = dmaengine_prep_slave_single(csi->dma.chan, addr, len,
+ DMA_DEV_TO_MEM,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc)
+ return -EIO;
+
+ desc->callback = ti_csi2rx_dma_callback;
+ desc->callback_param = buf;
+
+ cookie = dmaengine_submit(desc);
+ ret = dma_submit_error(cookie);
+ if (ret)
+ return ret;
+
+ dma_async_issue_pending(csi->dma.chan);
+
+ return 0;
+}
+
+static int ti_csi2rx_queue_setup(struct vb2_queue *q, unsigned int *nbuffers,
+ unsigned int *nplanes, unsigned int sizes[],
+ struct device *alloc_devs[])
+{
+ struct ti_csi2rx_dev *csi = vb2_get_drv_priv(q);
+ unsigned int size = csi->v_fmt.fmt.pix.sizeimage;
+
+ if (*nplanes) {
+ if (sizes[0] < size)
+ return -EINVAL;
+ size = sizes[0];
+ }
+
+ *nplanes = 1;
+ sizes[0] = size;
+
+ return 0;
+}
+
+static int ti_csi2rx_buffer_prepare(struct vb2_buffer *vb)
+{
+ struct ti_csi2rx_dev *csi = vb2_get_drv_priv(vb->vb2_queue);
+ unsigned long size = csi->v_fmt.fmt.pix.sizeimage;
+
+ if (vb2_plane_size(vb, 0) < size) {
+ dev_err(csi->dev, "Data will not fit into plane\n");
+ return -EINVAL;
+ }
+
+ vb2_set_plane_payload(vb, 0, size);
+ return 0;
+}
+
+static void ti_csi2rx_buffer_queue(struct vb2_buffer *vb)
+{
+ struct ti_csi2rx_dev *csi = vb2_get_drv_priv(vb->vb2_queue);
+ struct ti_csi2rx_buffer *buf;
+ struct ti_csi2rx_dma *dma = &csi->dma;
+ unsigned long flags = 0;
+ int ret;
+
+ buf = container_of(vb, struct ti_csi2rx_buffer, vb.vb2_buf);
+ buf->csi = csi;
+
+ spin_lock_irqsave(&dma->lock, flags);
+ /*
+ * Usually the DMA callback takes care of queueing the pending buffers.
+ * But if DMA has stalled due to lack of buffers, restart it now.
+ */
+ if (dma->state == TI_CSI2RX_DMA_IDLE) {
+ ret = ti_csi2rx_start_dma(csi, buf);
+ if (ret) {
+ dev_err(csi->dev, "Failed to start DMA: %d\n", ret);
+ vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
+ goto unlock;
+ }
+
+ dma->curr = buf;
+ dma->state = TI_CSI2RX_DMA_ACTIVE;
+ } else {
+ list_add_tail(&buf->list, &dma->queue);
+ }
+
+unlock:
+ spin_unlock_irqrestore(&dma->lock, flags);
+}
+
+/*
+ * Find the input format. This is done by finding the first device in the
+ * pipeline which can tell us the current format. This could be the sensor, or
+ * this could be another device in the middle which is capable of format
+ * conversions.
+ */
+static int ti_csi2rx_validate_pipeline(struct ti_csi2rx_dev *csi)
+{
+ struct media_pipeline *pipe = &csi->pipe;
+ struct media_entity *entity;
+ struct v4l2_subdev *sd;
+ struct v4l2_subdev_format fmt;
+ struct v4l2_pix_format *pix = &csi->v_fmt.fmt.pix;
+ const struct ti_csi2rx_fmt *ti_fmt;
+ int ret;
+
+ media_graph_walk_start(&pipe->graph, &csi->vdev.entity);
+
+ while ((entity = media_graph_walk_next(&pipe->graph))) {
+ if (!is_media_entity_v4l2_subdev(entity))
+ continue;
+
+ sd = media_entity_to_v4l2_subdev(entity);
+
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ fmt.pad = media_get_pad_index(entity, 0, PAD_SIGNAL_DEFAULT);
+
+ ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt);
+ if (ret && ret != -ENOIOCTLCMD)
+ return ret;
+ if (!ret)
+ break;
+ }
+
+ /* Could not find input format. */
+ if (!entity)
+ return -EPIPE;
+
+ if (fmt.format.width != pix->width)
+ return -EPIPE;
+ if (fmt.format.height != pix->height)
+ return -EPIPE;
+
+ ti_fmt = find_format_by_pix(pix->pixelformat);
+ if (WARN_ON(!ti_fmt))
+ return -EINVAL;
+
+ if (fmt.format.code == MEDIA_BUS_FMT_YUYV8_2X8 ||
+ fmt.format.code == MEDIA_BUS_FMT_VYUY8_2X8 ||
+ fmt.format.code == MEDIA_BUS_FMT_YVYU8_2X8) {
+ dev_err(csi->dev,
+ "Only UYVY input allowed for YUV422 8-bit. Output format can be configured.\n");
+ return -EPIPE;
+ }
+
+ if (fmt.format.code == MEDIA_BUS_FMT_UYVY8_2X8) {
+ /* Format conversion between YUV422 formats can be done. */
+ if (ti_fmt->code != MEDIA_BUS_FMT_UYVY8_2X8 &&
+ ti_fmt->code != MEDIA_BUS_FMT_YUYV8_2X8 &&
+ ti_fmt->code != MEDIA_BUS_FMT_VYUY8_2X8 &&
+ ti_fmt->code != MEDIA_BUS_FMT_YVYU8_2X8)
+ return -EPIPE;
+ } else if (fmt.format.code != ti_fmt->code) {
+ return -EPIPE;
+ }
+
+ if (fmt.format.field != V4L2_FIELD_NONE &&
+ fmt.format.field != V4L2_FIELD_ANY)
+ return -EPIPE;
+
+ return 0;
+}
+
+static int ti_csi2rx_start_streaming(struct vb2_queue *vq, unsigned int count)
+{
+ struct ti_csi2rx_dev *csi = vb2_get_drv_priv(vq);
+ struct ti_csi2rx_dma *dma = &csi->dma;
+ struct ti_csi2rx_buffer *buf, *tmp;
+ unsigned long flags = 0;
+ int ret = 0;
+
+ spin_lock_irqsave(&dma->lock, flags);
+ if (list_empty(&dma->queue))
+ ret = -EIO;
+ spin_unlock_irqrestore(&dma->lock, flags);
+ if (ret)
+ return ret;
+
+ ret = media_pipeline_start(&csi->vdev.entity, &csi->pipe);
+ if (ret)
+ return ret;
+
+ ret = ti_csi2rx_validate_pipeline(csi);
+ if (ret) {
+ dev_err(csi->dev,
+ "Format mismatch between source and video node\n");
+ goto err;
+ }
+
+ ti_csi2rx_setup_shim(csi);
+
+ ret = v4l2_subdev_call(csi->subdev, video, s_stream, 1);
+ if (ret)
+ goto err;
+
+ csi->sequence = 0;
+
+ spin_lock_irqsave(&dma->lock, flags);
+ buf = list_entry(dma->queue.next, struct ti_csi2rx_buffer, list);
+ list_del(&buf->list);
+ dma->state = TI_CSI2RX_DMA_ACTIVE;
+
+ ret = ti_csi2rx_start_dma(csi, buf);
+ if (ret) {
+ dev_err(csi->dev, "Failed to start DMA: %d\n", ret);
+ vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
+ spin_unlock_irqrestore(&dma->lock, flags);
+ goto err_stream;
+ }
+
+ dma->curr = buf;
+ spin_unlock_irqrestore(&dma->lock, flags);
+
+ return 0;
+
+err_stream:
+ v4l2_subdev_call(csi->subdev, video, s_stream, 0);
+err:
+ media_pipeline_stop(&csi->vdev.entity);
+
+ spin_lock_irqsave(&dma->lock, flags);
+ list_for_each_entry_safe(buf, tmp, &dma->queue, list) {
+ list_del(&buf->list);
+ vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
+ }
+ csi->dma.state = TI_CSI2RX_DMA_STOPPED;
+ spin_unlock_irqrestore(&dma->lock, flags);
+
+ return ret;
+}
+
+static void ti_csi2rx_stop_streaming(struct vb2_queue *vq)
+{
+ struct ti_csi2rx_dev *csi = vb2_get_drv_priv(vq);
+ struct ti_csi2rx_buffer *buf = NULL, *tmp;
+ struct ti_csi2rx_dma *dma = &csi->dma;
+ unsigned long flags = 0;
+ int ret;
+
+ media_pipeline_stop(&csi->vdev.entity);
+
+ ret = v4l2_subdev_call(csi->subdev, video, s_stream, 0);
+ if (ret)
+ dev_err(csi->dev, "Failed to stop subdev stream\n");
+
+ writel(0, csi->shim + SHIM_CNTL);
+
+ ret = dmaengine_terminate_sync(csi->dma.chan);
+ if (ret)
+ dev_err(csi->dev, "Failed to stop DMA\n");
+
+ writel(0, csi->shim + SHIM_DMACNTX);
+
+ spin_lock_irqsave(&dma->lock, flags);
+ list_for_each_entry_safe(buf, tmp, &csi->dma.queue, list) {
+ list_del(&buf->list);
+ vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+ }
+
+ if (dma->curr)
+ vb2_buffer_done(&dma->curr->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+
+ dma->curr = NULL;
+ dma->state = TI_CSI2RX_DMA_STOPPED;
+ spin_unlock_irqrestore(&dma->lock, flags);
+}
+
+static const struct vb2_ops csi_vb2_qops = {
+ .queue_setup = ti_csi2rx_queue_setup,
+ .buf_prepare = ti_csi2rx_buffer_prepare,
+ .buf_queue = ti_csi2rx_buffer_queue,
+ .start_streaming = ti_csi2rx_start_streaming,
+ .stop_streaming = ti_csi2rx_stop_streaming,
+ .wait_prepare = vb2_ops_wait_prepare,
+ .wait_finish = vb2_ops_wait_finish,
+};
+
+static int ti_csi2rx_init_vb2q(struct ti_csi2rx_dev *csi)
+{
+ struct vb2_queue *q = &csi->vidq;
+ int ret;
+
+ q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+ q->drv_priv = csi;
+ q->buf_struct_size = sizeof(struct ti_csi2rx_buffer);
+ q->ops = &csi_vb2_qops;
+ q->mem_ops = &vb2_dma_contig_memops;
+ q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+ q->dev = dmaengine_get_dma_device(csi->dma.chan);
+ q->lock = &csi->mutex;
+
+ ret = vb2_queue_init(q);
+ if (ret)
+ return ret;
+
+ csi->vdev.queue = q;
+
+ return 0;
+}
+
+static int ti_csi2rx_init_dma(struct ti_csi2rx_dev *csi)
+{
+ struct dma_slave_config cfg;
+ int ret;
+
+ INIT_LIST_HEAD(&csi->dma.queue);
+ spin_lock_init(&csi->dma.lock);
+
+ csi->dma.state = TI_CSI2RX_DMA_STOPPED;
+
+ csi->dma.chan = dma_request_chan(csi->dev, "rx0");
+ if (IS_ERR(csi->dma.chan))
+ return PTR_ERR(csi->dma.chan);
+
+ memset(&cfg, 0, sizeof(cfg));
+
+ cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_16_BYTES;
+
+ ret = dmaengine_slave_config(csi->dma.chan, &cfg);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int ti_csi2rx_v4l2_init(struct ti_csi2rx_dev *csi)
+{
+ struct media_device *mdev = &csi->mdev;
+ struct video_device *vdev = &csi->vdev;
+ const struct ti_csi2rx_fmt *fmt;
+ struct v4l2_pix_format *pix_fmt = &csi->v_fmt.fmt.pix;
+ int ret;
+
+ fmt = find_format_by_pix(V4L2_PIX_FMT_UYVY);
+ if (!fmt)
+ return -EINVAL;
+
+ pix_fmt->width = 640;
+ pix_fmt->height = 480;
+
+ ti_csi2rx_fill_fmt(fmt, &csi->v_fmt);
+
+ mdev->dev = csi->dev;
+ mdev->hw_revision = 1;
+ strscpy(mdev->model, "TI-CSI2RX", sizeof(mdev->model));
+ snprintf(mdev->bus_info, sizeof(mdev->bus_info), "platform:%s",
+ dev_name(mdev->dev));
+
+ media_device_init(mdev);
+
+ strscpy(vdev->name, TI_CSI2RX_MODULE_NAME, sizeof(vdev->name));
+ vdev->v4l2_dev = &csi->v4l2_dev;
+ vdev->vfl_dir = VFL_DIR_RX;
+ vdev->fops = &csi_fops;
+ vdev->ioctl_ops = &csi_ioctl_ops;
+ vdev->release = video_device_release_empty;
+ vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE |
+ V4L2_CAP_STREAMING | V4L2_CAP_IO_MC;
+ vdev->lock = &csi->mutex;
+ video_set_drvdata(vdev, csi);
+
+ csi->pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(&csi->vdev.entity, 1, &csi->pad);
+ if (ret)
+ return ret;
+
+ csi->v4l2_dev.mdev = mdev;
+
+ ret = v4l2_device_register(csi->dev, &csi->v4l2_dev);
+ if (ret)
+ return ret;
+
+ ret = media_device_register(mdev);
+ if (ret) {
+ v4l2_device_unregister(&csi->v4l2_dev);
+ media_device_cleanup(mdev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void ti_csi2rx_cleanup_dma(struct ti_csi2rx_dev *csi)
+{
+ dma_release_channel(csi->dma.chan);
+}
+
+static void ti_csi2rx_cleanup_v4l2(struct ti_csi2rx_dev *csi)
+{
+ media_device_unregister(&csi->mdev);
+ v4l2_device_unregister(&csi->v4l2_dev);
+ media_device_cleanup(&csi->mdev);
+}
+
+static void ti_csi2rx_cleanup_subdev(struct ti_csi2rx_dev *csi)
+{
+ v4l2_async_notifier_unregister(&csi->notifier);
+ v4l2_async_notifier_cleanup(&csi->notifier);
+}
+
+static void ti_csi2rx_cleanup_vb2q(struct ti_csi2rx_dev *csi)
+{
+ vb2_queue_release(&csi->vidq);
+}
+
+static int ti_csi2rx_probe(struct platform_device *pdev)
+{
+ struct ti_csi2rx_dev *csi;
+ struct resource *res;
+ int ret;
+
+ csi = devm_kzalloc(&pdev->dev, sizeof(*csi), GFP_KERNEL);
+ if (!csi)
+ return -ENOMEM;
+
+ csi->dev = &pdev->dev;
+ platform_set_drvdata(pdev, csi);
+
+ mutex_init(&csi->mutex);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ csi->shim = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(csi->shim))
+ return PTR_ERR(csi->shim);
+
+ ret = ti_csi2rx_init_dma(csi);
+ if (ret)
+ return ret;
+
+ ret = ti_csi2rx_v4l2_init(csi);
+ if (ret)
+ goto err_dma;
+
+ ret = ti_csi2rx_init_vb2q(csi);
+ if (ret)
+ goto err_v4l2;
+
+ ret = ti_csi2rx_init_subdev(csi);
+ if (ret)
+ goto err_vb2q;
+
+ ret = of_platform_populate(csi->dev->of_node, NULL, NULL, csi->dev);
+ if (ret) {
+ dev_err(csi->dev, "Failed to create children: %d\n", ret);
+ goto err_subdev;
+ }
+
+ return 0;
+
+err_subdev:
+ ti_csi2rx_cleanup_subdev(csi);
+err_vb2q:
+ ti_csi2rx_cleanup_vb2q(csi);
+err_v4l2:
+ ti_csi2rx_cleanup_v4l2(csi);
+err_dma:
+ ti_csi2rx_cleanup_dma(csi);
+ return ret;
+}
+
+static int ti_csi2rx_remove(struct platform_device *pdev)
+{
+ struct ti_csi2rx_dev *csi = platform_get_drvdata(pdev);
+
+ if (vb2_is_busy(&csi->vidq))
+ return -EBUSY;
+
+ video_unregister_device(&csi->vdev);
+
+ ti_csi2rx_cleanup_vb2q(csi);
+ ti_csi2rx_cleanup_subdev(csi);
+ ti_csi2rx_cleanup_v4l2(csi);
+ ti_csi2rx_cleanup_dma(csi);
+
+ return 0;
+}
+
+static const struct of_device_id ti_csi2rx_of_match[] = {
+ { .compatible = "ti,j721e-csi2rx", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ti_csi2rx_of_match);
+
+static struct platform_driver ti_csi2rx_pdrv = {
+ .probe = ti_csi2rx_probe,
+ .remove = ti_csi2rx_remove,
+ .driver = {
+ .name = TI_CSI2RX_MODULE_NAME,
+ .of_match_table = ti_csi2rx_of_match,
+ },
+};
+
+module_platform_driver(ti_csi2rx_pdrv);
+
+MODULE_DESCRIPTION("TI J721E CSI2 RX Driver");
+MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION("1.0");
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v3 10/11] media: dt-bindings: Add DT bindings for TI J721E CSI2RX driver
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (8 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 09/11] media: ti: Add CSI2RX support for J721E Pratyush Yadav
@ 2021-06-24 19:21 ` Pratyush Yadav
2021-07-01 14:02 ` Rob Herring
2021-06-24 19:22 ` [PATCH v3 11/11] media: dt-bindings: Convert Cadence CSI2RX binding to YAML Pratyush Yadav
2021-07-01 7:56 ` [PATCH v3 00/11] CSI2RX support on J721E Tomi Valkeinen
11 siblings, 1 reply; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Rob Herring, devicetree,
linux-kernel, linux-media
TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
capture over a CSI-2 bus. The TI CSI2RX platform driver glues all the
parts together.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
(no changes since v2)
Changes in v2:
- Rename to ti,j721e-csi2rx.yaml
- Add an entry in MAINTAINERS.
- Add a description for the binding.
- Change compatible to ti,j721e-csi2rx to make it SoC specific.
- Remove description from dmas, reg, power-domains.
- Remove a limit of 2 from #address-cells and #size-cells.
- Fix add ^ to csi-bridge subnode regex.
- Make ranges mandatory.
- Add unit address in example.
- Add a reference to cdns,csi2rx in csi-bridge subnode.
- Expand the example to include the csi-bridge subnode as well.
- Re-order subject prefixes.
.../bindings/media/ti,j721e-csi2rx.yaml | 101 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 102 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
diff --git a/Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml b/Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
new file mode 100644
index 000000000000..db87cfd65bed
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/ti,j721e-csi2rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI J721E CSI2RX Wrapper Device Tree Bindings
+
+description: |
+ The TI J721E CSI2RX Wrapper is a wrapper around Cadence CSI2RX bridge that
+ enables sending captured frames to memory over PSI-L DMA. In the J721E
+ Technical Reference Manual (SPRUIL1B) it is referred to as "SHIM" under the
+ CSI_RX_IF section.
+
+maintainers:
+ - Pratyush Yadav <p.yadav@ti.com>
+
+properties:
+ compatible:
+ items:
+ - const: ti,j721e-csi2rx
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: rx0
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ranges: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+patternProperties:
+ "^csi-bridge@":
+ type: object
+ description: CSI2 bridge node.
+ $ref: cdns,csi2rx.yaml#
+
+required:
+ - compatible
+ - reg
+ - dmas
+ - dma-names
+ - power-domains
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ ti_csi2rx0: ticsi2rx@4500000 {
+ compatible = "ti,j721e-csi2rx";
+ dmas = <&main_udmap 0x4940>;
+ dma-names = "rx0";
+ reg = <0x4500000 0x1000>;
+ power-domains = <&k3_pds 26 TI_SCI_PD_EXCLUSIVE>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ cdns_csi2rx: csi-bridge@4504000 {
+ compatible = "cdns,csi2rx";
+ reg = <0x4504000 0x1000>;
+ clocks = <&k3_clks 26 2>, <&k3_clks 26 0>, <&k3_clks 26 2>,
+ <&k3_clks 26 2>, <&k3_clks 26 3>, <&k3_clks 26 3>;
+ clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ phys = <&dphy0>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi2_0: port@0 {
+
+ reg = <0>;
+
+ csi2rx0_in_sensor: endpoint {
+ remote-endpoint = <&csi2_cam0>;
+ bus-type = <4>; /* CSI2 DPHY. */
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 96f002b9046d..e9b110115e5f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18471,6 +18471,7 @@ TI J721E CSI2RX DRIVER
M: Pratyush Yadav <p.yadav@ti.com>
L: linux-media@vger.kernel.org
S: Supported
+F: Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
F: drivers/media/platform/ti/j721e-csi2rx/
TI DAVINCI MACHINE SUPPORT
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v3 10/11] media: dt-bindings: Add DT bindings for TI J721E CSI2RX driver
2021-06-24 19:21 ` [PATCH v3 10/11] media: dt-bindings: Add DT bindings for TI J721E CSI2RX driver Pratyush Yadav
@ 2021-07-01 14:02 ` Rob Herring
0 siblings, 0 replies; 26+ messages in thread
From: Rob Herring @ 2021-07-01 14:02 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Vignesh Raghavendra, Tomi Valkeinen, Rob Herring,
Nikhil Devshatwar, linux-media, linux-kernel,
Mauro Carvalho Chehab, devicetree, Laurent Pinchart
On Fri, 25 Jun 2021 00:51:59 +0530, Pratyush Yadav wrote:
> TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
> capture over a CSI-2 bus. The TI CSI2RX platform driver glues all the
> parts together.
>
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Rename to ti,j721e-csi2rx.yaml
> - Add an entry in MAINTAINERS.
> - Add a description for the binding.
> - Change compatible to ti,j721e-csi2rx to make it SoC specific.
> - Remove description from dmas, reg, power-domains.
> - Remove a limit of 2 from #address-cells and #size-cells.
> - Fix add ^ to csi-bridge subnode regex.
> - Make ranges mandatory.
> - Add unit address in example.
> - Add a reference to cdns,csi2rx in csi-bridge subnode.
> - Expand the example to include the csi-bridge subnode as well.
> - Re-order subject prefixes.
>
> .../bindings/media/ti,j721e-csi2rx.yaml | 101 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 102 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/media/cdns,csi2rx.yaml'
xargs: dt-doc-validate: exited with status 255; aborting
make[1]: *** Deleting file 'Documentation/devicetree/bindings/media/ti,j721e-csi2rx.example.dt.yaml'
Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/media/cdns,csi2rx.yaml'
make[1]: *** [scripts/Makefile.lib:380: Documentation/devicetree/bindings/media/ti,j721e-csi2rx.example.dt.yaml] Error 255
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1416: dt_binding_check] Error 2
\ndoc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1496774
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v3 11/11] media: dt-bindings: Convert Cadence CSI2RX binding to YAML
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (9 preceding siblings ...)
2021-06-24 19:21 ` [PATCH v3 10/11] media: dt-bindings: Add DT bindings for TI J721E CSI2RX driver Pratyush Yadav
@ 2021-06-24 19:22 ` Pratyush Yadav
2021-07-01 18:55 ` Rob Herring
2021-07-01 7:56 ` [PATCH v3 00/11] CSI2RX support on J721E Tomi Valkeinen
11 siblings, 1 reply; 26+ messages in thread
From: Pratyush Yadav @ 2021-06-24 19:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Tomi Valkeinen,
Nikhil Devshatwar, Pratyush Yadav, Maxime Ripard, Rob Herring,
devicetree, linux-kernel, linux-media
Convert the Cadence CSI2RX binding to use YAML schema.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
Changes in v3:
- Add compatible: contains: const: cdns,csi2rx to allow SoC specific
compatible.
- Add more constraints for data-lanes property.
Changes in v2:
- New in v2.
.../devicetree/bindings/media/cdns,csi2rx.txt | 100 -----------
.../bindings/media/cdns,csi2rx.yaml | 169 ++++++++++++++++++
2 files changed, 169 insertions(+), 100 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
deleted file mode 100644
index 6b02a0657ad9..000000000000
--- a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Cadence MIPI-CSI2 RX controller
-===============================
-
-The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
-lanes in input, and 4 different pixel streams in output.
-
-Required properties:
- - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
- - reg: base address and size of the memory mapped region
- - clocks: phandles to the clocks driving the controller
- - clock-names: must contain:
- * sys_clk: main clock
- * p_clk: register bank clock
- * pixel_if[0-3]_clk: pixel stream output clock, one for each stream
- implemented in hardware, between 0 and 3
-
-Optional properties:
- - phys: phandle to the external D-PHY, phy-names must be provided
- - phy-names: must contain "dphy", if the implementation uses an
- external D-PHY
-
-Required subnodes:
- - ports: A ports node with 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:
-
- Port Description
- -----------------------------
- 0 CSI-2 input
- 1 Stream 0 output
- 2 Stream 1 output
- 3 Stream 2 output
- 4 Stream 3 output
-
- The stream output port nodes are optional if they are not
- connected to anything at the hardware level or implemented
- in the design.Since there is only one endpoint per port,
- the endpoints are not numbered.
-
-
-Example:
-
-csi2rx: csi-bridge@0d060000 {
- compatible = "cdns,csi2rx";
- reg = <0x0d060000 0x1000>;
- clocks = <&byteclock>, <&byteclock>
- <&coreclock>, <&coreclock>,
- <&coreclock>, <&coreclock>;
- clock-names = "sys_clk", "p_clk",
- "pixel_if0_clk", "pixel_if1_clk",
- "pixel_if2_clk", "pixel_if3_clk";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- csi2rx_in_sensor: endpoint {
- remote-endpoint = <&sensor_out_csi2rx>;
- clock-lanes = <0>;
- data-lanes = <1 2>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- csi2rx_out_grabber0: endpoint {
- remote-endpoint = <&grabber0_in_csi2rx>;
- };
- };
-
- port@2 {
- reg = <2>;
-
- csi2rx_out_grabber1: endpoint {
- remote-endpoint = <&grabber1_in_csi2rx>;
- };
- };
-
- port@3 {
- reg = <3>;
-
- csi2rx_out_grabber2: endpoint {
- remote-endpoint = <&grabber2_in_csi2rx>;
- };
- };
-
- port@4 {
- reg = <4>;
-
- csi2rx_out_grabber3: endpoint {
- remote-endpoint = <&grabber3_in_csi2rx>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
new file mode 100644
index 000000000000..8e42c9fdaaa3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cdns,csi2rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MIPI-CSI2 RX controller
+
+description: |
+ The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+ lanes in input, and 4 different pixel streams in output.
+
+maintainers:
+ - Pratyush Yadav <p.yadav@ti.com>
+
+properties:
+ compatible:
+ contains:
+ const: cdns,csi2rx
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 6
+
+ clock-names:
+ minItems: 3
+ maxItems: 6
+ items:
+ - const: sys_clk # main clock
+ - const: p_clk # register bank clock
+ - const: pixel_if0_clk # pixel stream 0 output clock
+ - const: pixel_if1_clk # pixel stream 1 output clock
+ - const: pixel_if2_clk # pixel stream 2 output clock
+ - const: pixel_if3_clk # pixel stream 3 output clock
+
+ phys:
+ maxItems: 1
+ description: phandle to the external D-PHY
+
+ phy-names:
+ items:
+ - const: dphy
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 input
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ uniqueItems: true
+ items:
+ maximum: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Stream 0 output
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Stream 1 output
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Stream 2 output
+
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Stream 3 output
+
+ required:
+ - port@0
+
+
+dependencies:
+ phys: [ 'phy-names' ]
+ phy-names: [ 'phys' ]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ csi2rx: csi-bridge@d060000 {
+ compatible = "cdns,csi2rx";
+ reg = <0x0d060000 0x1000>;
+ clocks = <&byteclock>, <&byteclock>,
+ <&coreclock>, <&coreclock>,
+ <&coreclock>, <&coreclock>;
+ clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+ phys = <&dphy0>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csi2rx_in_sensor: endpoint {
+ remote-endpoint = <&sensor_out_csi2rx>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csi2rx_out_grabber0: endpoint {
+ remote-endpoint = <&grabber0_in_csi2rx>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ csi2rx_out_grabber1: endpoint {
+ remote-endpoint = <&grabber1_in_csi2rx>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ csi2rx_out_grabber2: endpoint {
+ remote-endpoint = <&grabber2_in_csi2rx>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ csi2rx_out_grabber3: endpoint {
+ remote-endpoint = <&grabber3_in_csi2rx>;
+ };
+ };
+ };
+ };
--
2.30.0
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v3 11/11] media: dt-bindings: Convert Cadence CSI2RX binding to YAML
2021-06-24 19:22 ` [PATCH v3 11/11] media: dt-bindings: Convert Cadence CSI2RX binding to YAML Pratyush Yadav
@ 2021-07-01 18:55 ` Rob Herring
2021-07-07 18:45 ` Pratyush Yadav
0 siblings, 1 reply; 26+ messages in thread
From: Rob Herring @ 2021-07-01 18:55 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Vignesh Raghavendra,
Tomi Valkeinen, Nikhil Devshatwar, Maxime Ripard, devicetree,
linux-kernel, linux-media
On Fri, Jun 25, 2021 at 12:52:00AM +0530, Pratyush Yadav wrote:
> Convert the Cadence CSI2RX binding to use YAML schema.
>
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
>
> ---
>
> Changes in v3:
> - Add compatible: contains: const: cdns,csi2rx to allow SoC specific
> compatible.
> - Add more constraints for data-lanes property.
>
> Changes in v2:
> - New in v2.
>
> .../devicetree/bindings/media/cdns,csi2rx.txt | 100 -----------
> .../bindings/media/cdns,csi2rx.yaml | 169 ++++++++++++++++++
> 2 files changed, 169 insertions(+), 100 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> deleted file mode 100644
> index 6b02a0657ad9..000000000000
> --- a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> +++ /dev/null
> @@ -1,100 +0,0 @@
> -Cadence MIPI-CSI2 RX controller
> -===============================
> -
> -The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
> -lanes in input, and 4 different pixel streams in output.
> -
> -Required properties:
> - - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
> - - reg: base address and size of the memory mapped region
> - - clocks: phandles to the clocks driving the controller
> - - clock-names: must contain:
> - * sys_clk: main clock
> - * p_clk: register bank clock
> - * pixel_if[0-3]_clk: pixel stream output clock, one for each stream
> - implemented in hardware, between 0 and 3
> -
> -Optional properties:
> - - phys: phandle to the external D-PHY, phy-names must be provided
> - - phy-names: must contain "dphy", if the implementation uses an
> - external D-PHY
> -
> -Required subnodes:
> - - ports: A ports node with 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:
> -
> - Port Description
> - -----------------------------
> - 0 CSI-2 input
> - 1 Stream 0 output
> - 2 Stream 1 output
> - 3 Stream 2 output
> - 4 Stream 3 output
> -
> - The stream output port nodes are optional if they are not
> - connected to anything at the hardware level or implemented
> - in the design.Since there is only one endpoint per port,
> - the endpoints are not numbered.
> -
> -
> -Example:
> -
> -csi2rx: csi-bridge@0d060000 {
> - compatible = "cdns,csi2rx";
> - reg = <0x0d060000 0x1000>;
> - clocks = <&byteclock>, <&byteclock>
> - <&coreclock>, <&coreclock>,
> - <&coreclock>, <&coreclock>;
> - clock-names = "sys_clk", "p_clk",
> - "pixel_if0_clk", "pixel_if1_clk",
> - "pixel_if2_clk", "pixel_if3_clk";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> -
> - csi2rx_in_sensor: endpoint {
> - remote-endpoint = <&sensor_out_csi2rx>;
> - clock-lanes = <0>;
> - data-lanes = <1 2>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> -
> - csi2rx_out_grabber0: endpoint {
> - remote-endpoint = <&grabber0_in_csi2rx>;
> - };
> - };
> -
> - port@2 {
> - reg = <2>;
> -
> - csi2rx_out_grabber1: endpoint {
> - remote-endpoint = <&grabber1_in_csi2rx>;
> - };
> - };
> -
> - port@3 {
> - reg = <3>;
> -
> - csi2rx_out_grabber2: endpoint {
> - remote-endpoint = <&grabber2_in_csi2rx>;
> - };
> - };
> -
> - port@4 {
> - reg = <4>;
> -
> - csi2rx_out_grabber3: endpoint {
> - remote-endpoint = <&grabber3_in_csi2rx>;
> - };
> - };
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
> new file mode 100644
> index 000000000000..8e42c9fdaaa3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
> @@ -0,0 +1,169 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/cdns,csi2rx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence MIPI-CSI2 RX controller
> +
> +description: |
> + The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
> + lanes in input, and 4 different pixel streams in output.
> +
> +maintainers:
> + - Pratyush Yadav <p.yadav@ti.com>
> +
> +properties:
> + compatible:
> + contains:
> + const: cdns,csi2rx
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + minItems: 3
> + maxItems: 6
> +
> + clock-names:
> + minItems: 3
> + maxItems: 6
maxItems can be dropped here. Implied by items length.
> + items:
> + - const: sys_clk # main clock
> + - const: p_clk # register bank clock
> + - const: pixel_if0_clk # pixel stream 0 output clock
> + - const: pixel_if1_clk # pixel stream 1 output clock
> + - const: pixel_if2_clk # pixel stream 2 output clock
> + - const: pixel_if3_clk # pixel stream 3 output clock
> +
> + phys:
> + maxItems: 1
> + description: phandle to the external D-PHY
> +
> + phy-names:
> + items:
> + - const: dphy
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: CSI-2 input
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
Don't need a type here.
> + minItems: 1
> + maxItems: 4
> + uniqueItems: true
uniqueItems should be added in video-interfaces.yaml.
> + items:
> + maximum: 4
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Stream 0 output
> +
> + port@2:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Stream 1 output
> +
> + port@3:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Stream 2 output
> +
> + port@4:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Stream 3 output
> +
> + required:
> + - port@0
> +
> +
> +dependencies:
> + phys: [ 'phy-names' ]
> + phy-names: [ 'phys' ]
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + csi2rx: csi-bridge@d060000 {
> + compatible = "cdns,csi2rx";
> + reg = <0x0d060000 0x1000>;
> + clocks = <&byteclock>, <&byteclock>,
> + <&coreclock>, <&coreclock>,
> + <&coreclock>, <&coreclock>;
> + clock-names = "sys_clk", "p_clk",
> + "pixel_if0_clk", "pixel_if1_clk",
> + "pixel_if2_clk", "pixel_if3_clk";
> + phys = <&dphy0>;
> + phy-names = "dphy";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + csi2rx_in_sensor: endpoint {
> + remote-endpoint = <&sensor_out_csi2rx>;
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + csi2rx_out_grabber0: endpoint {
> + remote-endpoint = <&grabber0_in_csi2rx>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + csi2rx_out_grabber1: endpoint {
> + remote-endpoint = <&grabber1_in_csi2rx>;
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> +
> + csi2rx_out_grabber2: endpoint {
> + remote-endpoint = <&grabber2_in_csi2rx>;
> + };
> + };
> +
> + port@4 {
> + reg = <4>;
> +
> + csi2rx_out_grabber3: endpoint {
> + remote-endpoint = <&grabber3_in_csi2rx>;
> + };
> + };
> + };
> + };
> --
> 2.30.0
>
>
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v3 11/11] media: dt-bindings: Convert Cadence CSI2RX binding to YAML
2021-07-01 18:55 ` Rob Herring
@ 2021-07-07 18:45 ` Pratyush Yadav
0 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-07-07 18:45 UTC (permalink / raw)
To: Rob Herring
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Vignesh Raghavendra,
Tomi Valkeinen, Nikhil Devshatwar, Maxime Ripard, devicetree,
linux-kernel, linux-media
On 01/07/21 12:55PM, Rob Herring wrote:
> On Fri, Jun 25, 2021 at 12:52:00AM +0530, Pratyush Yadav wrote:
> > Convert the Cadence CSI2RX binding to use YAML schema.
> >
> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> >
> > ---
> >
> > Changes in v3:
> > - Add compatible: contains: const: cdns,csi2rx to allow SoC specific
> > compatible.
> > - Add more constraints for data-lanes property.
> >
> > Changes in v2:
> > - New in v2.
> >
> > .../devicetree/bindings/media/cdns,csi2rx.txt | 100 -----------
> > .../bindings/media/cdns,csi2rx.yaml | 169 ++++++++++++++++++
> > 2 files changed, 169 insertions(+), 100 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> > create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> > deleted file mode 100644
> > index 6b02a0657ad9..000000000000
> > --- a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> > +++ /dev/null
> > @@ -1,100 +0,0 @@
> > -Cadence MIPI-CSI2 RX controller
> > -===============================
> > -
> > -The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
> > -lanes in input, and 4 different pixel streams in output.
> > -
> > -Required properties:
> > - - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
> > - - reg: base address and size of the memory mapped region
> > - - clocks: phandles to the clocks driving the controller
> > - - clock-names: must contain:
> > - * sys_clk: main clock
> > - * p_clk: register bank clock
> > - * pixel_if[0-3]_clk: pixel stream output clock, one for each stream
> > - implemented in hardware, between 0 and 3
> > -
> > -Optional properties:
> > - - phys: phandle to the external D-PHY, phy-names must be provided
> > - - phy-names: must contain "dphy", if the implementation uses an
> > - external D-PHY
> > -
> > -Required subnodes:
> > - - ports: A ports node with 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:
> > -
> > - Port Description
> > - -----------------------------
> > - 0 CSI-2 input
> > - 1 Stream 0 output
> > - 2 Stream 1 output
> > - 3 Stream 2 output
> > - 4 Stream 3 output
> > -
> > - The stream output port nodes are optional if they are not
> > - connected to anything at the hardware level or implemented
> > - in the design.Since there is only one endpoint per port,
> > - the endpoints are not numbered.
> > -
> > -
> > -Example:
> > -
> > -csi2rx: csi-bridge@0d060000 {
> > - compatible = "cdns,csi2rx";
> > - reg = <0x0d060000 0x1000>;
> > - clocks = <&byteclock>, <&byteclock>
> > - <&coreclock>, <&coreclock>,
> > - <&coreclock>, <&coreclock>;
> > - clock-names = "sys_clk", "p_clk",
> > - "pixel_if0_clk", "pixel_if1_clk",
> > - "pixel_if2_clk", "pixel_if3_clk";
> > -
> > - ports {
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - port@0 {
> > - reg = <0>;
> > -
> > - csi2rx_in_sensor: endpoint {
> > - remote-endpoint = <&sensor_out_csi2rx>;
> > - clock-lanes = <0>;
> > - data-lanes = <1 2>;
> > - };
> > - };
> > -
> > - port@1 {
> > - reg = <1>;
> > -
> > - csi2rx_out_grabber0: endpoint {
> > - remote-endpoint = <&grabber0_in_csi2rx>;
> > - };
> > - };
> > -
> > - port@2 {
> > - reg = <2>;
> > -
> > - csi2rx_out_grabber1: endpoint {
> > - remote-endpoint = <&grabber1_in_csi2rx>;
> > - };
> > - };
> > -
> > - port@3 {
> > - reg = <3>;
> > -
> > - csi2rx_out_grabber2: endpoint {
> > - remote-endpoint = <&grabber2_in_csi2rx>;
> > - };
> > - };
> > -
> > - port@4 {
> > - reg = <4>;
> > -
> > - csi2rx_out_grabber3: endpoint {
> > - remote-endpoint = <&grabber3_in_csi2rx>;
> > - };
> > - };
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
> > new file mode 100644
> > index 000000000000..8e42c9fdaaa3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
> > @@ -0,0 +1,169 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/cdns,csi2rx.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Cadence MIPI-CSI2 RX controller
> > +
> > +description: |
> > + The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
> > + lanes in input, and 4 different pixel streams in output.
> > +
> > +maintainers:
> > + - Pratyush Yadav <p.yadav@ti.com>
> > +
> > +properties:
> > + compatible:
> > + contains:
> > + const: cdns,csi2rx
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + minItems: 3
> > + maxItems: 6
> > +
> > + clock-names:
> > + minItems: 3
> > + maxItems: 6
>
> maxItems can be dropped here. Implied by items length.
Ok.
>
> > + items:
> > + - const: sys_clk # main clock
> > + - const: p_clk # register bank clock
> > + - const: pixel_if0_clk # pixel stream 0 output clock
> > + - const: pixel_if1_clk # pixel stream 1 output clock
> > + - const: pixel_if2_clk # pixel stream 2 output clock
> > + - const: pixel_if3_clk # pixel stream 3 output clock
> > +
> > + phys:
> > + maxItems: 1
> > + description: phandle to the external D-PHY
> > +
> > + phy-names:
> > + items:
> > + - const: dphy
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/$defs/port-base
> > + unevaluatedProperties: false
> > + description: CSI-2 input
> > +
> > + properties:
> > + endpoint:
> > + $ref: video-interfaces.yaml#
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + clock-lanes:
> > + maxItems: 1
> > +
> > + data-lanes:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
>
> Don't need a type here.
Ok.
>
> > + minItems: 1
> > + maxItems: 4
> > + uniqueItems: true
>
> uniqueItems should be added in video-interfaces.yaml.
Ok. I will send that change as a separate patch independent of this
series.
Thanks for reviewing.
>
> > + items:
> > + maximum: 4
> > +
> > + required:
> > + - clock-lanes
> > + - data-lanes
> > +
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 00/11] CSI2RX support on J721E
2021-06-24 19:21 [PATCH v3 00/11] CSI2RX support on J721E Pratyush Yadav
` (10 preceding siblings ...)
2021-06-24 19:22 ` [PATCH v3 11/11] media: dt-bindings: Convert Cadence CSI2RX binding to YAML Pratyush Yadav
@ 2021-07-01 7:56 ` Tomi Valkeinen
2021-07-07 18:56 ` Pratyush Yadav
2021-09-09 18:11 ` Pratyush Yadav
11 siblings, 2 replies; 26+ messages in thread
From: Tomi Valkeinen @ 2021-07-01 7:56 UTC (permalink / raw)
To: Pratyush Yadav, Mauro Carvalho Chehab
Cc: Laurent Pinchart, Vignesh Raghavendra, Nikhil Devshatwar,
Alexandre Courbot, Arnd Bergmann, Benoit Parrot, Bert Vermeulen,
Dikshita Agarwal, Dongchun Zhu, Eugen Hristev, Ezequiel Garcia,
Fabio Estevam, Georgi Djakov, Hans Verkuil, Helen Koike,
Jacopo Mondi, Jiapeng Chong, Kieran Bingham, Kieran Bingham,
Lad Prabhakar, Martina Krasteva, Maxime Ripard, Michael Tretter,
Mirela Rabulea, Neil Armstrong, Niklas Söderlund,
Paul Kocialkowski, Qiushi Wu, Raag Jadav, Ricardo Ribalda,
Rob Herring, Sakari Ailus, Stanimir Varbanov, Steve Longerbeam,
Thomas Bogendoerfer, Tianshu Qiu, Yang Yingliang, Zou Wei,
devicetree, linux-kernel, linux-media
Hi Pratyush,
On 24/06/2021 22:21, Pratyush Yadav wrote:
> Hi,
>
> This series adds support for CSI2 capture on J721E. It includes some
> fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
> driver, and finally adds the TI CSI2RX wrapper driver.
>
> This series used to include the DPHY and DMA engine patches as well, but
> they have been split off to facilitate easier merging. Patch 3 is
> build-dependent on the DPHY series [0].
>
> The DMA engine patch [1] can go in any order since that is only a run
> time dependency. Things probably won't work without it but it will still
> build fine.
>
> Tested on TI's J721E with OV5640 sensor.
I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
Here are some notes from quick tests:
Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
When I load the modules, I get:
[ 237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c
I get a warning from DMA-API debug:
[ 298.774236] ------------[ cut here ]------------
[ 298.779109] DMA-API: ti-udma 31150000.dma-controller: mapping sg segment longer than device claims to support [len=1900544] [max=65536]
[ 298.791331] WARNING: CPU: 1 PID: 605 at kernel/dma/debug.c:1172 debug_dma_map_sg+0x304/0x390
[ 298.799764] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
[ 298.824656] CPU: 1 PID: 605 Comm: cam-mplex.py Not tainted 5.13.0-rc4-00417-g3331992006e9 #3
[ 298.833079] Hardware name: Texas Instruments K3 J721E SoC (DT)
[ 298.838900] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
[ 298.844895] pc : debug_dma_map_sg+0x304/0x390
[ 298.849245] lr : debug_dma_map_sg+0x304/0x390
[ 298.853593] sp : ffff800014dcf730
[ 298.856899] x29: ffff800014dcf730 x28: ffff00080154a880 x27: ffffffffffffffff
[ 298.864032] x26: 0000000000000000 x25: 0000000000000002 x24: 0000000000000001
[ 298.871164] x23: ffff80001163abe0 x22: 0000000000000000 x21: 0000000000000001
[ 298.878295] x20: ffff000801fa3010 x19: ffff000807585300 x18: 0000000000000000
[ 298.885426] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000030
[ 298.892558] x14: 6e61687420726567 x13: 6e6f6c20746e656d x12: ffff800011a91578
[ 298.899689] x11: 00000000000c0000 x10: ffff8000116b18f8 x9 : ffff8000100eabe0
[ 298.906820] x8 : ffff8000116598f8 x7 : ffff8000116b18f8 x6 : 0000000000000001
[ 298.913951] x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800011260000
[ 298.921082] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080673b000
[ 298.928214] Call trace:
[ 298.930653] debug_dma_map_sg+0x304/0x390
[ 298.934655] dma_map_sg_attrs+0x70/0xb0
[ 298.938487] drm_gem_map_dma_buf+0x6c/0xf0 [drm]
[ 298.943185] __map_dma_buf+0x28/0x80
[ 298.946756] dma_buf_map_attachment+0xe4/0x220
[ 298.951191] vb2_dc_map_dmabuf+0x3c/0x150
[ 298.955194] __prepare_dmabuf+0x1dc/0x514
[ 298.959197] __buf_prepare+0x1a0/0x25c
[ 298.962938] vb2_core_qbuf+0x3d4/0x72c
[ 298.966679] vb2_qbuf+0x9c/0xf4
[ 298.969814] vb2_ioctl_qbuf+0x68/0x7c
[ 298.973468] v4l_qbuf+0x54/0x70
[ 298.976603] __video_do_ioctl+0x194/0x400
[ 298.980603] video_usercopy+0x374/0xa14
[ 298.984431] video_ioctl2+0x24/0x4c
[ 298.987912] v4l2_ioctl+0x4c/0x70
[ 298.991222] __arm64_sys_ioctl+0xb4/0xfc
[ 298.995138] invoke_syscall+0x50/0x120
[ 298.998885] el0_svc_common.constprop.0+0x68/0x104
[ 299.003667] do_el0_svc+0x30/0x9c
[ 299.006976] el0_svc+0x2c/0x54
[ 299.010025] el0_sync_handler+0x1a8/0x1ac
[ 299.014025] el0_sync+0x198/0x1c0
[ 299.017333] irq event stamp: 98582
[ 299.020727] hardirqs last enabled at (98581): [<ffff8000100ec2bc>] console_unlock+0x53c/0x6b4
[ 299.029325] hardirqs last disabled at (98582): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
[ 299.037144] softirqs last enabled at (98568): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
[ 299.045565] softirqs last disabled at (98413): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
[ 299.054164] ---[ end trace bfe019acb2a9a04f ]---
I get a warning from media graph walk:
[ 299.066357] WARNING: CPU: 1 PID: 605 at drivers/media/mc/mc-entity.c:343 media_graph_walk_next+0x268/0x2cc
[ 299.076005] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
[ 299.100889] CPU: 1 PID: 605 Comm: cam-mplex.py Tainted: G W 5.13.0-rc4-00417-g3331992006e9 #3
[ 299.110698] Hardware name: Texas Instruments K3 J721E SoC (DT)
[ 299.116518] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
[ 299.122513] pc : media_graph_walk_next+0x268/0x2cc
[ 299.127295] lr : media_graph_walk_next+0x264/0x2cc
[ 299.132076] sp : ffff800014dcfa40
[ 299.135382] x29: ffff800014dcfa40 x28: 0000000000000000 x27: 0000000040045612
[ 299.142514] x26: 0000000000000001 x25: ffff800010d890f0 x24: ffff0008055c8148
[ 299.149645] x23: ffff0008055c8148 x22: ffff80001182bc40 x21: ffff80001163e2e8
[ 299.156776] x20: ffff80001182bbd0 x19: ffff0008055c8cb8 x18: 0000000000000000
[ 299.163907] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000028
[ 299.171037] x14: 0000000000000002 x13: 0000000000007e6f x12: 0000000000000002
[ 299.178169] x11: 0000000000040464 x10: 00000000916d3a5c x9 : ffff8000093110c0
[ 299.185301] x8 : ffff000807583d88 x7 : 0000000000000000 x6 : ffff00080673b900
[ 299.192431] x5 : 000000000000000a x4 : ffff000807583d80 x3 : ffff800011260000
[ 299.199562] x2 : 00000000000000c0 x1 : 00000000000000c0 x0 : 0000000000000000
[ 299.206693] Call trace:
[ 299.209133] media_graph_walk_next+0x268/0x2cc
[ 299.213568] ti_csi2rx_start_streaming+0xe0/0x5c8 [j721e_csi2rx]
[ 299.219569] vb2_start_streaming+0x70/0x160
[ 299.223745] vb2_core_streamon+0x9c/0x1a0
[ 299.227745] vb2_ioctl_streamon+0x68/0xbc
[ 299.231747] v4l_streamon+0x30/0x40
[ 299.235230] __video_do_ioctl+0x194/0x400
[ 299.239230] video_usercopy+0x374/0xa14
[ 299.243058] video_ioctl2+0x24/0x4c
[ 299.246539] v4l2_ioctl+0x4c/0x70
[ 299.249847] __arm64_sys_ioctl+0xb4/0xfc
[ 299.253764] invoke_syscall+0x50/0x120
[ 299.257508] el0_svc_common.constprop.0+0x68/0x104
[ 299.262291] do_el0_svc+0x30/0x9c
[ 299.265599] el0_svc+0x2c/0x54
[ 299.268648] el0_sync_handler+0x1a8/0x1ac
[ 299.272647] el0_sync+0x198/0x1c0
[ 299.275956] irq event stamp: 98754
[ 299.279349] hardirqs last enabled at (98753): [<ffff800010bf216c>] _raw_spin_unlock_irqrestore+0x9c/0xc0
[ 299.288900] hardirqs last disabled at (98754): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
[ 299.296716] softirqs last enabled at (98606): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
[ 299.305138] softirqs last disabled at (98585): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
Unloading the modules gives me:
ERROR: Unhandled External Abort received on 0x80000001 from S-EL1
ERROR: exception reason=0 syndrome=0xbf000000
Unhandled Exception from EL1
x0 = 0x0000000000000000
x1 = 0xffff00080564c000
x2 = 0xffff800014314000
x3 = 0xffff800011260000
x4 = 0x0000000000000001
x5 = 0x0000000000000001
x6 = 0x0000000000000001
x7 = 0x0000000000000000
x8 = 0xffff8000118870c0
x9 = 0xffff800010bf2140
x10 = 0x000000008260a2b7
x11 = 0x00000000000c821c
x12 = 0xffff800011a91578
x13 = 0x0000000000008b8e
x14 = 0x0000000000000006
x15 = 0x0000000000000028
x16 = 0x0000000000000000
x17 = 0x0000000000000000
x18 = 0x00000000fffffffb
x19 = 0xffff00080634cc00
x20 = 0x0000000000000000
x21 = 0xffff0008051eed00
x22 = 0xffff00080555f010
x23 = 0xffff00080555f000
x24 = 0xffff8000092e0058
x25 = 0x0000000000000047
x26 = 0xffff8000116d71d8
x27 = 0xffff8000092e0350
x28 = 0xffff8000092e0148
x29 = 0xffff800014d2f850
x30 = 0xffff8000092b0430
scr_el3 = 0x000000000000073d
sctlr_el3 = 0x0000000030cd183f
cptr_el3 = 0x0000000000000000
tcr_el3 = 0x0000000080803520
daif = 0x00000000000002c0
mair_el3 = 0x00000000004404ff
spsr_el3 = 0x0000000000000005
elr_el3 = 0xffff8000092b0440
ttbr0_el3 = 0x0000000070010b00
esr_el3 = 0x00000000bf000000
far_el3 = 0x0000000000000000
spsr_el1 = 0x0000000060000005
elr_el1 = 0xffff800010be5e10
spsr_abt = 0x0000000000000000
spsr_und = 0x0000000000000000
spsr_irq = 0x0000000000000000
spsr_fiq = 0x0000000000000000
sctlr_el1 = 0x0000000034d4d91d
actlr_el1 = 0x0000000000000000
cpacr_el1 = 0x0000000000300000
csselr_el1 = 0x0000000000000000
sp_el1 = 0xffff800014d2f850
esr_el1 = 0x0000000056000000
ttbr0_el1 = 0x00000008826e4a00
ttbr1_el1 = 0x076a000083180000
mair_el1 = 0x000c0400bb44ffff
amair_el1 = 0x0000000000000000
tcr_el1 = 0x00000034f5d07590
tpidr_el1 = 0xffff80086e790000
tpidr_el0 = 0x0000ffff980d6920
tpidrro_el0 = 0x0000000000000000
par_el1 = 0x0000000000000000
mpidr_el1 = 0x0000000080000001
afsr0_el1 = 0x0000000000000000
afsr1_el1 = 0x0000000000000000
contextidr_el1 = 0x0000000000000000
vbar_el1 = 0xffff800010011000
cntp_ctl_el0 = 0x0000000000000005
cntp_cval_el0 = 0x000000294b786efd
cntv_ctl_el0 = 0x0000000000000000
cntv_cval_el0 = 0x0000000000000000
cntkctl_el1 = 0x00000000000000d6
sp_el0 = 0x000000007000abd0
isr_el1 = 0x0000000000000040
dacr32_el2 = 0x0000000000000000
ifsr32_el2 = 0x0000000000000000
cpuectlr_el1 = 0x0000001b00000040
cpumerrsr_el1 = 0x0000000000000000
l2merrsr_el1 = 0x0000000000000000
Tomi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v3 00/11] CSI2RX support on J721E
2021-07-01 7:56 ` [PATCH v3 00/11] CSI2RX support on J721E Tomi Valkeinen
@ 2021-07-07 18:56 ` Pratyush Yadav
2021-07-08 8:19 ` Jacopo Mondi
2021-09-09 18:11 ` Pratyush Yadav
1 sibling, 1 reply; 26+ messages in thread
From: Pratyush Yadav @ 2021-07-07 18:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Vignesh Raghavendra,
Nikhil Devshatwar, Alexandre Courbot, Arnd Bergmann,
Benoit Parrot, Bert Vermeulen, Dikshita Agarwal, Dongchun Zhu,
Eugen Hristev, Ezequiel Garcia, Fabio Estevam, Georgi Djakov,
Hans Verkuil, Helen Koike, Jacopo Mondi, Jiapeng Chong,
Kieran Bingham, Kieran Bingham, Lad Prabhakar, Martina Krasteva,
Maxime Ripard, Michael Tretter, Mirela Rabulea, Neil Armstrong,
Niklas Söderlund, Paul Kocialkowski, Qiushi Wu, Raag Jadav,
Ricardo Ribalda, Rob Herring, Sakari Ailus, Stanimir Varbanov,
Steve Longerbeam, Thomas Bogendoerfer, Tianshu Qiu,
Yang Yingliang, Zou Wei, devicetree, linux-kernel, linux-media
Hi Tomi,
Thanks for looking into the patches.
On 01/07/21 10:56AM, Tomi Valkeinen wrote:
> Hi Pratyush,
>
> On 24/06/2021 22:21, Pratyush Yadav wrote:
> > Hi,
> >
> > This series adds support for CSI2 capture on J721E. It includes some
> > fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
> > driver, and finally adds the TI CSI2RX wrapper driver.
> >
> > This series used to include the DPHY and DMA engine patches as well, but
> > they have been split off to facilitate easier merging. Patch 3 is
> > build-dependent on the DPHY series [0].
> >
> > The DMA engine patch [1] can go in any order since that is only a run
> > time dependency. Things probably won't work without it but it will still
> > build fine.
> >
> > Tested on TI's J721E with OV5640 sensor.
>
> I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
Please use https://github.com/prati0100/linux-next/ branch "capture"
I will include the link in the cover letter from next version onwards.
>
> Here are some notes from quick tests:
>
> Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
I see this as well. I figured this had something to do with the sensor.
Which clock could cause this? I don't think anything in Cadence CSI2RX
bridge is sensitive to frame rate.
>
> When I load the modules, I get:
>
> [ 237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c
Ok, I enabled lockdep configs and I see it too. Will look into it.
>
> I get a warning from DMA-API debug:
>
> [ 298.774236] ------------[ cut here ]------------
> [ 298.779109] DMA-API: ti-udma 31150000.dma-controller: mapping sg segment longer than device claims to support [len=1900544] [max=65536]
> [ 298.791331] WARNING: CPU: 1 PID: 605 at kernel/dma/debug.c:1172 debug_dma_map_sg+0x304/0x390
> [ 298.799764] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
> drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> [ 298.824656] CPU: 1 PID: 605 Comm: cam-mplex.py Not tainted 5.13.0-rc4-00417-g3331992006e9 #3
> [ 298.833079] Hardware name: Texas Instruments K3 J721E SoC (DT)
> [ 298.838900] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> [ 298.844895] pc : debug_dma_map_sg+0x304/0x390
> [ 298.849245] lr : debug_dma_map_sg+0x304/0x390
> [ 298.853593] sp : ffff800014dcf730
> [ 298.856899] x29: ffff800014dcf730 x28: ffff00080154a880 x27: ffffffffffffffff
> [ 298.864032] x26: 0000000000000000 x25: 0000000000000002 x24: 0000000000000001
> [ 298.871164] x23: ffff80001163abe0 x22: 0000000000000000 x21: 0000000000000001
> [ 298.878295] x20: ffff000801fa3010 x19: ffff000807585300 x18: 0000000000000000
> [ 298.885426] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000030
> [ 298.892558] x14: 6e61687420726567 x13: 6e6f6c20746e656d x12: ffff800011a91578
> [ 298.899689] x11: 00000000000c0000 x10: ffff8000116b18f8 x9 : ffff8000100eabe0
> [ 298.906820] x8 : ffff8000116598f8 x7 : ffff8000116b18f8 x6 : 0000000000000001
> [ 298.913951] x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800011260000
> [ 298.921082] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080673b000
> [ 298.928214] Call trace:
> [ 298.930653] debug_dma_map_sg+0x304/0x390
> [ 298.934655] dma_map_sg_attrs+0x70/0xb0
> [ 298.938487] drm_gem_map_dma_buf+0x6c/0xf0 [drm]
> [ 298.943185] __map_dma_buf+0x28/0x80
> [ 298.946756] dma_buf_map_attachment+0xe4/0x220
> [ 298.951191] vb2_dc_map_dmabuf+0x3c/0x150
> [ 298.955194] __prepare_dmabuf+0x1dc/0x514
> [ 298.959197] __buf_prepare+0x1a0/0x25c
> [ 298.962938] vb2_core_qbuf+0x3d4/0x72c
> [ 298.966679] vb2_qbuf+0x9c/0xf4
> [ 298.969814] vb2_ioctl_qbuf+0x68/0x7c
> [ 298.973468] v4l_qbuf+0x54/0x70
> [ 298.976603] __video_do_ioctl+0x194/0x400
> [ 298.980603] video_usercopy+0x374/0xa14
> [ 298.984431] video_ioctl2+0x24/0x4c
> [ 298.987912] v4l2_ioctl+0x4c/0x70
> [ 298.991222] __arm64_sys_ioctl+0xb4/0xfc
> [ 298.995138] invoke_syscall+0x50/0x120
> [ 298.998885] el0_svc_common.constprop.0+0x68/0x104
> [ 299.003667] do_el0_svc+0x30/0x9c
> [ 299.006976] el0_svc+0x2c/0x54
> [ 299.010025] el0_sync_handler+0x1a8/0x1ac
> [ 299.014025] el0_sync+0x198/0x1c0
> [ 299.017333] irq event stamp: 98582
> [ 299.020727] hardirqs last enabled at (98581): [<ffff8000100ec2bc>] console_unlock+0x53c/0x6b4
> [ 299.029325] hardirqs last disabled at (98582): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> [ 299.037144] softirqs last enabled at (98568): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> [ 299.045565] softirqs last disabled at (98413): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
> [ 299.054164] ---[ end trace bfe019acb2a9a04f ]---
I don't get this warning. I remember you reported this last time as
well. I tried reproducing this but have not managed to do so. I have
CONFIG_DMA_API_DEBUG and CONFIG_DMA_API_DEBUG_SG enabled.
What application/command do you use to run into this? I use yavta and
don't see this.
>
> I get a warning from media graph walk:
I don't see this one either.
>
> [ 299.066357] WARNING: CPU: 1 PID: 605 at drivers/media/mc/mc-entity.c:343 media_graph_walk_next+0x268/0x2cc
Line 343 seems to be
lockdep_assert_held(&entity->graph_obj.mdev->graph_mutex);
I wonder why I don't hit this even with lockdep configs (CONFIG_LOCKDEP,
CONFIG_DEBUG_LOCKDEP).
> [ 299.076005] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
> drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> [ 299.100889] CPU: 1 PID: 605 Comm: cam-mplex.py Tainted: G W 5.13.0-rc4-00417-g3331992006e9 #3
> [ 299.110698] Hardware name: Texas Instruments K3 J721E SoC (DT)
> [ 299.116518] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> [ 299.122513] pc : media_graph_walk_next+0x268/0x2cc
> [ 299.127295] lr : media_graph_walk_next+0x264/0x2cc
> [ 299.132076] sp : ffff800014dcfa40
> [ 299.135382] x29: ffff800014dcfa40 x28: 0000000000000000 x27: 0000000040045612
> [ 299.142514] x26: 0000000000000001 x25: ffff800010d890f0 x24: ffff0008055c8148
> [ 299.149645] x23: ffff0008055c8148 x22: ffff80001182bc40 x21: ffff80001163e2e8
> [ 299.156776] x20: ffff80001182bbd0 x19: ffff0008055c8cb8 x18: 0000000000000000
> [ 299.163907] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000028
> [ 299.171037] x14: 0000000000000002 x13: 0000000000007e6f x12: 0000000000000002
> [ 299.178169] x11: 0000000000040464 x10: 00000000916d3a5c x9 : ffff8000093110c0
> [ 299.185301] x8 : ffff000807583d88 x7 : 0000000000000000 x6 : ffff00080673b900
> [ 299.192431] x5 : 000000000000000a x4 : ffff000807583d80 x3 : ffff800011260000
> [ 299.199562] x2 : 00000000000000c0 x1 : 00000000000000c0 x0 : 0000000000000000
> [ 299.206693] Call trace:
> [ 299.209133] media_graph_walk_next+0x268/0x2cc
> [ 299.213568] ti_csi2rx_start_streaming+0xe0/0x5c8 [j721e_csi2rx]
> [ 299.219569] vb2_start_streaming+0x70/0x160
> [ 299.223745] vb2_core_streamon+0x9c/0x1a0
> [ 299.227745] vb2_ioctl_streamon+0x68/0xbc
> [ 299.231747] v4l_streamon+0x30/0x40
> [ 299.235230] __video_do_ioctl+0x194/0x400
> [ 299.239230] video_usercopy+0x374/0xa14
> [ 299.243058] video_ioctl2+0x24/0x4c
> [ 299.246539] v4l2_ioctl+0x4c/0x70
> [ 299.249847] __arm64_sys_ioctl+0xb4/0xfc
> [ 299.253764] invoke_syscall+0x50/0x120
> [ 299.257508] el0_svc_common.constprop.0+0x68/0x104
> [ 299.262291] do_el0_svc+0x30/0x9c
> [ 299.265599] el0_svc+0x2c/0x54
> [ 299.268648] el0_sync_handler+0x1a8/0x1ac
> [ 299.272647] el0_sync+0x198/0x1c0
> [ 299.275956] irq event stamp: 98754
> [ 299.279349] hardirqs last enabled at (98753): [<ffff800010bf216c>] _raw_spin_unlock_irqrestore+0x9c/0xc0
> [ 299.288900] hardirqs last disabled at (98754): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> [ 299.296716] softirqs last enabled at (98606): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> [ 299.305138] softirqs last disabled at (98585): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
>
> Unloading the modules gives me:
I tested unloading and reloading modules and it worked fine for me.
Maybe this is dependent on the order in which modules are inserted or
removed? Can you please share the order in which you loaded and unloaded
them?
>
> ERROR: Unhandled External Abort received on 0x80000001 from S-EL1
> ERROR: exception reason=0 syndrome=0xbf000000
> Unhandled Exception from EL1
> x0 = 0x0000000000000000
> x1 = 0xffff00080564c000
> x2 = 0xffff800014314000
> x3 = 0xffff800011260000
> x4 = 0x0000000000000001
> x5 = 0x0000000000000001
> x6 = 0x0000000000000001
> x7 = 0x0000000000000000
> x8 = 0xffff8000118870c0
> x9 = 0xffff800010bf2140
> x10 = 0x000000008260a2b7
> x11 = 0x00000000000c821c
> x12 = 0xffff800011a91578
> x13 = 0x0000000000008b8e
> x14 = 0x0000000000000006
> x15 = 0x0000000000000028
> x16 = 0x0000000000000000
> x17 = 0x0000000000000000
> x18 = 0x00000000fffffffb
> x19 = 0xffff00080634cc00
> x20 = 0x0000000000000000
> x21 = 0xffff0008051eed00
> x22 = 0xffff00080555f010
> x23 = 0xffff00080555f000
> x24 = 0xffff8000092e0058
> x25 = 0x0000000000000047
> x26 = 0xffff8000116d71d8
> x27 = 0xffff8000092e0350
> x28 = 0xffff8000092e0148
> x29 = 0xffff800014d2f850
> x30 = 0xffff8000092b0430
> scr_el3 = 0x000000000000073d
> sctlr_el3 = 0x0000000030cd183f
> cptr_el3 = 0x0000000000000000
> tcr_el3 = 0x0000000080803520
> daif = 0x00000000000002c0
> mair_el3 = 0x00000000004404ff
> spsr_el3 = 0x0000000000000005
> elr_el3 = 0xffff8000092b0440
> ttbr0_el3 = 0x0000000070010b00
> esr_el3 = 0x00000000bf000000
> far_el3 = 0x0000000000000000
> spsr_el1 = 0x0000000060000005
> elr_el1 = 0xffff800010be5e10
> spsr_abt = 0x0000000000000000
> spsr_und = 0x0000000000000000
> spsr_irq = 0x0000000000000000
> spsr_fiq = 0x0000000000000000
> sctlr_el1 = 0x0000000034d4d91d
> actlr_el1 = 0x0000000000000000
> cpacr_el1 = 0x0000000000300000
> csselr_el1 = 0x0000000000000000
> sp_el1 = 0xffff800014d2f850
> esr_el1 = 0x0000000056000000
> ttbr0_el1 = 0x00000008826e4a00
> ttbr1_el1 = 0x076a000083180000
> mair_el1 = 0x000c0400bb44ffff
> amair_el1 = 0x0000000000000000
> tcr_el1 = 0x00000034f5d07590
> tpidr_el1 = 0xffff80086e790000
> tpidr_el0 = 0x0000ffff980d6920
> tpidrro_el0 = 0x0000000000000000
> par_el1 = 0x0000000000000000
> mpidr_el1 = 0x0000000080000001
> afsr0_el1 = 0x0000000000000000
> afsr1_el1 = 0x0000000000000000
> contextidr_el1 = 0x0000000000000000
> vbar_el1 = 0xffff800010011000
> cntp_ctl_el0 = 0x0000000000000005
> cntp_cval_el0 = 0x000000294b786efd
> cntv_ctl_el0 = 0x0000000000000000
> cntv_cval_el0 = 0x0000000000000000
> cntkctl_el1 = 0x00000000000000d6
> sp_el0 = 0x000000007000abd0
> isr_el1 = 0x0000000000000040
> dacr32_el2 = 0x0000000000000000
> ifsr32_el2 = 0x0000000000000000
> cpuectlr_el1 = 0x0000001b00000040
> cpumerrsr_el1 = 0x0000000000000000
> l2merrsr_el1 = 0x0000000000000000
>
> Tomi
>
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 00/11] CSI2RX support on J721E
2021-07-07 18:56 ` Pratyush Yadav
@ 2021-07-08 8:19 ` Jacopo Mondi
2021-07-08 8:43 ` Tomi Valkeinen
0 siblings, 1 reply; 26+ messages in thread
From: Jacopo Mondi @ 2021-07-08 8:19 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Tomi Valkeinen, Mauro Carvalho Chehab, Laurent Pinchart,
Vignesh Raghavendra, Nikhil Devshatwar, Alexandre Courbot,
Arnd Bergmann, Benoit Parrot, Bert Vermeulen, Dikshita Agarwal,
Dongchun Zhu, Eugen Hristev, Ezequiel Garcia, Fabio Estevam,
Georgi Djakov, Hans Verkuil, Helen Koike, Jacopo Mondi,
Jiapeng Chong, Kieran Bingham, Kieran Bingham, Lad Prabhakar,
Martina Krasteva, Maxime Ripard, Michael Tretter, Mirela Rabulea,
Neil Armstrong, Niklas Söderlund, Paul Kocialkowski,
Qiushi Wu, Raag Jadav, Ricardo Ribalda, Rob Herring,
Sakari Ailus, Stanimir Varbanov, Steve Longerbeam,
Thomas Bogendoerfer, Tianshu Qiu, Yang Yingliang, Zou Wei,
devicetree, linux-kernel, linux-media
Hi Tomi, Pratyush,
On Thu, Jul 08, 2021 at 12:26:38AM +0530, Pratyush Yadav wrote:
> Hi Tomi,
>
> Thanks for looking into the patches.
>
> On 01/07/21 10:56AM, Tomi Valkeinen wrote:
> > Hi Pratyush,
> >
> > On 24/06/2021 22:21, Pratyush Yadav wrote:
> > > Hi,
> > >
> > > This series adds support for CSI2 capture on J721E. It includes some
> > > fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
> > > driver, and finally adds the TI CSI2RX wrapper driver.
> > >
> > > This series used to include the DPHY and DMA engine patches as well, but
> > > they have been split off to facilitate easier merging. Patch 3 is
> > > build-dependent on the DPHY series [0].
> > >
> > > The DMA engine patch [1] can go in any order since that is only a run
> > > time dependency. Things probably won't work without it but it will still
> > > build fine.
> > >
> > > Tested on TI's J721E with OV5640 sensor.
> >
> > I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
>
> Please use https://github.com/prati0100/linux-next/ branch "capture"
>
> I will include the link in the cover letter from next version onwards.
>
> >
> > Here are some notes from quick tests:
> >
> > Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
>
> I see this as well. I figured this had something to do with the sensor.
Tomi you might remember your patch to change the h/vtot values which I
collected in a series which I never managed to bring to v1, as Hugues
reported it was broken for JPEG capture.
I'll leave it here just for reference, I admit I dropped the ball
rather quickly there:
https://patchwork.linuxtv.org/project/linux-media/cover/20201028225706.110078-1-jacopo+renesas@jmondi.org/
I wish I could re-test but seems I've lost the powering cable of the
device I used to test ov5640 :(
> Which clock could cause this? I don't think anything in Cadence CSI2RX
> bridge is sensitive to frame rate.
>
> >
> > When I load the modules, I get:
> >
> > [ 237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c
>
> Ok, I enabled lockdep configs and I see it too. Will look into it.
>
> >
> > I get a warning from DMA-API debug:
> >
> > [ 298.774236] ------------[ cut here ]------------
> > [ 298.779109] DMA-API: ti-udma 31150000.dma-controller: mapping sg segment longer than device claims to support [len=1900544] [max=65536]
> > [ 298.791331] WARNING: CPU: 1 PID: 605 at kernel/dma/debug.c:1172 debug_dma_map_sg+0x304/0x390
> > [ 298.799764] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
> > drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> > [ 298.824656] CPU: 1 PID: 605 Comm: cam-mplex.py Not tainted 5.13.0-rc4-00417-g3331992006e9 #3
> > [ 298.833079] Hardware name: Texas Instruments K3 J721E SoC (DT)
> > [ 298.838900] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> > [ 298.844895] pc : debug_dma_map_sg+0x304/0x390
> > [ 298.849245] lr : debug_dma_map_sg+0x304/0x390
> > [ 298.853593] sp : ffff800014dcf730
> > [ 298.856899] x29: ffff800014dcf730 x28: ffff00080154a880 x27: ffffffffffffffff
> > [ 298.864032] x26: 0000000000000000 x25: 0000000000000002 x24: 0000000000000001
> > [ 298.871164] x23: ffff80001163abe0 x22: 0000000000000000 x21: 0000000000000001
> > [ 298.878295] x20: ffff000801fa3010 x19: ffff000807585300 x18: 0000000000000000
> > [ 298.885426] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000030
> > [ 298.892558] x14: 6e61687420726567 x13: 6e6f6c20746e656d x12: ffff800011a91578
> > [ 298.899689] x11: 00000000000c0000 x10: ffff8000116b18f8 x9 : ffff8000100eabe0
> > [ 298.906820] x8 : ffff8000116598f8 x7 : ffff8000116b18f8 x6 : 0000000000000001
> > [ 298.913951] x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800011260000
> > [ 298.921082] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080673b000
> > [ 298.928214] Call trace:
> > [ 298.930653] debug_dma_map_sg+0x304/0x390
> > [ 298.934655] dma_map_sg_attrs+0x70/0xb0
> > [ 298.938487] drm_gem_map_dma_buf+0x6c/0xf0 [drm]
> > [ 298.943185] __map_dma_buf+0x28/0x80
> > [ 298.946756] dma_buf_map_attachment+0xe4/0x220
> > [ 298.951191] vb2_dc_map_dmabuf+0x3c/0x150
> > [ 298.955194] __prepare_dmabuf+0x1dc/0x514
> > [ 298.959197] __buf_prepare+0x1a0/0x25c
> > [ 298.962938] vb2_core_qbuf+0x3d4/0x72c
> > [ 298.966679] vb2_qbuf+0x9c/0xf4
> > [ 298.969814] vb2_ioctl_qbuf+0x68/0x7c
> > [ 298.973468] v4l_qbuf+0x54/0x70
> > [ 298.976603] __video_do_ioctl+0x194/0x400
> > [ 298.980603] video_usercopy+0x374/0xa14
> > [ 298.984431] video_ioctl2+0x24/0x4c
> > [ 298.987912] v4l2_ioctl+0x4c/0x70
> > [ 298.991222] __arm64_sys_ioctl+0xb4/0xfc
> > [ 298.995138] invoke_syscall+0x50/0x120
> > [ 298.998885] el0_svc_common.constprop.0+0x68/0x104
> > [ 299.003667] do_el0_svc+0x30/0x9c
> > [ 299.006976] el0_svc+0x2c/0x54
> > [ 299.010025] el0_sync_handler+0x1a8/0x1ac
> > [ 299.014025] el0_sync+0x198/0x1c0
> > [ 299.017333] irq event stamp: 98582
> > [ 299.020727] hardirqs last enabled at (98581): [<ffff8000100ec2bc>] console_unlock+0x53c/0x6b4
> > [ 299.029325] hardirqs last disabled at (98582): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> > [ 299.037144] softirqs last enabled at (98568): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> > [ 299.045565] softirqs last disabled at (98413): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
> > [ 299.054164] ---[ end trace bfe019acb2a9a04f ]---
>
> I don't get this warning. I remember you reported this last time as
> well. I tried reproducing this but have not managed to do so. I have
> CONFIG_DMA_API_DEBUG and CONFIG_DMA_API_DEBUG_SG enabled.
>
> What application/command do you use to run into this? I use yavta and
> don't see this.
>
> >
> > I get a warning from media graph walk:
>
> I don't see this one either.
>
> >
> > [ 299.066357] WARNING: CPU: 1 PID: 605 at drivers/media/mc/mc-entity.c:343 media_graph_walk_next+0x268/0x2cc
>
> Line 343 seems to be
>
> lockdep_assert_held(&entity->graph_obj.mdev->graph_mutex);
>
> I wonder why I don't hit this even with lockdep configs (CONFIG_LOCKDEP,
> CONFIG_DEBUG_LOCKDEP).
>
> > [ 299.076005] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
> > drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> > [ 299.100889] CPU: 1 PID: 605 Comm: cam-mplex.py Tainted: G W 5.13.0-rc4-00417-g3331992006e9 #3
> > [ 299.110698] Hardware name: Texas Instruments K3 J721E SoC (DT)
> > [ 299.116518] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> > [ 299.122513] pc : media_graph_walk_next+0x268/0x2cc
> > [ 299.127295] lr : media_graph_walk_next+0x264/0x2cc
> > [ 299.132076] sp : ffff800014dcfa40
> > [ 299.135382] x29: ffff800014dcfa40 x28: 0000000000000000 x27: 0000000040045612
> > [ 299.142514] x26: 0000000000000001 x25: ffff800010d890f0 x24: ffff0008055c8148
> > [ 299.149645] x23: ffff0008055c8148 x22: ffff80001182bc40 x21: ffff80001163e2e8
> > [ 299.156776] x20: ffff80001182bbd0 x19: ffff0008055c8cb8 x18: 0000000000000000
> > [ 299.163907] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000028
> > [ 299.171037] x14: 0000000000000002 x13: 0000000000007e6f x12: 0000000000000002
> > [ 299.178169] x11: 0000000000040464 x10: 00000000916d3a5c x9 : ffff8000093110c0
> > [ 299.185301] x8 : ffff000807583d88 x7 : 0000000000000000 x6 : ffff00080673b900
> > [ 299.192431] x5 : 000000000000000a x4 : ffff000807583d80 x3 : ffff800011260000
> > [ 299.199562] x2 : 00000000000000c0 x1 : 00000000000000c0 x0 : 0000000000000000
> > [ 299.206693] Call trace:
> > [ 299.209133] media_graph_walk_next+0x268/0x2cc
> > [ 299.213568] ti_csi2rx_start_streaming+0xe0/0x5c8 [j721e_csi2rx]
> > [ 299.219569] vb2_start_streaming+0x70/0x160
> > [ 299.223745] vb2_core_streamon+0x9c/0x1a0
> > [ 299.227745] vb2_ioctl_streamon+0x68/0xbc
> > [ 299.231747] v4l_streamon+0x30/0x40
> > [ 299.235230] __video_do_ioctl+0x194/0x400
> > [ 299.239230] video_usercopy+0x374/0xa14
> > [ 299.243058] video_ioctl2+0x24/0x4c
> > [ 299.246539] v4l2_ioctl+0x4c/0x70
> > [ 299.249847] __arm64_sys_ioctl+0xb4/0xfc
> > [ 299.253764] invoke_syscall+0x50/0x120
> > [ 299.257508] el0_svc_common.constprop.0+0x68/0x104
> > [ 299.262291] do_el0_svc+0x30/0x9c
> > [ 299.265599] el0_svc+0x2c/0x54
> > [ 299.268648] el0_sync_handler+0x1a8/0x1ac
> > [ 299.272647] el0_sync+0x198/0x1c0
> > [ 299.275956] irq event stamp: 98754
> > [ 299.279349] hardirqs last enabled at (98753): [<ffff800010bf216c>] _raw_spin_unlock_irqrestore+0x9c/0xc0
> > [ 299.288900] hardirqs last disabled at (98754): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> > [ 299.296716] softirqs last enabled at (98606): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> > [ 299.305138] softirqs last disabled at (98585): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
> >
> > Unloading the modules gives me:
>
> I tested unloading and reloading modules and it worked fine for me.
> Maybe this is dependent on the order in which modules are inserted or
> removed? Can you please share the order in which you loaded and unloaded
> them?
>
> >
> > ERROR: Unhandled External Abort received on 0x80000001 from S-EL1
> > ERROR: exception reason=0 syndrome=0xbf000000
> > Unhandled Exception from EL1
> > x0 = 0x0000000000000000
> > x1 = 0xffff00080564c000
> > x2 = 0xffff800014314000
> > x3 = 0xffff800011260000
> > x4 = 0x0000000000000001
> > x5 = 0x0000000000000001
> > x6 = 0x0000000000000001
> > x7 = 0x0000000000000000
> > x8 = 0xffff8000118870c0
> > x9 = 0xffff800010bf2140
> > x10 = 0x000000008260a2b7
> > x11 = 0x00000000000c821c
> > x12 = 0xffff800011a91578
> > x13 = 0x0000000000008b8e
> > x14 = 0x0000000000000006
> > x15 = 0x0000000000000028
> > x16 = 0x0000000000000000
> > x17 = 0x0000000000000000
> > x18 = 0x00000000fffffffb
> > x19 = 0xffff00080634cc00
> > x20 = 0x0000000000000000
> > x21 = 0xffff0008051eed00
> > x22 = 0xffff00080555f010
> > x23 = 0xffff00080555f000
> > x24 = 0xffff8000092e0058
> > x25 = 0x0000000000000047
> > x26 = 0xffff8000116d71d8
> > x27 = 0xffff8000092e0350
> > x28 = 0xffff8000092e0148
> > x29 = 0xffff800014d2f850
> > x30 = 0xffff8000092b0430
> > scr_el3 = 0x000000000000073d
> > sctlr_el3 = 0x0000000030cd183f
> > cptr_el3 = 0x0000000000000000
> > tcr_el3 = 0x0000000080803520
> > daif = 0x00000000000002c0
> > mair_el3 = 0x00000000004404ff
> > spsr_el3 = 0x0000000000000005
> > elr_el3 = 0xffff8000092b0440
> > ttbr0_el3 = 0x0000000070010b00
> > esr_el3 = 0x00000000bf000000
> > far_el3 = 0x0000000000000000
> > spsr_el1 = 0x0000000060000005
> > elr_el1 = 0xffff800010be5e10
> > spsr_abt = 0x0000000000000000
> > spsr_und = 0x0000000000000000
> > spsr_irq = 0x0000000000000000
> > spsr_fiq = 0x0000000000000000
> > sctlr_el1 = 0x0000000034d4d91d
> > actlr_el1 = 0x0000000000000000
> > cpacr_el1 = 0x0000000000300000
> > csselr_el1 = 0x0000000000000000
> > sp_el1 = 0xffff800014d2f850
> > esr_el1 = 0x0000000056000000
> > ttbr0_el1 = 0x00000008826e4a00
> > ttbr1_el1 = 0x076a000083180000
> > mair_el1 = 0x000c0400bb44ffff
> > amair_el1 = 0x0000000000000000
> > tcr_el1 = 0x00000034f5d07590
> > tpidr_el1 = 0xffff80086e790000
> > tpidr_el0 = 0x0000ffff980d6920
> > tpidrro_el0 = 0x0000000000000000
> > par_el1 = 0x0000000000000000
> > mpidr_el1 = 0x0000000080000001
> > afsr0_el1 = 0x0000000000000000
> > afsr1_el1 = 0x0000000000000000
> > contextidr_el1 = 0x0000000000000000
> > vbar_el1 = 0xffff800010011000
> > cntp_ctl_el0 = 0x0000000000000005
> > cntp_cval_el0 = 0x000000294b786efd
> > cntv_ctl_el0 = 0x0000000000000000
> > cntv_cval_el0 = 0x0000000000000000
> > cntkctl_el1 = 0x00000000000000d6
> > sp_el0 = 0x000000007000abd0
> > isr_el1 = 0x0000000000000040
> > dacr32_el2 = 0x0000000000000000
> > ifsr32_el2 = 0x0000000000000000
> > cpuectlr_el1 = 0x0000001b00000040
> > cpumerrsr_el1 = 0x0000000000000000
> > l2merrsr_el1 = 0x0000000000000000
> >
> > Tomi
> >
> >
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 00/11] CSI2RX support on J721E
2021-07-08 8:19 ` Jacopo Mondi
@ 2021-07-08 8:43 ` Tomi Valkeinen
2021-07-08 11:25 ` Pratyush Yadav
0 siblings, 1 reply; 26+ messages in thread
From: Tomi Valkeinen @ 2021-07-08 8:43 UTC (permalink / raw)
To: Jacopo Mondi, Pratyush Yadav
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Vignesh Raghavendra,
Nikhil Devshatwar, Alexandre Courbot, Arnd Bergmann,
Benoit Parrot, Bert Vermeulen, Dikshita Agarwal, Dongchun Zhu,
Eugen Hristev, Ezequiel Garcia, Fabio Estevam, Georgi Djakov,
Hans Verkuil, Helen Koike, Jacopo Mondi, Jiapeng Chong,
Kieran Bingham, Kieran Bingham, Lad Prabhakar, Martina Krasteva,
Maxime Ripard, Michael Tretter, Mirela Rabulea, Neil Armstrong,
Niklas Söderlund, Paul Kocialkowski, Qiushi Wu, Raag Jadav,
Ricardo Ribalda, Rob Herring, Sakari Ailus, Stanimir Varbanov,
Steve Longerbeam, Thomas Bogendoerfer, Tianshu Qiu,
Yang Yingliang, Zou Wei, devicetree, linux-kernel, linux-media
On 08/07/2021 11:19, Jacopo Mondi wrote:
> Hi Tomi, Pratyush,
>
> On Thu, Jul 08, 2021 at 12:26:38AM +0530, Pratyush Yadav wrote:
>> Hi Tomi,
>>
>> Thanks for looking into the patches.
>>
>> On 01/07/21 10:56AM, Tomi Valkeinen wrote:
>>> Hi Pratyush,
>>>
>>> On 24/06/2021 22:21, Pratyush Yadav wrote:
>>>> Hi,
>>>>
>>>> This series adds support for CSI2 capture on J721E. It includes some
>>>> fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
>>>> driver, and finally adds the TI CSI2RX wrapper driver.
>>>>
>>>> This series used to include the DPHY and DMA engine patches as well, but
>>>> they have been split off to facilitate easier merging. Patch 3 is
>>>> build-dependent on the DPHY series [0].
>>>>
>>>> The DMA engine patch [1] can go in any order since that is only a run
>>>> time dependency. Things probably won't work without it but it will still
>>>> build fine.
>>>>
>>>> Tested on TI's J721E with OV5640 sensor.
>>>
>>> I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
>>
>> Please use https://github.com/prati0100/linux-next/ branch "capture"
>>
>> I will include the link in the cover letter from next version onwards.
>>
>>>
>>> Here are some notes from quick tests:
>>>
>>> Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
>>
>> I see this as well. I figured this had something to do with the sensor.
>
> Tomi you might remember your patch to change the h/vtot values which I
> collected in a series which I never managed to bring to v1, as Hugues
> reported it was broken for JPEG capture.
>
> I'll leave it here just for reference, I admit I dropped the ball
> rather quickly there:
> https://patchwork.linuxtv.org/project/linux-media/cover/20201028225706.110078-1-jacopo+renesas@jmondi.org/
>
> I wish I could re-test but seems I've lost the powering cable of the
> device I used to test ov5640 :(
Yes, I'm still using my hack patch when working with OV5640. With that
hack, on TI platforms with CAL IP, I get ~30fps. With this series on J7,
I get the above mentioned 28.98.
It's possible my hack patch is wrong, and CAL driver is buggy, but
together they make things right. I guess I should also try J7 without my
hack patch.
If I recall right, I tested your changes but I couldn't get them to work
on my HW.
I haven't worked on that since then, as I decided that debugging blind
is pointless. We need someone to analyze the signals to see what OV5640
is sending. Or some new understanding about the OV5640 HW.
Tomi
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 00/11] CSI2RX support on J721E
2021-07-08 8:43 ` Tomi Valkeinen
@ 2021-07-08 11:25 ` Pratyush Yadav
0 siblings, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-07-08 11:25 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jacopo Mondi, Mauro Carvalho Chehab, Laurent Pinchart,
Vignesh Raghavendra, Nikhil Devshatwar, Alexandre Courbot,
Arnd Bergmann, Benoit Parrot, Bert Vermeulen, Dikshita Agarwal,
Dongchun Zhu, Eugen Hristev, Ezequiel Garcia, Fabio Estevam,
Georgi Djakov, Hans Verkuil, Helen Koike, Jacopo Mondi,
Jiapeng Chong, Kieran Bingham, Kieran Bingham, Lad Prabhakar,
Martina Krasteva, Maxime Ripard, Michael Tretter, Mirela Rabulea,
Neil Armstrong, Niklas Söderlund, Paul Kocialkowski,
Qiushi Wu, Raag Jadav, Ricardo Ribalda, Rob Herring,
Sakari Ailus, Stanimir Varbanov, Steve Longerbeam,
Thomas Bogendoerfer, Tianshu Qiu, Yang Yingliang, Zou Wei,
devicetree, linux-kernel, linux-media
On 08/07/21 11:43AM, Tomi Valkeinen wrote:
> On 08/07/2021 11:19, Jacopo Mondi wrote:
> > Hi Tomi, Pratyush,
> >
> > On Thu, Jul 08, 2021 at 12:26:38AM +0530, Pratyush Yadav wrote:
> > > Hi Tomi,
> > >
> > > Thanks for looking into the patches.
> > >
> > > On 01/07/21 10:56AM, Tomi Valkeinen wrote:
> > > > Hi Pratyush,
> > > >
> > > > On 24/06/2021 22:21, Pratyush Yadav wrote:
> > > > > Hi,
> > > > >
> > > > > This series adds support for CSI2 capture on J721E. It includes some
> > > > > fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
> > > > > driver, and finally adds the TI CSI2RX wrapper driver.
> > > > >
> > > > > This series used to include the DPHY and DMA engine patches as well, but
> > > > > they have been split off to facilitate easier merging. Patch 3 is
> > > > > build-dependent on the DPHY series [0].
> > > > >
> > > > > The DMA engine patch [1] can go in any order since that is only a run
> > > > > time dependency. Things probably won't work without it but it will still
> > > > > build fine.
> > > > >
> > > > > Tested on TI's J721E with OV5640 sensor.
> > > >
> > > > I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
> > >
> > > Please use https://github.com/prati0100/linux-next/ branch "capture"
> > >
> > > I will include the link in the cover letter from next version onwards.
> > >
> > > >
> > > > Here are some notes from quick tests:
> > > >
> > > > Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
> > >
> > > I see this as well. I figured this had something to do with the sensor.
> >
> > Tomi you might remember your patch to change the h/vtot values which I
> > collected in a series which I never managed to bring to v1, as Hugues
> > reported it was broken for JPEG capture.
> >
> > I'll leave it here just for reference, I admit I dropped the ball
> > rather quickly there:
> > https://patchwork.linuxtv.org/project/linux-media/cover/20201028225706.110078-1-jacopo+renesas@jmondi.org/
> >
> > I wish I could re-test but seems I've lost the powering cable of the
> > device I used to test ov5640 :(
>
> Yes, I'm still using my hack patch when working with OV5640. With that hack,
> on TI platforms with CAL IP, I get ~30fps. With this series on J7, I get the
> above mentioned 28.98.
>
> It's possible my hack patch is wrong, and CAL driver is buggy, but together
> they make things right. I guess I should also try J7 without my hack patch.
I think this is a OV5640 related issue. On IMX219 I am seeing exactly 30
fps.
>
> If I recall right, I tested your changes but I couldn't get them to work on
> my HW.
>
> I haven't worked on that since then, as I decided that debugging blind is
> pointless. We need someone to analyze the signals to see what OV5640 is
> sending. Or some new understanding about the OV5640 HW.
>
> Tomi
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 00/11] CSI2RX support on J721E
2021-07-01 7:56 ` [PATCH v3 00/11] CSI2RX support on J721E Tomi Valkeinen
2021-07-07 18:56 ` Pratyush Yadav
@ 2021-09-09 18:11 ` Pratyush Yadav
1 sibling, 0 replies; 26+ messages in thread
From: Pratyush Yadav @ 2021-09-09 18:11 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Vignesh Raghavendra,
Nikhil Devshatwar, Alexandre Courbot, Arnd Bergmann,
Benoit Parrot, Bert Vermeulen, Dikshita Agarwal, Dongchun Zhu,
Eugen Hristev, Ezequiel Garcia, Fabio Estevam, Georgi Djakov,
Hans Verkuil, Helen Koike, Jacopo Mondi, Jiapeng Chong,
Kieran Bingham, Kieran Bingham, Lad Prabhakar, Martina Krasteva,
Maxime Ripard, Michael Tretter, Mirela Rabulea, Neil Armstrong,
Niklas Söderlund, Paul Kocialkowski, Qiushi Wu, Raag Jadav,
Ricardo Ribalda, Rob Herring, Sakari Ailus, Stanimir Varbanov,
Steve Longerbeam, Thomas Bogendoerfer, Tianshu Qiu,
Yang Yingliang, Zou Wei, devicetree, linux-kernel, linux-media
Hi Tomi,
On 01/07/21 10:56AM, Tomi Valkeinen wrote:
> Hi Pratyush,
>
> On 24/06/2021 22:21, Pratyush Yadav wrote:
> > Hi,
> >
> > This series adds support for CSI2 capture on J721E. It includes some
> > fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
> > driver, and finally adds the TI CSI2RX wrapper driver.
> >
> > This series used to include the DPHY and DMA engine patches as well, but
> > they have been split off to facilitate easier merging. Patch 3 is
> > build-dependent on the DPHY series [0].
> >
> > The DMA engine patch [1] can go in any order since that is only a run
> > time dependency. Things probably won't work without it but it will still
> > build fine.
> >
> > Tested on TI's J721E with OV5640 sensor.
>
> I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
>
> Here are some notes from quick tests:
>
> Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
>
> When I load the modules, I get:
>
> [ 237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c
I see this with CAL's OV5640 overlay as well. I think this is caused by
the endpoint nodes on csi-bridge and sensor pointing to each other. I
can't quite understand any bad implications of this warning since
everything seems to work correctly.
Should we model the connections between the sensor and CSI bridge
differently to not cause a cycle in the graph? Or can we just ignore
this warning since things seem to work fine despite it?
>
> I get a warning from DMA-API debug:
>
> [ 298.774236] ------------[ cut here ]------------
> [ 298.779109] DMA-API: ti-udma 31150000.dma-controller: mapping sg segment longer than device claims to support [len=1900544] [max=65536]
> [ 298.791331] WARNING: CPU: 1 PID: 605 at kernel/dma/debug.c:1172 debug_dma_map_sg+0x304/0x390
> [ 298.799764] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
> drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> [ 298.824656] CPU: 1 PID: 605 Comm: cam-mplex.py Not tainted 5.13.0-rc4-00417-g3331992006e9 #3
> [ 298.833079] Hardware name: Texas Instruments K3 J721E SoC (DT)
> [ 298.838900] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> [ 298.844895] pc : debug_dma_map_sg+0x304/0x390
> [ 298.849245] lr : debug_dma_map_sg+0x304/0x390
> [ 298.853593] sp : ffff800014dcf730
> [ 298.856899] x29: ffff800014dcf730 x28: ffff00080154a880 x27: ffffffffffffffff
> [ 298.864032] x26: 0000000000000000 x25: 0000000000000002 x24: 0000000000000001
> [ 298.871164] x23: ffff80001163abe0 x22: 0000000000000000 x21: 0000000000000001
> [ 298.878295] x20: ffff000801fa3010 x19: ffff000807585300 x18: 0000000000000000
> [ 298.885426] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000030
> [ 298.892558] x14: 6e61687420726567 x13: 6e6f6c20746e656d x12: ffff800011a91578
> [ 298.899689] x11: 00000000000c0000 x10: ffff8000116b18f8 x9 : ffff8000100eabe0
> [ 298.906820] x8 : ffff8000116598f8 x7 : ffff8000116b18f8 x6 : 0000000000000001
> [ 298.913951] x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800011260000
> [ 298.921082] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080673b000
> [ 298.928214] Call trace:
> [ 298.930653] debug_dma_map_sg+0x304/0x390
> [ 298.934655] dma_map_sg_attrs+0x70/0xb0
> [ 298.938487] drm_gem_map_dma_buf+0x6c/0xf0 [drm]
I still can't reproduce this, and I think this might be why. I am saving
the stream to a file and then replaying on my PC. You seem to be sending
it to a display. The DMA warning looks to be coming from DRM side, not
CSI.
Anyway, I think this is not a big problem. The UDMA driver simply does
not populate max_segment_size, so dma_get_max_seg_size() returns 64 KiB
as default. The hardware can actually support virtually unlimited
segment size for TR mode and 2^27 bytes for packet mode. CSI uses TR
mode so it can certainly handle more than 64 KiB long segments. I am not
sure which mode DRM uses but 2^27 is still much bigger than 1900544.
Long story short, this warning has little to do with the CSI patches
here and can be safely ignored IMO.
> [ 298.943185] __map_dma_buf+0x28/0x80
> [ 298.946756] dma_buf_map_attachment+0xe4/0x220
> [ 298.951191] vb2_dc_map_dmabuf+0x3c/0x150
> [ 298.955194] __prepare_dmabuf+0x1dc/0x514
> [ 298.959197] __buf_prepare+0x1a0/0x25c
> [ 298.962938] vb2_core_qbuf+0x3d4/0x72c
> [ 298.966679] vb2_qbuf+0x9c/0xf4
> [ 298.969814] vb2_ioctl_qbuf+0x68/0x7c
> [ 298.973468] v4l_qbuf+0x54/0x70
> [ 298.976603] __video_do_ioctl+0x194/0x400
> [ 298.980603] video_usercopy+0x374/0xa14
> [ 298.984431] video_ioctl2+0x24/0x4c
> [ 298.987912] v4l2_ioctl+0x4c/0x70
> [ 298.991222] __arm64_sys_ioctl+0xb4/0xfc
> [ 298.995138] invoke_syscall+0x50/0x120
> [ 298.998885] el0_svc_common.constprop.0+0x68/0x104
> [ 299.003667] do_el0_svc+0x30/0x9c
> [ 299.006976] el0_svc+0x2c/0x54
> [ 299.010025] el0_sync_handler+0x1a8/0x1ac
> [ 299.014025] el0_sync+0x198/0x1c0
> [ 299.017333] irq event stamp: 98582
> [ 299.020727] hardirqs last enabled at (98581): [<ffff8000100ec2bc>] console_unlock+0x53c/0x6b4
> [ 299.029325] hardirqs last disabled at (98582): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> [ 299.037144] softirqs last enabled at (98568): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> [ 299.045565] softirqs last disabled at (98413): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
> [ 299.054164] ---[ end trace bfe019acb2a9a04f ]---
>
> I get a warning from media graph walk:
Fixed this one. It was caused by the graph_mutex not being held.
>
> [ 299.066357] WARNING: CPU: 1 PID: 605 at drivers/media/mc/mc-entity.c:343 media_graph_walk_next+0x268/0x2cc
> [ 299.076005] Modules linked in: ov5640 j721e_csi2rx cdns_csi2rx cdns_dphy v4l2_fwnode v4l2_async tidss ti_tfp410 tc358767 display_connector cdns_mhdp8546 panel_simple
> drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea phy_j721e_wiz phy_cadence_torrent
> [ 299.100889] CPU: 1 PID: 605 Comm: cam-mplex.py Tainted: G W 5.13.0-rc4-00417-g3331992006e9 #3
> [ 299.110698] Hardware name: Texas Instruments K3 J721E SoC (DT)
> [ 299.116518] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> [ 299.122513] pc : media_graph_walk_next+0x268/0x2cc
> [ 299.127295] lr : media_graph_walk_next+0x264/0x2cc
> [ 299.132076] sp : ffff800014dcfa40
> [ 299.135382] x29: ffff800014dcfa40 x28: 0000000000000000 x27: 0000000040045612
> [ 299.142514] x26: 0000000000000001 x25: ffff800010d890f0 x24: ffff0008055c8148
> [ 299.149645] x23: ffff0008055c8148 x22: ffff80001182bc40 x21: ffff80001163e2e8
> [ 299.156776] x20: ffff80001182bbd0 x19: ffff0008055c8cb8 x18: 0000000000000000
> [ 299.163907] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000028
> [ 299.171037] x14: 0000000000000002 x13: 0000000000007e6f x12: 0000000000000002
> [ 299.178169] x11: 0000000000040464 x10: 00000000916d3a5c x9 : ffff8000093110c0
> [ 299.185301] x8 : ffff000807583d88 x7 : 0000000000000000 x6 : ffff00080673b900
> [ 299.192431] x5 : 000000000000000a x4 : ffff000807583d80 x3 : ffff800011260000
> [ 299.199562] x2 : 00000000000000c0 x1 : 00000000000000c0 x0 : 0000000000000000
> [ 299.206693] Call trace:
> [ 299.209133] media_graph_walk_next+0x268/0x2cc
> [ 299.213568] ti_csi2rx_start_streaming+0xe0/0x5c8 [j721e_csi2rx]
> [ 299.219569] vb2_start_streaming+0x70/0x160
> [ 299.223745] vb2_core_streamon+0x9c/0x1a0
> [ 299.227745] vb2_ioctl_streamon+0x68/0xbc
> [ 299.231747] v4l_streamon+0x30/0x40
> [ 299.235230] __video_do_ioctl+0x194/0x400
> [ 299.239230] video_usercopy+0x374/0xa14
> [ 299.243058] video_ioctl2+0x24/0x4c
> [ 299.246539] v4l2_ioctl+0x4c/0x70
> [ 299.249847] __arm64_sys_ioctl+0xb4/0xfc
> [ 299.253764] invoke_syscall+0x50/0x120
> [ 299.257508] el0_svc_common.constprop.0+0x68/0x104
> [ 299.262291] do_el0_svc+0x30/0x9c
> [ 299.265599] el0_svc+0x2c/0x54
> [ 299.268648] el0_sync_handler+0x1a8/0x1ac
> [ 299.272647] el0_sync+0x198/0x1c0
> [ 299.275956] irq event stamp: 98754
> [ 299.279349] hardirqs last enabled at (98753): [<ffff800010bf216c>] _raw_spin_unlock_irqrestore+0x9c/0xc0
> [ 299.288900] hardirqs last disabled at (98754): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
> [ 299.296716] softirqs last enabled at (98606): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
> [ 299.305138] softirqs last disabled at (98585): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
>
> Unloading the modules gives me:
Fixed this too. Both cdns-csi2rx and j721e-csi2rx share the same power
domain, but only j721e-csi2rx contains the power-domains property. If
you load cdns-csi2rx before j721e-csi2rx then the PD is not active and
register access causes an abort. Fixed by adding power-domains to the
csi-bridge node.
>
> ERROR: Unhandled External Abort received on 0x80000001 from S-EL1
> ERROR: exception reason=0 syndrome=0xbf000000
> Unhandled Exception from EL1
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
^ permalink raw reply [flat|nested] 26+ messages in thread